Finding the Problem-Solving Super Highway [Matt Schlegel]

Returning to Marcus Buckingham’s book “First, Break All the Rules,” I delighted in his analogy of people’s strengths and weaknesses as super highways and country lanes in the wiring of their brains. I subscribe to this line of thinking; however, it leaves me wanting for a way to identify predictably the super highways and bumpy country lanes of candidate team members, be they for a problem-solving initiative or a spot on a development team. So began a search for a navigation tool to find those super highways and avoid the country lanes.

Many people subscribe to the romantic notion that if you try hard enough you can do anything. I don’t. There are things you are naturally good at and things that you are not. Further, there are things that you are passionate about and things that you are not. The magic occurs when there is alignment of your passions and your natural talents.

Let’s say that you are John Rittman, Head Coach for Stanford’s softball team. And, let’s say that your ace pitcher throws right handed. The problem is that the teams in your division hit much better against right-handed pitchers than against left-handed pitchers. What is the solution to this problem? Are you going to tell your right-handed ace to start practicing with her left hand because if she tries hard enough she can be as great with her left hand as she is with her right hand? Or, are you going to let your ace right hander continue to hone her skills as a right hander and go out and find some left-handed talent to round out the roster?

I am right handed, and last weekend I went out and practiced throwing with my left hand. It is remarkable to me how absolutely inept I am at throwing with my left hand compared with the right. Both accuracy and power suffer, as well as my whole body feels off balance. My brain definitely applies its resources to giving me some competence at throwing right handed while neglecting that capability with my left hand. My right hand definitely got the super highway to my left hand’s country lane.

What we need is a navigation device that can help our teams navigate the problem- solving process. This device needs to not only find the shortest path, but keep us on the super highways whenever possible. I will describe such a device in the next few blogs.


As an engineering manager, one of Matt Schlegel’s most satisfying roles was finding the alignment between people’s natural talents and their passions, and guiding them towards roles in which they could be fabulously successful.
More...

Managing Risk in IT organizations [John Levy]

Most losses / failures in IT Development are initiated or compounded by management shortcomings; very few losses / failures are due to technical inadequacy.


1. IT Operations and Development must be managed differently. Development is Engineering and must be managed as such. Outsourcing of Development does not convert it into Operations – it is still Engineering.

2. Measurements for IT Operations and Engineering (Development) are different: Development should be measured based on expected ROI plus certain strategic factors; Operations should be measured based on predictability of spending and certain Quality of Service measures, along with regular and consistent assessment of relevance of those measures to the business. [This is analogous to market risk in financial portfolios]

3. Most losses / failures in IT Development are initiated or compounded by management shortcomings; very few losses / failures are due to technical inadequacy. In addition, the probability of future failures remains undiminished so long as the management shortcomings are not addressed.

4. The cost of failure in IT Development always exceeds the allocated budget for the activity, because failure has consequences beyond the immediate failed project, both for people and for other projects. For example, one major factor of risk that increases when a development project fails is the loss of key people. It is rare to find IT management mitigating this risk immediately on learning of a development failure.

5. Failures and losses in IT Operations usually involve either directly managed operations centers or outsourced providers’ operations. Outsourced operations are inherently riskier because the providers’ operations are less visible, and therefore less known, to Operations managers. [Cf. Failure in Microsoft-provided services for Sidekick smart phones, Oct., 2009] [This is analogous to credit or counterparty risk in financial transactions]

6. IT management should be able to communicate to top management the nature of the tradeoffs in IT Operations and Development, so that strategic implications of decisions in IT are well understood at the top level. This means that financial factors must not be the exclusive determinants of IT decisions. The CIO should not report through the CFO.

7. Multi-year planning is essential for both IT Operations and Development. A roadmap for rationalization and integration of resources and services is necessary, even if it must be revised multiple times per year as new equipment and services are needed. Contingency planning and scenario analysis related to possible shortcomings of vendors and outsourced services must be part of the plans.


Above thoughts on IT management are based on my recent experiences at a client company and were triggered by a paper, “Risk Management Failures” by Prof. Rene Stultz, Fisher College of Business, Ohio State University, published by Cornerstone Research http://www.cornerstone.com/

John Levy consults on managing Agile development and is a frequent expert witness in computer & software patent cases. He has 30 years’ experience as a consultant and manager at Quantum, Apple, Tandem and DEC. His book on high-tech management, Get Out of the Way, is due out in 2009. More info is at http://johnlevyconsulting.com


More...

Problem Solving, Shared Leadership and the Enneagram [Matt Schlegel]

In recent blogs I have described the steps of a problem-solving methodology that I have found works extraordinarily well in helping teams solve complex problems. What I have also found is that different team members contribute in different ways, and their contributions are better aligned with some steps of the problem-solving process than others. Imagine if there were a way to understand how each team member best contributes to the problem solving. Imagine if you had a way to ensure that there were strong contributors at each step of the way through the problem-solving process. Also, imagine if you understood when there was too much or too little representation of a particular strength so that you could avoid some classic problem-solving mistakes (for instance, paralysis by analysis.) The next sequence of blogs will describe the connection between people’s strengths and weaknesses and the process itself.

The basic premise of this discussion is that we can find a method that does provide a link between each step in the problem-solving process and people’s strengths and weaknesses. I discovered such a link while studying the Enneagram. For those of you not familiar with the Enneagram, I recommend checking out this link. I find that this book is a great introduction to the Enneagram.

During an Enneagram workshop I attended, the question was raised as to why there are numbers to describe the different personality types. The instructor indicated that the numbers are arranged in the order that people solve problems. Voila! The Enneagram not only describes 9 basic personality types, but it also describes the order in which each type contributes to a way humans solve problems. Fascinating! It was based on this bit of inspiration that I started to develop the problem-solving process I have described in previous blogs. In using this process with teams, I did find that there is a strong correlation between a person’s Enneagram type and their ability to contribute to the problem-solving process. I used this correlation to promote leadership of those with particular strengths as the team needed those strengths during a particular phase. Asking people to do what they are naturally gifted to do yields remarkable results. I believe this is one of the most powerful aspects of this problem-solving process.

Matt Schlegel has studied the Enneagram since 2001. His introduction to the Enneagram came through his family. Over time, he found that it was a useful tool in helping resolve conflicts in the workplace and getting teams to work together more effectively. He also discovered its powerful use as a problem-solving tool. Matt continues to study the Enneagram, discovering something new and interesting with every encounter.

More...

Introducing Myself [Robert Lasater]

Hello everyone. My name is Robert Lasater. I am the engineer responsible for maintaining this blog.If you have issues, questions or comments, you can contact me at rlasater "at" hotmail . com

My goal for this blog is to provide a forum for people at all levels of engineering leadship. For example, as a software engineer I am an individual contributor, but I have led projects from initial requirements to full scale deployments, working with domain experts, quality assurance, and customer representatives. So I want this blog to be relevant and helpful to people like myself.

Obviously the blog should also be of help and interest to team leads - people who have one or more people reporting to them, most likely supervised by a manager or director - through managers, directors to vice presidents of engineering.

Anyway, I have been working this blog for a few weeks and look forward to working with the EL SIG team to make it a Must See site for engineering leaders in Silicon Valley and across the nation and the world.

Robert Lasater is a software developer with several years of experience leading projects to develop firmware for embedded systems.
More...

Problem Solving Tool - Step 8: Smoothing the Feathers [Matt Schlegel]

The problem-solving team has performed an apparent miracle. A transformative change has taken place in the organization. Results have been measured and confirmed – the goals that the team set out to achieve have been reached, and the problem has been solved. Is it time to celebrate? Well, hold on just a minute.


Whenever there is a transformative change within an organization, there will be perceived “winners” and “losers.” There will be those whose position in the company is apparently improved and those whose position is apparently diminished. Humans are great detectors of these types of changes – we cannot help ourselves, it is just what we do. The 8th and final step of this process (at least numerically speaking) is to reach out to all those people that are affected by the change, find out what is working well and what is not working well in the post-transformation organization.

The team is no longer selling the change. The most important skill at this point in the process is LISTENING. It is particularly important to listen to those who have undergone disruptive change in the way that they perform their function. Not only has this change been emotionally unsettling, there also may be new, unforeseen issues that are impeding workflow. It is important to capture these issues and concerns, address them as well as possible, and ensure that all workflows are moving effectively.

Continuous Improvement

Inevitably, there will be some issues raised during this final listening step of great enough magnitude as to require more than a quick and simple fix. Capture those issues. The interesting thing about this process is that it is not linear, but circular. After the change, new problems arise and can be addressed with the same process, back to step #1. In this manner, an organization can be continually evaluating its effectiveness and taking the steps necessary to improve itself in a never ending cycle, a cycle of continuous improvement.

Time to Celebrate

Okay, the team has taken the time to listen to those who have concerns. You have implemented quick fixes to address the simple concerns, and have recorded those concerns of greater magnitude for careful consideration later. Importantly, you have included all those affected and taken the time to smooth any ruffled feathers. Now, it is time to celebrate! The problem is solved, the metaphoric dragon slain. Take the time to enjoy your success as a team. You deserve it.

In the next series of blogs I will return to the idea of sharing leadership during the problem-solving process.



As an engineering manager, Matt Schlegel had the opportunity to organize/sponsor some memorable celebrations. His favorites to date are canoeing on the Russian River, kayaking in Elkhorn Slough, and cooking at Culinary Center of Monterey. What have been your most memorable team celebrations?

More...

You Say “Later”, They Hear “Never” [Tanya Berezin]

I don’t have a crystal ball but this I can see without one. If you manage software development projects, this will happen on your next one:

• Customers (or Marketing or Product Management) will want more than your team can deliver.
• It will be your job to tell them that.
• They won’t be happy.

You’ll need to deal with the immediate issue of salvaging your release and the longer term need to reestablish your credibility with the customers.

The immediate problem usually is somewhat straightforward. If you cannot get more resources - time, people, money, tools, etc. - and you cannot compromise quality, you’ll have to work with your customers to cut some planned features. Once you agree on what gets cut, they’ll want to know when the cut features will make it into the product. And, sometimes silently and sometimes out loud, they’ll wonder if these features will ever make it in.

You can’t blame them for being suspicious: they’ve had to postpone features on other projects before and in many cases these features never got implemented at all. But you need to tackle this concern quickly and persuasively, or negotiating scope again in the future will be much, much harder.

I will assume the features you postponed are worth implementing. (See my previous post on how to artfully say “no” to unnecessary work.) How will you assure your customers that you are only delaying the work, not burying it permanently?

1. Show the backlog.

Use your project backlog, product roadmap, or another list that shows planned features in priority order. (You don’t have one? Put one together as soon as you can.) Your customers worked with you on it, so pull it out and remind them what you were thinking of when you prioritized the list. If the business context has changed, now is a very good time to review and change this list. If not, your customers will be reminded that you were planning all along to add features over time and that hasn’t changed.

2. Discuss risks.

Acknowledge that reality can intervene with your best intentions. Your project could lose the backing of your sponsor; a new competitor could show up and you’d have to change what you are doing; or any of hundreds of other things quite outside of your control could happen. (For a list of typical project risks go to www.construx.com and navigate to the Resources & Tools section.) Show your customer your top risks list (you have one, right?) and your contingency and prevention plans for each. This will reassure them that you are doing all you can to protect the planned features from being permanently on hold.

3. Deliver.

Of course, the best thing you can do to maintain your credibility is to deliver what you promise. So when you do cut scope for one release, don’t overpromise for the next one. Keep track of what you estimated your team could do and what they actually did and improve your estimates over time.

This way, next time you say “later” to a feature, your customers won’t hear “never!”

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 http://www.linkedin.com/in/tanyaberezin

More...

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.”

More...