Handing over my Baby eehmm Project
I’m just in the last phase of a project: Handing over my baby eehmm, sorry, I mean project to the maintenance team. Looking back, I find that the project has undergone a number of phases, setting quite different demands on the technical leadership.
After this week I will no longer have any own assignments in the project, I will just be available for questions and helping out when needed. It’s always a bit sad to leave a project, especially this one that was a greenfield project where I have defined the entire architecture and written a lot of the code. Being an architect is equally much a leadership role as it is a technical role. Looking back, I find that there are five different phases that require distinctly different leadership.
- Setting the Bar
- Controlling
- Coaching
- Trusting and Giving Freedom
- Leaving
Setting the bar
Leadership in the first phase of a project is mostly about informing, making sure that everybody knows what I expect in all areas. I have expectations on code quality, on documentation, on performance, on security considerations, on version control routines. I know that everyone reading this is a top developer, so it might come as a surprise, but more often than not I find that a lot of basics are not as natural as they should be.
During the first phase of a project I do set the bar. I make sure that everyone understands what quality I do expect.
This phase also requires some hard work from myself. I have to show that I live up to, or exceeds the standards I demand of others. If I didn’t set at least the same demands on myself it wouldn’t be leadership. It would be dictatorship.
Controlling
When everyone in the project knows what is expected, the next phase begins. The phase of control. I find that this is in many ways the hardest and most challenging part. It’s about keeping up to the standards without becoming a complete pain for the rest of the team. Organized code reviews is a great tool in this phase. They give ample of opportunity to both give credits for things done right, and point out where improvements are needed.
The hard part is sometimes to find things to give credits for. When the code is a mess and looks like the person writing it didn’t care at all about it and there is nothing to give credit for, just a lot of things to improve there is no other option that to just criticize. When the same piece of code fails to pass my code review for the fourth time I’m sure that the author of that code thinks things about me that isn’t suitable to express nor put down in writing.
I wish I knew a way to avoid this phase, but I don’t. Instead I keep on being a pain with sadistically detailed code reviews that requires code to be revised until it meets my quality standards. I keep on doing, because I know that in the end it will be worth it.
Coaching
After a few weeks, the level of quality I demand has usually sunk in and the team members understand what is required. The team even start to make the quality requirements their own. They understand why quality matters and try hard themselves to reach the required level. This is where the fun starts. I can now focus on coaching, with people asking for help before the code reviews as they start to be able to identify solutions that are not good enough.
Coaching could be an ever ongoing phase but I don’t want to be stuck in a single project. I want to move on and be able to work on something new so it’s time to prepare my exit. When I feel that the team is able to reach a decent quality level it’s time to trust the team and give them freedom.
Trusting and Giving Freedom
Leaving a project requires planning. The first phase is to hand over control of the project to the team. It’s still a matter of coaching, but now it’s time to coach them to help each other and to trust themselves. They have to feel that they can handle this on their own.
For me it requires that I do give them freedom. Quite the contrary to the controlling phase earlier it’s now time to let go of things, unless they are totally disastrous. The ultimate goal of this phase is to make myself obsolete in the project.
Leaving
Finally it’s time to leave. If the previous phases have been done correctly, the leaving will not be dramatic.
The last week has been about leaving my previous project. I have still been physically located with them, but spent most of my time on my next project and various between-project administration. I don’t have the feeling anyone has noticed that I’m no longer doing any significant work on the project. The team has taken charge of the project and can do without me.
It’s time to leave. It’s time to start a new project. It’s time to once again set the bar.
