I like to learn from everyone around me.  One of my most influential mentors has been my manager, Per.  Here’s a highlight of some of the lessons I learned from Per over the years:

Communication

• Consolidate communication.   Chunky over chatty.  Rather than a random stream of ideas, consolidate down to a theme.  Rather than a bunch of mini-mails, consolidate to a more meaningful message. 
• Distinguish between phases of communication.  Walt Disney used three stages for ideas: Dreamer, Realist, and Critic.  Dreamer is the vision, Realist is the steps, Critic is the constraints and limits.  In practice, Per encourages first brainstorm, then critique.

Cutting Questions

• Do you influence or do you own?   Distinguish between when you own the decision versus when you influence.  If you influence, but don’t own, reset your own expectations.  Responsibility without authority is a common pitfall. 
• Does it matter?   In the grand scheme of things, does this particular issue matter.
• Five customers under your belt?  If you don’t have five customers you can point to that stand behind what you’re doing, it’s a flag.  As simple as this test sounds, I’ve used it many times to ensure project success.
• Is it the right thing to do?  First figure out the right thing to do, then figure out what you can do based on the circumstances.
• Is it working?  If you keep taking the same approach, but it’s not working, you need to change your approach.  It’s simple, but you’d be surprised how many people get stuck.
• Next steps?   Asking “next steps?” at the end of your meeting is a pretty crisp way of turning talk into action.
  What’s the agreement?  When you’re not sure why things aren’t happening as you expect, check the agreement.  You might find you don’t really have one.
• What’s the solution?  If you’re spending too much time on the problem, switch by asking, “what’s the solution?”
• What’s their story?  If you don’t get why another person or team isn’t doing what you want, figure out what their side of the story is.  (see What’s Their Story)
  What’s your gut say?  If you find a decision isn’t sitting right, check your gut.   While the numbers may say one thing, your intuition may be telling you a deeper story.

Influence

• Argue the data.  Rather than argue your opinion, argue the data.  Arguing the data keeps it more objective.  It can also be more convincing.
• Don’t state the conclusion.  Rather than state your conclusions, show the data that leads to your conclusions.  Even if you know the “right answer,” showing the data can help others get on board.
• Lead the horse to water.   Let them connect the dots.  You can draw a dotted line, but let your audience connect the dots. 
  Mental Judo.  This is Per’s phrase for Ward Cunninham’s uncanny ability to lead people to a conclusion through rhetoric and stories.
• Set the frame.   Frame the problem or solution so that you have a common backdrop to share understanding.  This will help set boundaries, create agreements, and improve communication.
• They’re not engaged.  If you notice a lack of engagement throughout your meeting, there’s a good chance that you don’t have rapport.  If you don’t have rapport, you won’t effectively influence.
• They’re not on board.  You should be able to tell whether somebody is on board.  If they aren’t, then don’t kid yourself.
  You didn’t agree on values.  Recognize when you don’t have the same values.  Do they value time or do they value a level of results?  If you don’t share the values, you can expect problems in agreements, prioritization, expectations, and results.
• You didn’t have buy in.  Just because somebody shakes their head yes, doesn’t mean they are bought in.  You don’t want somebody to tell you yes, just to drag their feet.

Organizational Prowess

• Call it an experiment.  In a risk adverse environment, it can help to call a project an experiment.  It’s a simple but effective metaphor to help people think about trying something new.
• Do you influence or do you own?  If you don’t own the decision, you don’t own it.  Period.  You can attempt to influence, but at the end of the day, you’re not the owner.   That doesn’t mean don’t try your best.  Just don’t be surprised if it’s not the decision you wanted and don’t take it personally.
• Expose the approach.   People may not agree on the implementation or the results, but sharing the approach is a good place to start.  Exposing the approach gives you a chance to improve the approach.  Exposing the approach can also build trust, particularly if everybody buys in.
• Expose the thinking.  This is similar to showing your homework.  If you expose the thinking, then you can improve the thinking.  You can also help build trust.  You may not get to the right answer, but showing how you got there helps bring people along with you.
• Get consensus.  Where possible and time permits, get folks on board.  If there’s resistance, this can be a flag that you’re off in the wrong direction.  If it’s a decision where you need everybody’s skin in the game, then you’ll want them on board helping push the ball forward versus dragging their feet.
• Get smart folks on the bus.  This is just a general belief that if you have smart people around, the right things will happen.  It’s about people over process.
• Slides are a forcing function.    Slides are a great way to get folks on the same page, or at least start the dialogue.  If you can’t show your ideas in a slide, then you don’t have a well-formed message for others.  Doing slides helps create a strawman of the thoughts that can be reviewed and improved.  Slides can help turn thoughts into action.

Results

• Change your approach.  If it’s not working; change your approach.
• Change yourself first.  You can change yourself faster than you can change others.  Seriously.
• Chunk it down.   If you can’t release something in a healthy rhythm, chunk it down.
• Divide and Conquer.  If you have an overwhelming challenge, divide and conquer.(See Divide and Conquer - One Step at a Time)
• Drive or Be Driven.  If you don’t drive it, you’ll be driven by somebody else.
  Get it out and get feedback.  Good ideas often die because there’s no action or momentum.  If you get something out, you can get feedback and start to improve it.
• Give attribution.  In our industry, acknowledgement is important.  Be sure to give attribution where it’s due.
• Focus.   If there’s one place where projects fail or people fail, it’s a lack of focus.  Focus is your friend.  If you’re not getting results, narrow the focus. 
• Follow your passion.  Where there’s passion, there’s strength.
• Forcing functions.  Use meetings, slides, and reviews as forcing functions to drive results.
• Model the best.   This is Per’s phrase for my approach of finding the best people and modeling their success. 
• Play to your strengths.  Per’s a fan of the book, Good to Great, and he believes in focusing on your strengths rather than your weaknesses.
• Rattle the cage.  Challenge the thinking.  Challenge ideas.  Challenge yourself.  Don’t fall into the trap of the status quo.
• Ship it!  This is one of Per’s favorite sayings which characterizes the emphasis on getting results and making impact.   He’s learned that a rhythm of shipping produces results while failure to ship is how teams fail at Microsoft. 

My Related Posts

• Forcing Functions
• Cutting Questions
• What's Their Story
• The Zen of Results
• Patterns and Practices for New Hires
• Rituals for Results
• Solution-Focused Questions
• 7 Habits of Highly Effective PMs

Here's a brief set of success patterns I've shared with a few colleagues.  These are the patterns I see that make a difference in getting results.

10 Success Patterns

1. Empathic listening.
2. Rapport before influence
3. Character trumps emotion trumps logic
4. Match their style
5. Ask WIIFY
6. Distinguish between responsibility and authority
7. Turn chickens into pigs
8. Adapt, adjust, or avoid situations
9. Know the system.
10. Analyze it over time.

Success Patterns Explained
Here's the essence of each:

• Empathic listening.  Listen until the other person "feels" they've been heard.  Once they feel heard, they're more likely to listen to you.  You can do this 1:1 or in a large meeting.  Covey uses an "Indian Talking Stick."  The person with the stick talks until they feel heard.  A former Softie told me his team used an eraser as "the mutex."   See Stephen Covey Speaks at Microsoft.
• Rapport before influence.  This is true whether it’s a presentation, interview … etc.. For example, go to a comedy club and see how the comedian gets the crowd laughing only  after they have rapport.  See How Might That Be True?
• Character trumps emotion trumps logic.  If you base all your arguments on logic, but fail to persuade, now you know.  See Win the Heart, the Mind Follows.
• Match their style.  You don't have to go overboard, but a little bridge can go along way.  If somebody is visual, could you whiteboard it for them?  If somebody's detail oriented, can you provide the details?  If somebody needs to hear action, can you turn your ideas into action?
• Ask WIIFY.  Ask the question What's In It For You?  If you're a marketer, this might come natural for you.  If you're an engineer, this might feel weird.  It's about shifting the focus from the thing to the person. If nobody shows up to your meetings, tailor the invite to be explicit about what's in it for the attendees.
• Distinguish between responsibility and authority.  Know whether you influence a decision or own it.  When you don't have authority, but you need to get results, leverage the model in Influencing Without Authority.
• Turn chickens into pigs.  A pig's committed while a chicken's involved.  Don't let a chicken have a controlling vote, without turning them into a pig.  See Turning Chickens into Pigs.
• Adapt, adjust, or avoid situations.  Learn how to read situations. Some situations you should just avoid.  Some situations you should adapt yourself, as long as you play to your strengths.  Some situations you should adjust the situation to set yourself up for success.
• Know the system.   Analyze the problem from a system standpoint.  What are the components and subsystems?  What are the inputs and outputs?  Who are the players?   What levers can you pull that make the most impact?  If you don't know, who does?
• Analyze it over time.  Look at the problem or solution over time. Build your temporal skills.  The more you play "what ifs" in the future, the easier it gets to anticipate.

Do you have any favorite success patterns to share?

My Related Posts

• 7 Habits of Highly Effective Program Managers
• Patterns and Practices for New Hires

When people ask me my take on model-driven approaches, I think of two ends of the spectrum -- human and the machine.

Key Points 

• Model for humans.  For humans, I find using a whiteboard (whiteboard modeling) works well -- it's universal.
• Model for machines.  For machines, I find speaking closer to the code is a good thing and design is rarely a clean model.
• Model to learn.  I've found modeling more useful when you throw it away -- it's a learning tool.  Model so you get it, then go to it.  I think the key is that the model is a map, not the actual territory.  The usefulness of a map is actually decoupling from the complexity and creating a simpler lens.
• Model to share.  I think the real value of models is when you create a way to share the problem or solution in a simplified way.  This helps for sharing a vision of the end in mind, as well as getting more sustained thinking around the problem.

Model-Driven Code
I've never experienced an effective modeling approach that turns visuals of systems into code, where the model doesn't get in the way.  At some point, the model stops being useful for humans or stops being useful to the machine.  As a result, I've never really been a fan of model-driven approaches that are coupled to code in practice, although they're always interesting in theory.   While I'm open to the idea, I just haven't seen it.  Am I missing out?

Effective Modeling for Shaping Software
While I'm not a fan of most visual modeling tools, there’s some very real modeling approaches I find to be effective (which is more about modeling for the humans to understand what matters.)  I find that light-weight, human-oriented models are particularly effective for shaping software around quality attributes.  For example:

• Performance.  For performance design, I've found Performance Modeling to be effective.  See patterns & practices Performance Modeling
• Security.  For security design, I've found Threat Modeling to be effective.  See patterns & practices Threat Modeling
• Reliability.  For reliability design, I've found Fault-tree modeling to be effective.

My Related Posts

• What Makes a Good Threat Model
• How I Explain Threat Modeling to Customers

Have you seen Peaceful Warrior?  It's a pretty simple movie, but it's full of lessons.  Probably the most important lesson is how to keep getting back up when life knocks you down and how to continue to follow your dreams, even after your world is shattered.   I shared my lessons learned from Peaceful Warrior with some colleagues and they suggested I post them.  Here it goes ...

Where Are You, What Time is It, What Are You
This theme echoed throughout the movie:

• Where are you? .... HERE.
• What time is it? ... NOW.
• What are you? ... THIS MOMENT.

Favorite Lessons

• There are no ordinary moments
• A Warrior acts; only a fool reacts.
• What do you do if you can’t do what you were born to do?  Everything has a purpose -- it’s up to you to find it.
• Make every move about the move -- that one moment in time.
• Don't fall into the trap -- If only I had this, I'd be ...  If only ... , I'd get to be happy. 
• If you don't get what you want, you suffer.  If you get what you want, you still suffer.
• You control you.  Master you.
• Don't pin your success on outcomes.
• The people that are the hardest to love, probably need it the most.
• Take out the trash.  Clear you mind of everything you don't need (doubt, past failures, future victories, ... etc.)
• Develop the wisdom to use the right leverage at the right time.
• Knowledge is not the same as wisdom.  Knowledge is knowing -- wisdom is doing.
• You'll never be better than anybody, the same way you'll never be any less.

Additional Lessons Learned 
Here’s my lessons from peaceful warrior:

• Experience the moment.  Be fully engaged in the moment.
• Limiting beliefs.  Don't become a victim of your own limiting beliefs.  Stay adaptable.
• Don't miss out on what's going on by letting your mind fill up with noise.
• Trash is anything that keeps you from the only thing that matters which is right here and now.
• Be right here, right now.  Don't be in the past, gloating.  Be in the present living.
• All you have is right now.
• Let got of attachments.
• Meditate.  Be able to clear you mind and focus on the moment.
• Don't let your emotions control you.
• Enjoy the here and now -- that's the secret.
• Savor the moment.
• Other people's perspectives don't matter as much if you have your own perspective.
• Find your purpose.
• Assign meaning.  You're the most important meaning maker in your life.
• There's never nothing going on (take a look around.)
• Don't give up the one thing you control -- your response.
• The habit is the problem.  Wake up and experience the moment.
• Be conscious of your choices.
• Be responsible for your actions.
• Every action has its price and it's pleasure.
• Most people don't live at all.
• When you feel fear, use this sword.
• Don't take for granted what you can do; don't be sloppy with your life.
• Devote life to a higher purpose; service to others.
• The warrior doesn't give up what they love.
• The warrior finds the love in what they do.
• The warrior is not about invincibility.
• The warrior chooses to act; the coward reacts.
• Life is about 20 seconds in front of the judges.
• A warrior does what they love.  A warrior does the thing they are put here to do.
• Don't live in fear of failure
• It's the journey, not the destination.
• Warrior is not about perfection.  Warrior is about absolute vulnerability.
• Life is about choice.
• Actions speak for themselves.

Periodically I like to revisit our project life cycle in patterns & practices. I like to see how it's shape-shifted over the years.  (Note - our project life cycle wraps our product cycle)  

patterns & practices Project Life Cycle Circa 2005
Here's a snapshot of our patterns & practices project life cycle circa 2005:

I used this as a baseline to reflect against.  Here are the phases, stages, and milestones:

Phases
Projects cycled through the following phases:

• Planning
• Design
• Implementation
• Stabilization
• Release

Stages
Stages included:

• Requirements
• Specifications
• Iteration 1
• Iteration N
• Final Test and Edit Pass
• Production

Milestones
The milestones included:

• Proposal Approved
• Vision Scope Approved
• M0 (Milestone Zero) / Specifications Approved
• Technical Review and Solution Approved
• Test and Edit Complete
• Go / No Go
• Customer Availability

Three Things That Worked Well
Here's three things that worked well with the original project cycle:

• There were clear phases, stages, milestones, and deliverables, along with criteria.
• The project cycle was decoupled from the product cycle.  This gave management a simple frame for understanding projects.  This also gave each project flexibility to choose the most appropriate software development methodology depending on the product.
• There was sufficient time between key milestones to provide a frame + air-cover.  This helped avoid randomizing engineering and being able to see the forest from the trees.

Additionally, the key milestones such as Vision Scope and MO were something of a ceremony and tended to include the right representation across the p&p team.

Three Things That Needed Improvement
Here's three things that needed improvement:

• It was a lot of overhead for smaller projects.  It worked well for larger programs (collections of projects), but it was tougher for individual projects.
• It was tough to bootstrap projects.  M0 and Vision/Scope could be especially tough.  In retrospect, there were two key issues: 1) asking the right questions at the wrong time (premature) 2) chickens with controlling votes over pigs. (See Turning Chickens Into Pigs.)
• There was too much agreement up front, with not enough ability to coarse correct in the later stages/phases (needed more agility)

I like to draw from a variety of sources for software engineering principles, patterns, and practices.  To be able to do this, I usually need to create information models that let me quickly scan bodies of knowledge.  Once I can frame out a space, it's a lot easier to drill into areas looking for gold.  I can also step back and see across approaches and this helps me see underlying principles or key distinctions between approaches.

XP, MSF Agile, RUP, and Microsoft Solution Framework
To compare process methodologies, here are some skeletal information models I've used:

• Extreme Programming (XP) at a Glance
• MSF Agile at a Glance
• Rational Unified Process (RUP) at a Glance
• Microsoft Solution Framework (MSF) at a Glance

While the frames aren't entirely consistent, I can still quickly scan the methodologies and get a good sense of what the key ideas, activities, artifacts, and practices are.

My Related Posts

• MSF Agile Frame (Workstreams and Activities)