Monday, November 22, 2004

Metrics and Radiators

We all know that what gets measured gets done. So why is it that so many software organizations don't have data on their performance? My theory is that people are afraid to be measured. I have personally seen aversion to ascribing defect rates to individuals. The argument against it was that managers are not capable of interpreting the subtlety in the data, afraid that if one takes on harder work and incurs inherently higher defects rates, that managers won't know how to parse that out.

One of the better components of Agile Software Development is the information radiator. This is the prominent public display of data relevant to the project. I argue that a combined team and individual defect rate radiator will inherently drive the right behaviors in an organization. Management need take no additional action other than to keep the radiator current. Capable, normal Individuals and teams want to do better. They can rationalize why they might have worse metrics than other individuals or teams, but they will work to make it better if it's visible.

Other metrics I have worked on include those for efficiency and effectiveness of an organization. The first time you sit down with your team to define these, they probably won't get it. Mine came back and wanted to measure the number of meetings with agendas and number of meetings which finished on time. They chose those because meeting time seemed very wasteful to people. While interesting, this wasn't what I had in mind for measuring how well an organization is doing. So I went after another aspect of quality: delivering products on time.

One regular challenge to delivering products on time was dealing with change. Schedule changes from dependent components, requirements changes from customers or the market, design changes due to oversight,etc. What we agreed to measure was the number of contingency plans we had relative to the number we needed, and whether those contingency plans actually worked when needed. The other part related to that was how well we executed relative to plan. In order to do this you need a fairly granular plan. And a radiator. Also not a perfect measurement system, but one which should get the proper results.

Thursday, November 04, 2004

Strategy and Mission

Much has been written on strategy. It can be a fuzzy and cosmic subject. I advocate a very simple approach to setting and communicating a strategy, and it can be done at all levels of the organization where choices are made.

A simple strategy is one that is written specifically for the purpose of review by other parts of the organization. It should cover what could be done, what will and won't be done, in what order, and why. Writing this down invites discussion of the rationale for investment. It can make the case for dial-up or dial-down investment in an area. In a healthy business there is more that could be done than you can afford to do. Without a written strategy, your department may subject itself to direction changes from other departments, customers and others.

That doesn't mean you won't change your mind. When you do, the simple strategy provides a level of rigor and review to make sure you haven't compromised something else by doing so.

A written strategy is a mission statement on steroids.

Sunday, October 24, 2004

Corporate Life Cycle

I am a fan of Adizes' model for the corporate life cycle. In his book Corporate Lifecycles, he describes four categories of roles that each executive should have reporting to him or her, in order to bring good conflict to the table that can be used for good decision making. The four roles are PAEI:

Performing. In software product development, this is most of what we think about the business; viz creating code which provides a value which translates to money.

Administering. These roles provide predictability, repeatability, quality in what you work on today.

Entrepreneuring. These roles ensure the long term success of your business, looking ahead to what you need to do in the future.

Integrating. These roles are also long term, making sure that you can afford to work on what you need to in the future.

The essence of the model is that you can predict how an organization will perform based on how well balanced these roles are. It is a fascinating read.

Wednesday, October 20, 2004


One of the best ways you can get input on all aspects of your organization is to make sure people want to talk to you. This seems self evident, yet many leaders don't invite input except from superiors. You can't just say "give me your input" and expect it to happen, you have to demonstrate that you care.

What I do is make others feel respected and important. Everyone. The janitor. The receptionist. My developers. My peers. My entire network. I get to know their name and commit it to memory. I banter with them when I first see them during the day. I enjoy them as a person for a couple of minutes on every interaction.

I remember a former manager and mentor who told me that he respects anyone who does their job well, irrespective of the status of their position. If an individual takes to his or her job with pride, if s/he is the best XYZ that s/he can be, that deserves respect and admiration. That feedback stuck with me, and as I became more people oriented as my career went along, I put it into practice.

I'm sure some executives will say this is poor time management. I disagree. As an executive you will get more back from your organization by doing this. Two benefits resulting from this attitude and behavior are trust and loyalty, and it is both exponential and infectious.

Tuesday, October 05, 2004

The one true way

You've all seen it: religious wars over technical solutions. emacs versus vi. C++ versus Java. VxWorks versus Embedded Linux. These are decisions you often can't make right because there is no right solution. And whichever you choose, you will alienate a percentage of your technical people. I've tried various ways to solve this dilemma with disappointing results.

What should you do when faced with these?

You will have to do due diligence to make sure that there isn't a clear winner because of some property you haven't yet thought of. Pick a senior person or a small team as technical advisors, and have them research the options, but give them a due date and set the expectation for how much resources they should spend on it. You want to understand whether you can get mindshare or not. If you can't you want to discover that quickly, recognize there probably isn't a "right answer", then simply decide or appoint someone to decide.

Here's the critical part though: make sure the team knows that the decision will be final, who will make the decision, when, and what any known decision criteria is. Let them know that you will support the decision and that you expect the entire team to support it as well. Moreover, that there will be negative consequences for anyone who doesn't go along with the decision. Make sure you are captain of your ship and that the crew isn't going to sabotage the decision. They are either on your ship or not. Their choice. All for one and one for all.

Then you can go on to working on things that add value.

The most important thing about leadership

What I have noticed when technical people complain about bad leadership (as opposed to lack of leadership), is that there is really a lack of trust. This typically occurs because the leader has either exhibited repeated selfish behavior or is failing to communicate openly and honestly. I have seen some leaders holding back information in the interest of appearing dignified or more intelligent than others. I have also observed leaders spewing the party line to cheer up the audience, when the party line is not credible. Neither of these behaviors will lead to long term success.

In my experience, people will respect you and follow you when they understand that you have their well being in mind at all times. The only way I know of to establish that understanding is to drop your guard and let others know where you stand. I'm not advocating that you don't speak the party line, but when you do, make sure you add what you really think (perhaps softened a little if it is a sensitive issue). That way people know you are real, and when you say things are really good, or that they could be really good if only the company or individual did something, they will believe.

You need to go out of your way to help others, in and out of your team, when it is the right thing to do for the group. If this makes the team stronger or the product better, everyone wins. You'll get credit for doing the right thing even though it hurt you, and when you need their help, they'll be there to help you. You want to be the leader that will be there for them when they need you, and you need to demonstrate that every chance you get.

The consequences of losing trust in a high tech firm are dire. Once you lose trust, you lose a lot of the communication that needs to happen. Your team needs to be able to tell you when you are heading for a mine field. They will do that when you do the same for them. As a leader in high tech, you have to accept the fact that you don't have all the answers, and you will need effective communication to help your group get to the right destination.

If your company is healthy, individual well being is typically best served by the company's well being. So if you focus on what is right for the company, while respecting the individual, people will notice. If your company isn't healthy, that is a totally different situation. You need to decide what is best for each individual and let them know why you believe the things you do. If you are a leader in an unhealthy company, you have to think of the individuals first. Anything less than that isn't leading, its pandering.

In the end, it's all about trust.