Saturday, September 26, 2009

Problem Solving Tool - Step 7: Git’er Done [Matt Schlegel]

Finally, finally, FINALLY! – finally, we are at the step in the process where we actually DO something. We have been talking, talking, talking – all we have done is talk in circles. Now, we finally get to the DOING. It is hard to believe that we have spent so much time thinking and talking. What a waste of time! Let’s get down to the business of solving the problem. Let’s git’er done.

Know anyone who might say that?

Well, they are correct. To this point I have described 6 steps, none of which have actually solved the problem. Furthermore, to describe those steps, I have written 9 blogs. In all that, we really haven’t “done” a thing to solve the problem itself. Can you imagine the time and patience a team would have to go through to get to this point without actually jumping in to solve the problem? It is very tough to imagine for the git’er-done person who spoke in the first paragraph. Well, what have we accomplished? This is a good time to summarize:

1. We have described the problem and established goals
2. We have built a team and defined the roles and responsibilities of its members
3. We have generated a rich set of creative ideas from which to draw
4. We have analyzed those ideas and uncovered the costs and benefits of each
5. We have built a plan around the best set of ideas that will meet the goals, solve the problem
6. And, we have obtained permission to execute that plan

So, yes, while that has been mostly talking, the team has laid the foundation upon which to successfully implement a solution to the problem, and that foundation has buy-in from the stakeholders who have committed the resources necessary to accomplish the goals.

Start Small

Practically speaking, the implementation step often takes the most time. In fact, depending on the goals the team has set out to accomplish, this phase could take more time than the first six steps combined. During this implementation phase, I have found that starting small and building on successes is a great recipe to keep up the momentum. For instance, when implementing solutions that will affect a company’s product development process, I advise the team to pick just one project and prototype the solution with only that one product development team. Working with that one team, you can learn what works and what doesn’t. You can develop the materials you will need to communicate the solutions to other teams. And you can demonstrate the positive effects that the solutions have on the product development outcome. All of this makes it just that much easier for each successive product development team to adopt the solution. After a while, all the teams are using the proposed solution, mitigating the problem and accomplishing the goal.

Git’er done

And, if you know someone who might say what I wrote in the first paragraph, they may be a good candidate to take the lead during this phase of the problem-solving process. This phase is about action and the ideal person is an action-oriented leader, perhaps a team stakeholder with a program management background, who will drive the implementation and not be afraid to ruffle a few feathers along the way if that is what it takes. And, whenever you try to accomplish something big and important, feathers will be ruffled. I will address this issue in the next blog.

Matt Schlegel has a bias toward actions and has been reminded, on occasion, that he is a human “being” not a human “doing.”


Sunday, September 6, 2009

Problem Solving Tool - Step 6: Tapping your Inner Medieval Salesperson [Matt Schlegel]

After a much too brief summer break, I pick up where I left off. In the last blog I wrote about Step 5, creating a plan to solve your team’s big problem. This step I affectionately referred to as “The Path of Least Danger.” Now that your team has constructed the path, it is time to start the journey down that path, right? Well, not quite yet. Your core, problem-solving team may be revved up and ready to charge down that path, but the wider group of stakeholders may not be there, yet. At this point, it is time to bring the wider group of stakeholders, including the executive sponsors, up to that same level of enthusiasm. It is time to sell your plan.

Folks in sales will understand this phase of the problem-solving process very well. When facilitating problem-solving groups at this phase, I recommend that the team create a presentation that tells a story. The first part of that story sets the stage: you remind your stakeholders of the pain that they are experiencing because of their very big problem. To make this more dramatic, let’s call the problem “the Dragon.” Then, you introduce your heroes, the highly credible team of talented folks that want to slay the Dragon. You may want to share some examples of havoc wreaked by the Dragon, and some stories of early, unsuccessful attempts to slay the Dragon. Then, you will want to share the insight that your heroes had that exposed the path to the Dragon’s weakness. Finally, your story will explain the careful preparation that the heroes have made to march down that path and destroy the Dragon once and for all. And, there you stop.

What do you think that your executive sponsor/decision maker will do at this point? In my experience, having facilitated this process over a dozen times, the response is unequivocally – Go Slay That Dragon! I have found that all reasonable requests for resources - people, capital and cash – are made available for the Dragon Slaying Quest. Also, there is a strong sense of empathy about the shared problem and anticipation of a world in which the Dragon is eliminated. That anticipation is infectious – certainly the executive sponsors feel it. Also, the broader organization will eagerly support our heroes in their quest. That wide-spread support is certainly important since killing this Dragon will not be easy and will require everyone’s cooperation.

I may have stretched the Dragon metaphor to the limits here, but I think it does highlight the important step of having the team get direct permission from the executive sponsors to proceed with expending company resources to solve the big problem. The manner in which this is done is very similar to a sales process. I recommend that the team enlist the help of an enthusiastic, people-oriented salesperson-type to assist the team in both creating and telling your compelling story. With that permission, we then arrive at Step 7 in which you solve your problem. I will describe this step in the next blog.

Growing up, Matt Schlegel was much more interested in riding dragons than slaying them and fondly recalls reading the Dragonriders of Pern by Anne McCaffrey.


Wednesday, September 2, 2009

Say No in a Delightful Way [Tanya Berezin]

We’ve all been there: your product manager comes to you with a great feature idea. You – the engineering manager – know your team is already stretched implementing the other great features scheduled for the next release. You offer to prioritize the new feature against others already scheduled and the two of you agree on a reasonable scope for the release.

It’s all very logical but doesn’t feel good. The product manager is disappointed with you: you always seem to throw cold water on his ideas. And you are annoyed, too: you wish the product manager would let you focus on delivering what’s already agreed on. Time to try something different.

Do you know why the product manager is excited about the feature? Find out: have her walk you through her thinking – what customer need does the feature meet? How many customers might need it? Is the need urgent? Are we going to make more money from it?

As you think through these questions together, the PM begins to see that you both are genuinely interested in making the product better for your customers. All of a sudden, you seem a lot less rejecting – a win for your relationship. In addition, if your PM is inexperienced and has no answer to these questions, you’ve just taught her how to be a better product manager. And if this conversation leads you to conclude that the idea isn’t as hot as it seemed at first, the extra work for your team has been headed off, never to come back.

Let’s suppose you, too, are now a believer. Are you sure your customers will be as enthusiastic as the two of you? With a little ingenuity you can find a way to test the feature with customers without needing any engineering work upfront (think low fidelity prototypes, user surveys, etc.) Thus, you and your PM have moved forward with the idea while your engineers still haven’t been handed any extra work.

(This isn’t as much work as it may seem – many times, I’ve done both of these steps in a 30 minute meeting. Last time, as the PM left my office, eager to get started, she said: “I came to ask for engineering time and you just said ‘no’ to me, didn’t you? But I couldn’t be happier. How did you do that?”)

OK, you’ve tested the feature with customers and they seem really jazzed about it. Is now the time to have the re-prioritization discussion we started with? Not quite yet; instead, can you think of a different way to meet the customer need using the features you already have? All the research you’ve just done may give you ideas on how to do that. If you do, the extra work for the new feature may never need to be done.

If after all this you are still convinced that the new feature is worth the extra development effort, then you should put it in your backlog and prioritize. But this time, the prioritization discussion will feel very different: the product manager won’t feel thwarted and you won’t feel jerked around. In fact, you’ll be delighted with each other!

Tanya Berezin is a successful software development leader who consistently delivers complex, bet-the business, need-it-yesterday projects. She enjoys building high-performing teams who delight customers with easy to use products. Find more information about her at