Lessons Learned in patterns & practices

I’ve been a part of the Microsoft patterns & practices team for several years.  I’ve shipped a lot of things and learned a lot of stuff.  Here’s a distillation of some of my key lessons learned.  I’m leaving myself room so that I can expand or elaborate on some of the points downstream.

Top Ten Lessons
Here’s my favorite lessons at a glance:

• Win the heart, the mind follows.
• Know the tests for success.
• Fix time, flex scope.
• Use the system to educate.
• Work with the right people, on the right problems, making the right impact.
• Have the right people in the room asking the right questions.
• Sell the vision.
• Make it a project.
• Know what you’re optimizing.
• Turn chickens into pigs.

Here’s a more exhaustive list of my lessons with relevant notes, grouped by key areas.

Organization
Here’s some of the organizational lessons I’ve learned:

• Work with the right people, on the right problems, making the right impact.  It’s a simple recipe for success.
• Know the mission, vision, and guiding principles.  This drives people and is a foundation for the culture.
• Test your organizational clarity.  How well do you know the following: vision / mission, customers, problems, business case, measures of success, catalog / product line, and rhythm of results.  Put it another way: What’s the one-liner vision and mission?, Who’s your customer?, What domains or problems do you focus on? What’s the internal and external business case?   What’s the measures of success?  What’s the product line / deliverables / results?  What’s the product cycle or rhythm of results?
• Organize by programs / themes.  Chunking up the work you do into programs and themes has a few key benefits.  For example, it makes it easier to consolidate resources around a common theme.  It also helps, build momentum on a particular problem.  , It also make it easier to talk about and share the focus and goals inside and outside the group.
• Use a portfolio planning process.   Have an agreed upon approach for triaging the focus and priorities.  Everybody should know how projects get proposed, prioritized and executed.
• Have a dashboard of results.  You need a scoreboard so that people feel the fruits of their efforts and can do more of what’s working and less of what’s not.
• Have a frame for impact.  This helps turn the values into action and helps people prioritize their efforts.  For example, we framed our product impact, where 3.0 was expected, but 4.5 was above and beyond:  1) 3.0 – Change existing platform.  Features.  Improve customer experience on current product / platform.  Influence today’s product capabilities. 2) 3.5 – Change product goals.  Scenarios. Change product/platform goals to better fit existing and emerging customer application scenarios, architecture, and use cases.  Influence planning.  3) 4.0 – Change the market.  Innotvation.  Expose new market opportunities, validate and fit within Microsoft strategy.  4) 4.5 – Change the approach.  Approach.  Change platform architecture and product development culture, processes and practices to be more transparent and responsive to customers.  Influence the company.
• Focus on the vital few.  Do a few high-valued things over a lot of things that have less perceived value.
• Have a baseline process for each product line.  We The common baseline process gives you a common view of the, velocity, and plans of each of the projects and project teams.   Teams can tailor to the unique scope and needs of an individual project, but at least they aren’t starting from scratch.

Leadership / Influence
I think of leadership as influence.  I also think of two kinds of leadership: thought-leadership and people-leadership.  Here’s my leadership lessons learned:

• Frame and name the space.  If you frame it and name it, you have authority.  Building the language and map that people use demonstrates thought leadership and paving a path for others.
• Win the heart, the mind follows.   If you win the mind, the heart won’t necessarily follow, but if you win the heart, the mind follows.  This is important when you have a great case based on logic, but there’s no emotional connection.
• Maximize your strength quotient.  Build teams and surround yourself with people that supplement your strengths.  Think in terms of marketing, execution, business, technical, and quality.  The key here is to have self-awareness.  The more you know about your strengths and weaknesses, the better you can bring on the right strengths.
• Distinguish between what you own and influence.  If you own a decision great.  When you influence a decision, you have to remember you don’t have the final say.  At best, you weight in with your perspective and evidence to help influence for the right decision.  This is about having the right mindset so you can pace yourself and set your own expectorations.
• Get incremental buy in.  For some people, buy in takes time as well as repeated exposure.
• Use the system to educate.  Don’t argue your opinion.  Argue the customer data.  You can use customer feedback as external pressure on the internal system.  Social proof is another important factor.
• Involve the right people.   People will care who was involved.  You can’t claim victory in a space if the right people don’t stand behind it.
• Get their fingerprints on it.  People are more likely to stand behind something if they’re a part of it.
• Influence the right people in the right sequence.  Who you influence and in what sequence matters.  If you get the right people on board, it’s like a domino effect.
• Have a metaphor and tagline.  The fastest way to help folks latch on to an idea is a simple metaphor they get.  A tagline helps too.
• Have an elevator pitch.    Ideas are stickier if you have a simple way to share them.   It’s even better if other people can easily share your idea.  A simple elevator pitch helps.
• Have the right people in the room asking the right questions.   Again this is about social proof, but it’s powerful. 
• Use scenario evaluations for product design and feedback.     You can step through a scenario.  You can also measure effectiveness against a scenario.  You can’t evaluate a solution in a vacuum, but you can measure it against a scenario and context.

Projects
Projects have a start and finish.   They produce a result.  Ideally, the result is significant.  Here’s my lessons learned from driving projects:

• Make it a project.  If you want to make meaningful progress on a problem, make it a project.  It’s how things get done.
• Fix time, flex scope.  Value time.  Choose quality over scope.
• Sell the vision.  It’s the vision that will get people to support you.  if people aren’t on board with the vision, then the project execution details won’t matter.  If folks buy into the vision, you’ll get more support on the execution plans.
• Know the business case.   The business case should answer how big is the pie and what slice is yours.  You should be able to show the ROi on the investment.  You should be able to chunk it down, in the case you can’t get all the budget, time or resources you ask for, which is often the case.
• Know the tests for success.   You need to know what good looks like.  You don’t want to finish a project only to have people tell you that you missed the mark.  The stakeholders should weight in on the tests for success, since they’ll be the ones grading you in the end.
• Frame the problem space.   Map out the problem space.  If you create a shared frame, you can expose the thinking and have an organized dialogue around trade-offs and prioritization.
• Deliver incremental value.  Find a way to flow value.  Chunk it down.  Flowing value builds credibility that you can ship and that you’re valuable to the business.  The longer you wait to show results, the tougher life gets for you.
• Know the work to be done.   This is where you your frame or map comes in handy.  the best tool is a work breakdown structure (WBS).  The more you know about the nature of the work, the better you can get the right people for the job.  You can also make better predictions about time.  Using a work breakdown structure also provides a map and a way to share lessons learned.
• Know what the project constraints are capable of. Stretch the budget, time and team you have in hand, not the one you don’t .  You need to be able to bring the team back alive.  Put a premium on your work / life balance.  It should be a thriving experience, not a surviving experience or a death march.
• Know what you’re optimizing.  This is such a fundamental question.  It has an enormous impact on your product design and how you structure your product life cycle.   For example, are you optimizing time? … money? … impact? … innovation? … resource utilization? If you don’t answer this question first, it’s very easy to pick the wrong hammer for your screws.  A few things I use to help me figure out what to optimize are I figure out my objectives, I figure out my constraints, and I look for my possible high ROI paths.  I always want more out of what I do.  The trick is to know when doing more, gets you less.  Your objectives keep you grounded along the way.  What I like about this question is it universally applies to any activity you do, including how you design your day.  Are you optimizing around results, or connecting with people? Are you optimizing for enjoyment along the way or for reward in the end?
• Factor project cycles from product cycles.  The project cycle as project management and product cycle as engineering.  Your project cycle is your interface between the project team and management.  The product cycle is how you build stuff.  You might need a less iterative project cycle, but a more iterative and incremental product cycle.  Factoring the project cycle from the product cycle helps create the right buffers and interfaces.  It also helps you norm the project cycles across a group while the product cycles may vary based on the type of product.  You can also choose the right product cycle for the job.
• Turn chickens into pigs.   This is about having skin in the game.  The worst scenario is to have chickens with controlling votes.  Chickens are involved, but not committed to the success.  Pigs are committed and have skin in the game.  if somebody has a controlling vote, they should be committed to the success.
• Create a frame plus air-cover.  Use checkpoints to update stakeholders.  A checkpoint frame I’ve used is: 1.) what are we checking – what’s success look like? 2)  where we we / what happened? 3) what are we doing next?
• Reduce friction.  Find the key bottlenecks in your process and work on those.   The more you reduce friction in the process, the more you have a sustainable process that can grow and adapt.
• Have 5 customers that stand behind you.  
• Have the right people working on the right things.    This is the key to project success.  If you don’t have the right people, that’s the worst scenario.  If you have the right people, make sure they’re working on the areas where they play to their strengths and deliver the most value.
• Have a core team of generalists and supplement with specialists.    You need a core team you trust for execution.  This is the team you count on for showing up every day and executing.  You know you have the right core team when you can run towards the problem versus away.   The core team should be flexible in their skill set.  Supplement the core team with specialists with expertise in key areas as you need it.
• Keep the team in synch.  The vision is the common mental model for the end in mind.  The test is that everybody can draw the vision.  The key practices to keep the team in synch include iteration meetings, daily standups, and show and tells / demos.  Pairing is another good way to help share and spread knowledge on the team.

Engineering
Engineering is about building and constructing the deliverables.  Here’s my lessons learned:

• Customer-connected engineering.  Involve customers throughout the project.  They’re you’re best test-bed for real-world feedback.  Keep a close set that will run alongside you.  Make sure you have coverage that reflects your various types of customers and segments.  What you don’t want to do is release your product at the end of your project to find out nobody wants it.
• Think in terms of user, business, and technical trade-offs.  Just about every significant engineering decision will be a trade-off among these perspectives.
• Optimize around the user experience.  If your users don’t like to use what you built, no matter how clever you addressed the technical side or the business side, it won’t matter.
• Think in terms of product lines.  Product lines help you optimize the right engineering approach based on what you’re building.
• Use persona-based scenarios with goals.  
• Ship it.  It’s more important to get it out and get feedback, than try to perfect it up front.
• Ship scenarios over features.  Scenarios are a good forcing function.  They put the features in the context of a goal.  When you ship scenarios, you enable users to meet their goals.  This is the secret to snowballing your success, a scenario a time.
• Pair up.  Pairing is like a student-driver model.  It’s the fastest way to exchange knowledge on the team.  It also helps keep people going when they might otherwise get stuck on their own.
• Build to change over build to last.   The only constant is change.  If you design for change, you can evolve as you need to downstream.   Think of this as trying not to paint yourself into a corner.
• Expect to refactor your design.  Nothing beats 20/20 hindsight.  The more you build, the more you learn.   if your design is getting in the way more than it’s helping, at some point, you have to refactor it.  If you expect it, it’s less painful.  This is also where designing for change comes into play.
• Involve test early.  It’s easier to get test on board early where they can follow along and gel with the team.  They can also help identify the tests for success and acceptance criteria, along with the customers.

Innovation
Innovation is the key to keeping a business relevant and healthy.  You can innovate in terms of your operations or product.   Here’s my lessons learned:

• Invest in innovation.   The business and the context aren’t static.  Investing in innovation is the way to keep your business in the game.
• Some of the best innovations are in operations.  If you innovate in operations, you improve your ability to execute.  If you improve your ability to execute, you improve your chances of delivering value.  It’s a numbers game.
• Think in terms of problem, strategy or implementation.  You can differentiate in terms of the problem you work on, the strategy you use, or the implementation.  This is important when you need to compete.
• Think in terms of user experience, tech feasibility, and business case.  This can help you prioritize where to focus.  It’s easy to churn a lot of your R&D proving technical feasibility or the business case, only to find out that you haven’t figured out the user experience and nobody wants your innovation.
• Have hypotheses, assumption and tests.  You need to know what you’re testing against.  This doesn’t discount exploratory innovation, but you should at least recognize when you’re learning important insights.  If you have a frame, you’ll be more aware of what you learn and you’ll have a frame for sharing your learnings.
• Know if the market’s ready.  Sometimes the market’s not ready.   This doesn’t mean it’s a bad idea, just wrong timing.   You may want to rehydrate it and invest more downstream.
• Distinguish between concept and implementation.  Don’t throw out the baby with the bathwater.  Many good ideas have been tainted by bad implementation.   Carry the good ideas forward.
• Carry forward lessons learned.   If you spend time on innovation, you’ll learn something.  You’ll probably make a lot of mistakes too.  Share the lessons.
• Carry forward the user experiences.  There’s multiple ways to turn innovation into results.  It’s not about bringing to market the exact innovation from your incubation or R&D efforts.  For example, you may have figured out valuable user experiences that you leverage in other places.  You can leave the implementation behind, but carry the user experiences forward.
• Change the frame, change the game.   How you frame the problem can have a lot to do with how you go about solving it.  This ties back to how you choose to differentiate – the problem, the strategy, or the implementation.   Changing the frame can devalue one thing or inflate the value of another.