As a project grows the role of the guru has to change with it. At the start the guru is the technical wizard writing a lot of code because he is the entire technical team. When the project is large, he isn’t so much a coder but a coordinator and manager of the technical vision. Those are two very different sets of skills that don’t really have that much overlap.
Making that change is never easy and for some people it’s just impossible. Personally, I have trouble with delegating like that. It is difficult to give up a level of control, but that needs to happen if you want the people to feel that they have some control over what they’re doing.
What do you do when the person you delegated to is not doing the job as well as you could? The first thing is to take a look at what they’re doing.
Is it just different than how you would do it? Different is OK, you can let different go, to an extent. Remember that you don’t have a monopoly on good ideas, other people are allowed to have them too. However, when it starts getting too different you have to reign them in a little and suggest ways to get back to a little more orthodox approach. If the different idea is good enough it could mean changing the project to come closer to the new approach, like you were in an actual agile, learning team or something.
Is it going to be flawed because they didn’t take something into account? That’s probably your fault as a guru. I pretty much boils down to one of three options:
- Either you didn’t communicate enough of the overall picture so that they could understand what really needed to happen.
- They were locally optimizing and losing sight of the big picture, for example performance tuning the heck out of a screen by sacrificing usability.
- They just made a mistake and it’s up to you to help them fix it.
Those three things all have a single solution, communication. It’s tough to get people to follow your ideas if you don’t interact with them. Probably impossible. Communication is a binary process, you have a sender and a receiver. This means that you have to find the best way to communicate with each person. As an analogy, you can’t send a sonar signal and expect someone with a radio to pick it up.
It’s a different skill set than being just a heads down developer. The skills aren’t even really related to being a good developer. Not that you can let the skills that made you a good developer atrophy.
Scott's Thoughts 