Why do you want to be a manager?

Recently, a friend and I discussed an opportunity he has to become a first time manager. As we spoke, I relayed some conversations I've had with employees who have wanted to become managers.

Typically, employees approach me with something along the lines of "What do I need to do to become a manager?" I suspect they expect me to enumerate a series of skills or development needs. Perhaps a course or two, and presto - they are now manager-ready. This is a reasonable expectation, since rating systems almost always focus on the skills required to do a job, get promoted, etc.

Management, however, is not primarily about skills (although skills matter). It's about motivation. I mean, what is the motivation behind someone wanting to become a manager. The question isn't about what, it is about why.

And that is precisely the first question I pose: "Why do you want to be a manager?"

Believe it or not, I can usually tell within a matter of seconds if the person will ultimately make a great manager. Let's start with a few responses that tell me the person isn't ready to manage:

• I want to have greater influence
• It seems like the next step in my growth
• I want to be able to control (insert any number of things here)
• I think I'm ready to manage others
• I'm very good at what I do, and think I can direct others to be as good
  

On the surface, these are reasonable responses. That is, if being a manager is all about the manager. But it's not. Managing is about the people being managed, not the manager.

Read that last sentence again. It's not about the manager. Most of the time, people possess a very "me" centered approach to management. That isn't going to work in my organization.

So, what types of responses indicate that someone is ready to manage? Here are examples:

• I love coaching
• I want to help create an environment where people can achieve more than they can without my guidance
• I want to help people grow and be challenged
• I love helping people succeed

This set of responses is focused on service to others. That is what great managers do. The first set of answers are given by people destined to remain managers. The second set of answers are given by your next generation of leaders.

Is there no hope for the first set of folks? Of course there is hope. I suggest you send them home with a simple assignment: Have them write down the reasons why they want to become a manager. Don't set a time limit - leave it to them. In some cases, they will never return. That tells you everything you need to know about them.

Others will report that they changed their minds. These are people you might be able to coach. Ask them what changed their mind. If they spent time reviewing their reasons, they have demonstrated the ability for self-reflection. You may have to tease it out, but you may be able to guide this person towards a service oriented approach to management. In some cases, people understand this approach, and realize that they would rather stay self-focused. At a minimum, you now know that you have someone who is willing to look inside themselves. They may not be ready today, but keep your eye on them for the future.

The last set of folks will return with their list. This is where your management ability matters. These are the folks who truly want to grow (or they would have not taken time to complete their homework). Usually, you will be able to show them a bias towards self, and reinforce the value of service orientated management.

I'm not saying that these folks are slam dunks.

Some will remain "me" centered. It is up to you to help them understand that management is a service to others. If they can't or won't understand this view, then you have to decide how much damage to the team you are willing to inflict. You also might want to look inside and assess what style you are projecting. They are getting their perception of management somewhere.

When you have an employee that values helping others, you have a potentially great manager. This is a person to nurture. Reinforce the values through your own actions with her or him. With the correct orientation to management, now you can begin a discussion about the skills that must be developed or built on.

These folks are rare. So when you find one, cherish them.

Agile: It's about learning

Driving home this evening, I thought about the reasons I'm attracted to Agile Software Development. Increased transparency and intimate customer involvement are two that come to mind. However, what struck me most is that Agile gives me a chance to do something I love:

Learn.

Quite frankly, spending months developing a set of requirements and more months developing, only to learn that we didn't solve the business problem (but met all the documented requirements) annoys me.

This annoyance has led me through the years to drive for small, reversible decisions. There is a sense of progress. Of accomplishment. Of creating results. Of learning.

Agile allows me to learn frequently. Think about your school days. Which were better learning experiences? The classes where you had one final at the end, or the ones where you had a weekly series of small tests? I never appreciated the instructors who adopted the weekly testing approach. I was "forced" to make steady progress, week after week. I had to master a topic in order to build a foundation for future learning. (Perhaps they should be called course scrum masters instead of instructors?)

Fast forward to executive leadership. What does learning have to do with anything? It's about hitting dates and generating sales, right? Of course. But how do you achieve these goals? By learning what works and what doesn't. Agile allows you and your teams to learn.

You learn what practices are effective and aren't effective.

You learn what your customers like and what they don't like.

It is this constant learning that enables the achievement of your goals. Would you rather learn sooner or learn later that your software isn't going to solve your customer's business needs? Learning sooner (in product demonstrations or sprint planning meetings) gives you time to think your way out of a problem instead of frantically re-work a poor solution.

There is an interesting advantage to be gained by learning. Level of experience is a significant factor in team performance. Using the traditional waterfall approach to development, you perform one planning exercise, and perhaps a few more along the way at the infamous "checkpoint" or "gate" reviews. Your competitor using Agile practices plans every two weeks. After a 6 month project, your competitor experienced twelve planning exercises. That is 3,4, or more times the number your team experienced.

Which team do you think will be more effective planning? Since your customers don't buy plans, consider why this matters.

To be continued...

Make a decision, would ya'?

Senior leaders are paid to make decisions. So, why does it seem like so many prefer not to do so?

Studies are commissioned, "tiger" teams are formed, data are collected. But the decision to do or to not do something is buried in steering committees, integrated program teams, or follow up meetings with a sub-team.

Meanwhile, valuable time and experience are lost.

Watts Humphrey, originator the Software Engineering Institute's Capability Maturity Model and a significant contributor to the concept that software development is an engineering discipline, once remarked to me that one can learn a lot more from doing than by studying.

Of the many lessons Watts' provided to me, this one found itself into my essence as an executive. Don't get me wrong. I'm not walking around all day randomly making critical decisions without thoughtful input and deliberation. But I do not wait forever, hoping that if I just have enough more information or the time is right, then I'll decide.

The key is to make decisions at the latest possible moment (Agile folks should recognize this). Another key is to leave yourself an out if the decision needs to be corrected. Let's be real here - most decisions you make are not so critical that they have to be 100% correct. In reality, you can never know if you are 100% correct anyway. Your goal is to be correct enough, learn from the execution of the decision, then make corrections.

This is not new. Nancy Wang and I wrote about this many years ago in Software Testing and Quality Assurance (Juggling Concurrent Releases). The concept of failing fast, learning from doing, and responding quickly is at the core of Agile Development, as well. With the emerging acceptance of Agile Development principles, perhaps some of this thinking will make its way into the execute suite.

Since Nancy and I wrote that article, I've had many opportunties to make a decision with less than ideal information.

During that time, I've learned another lesson : Build your team to be adaptable. You see, most teams expect their leaders to make infallable decisions.

Try these approaches with your team:

• Let them know that you don't have all the information you would like to make the decision. This is important because someone on your team actually may have more information and prevent you from doing something bad. It also helps perpare them for the fact that down the road, the decision may need to be revisited.
• Be very clear with your team that you have very intention in changing course if the consequences of the decision require it. (HINT: The consequences will). I often set a specific time for when we will revisit the decision. This has the effect of preventing the team from getting too wrapped up with making the decision "stick" and allows the team to focus on the business problem we are trying to address.
• Demonstrate concrete changes you make in response to lessons you learn once the decision is being put into place. I believe this is an action that gains tremendous credibility. It shows that you are willing to take a chance and make adjustments when presented with new information.
• Allow people on your team to fail. Ok, maytbe not fail miserably, but at least them understand that it is OK to take a course of action that doesn't turn out as hoped. The be there for them to help them make the adjustments needed to get back on track.

Perhaps most importantly, these steps begin to build your next generation of leaders. They provide a model of how to navigate uncertain times. Nobody expects a pilot to take off and blindly stay on the planned course, regardless of what reality presents.

We shouldn't act like our decisions are any more accurate and stable than this.

Why do we need another blog?

For several months (OK, years), I've read and observed quite a bit regarding software development, management, etc. Much of what is written is spot-on accurate. I noticed, however, that much of what is written seems to be written by consultants (which is fine - more on this in future posts) or by folks "in the trenches".

As I move from post to post, book to book, and article to article, I have a growing sense that there is something missing. What I find missing is representation from executive leaders.

That is - where are the Vice President and Director level voices out there?

• Are we too busy? (Doubt it)
• Do we not have anything to say? (Doubt that too - just ask my team)
• Do we not care? (I hope we do)

Ultimately, I'm not really sure. Maybe it's just that I am reading/listening/viewing the wrong material.

So this blog is my contribution to the literature - from the view of a software exec.

A few things:

• These writings are my personal opinions
• Any real life stories are going to be greatly changed to minimize or eliminate harm to companies and people I've worked with and for.
• I'll be reluctant to even identify people and places for things I believe a genuinely good, in order to respect folks that may have contributed and have been inadvertently omitted.

If you got this far, thanks for reading.