Managing Like A Boss

I’m about to close up shop and go to Florida to get my Pilot’s license, so I thought I’d give my thoughts on being in, and running a dev team.

I like to be friendly, make people laugh and generally keep people happy. It’s a great thing to do within a team, but it can cause difficulty when handing out tasks or when you need to use your serious face. In general, this has lead to me being the guy at unit9 that the producers and designers like to come to when they want to know if something is possible or if they need little odd jobs doing. It is very important to remember that they are not developers. What comes naturally to you, may not come naturally to others; empathy is key.

When a producer asks me things, I never like to give just a yes or no answer unless that’s all they’re looking for. I know a few developers who don’t have the time of day for producers’ questions and just respond with a grumpy ‘yeah, we can do that’, then put their headphones back on. They are like that for a reason, they’ve worked with too many people who listen for the yes or no, and then stop listening while the developer explains why. I’ve had that too, and it can be enraging, but I like to engage with people and really help them work out what they want and why. It makes people feel stupid if you don’t bother explaining the reasons behind your response, especially if it’s no, because they themselves can’t explain why to whoever asked them that very question. It also helps bring up new questions in the producer’s mind and maybe you can then steer them onto a better path if what they want is possible, but not brilliant.

Having the kind of relationship with your producer where you are accommodating and understanding, no matter how simple you think the answer to their question is, is important. They have to trust that you will always equip them with the technical explanations they need in their day to day dealings with the client. Conversely you need to make sure that your producer doesn’t promise things that you can’t deliver. I have been on the receiving end many times of a Tech Lead coming and saying the producer has promised an extra feature to the client outside of the agreed schedule. I try to make sure that never happens. I have the benefit of project management systems such as Basecamp and Trac that my predecessors did not, as well as insisting that I’m CC’ed on any email that discusses schedule or features. Whenever I see an out of place comment on Basecamp I’m straight on with a reply clarifying that this extra feature will come with added cost or not at the specified time. Developers that are overworked are not happy developers.

When handing out tasks for the Dev team, I’ve found that the best approach is to split the project into sections, and then the sections into features. I then get the whole Dev team together and we pick the sections and features that are interesting to us. Each section has an owner, who makes sure their section works, but any developer can develop any feature within that section. Where we get parts that more than one person wants to do, I start coupling the attractive ones with the mundane or boring tasks, usually grouping by development time. That way you get to do the fun thing, but then you also have to do the boring thing that nobody wants to do [read html wrapper for a flash site, or adding the analytics]. Of course, if there is a particularly risky feature, I’ll make sure it goes to a more experienced developer, or if a junior developer thinks they can do it, I’ll keep a close eye on them and keep a back up ready if they struggle.

And that’s the crux of it. Keeping everyone happy is hard. Keeping clients happy means always making them feel like you are available and delivering what you promise. Keeping producers happy means managing expectations and sticking to your deadlines. Keeping creatives happy means helping them understand what we can do, letting them get to know their developers habits so they aren’t having to redo assets and working with them so that development and design schedules match as best as they can. And finally keeping developers happy means protecting them from excessive workloads, managing feedback for them and being flexible and accommodating if they fall behind in their work. Trying to do that all in one go can be difficult, but it’s worth it.

In the end I’ve learnt that everything boils down to trust. Producers have to trust that your estimates are correct, and generally that what you tell them is the truth. Developers have to trust that you know what you are talking about, and that you will keep the useless feedback away from them while they get on with [what they consider] important tasks.

I found this article on the subject. It’s pretty interesting.