Wednesday, April 28, 2010

All in the Family [Matt Schlegel]

One of my clients is a small-sized, innovative technology company that has been in business for over 20 years. It is a self-funded, privately held company with no venture backing. The company is like a family; it is not uncommon for an employee to say they have been with the company over 15 years. At no other technology company have I felt that the company is as much a family as it is a corporation. Working with such a close-knit group can be a double-edged sword. That is why they asked me to help.

People who work together for many years come to know each other’s strengths and weaknesses very well. They come to accept one another and resolve to work with each other through any situation. This resolution often requires being sensitive to other’s feelings and needs and taking an approach that minimizes conflict and drama in order to keep focused on getting the job done. The downside of this approach is that people will tend to downplay problems for the sake of maintaining group harmony.

My client is a group of some of the kindest, most helpful people I have ever had the pleasure to work with. Some of the adjectives that I would use to describe this group are helpful, creative, analytical, cautious and enthusiastic. Two adjectives that I would not use to describe this group are perfectionist and assertive. Yes, this group appears to have weeded out anyone who would be unwilling to put up with the problems of others and anyone who would be assertive to the point of ruffling feathers. Not that this does not happen from time to time, but this is the exception rather than the rule.

The figure shows the problem-solving dynamic that tends to occur at the company. First, there is a great reluctance to acknowledge that there is a problem in the first place. There are no systems in place to identify and report problems to the group in a systematic way. As such, most problems are raised via the squeaky-wheel method. (Cliché: Squeaky wheel gets the grease.) Once someone has a big enough problem and shares that with the right person at the company, the helpful nature of the team kicks in. They want to solve the problem for that person. The company has great strength in creativity and analysis. They bend over backwards and find a creative solution to solve that particular problem. The team will get the thrill of moving towards solving the problem. If the problem is easy enough, it will get addressed. However, if solving the problem requires any transformative change to the way the team has historically worked, there is no one there assertive enough to move the team through that transformation. The problem is addressed to the point that the squeak stops, and the team moves on to the next squeak.

With this client, my two main jobs have been to fill the role of the perfectionist and the asserter. I have helped the company put in place the tools for collecting data, analyzing the data and reporting problems. As the data reveal the problems, the helpful nature of the team kicks in and moves the team smoothly through the problem-solving process. Then, it is my role to serve as the asserter to nudge the team through any transformative changes that will help them resolve their longer term, systematic problems.

This problem-solving framework gives me the tools to understand both the steps of effective problem solving and the interpersonal dynamics that will influence the team’s progression through those steps. It also gives me the tools to explain to my client what may be missing in their skill set that is impeding them from becoming effective problem solvers.

---------------
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.

More...

Saturday, April 24, 2010

Meetings as Performance [Rino Jose]

When you view meetings as a performance, you're practicing something similar to servant-leadership. Instead of demanding people's attention, you earn it. Instead of holding court, you're on stage. It's still your show, but you want people to enjoy it.

When your meeting is a performance, you'll approach it differently. You'll spend time preparing for it. You'll work to make sure everyone's engaged. You'll discuss things that matter. You'll become more animated. You'll think through what you're going to say. Your meetings will have life and energy. Your meetings will have an arc and a story. Your meetings will have a point.

When you play the role of someone on stage, the attendees play the role of the audience. Certain expectations are established naturally. You are there to inspire, entertain, elucidate; they are there to watch, listen, participate -- no cell phones or e-mail during the performance. When you perform well, no one will be bored, and people (including yourself) will look forward to each meeting.

Looking at meetings this way gives you a chance to hone your presentation skills and to practice public speaking. Weekly meetings, in particular, give you a great venue to experiment with different styles and approaches. Vary what you do each week. See what works best for you. Build up your repertoire.

Another benefit to viewing meetings as a performance: it helps you lead change. When you deliver a solid performance, you connect with your audience at an emotional level. You'll find it easier to deliver tough messages and convince people to try something new. When people decide to change, it's usually based on emotion first and then rationalized afterwards. If you can get people to laugh, you can get them to change.

(originally posted on Management Revolution)

_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.

More...

Thursday, April 15, 2010

Bumps and Dips on the Path to Solving your Problem [Matt Schlegel]

In past blogs I have described a problem-solving process. When I describe it, it is a nice smooth process flowing from one step to the next. Funny thing is, when you use the process in practice, it may not be so smooth. What if we could look down the path to anticipate likely bumps and dips in the process. We may not be able to avoid those obstacles, but we can brace ourselves to move through them. In this blog I will describe a method to let my fellow problem solvers identify in advance those bumps and dips.

People tend to play to their strengths and avoid their weaknesses. Your problem-solving team is comprised of people and their various strengths and weaknesses. Depending on where you are in the problem-solving process, your team members will resonate or not with the phase at hand. If the phase requires a strength that is absent in your team, the team can get stuck and have trouble moving to the next phase. If the team is overrepresented by a particular strength, again the team can get stuck or repeatedly go back to the overrepresented step.

The figure illustrates a team that is generally well represented by team members with various strengths, but has an underrepresentation in the Get It Done Step (step 7) and over representation in the Identify the Problem Step (step 1). What can happen in this case is that team would move around the process to the point of underrepresentation, get stuck, and then move back to the overrepresented step, a discussion about what is wrong, without ever taking the action to solve the problem.



This is just one example. You can see that depending on your team make-up, there can be any number of bumps and dips encountered as you move around the process. It is important for the facilitator of process to understand the team make-up, anticipate the trouble spots, and ensure that the team can move through the obstacle. In the example above, the facilitator needs to clearly identify the Driver role in step 7 and ensure that that role is filled with a willing and able team member. Also, when the team restarts the discussion about the problem, the facilitator needs pull the team back on track by reminding the team that a problem statement already exists.

As I work with teams and see how the strengths and weaknesses influence progress, I realize that there are many well-known clichés that describe these bumps and dips. To name a few: paralysis by analysis, half baked idea, heart in the right place, look before you leap, etc. On your problem-solving teams, what bumps and dips have you encountered and what clichés have come to mind?


_______________________________________________________
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use the process to help companies solve big challenges, and folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at www.sakinoconsulting.com.

More...

Wednesday, April 14, 2010

The Knowing-Doing Gap [Kimberly Wiefling]

If knowing “HOW” to do something were enough we’d all be rich and thin. There’s always some reason why well-intentioned, educated, experienced professionals are doing the opposite of what they know makes sense. Frequently it’s because they are really busy, and can’t possibly do what needs to be done until someone ELSE changes first, usually their boss, or someone in a different department. “If only” someone or something else would change then THEY would be able to do what they need to do to accomplish the goals.

A whole book on “The Knowing-Doing Gap” was written on this by two professors of Stanford University when they realized that their colleagues at the Stanford Business School didn’t follow the principles that they taught when they themselves were leading companies. It happens in engineering teams, too. If you want an example of the knowing-doing gap in engineering teams, just consider numerous studies that indicate that the top reason that teams fail is for lack of clear goals. What could possibly be more important for an engineering manager than clarifying goals and communicating them to the team?

Alas, common sense is NOT common practice. What is the source of the Knowing-Doing Gap?
FAIL – The 4 legs on the stool causing the knowing-doing gap and preventing people from crossing it are:

· Fear of Failure – If you’re not allowed to fail you must be careful what you start!
· Aversion to Planning – Studies have proven that, given a choice, people prefer not to plan. At the same time, we also know that planning dramatically improves results.
· Instinct for Competition – The win-lose frame is the first assumption for many people in any situation involving another person. Fear of losing, tied into #1, prevents people from even playing the game.
· Learned Helplessness – “It’s not my fault!”, and “They are doing it to me” thinking. The research on this is absolutely shocking.

The difference between someone occupying an engineering leadership position and a true engineering leader is that the pros do what is required whether they feel like it or not, whether they think they have time or not – no excuses! Winston Churchill is one of my favorite leadership role models and he said “Sometimes doing your best is not enough. Sometimes you must do what is required!” Yeah, that’s right, Winston.

Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.

More...

Thursday, April 8, 2010

Getting Really Good at Agile [Ron Lichty]

From the speaker at the next Engineering Leadership SIG event, April 15, 2010:

The first half of Mike Cohn's book, "Succeeding with Agile: Software Development Using Scrum", isn't so much about how to be successful with agile as how to be successful replacing non-agile with agile, selling agile, and transitioning to agile.Mike Cohn is neither a wild-eyed dogmatist professing the one true way nor an ivory-tower philosopher; he's a pragmatist. He devotes entire chapters to helping scrum evangelists decide whether to start with a pilot or go all-in across the organization, whether to pilot publicly or in stealth, what factors might prevent success, how to swing things your way, how to approach a transition in steps, picking the right first project and first team, and how soon to adopt agile technical practices like simple design, pair programming, TDD, continuous builds, refactoring, and automated testing. He notes from the first chapter that agile implementations are hard and don't always "take" - and explains why. He recommends solutions to the many conundrums and traps that agile teams face.

About midway through the book, as you're reading insights into teamwork, you realize that this book is not just about transitioning to agile but about getting really good at agile - and that you're going to need to read it not just once but come back to it for new insights again and again. The fact is it's stuffed with tips, guides, data, approaches, failures, successes, and helpful hints of every kind.

Part of what makes this book important for me is repeatedly reading observations consistent with my own experience, but drawing on so many more experiences with agile that it results in emergent patterns, as well as in truths that are too often left unsaid. Then there are the surprises that come from reading an author who is remarkably well-read across genres. He does us all the favor of reviewing and summarizing scads of studies and surveys that demonstrate why agile is worth the effort, with data on productivity gains, lower costs, improved employee engagement and job satisfaction, faster time to market, higher quality and, importantly, stakeholder satisfaction gains.

What's the role of a manager of a self-organizing team? One of them, agile gurus seem to agree, is exercising subtle control (as opposed to command-and-control) and Mike provides an entire framework for debugging team problems and influencing their success. This will be one of those chapters I know I'll revisit repeatedly.

In another example, Mike remarkably provides what in essence is a crash course in change, and that chapter alone, while loaded with specifics about making a change to agile, could be used by any technical leader making a technology-and-culture change of any kind. Know why shopping carts were introduced and how shoppers were convinced to use them? Mike does, and effectively uses the example to teach change leadership. How does a leader deal with the skeptics and the saboteurs, the diehards and the followers certain to show up on your teams? How do you sway the uncertain to get on board?

Cohn is practical right down to the challenges from facilities and h.r., the likelihood agile transitions will face waterfall-driven expectations, and strategies for coexisting with other approaches, regulatory standards and processes. Importantly, he provides helpful anecdotes and examples from companies large and small. He's familiar enough with other process changes your company may have attempted to be able to compare and contrast and differentiate the substance and style of scrum from everything that came before.

While Cohn is sometimes unsatisfying - drilling down not quite far enough in sharing what's worked - in its 400-plus pages, it's remarkable how few of these unsatisfying examples there are.

Finally, I should point out that though it may not be immediately obvious, there's one more group of readers for whom this book has enormous value: Agile wannabes who know their current process isn't working. They frequently have heard of agile but have no idea what it looks like or how to sell it. If you're one of those, you also need to read this book. Mike Cohn over and over offers advice and examples and data that will give you aha after aha as you build a picture of what a truly effective process can look like - and how yours could become functional like his.

If you're interested, there's a longer version of this review at:

http://ronlichty.blogspot.com/2010/04/book-review-succeeding-with-agile.html
_________________________________________
Ron Lichty is a "VPE of Fix-It," providing interim and on-demand VP Engineering services to optimize software organizations and efforts. He specializes in solving problems like painfully slow product development, past-due estimates with no delivery in sight, snafus from geographically dispersed teams, scalability stymied by sluggish data integration, productivity bridled by uncertainty, an "order-taking mentality" from teams that should be proactive, and teams unable to break out of research and move on to development and delivery. He also untangles organizational knots, creates roadmaps everyone can follow, builds communications with other parts of the organization, coaches and trains organizations in agile and scrum, and gets teams productive and focused on delivery, quality and customers. Small tweaks, dramatic impacts. He'll be presenting the SDForum's April 15 Engineering Leadership SIG topic on how agile changes the development manager role group in Palo Alto: "If Agile Teams Are Self-Directing, What Do Managers Do?" His book on managing software developers and software development teams, "Managing the Unmanageable: Rules, Tools, and Wisdom for Managing Software People and Projects", is forthcoming.

More...

Wednesday, April 7, 2010

Corporations are People, Too! [Matt Schlegel]

A US Supreme Court decision on January 21, 2010 has re-ignited buzz about the rights (and responsibilities) of corporations. When this buzz happens, and it periodically does (here is an example from 1886), I wonder why it is that we humans are inclined to organize ourselves into ever larger groups? What do those groups afford us? And, what can we learn from this behavior about how organizations solve problems?

When I think about these questions, I first think about what it means to be an individual. The brain is a good place to start thinking about this (literally!) Each of our brains (and I am including all vertebrates here) detects our individual needs and communicates those needs to us in the form of feelings or actions. Satisfying those needs is the problem that the brain is constantly endeavoring to solve. A big part of the brain is dedicated to understanding the problems of one part of the body, and then translating and transferring that information to other parts of the body to help solve the various problems. Our individual brains enable us to be good at solving some problems and not so good at solving others.

Some of the needs identified by our individual brains are best met in collaboration with other individuals and their brains. (2 heads are better than 1!) Our brains figure out what other individuals are good at, and we tend to collaborate with other individuals that help us meet our needs. In that way, collectively we are able to accomplish more and meet each other’s needs better than if we worked individually by ourselves. And, this characteristic is scalable. As the collection of neurons in our brains grows more numerous, and those neurons communicate better with each other, the better the brain becomes at solving problems (fish, reptiles and birds, mammals, culminating in the human brain.) And, this appears to be true for collections of those brains (schools of fish, flocks of birds, herds of animals, organizations of people.) I suppose it is not surprising that brains will tend to use the same successful formula for both internal scaling and external scaling.

When, as individuals, we join a larger group, we create an identity associated with that group. In a sense, as we become part of it, it becomes part of us. As the organization takes on members, it starts to reflect the traits of the individuals. Often, like-minded individuals attract one another, and these individuals may share similar characteristics, including similar strengths and weaknesses. Those strengths and weaknesses can be reflected as strengths and weaknesses of the organization. In the coming blogs, I will share with you some of my experiences about the strengths and weaknesses of organizations for whom I have consulted and show how those strengths and weaknesses affected the organization’s ability to solve problems. Remarkably, the tools that I use for analyzing individuals seem to work very well for analyzing larger collections people. Maybe corporations really are people.

___________________________________________________________________
Matt Schlegel developed his problem-solving methodology over the past decade. He continues to use this methodology to help companies solve big challenges, and he folds those experiences into the refinement of the process. He also consults for companies developing products jointly with Asian companies. Matt can be found at http://www.sakinoconsulting.com/.

More...

Sunday, April 4, 2010

Think Outside the Tool [Rino Jose]

Remember this one?


In the figure below, find a way to draw four straight lines through the nine points without lifting your pen from the page.

nine-dots.png



The answer, of course, is to allow the lines to extend beyond the boundaries of the implied box:


four-line-solution.png


This puzzle gave rise to one of the biggest business cliches ever: "Think Outside the Box".

The next logical challenge then is, can you find a way to draw two straight lines through the nine points without lifting your pen from the page? Not possible, you say? Can't make the box big enough? Here's a hint: "Think Outside the Tool".

What if you used a pen with a really wide diameter? Then you could do something like this:

two-line-solution.png


This is a better tool for the job. Less work for you. Faster results.


Every tool has built in assumptions


When you use a fine-tipped pen, it's assumed that you want thin strokes so you can draw or write with fine detail. You wouldn't want to use this type of pen to paint a wall. Likewise, a paint roller is great for painting walls, but you wouldn't want to use it to sign a contract.

Assumptions aren't necessarily bad things. A more generic tool designed with fewer assumptions often requires more effort to use for a particular job. For instance, spreadsheet applications are great for summarizing tabular data and doing quick computations, but using them to manage projects requires a lot of thought and work (and rework) to set up -- and ongoing effort to keep updated.

Specialized tools make specific assumptions about how they will be used. If you use them as they were intended, they can make your job a lot simpler and easier.

When you start using a tool, understand what assumptions it's making and how these assumptions relate to the work at hand.

Learn Your Tools


If you find yourself using a tool every day, it's probably worth blocking off an hour this week so you can browse the documentation. Skim the table of contents or the index and jot down the features you're not familiar with. Do a websearch on the tips and tricks for the tool so you can get an idea of what others have found useful.

If any of these are relevant to your work right now, figure out how to use them today. If not, keep them in the back of your mind for when the time is right. Investing an hour to learn the tools you use every day can pay for itself many times over down the road.


When all you have is a hammer...


When your tools aren't working well, or when you and your team seem to be spending too much time fighting them, even after you've taken the time to learn them, you might need a different tool.

Take a good hard look at your current tools. What assumptions are built into them? Do they help you do your job, or do you need to hire someone just to keep them running? If you're not using the right tool for the job, find (or build) a better one.

Don't just get by with the tools you have. What if you could save 4 days of effort per week with the right tool? Wouldn't that have a huge impact on your organization? There are tools like this (I've built one). Use them.
(originally posted on Management Revolution)

_________________________________________
Rino Jose is the principal co-founder of Lakeway Technologies, a startup that develops web apps for automating engineering and project management. He has developed software and managed software teams professionally for over 15 years. As a manager and management consultant, he has led turnarounds for multiple engineering teams. Rino holds a B.S. from U.C. Berkeley and a Ph.D. from the University of Pennsylvania with cross-disciplinary focus between Engineering, Computer Science, and the Wharton Business School.

More...

Thursday, April 1, 2010

Self-inflicted Project Wounds [Kimberly Wiefling]

There is a group of forensic chemists who gather periodically for something called “The Bite-mark Breakfast”, where they are treated to a slide show of various bite marks, which they attempt to identify while enjoying their eggs, sausage and toast. (This popped into my head this morning as I was feeding my cat. She was in a nasty mood, and I made the mistake of picking her up to give her a little rub before heading off for a 3 week business trip.) In this same vein (pun intended!) I thought it would be fun to take a spirited look at the wounds incurred by engineering projects, in particular those of the self-inflicted kind. While there are endless challenges rained down upon any product development project, the most regrettable are those we bring upon ourselves. These acts of self-mutilation and attempted suicide are largely avoidable, and it’s a pity to have any hard-working team suffer the consequences of such behavior on the part of an engineering project leader.

The single-most hideous self-induced risk to life and limb of any project is to for an inexperienced and unqualified project manager to take the lead. Just because project management seems easy when it’s done properly is no reason to believe that anyone with half a brain can do it. Technical geniuses who can figure out how to launch the space shuttle from their iPods can’t necessarily hammer out a shared vision among the divergent views of a bunch of clamoring stakeholders. Process gurus sporting black belts in the latest incarnation of statistical process control and the Plan-Do-Check-Act cycle created by Shewhart and popularized by Dr. Deming in the last century aren’t automatically gifted at motivating, coaching and inspiring individuals to contribute their very best in the pursuit of a worthy cause. And don’t EVEN get me started about what a person who is able to study the PMBOK (PMI’s Project Management Body of Knowledge) and remember what they read long enough to answer multiple choice questions on a test may or may not be capable of!

A qualified and experienced project manager knows enough about the product and technology to facilitate sensible decisions among the project team, and detect total nonsense when they hear it. They are capable of employing a variety of problem-solving methods that assure that all relevant information and viewpoints are considered, not just chairing a round table swapping of opinions. And, far beyond dishing out tasks and checking on status, they are committed to bringing out the best in each of the individuals on their team through a combination of appropriately matching the person to the task, encouragement and course-correcting feedback. These are the essential “3 Ps” that produce business results: Product/Process/People.

Yeah, but . . . what if you are the unqualified and inexperienced project manager who is currently leading a project that is way above your capacity? Run, don’t walk, to the nearest highly experienced and capable person you can find and beg them to help you and your team avoid the self-inflicted damage toward which you are surely tottering. Get them to “shadow manage” the project by coaching and mentoring you every step of the way. Meet with them at length on a weekly basis, and talk with them informally frequently throughout the week. This is exactly how I managed my first project, which I was assigned to lead after I complained bitterly about the inadequacies of the current project manager. I was fortunate to have a manager who was willing and able to guide me through my first project leadership experience. You may not be so lucky, in which case you may need to find a mentor, or even hire someone to help you. That’s right, if you can’t get your company to provide you what you need, pay good money out of your own pocket if necessary to get the kind of support that you need to do a great job on your project. I’ve hired professional coaches from time to time in my career, usually when I stepped into a role that felt 5 sizes too big for me. There’s nothing like having someone with 20 years of experience showing you the way. Reading books, taking classes and passing exams are no substitute for decades of experience. Consider it an investment in your continued employment! And you can usually write it off on your taxes.

Cross posted at www.SVProjectManagement.net
_________________________________________
Kimberly Wiefling specializes in enabling people to achieve what seems impossible, but is merely difficult. She is the author of one of the top project management books in the US, “Scrappy Project Management - The 12 Predictable and Avoidable Pitfalls Every Project Faces”, growing in popularity around the world, and published in Japanese by Nikkei Business Press. The founder of Wiefling Consulting, LLC, she consults to global business leaders. She spends about half of her time working with high-potential leaders in Japanese companies, facilitating leadership, innovation and execution excellence workshops to enable Japanese companies to solve global problems profitably.

More...