If you are new or have had the CTO/VP engineering position for 10 years, it does not matter. You must start from square one. Of course it might be a bit easier if you are new at the job to do this, but do not fall into the trap that you know your organization, especially if you been on the job for sometime. You must get out from you room and start talking to all people in you organization. Start with your own organization and next inline is the organization who orders the products from development (for example product management or product planning). If you have product management or product planning in your organization, you have already found one problem right here :-), more about this in future posts (link).
Why talk to your people yourself? (NOTE: Do not fall into the trap getting a management consultant doing the job for you). Talking to your people yourself will give you at least three things.
- You will hear and understand the feedback first hand (hence no whispering game, i.e. loss of data) and you can ask follow-up questions directly to fully understand what he/she says.
- All employees want to be seen even more so if they have been seen by the boss or bosses boss etc. Even better if they also feel they have been heard. Do not underestimate the power of this…
- And most importantly in 99% of the cases, they do not only know what is wrong, they will also know how to fix the problems in most cases
Do not fall into the trap of to many questions. Two simple questions is usually enough (you should of course not forget the “social part” of the meeting as well).
- What things can we improve?
- How would you go about to solve these issues?
If you do this simple first step you will have plenty to work with for the coming years…I once meet a manager that did this with more than 150 employees, he was a true inspiration and a fantastic leader.
Next post I will talk about what to do with the stuff you find…
Kind regards
Anders
Posts
The most critical part of any management team is to understand the capacity and drivers in there own organization. To paraphrase what you said before - I have yet to come across a company where the management team truly understood what the capacity and the limiting forces in the product/developing part of the organization was/is.
ReplyDeleteThe "We will be the best in the world and we will do everything in half the time compared to our competition" syndrome is all to common. The critical part is not wanting this to happen but rather understand what stops the company from moving in that direction.
As you point out, requirements is all but just one component in that equation. Failure to understand the impact of changed/added/removed requirements together with the believes that never before tested technologies will behave in a predictable matter is another.
It is interesting to read the the GAO reports from DoD (www.gao.gov/products/GAO-09-326SP) which goes through of the 50 major weapons programs in USA which has (almost) unlimited founding, the best people and still fail. Many of the reasons identified for these failures apply in smaller scale as well - failure to understand complexity, mistaking new technologies for proven and shear optimism that "it will probably be worked out" without any contingency if the expected miracle does not happen.
The SCRUM methodology is really nothing new. I would more call it realization on the management level that it probably will not work if we first spend 3 years developing the requirements and then start developing. Starting early development as part of the requirement clarification process is always necessary.
SCRUM is the way the majority of all open source and academic SW development have taken place the last 30 years or so although it wasn't called SCRUM. What is new is the fact that it has been realized on a company wide level that SW has an inherent complexity and freedom that must be approached in a step wise manner. This coupled with a clearer goal-fulfillment visualization for the development teams is probably a step in the right direction.