This guest post is by Alan Skorkin, a software developer from Melbourne, Australia. He shares his ideas about software development, software process, and his programming efforts on his blog skorks.com.
So what do you need to be a great development manager?
After reflecting on the question for a bit I came up with a set of traits that I would love to see in any dev manager I work with, and that are also more than just your stock standard advice about walking around, networking, and looking people in the eye.
1) Hire People I Actually Want To Work With
As a dev manager you're probably responsible for hiring new team members and there is often a lot of pressure to fill any open roles quickly. After all, as long as a role remains open the team is not working at full capacity. Do not give in to this pressure! Hiring decisions are some of the most important you can make and it behooves you to take your time about it. As a guideline, you need to look for someone who will share the culture of the team (obviously), someone I can respect as a peer (developer) as well as a human being. Get me to participate in the hiring process if it helps. Long story short, you're not just looking for an extra set of hands, but instead you're trying to find someone who can enhance the team you already have.
2) Don't Micromanage
This one can be tough especially for dev managers that were developers themselves at one point, so do watch for this one in yourself. There are few things that annoy me more than being micromanaged. Constant status updates, inane advice, trying to tackle every problem yourself (when the team is clearly better equipped), acting in a stressed-out fashion in front of your team. All these are little things that grind on people and add up to big issues down the track. You've done a great job hiring me (see above) now trust me – as a professional – to do the job I was hired for and do it well. If the status changes, I will let you know. If I need advice or help, I will ask. Don't narrow your focus too much, trust your team and they will recognize that fact and do their very best to validate your trust.
3) Always Follow-up On Your Promises
One of the things that you always need to be conscious of is forgetting to do/act on something when you promised the team (or a team member) that you will do so. Always remember to keep your promises, carry a pen and a writing pad with you always and whenever you promise something write it down (makes me feel good when a dev manager does that, makes you feel like your input is valued). I first learned about this one from Tom DeMarco's and Tim Lister's "Peopleware". Oh, by the way, if you haven't read that book yet I suggest you do so as soon as possible.
4) Have Excellent Business Domain Knowledge
Sometimes the dev manager is part BA and part business representative (especially when those are not around for whatever reason). The team expects you to have the answers, to know a little more than they do about the domain you work in. They will cut you some slack if you're new, but if after a few years you still don't have a good understanding of the business domain you're in, you're doing something wrong. Make an effort to gain this knowledge, if you can do it organically – great, but if not, do go out of your way to acquire it.
5) Have Excellent Technical Skills
This is probably not strictly required, but it is "oh so good" to work with a dev manager who you can respect as a fellow technical person. Since you will have excellent domain knowledge (see point 4), it is actually really great to sometimes bounce some of my technical ideas off you. And when you can contribute something constructive, make me think of it in a different way, or even point me in a technical direction I haven't though of, well that is just awesome. You will walk away from that conversation with me respecting you a little more every single time (developers respect people who are technical, that's just the way it is). But be hands-off about this, don't force your opinions on your team (remember what I said about micromanagement).
6) Create And Maintain Excellent Relationships
Whenever I need help with an external party that I have become involved with (for whatever reason) I expect you to be able to smooth the waters for me if I need it. The dev manager is someone the team can turn to (if necessary) when customers, stakeholders, other managers or anyone outside the team engages them. This means you need to develop and maintain good relationships with everyone who is in some way involved with your team. If I need to chat to someone external about an issue I am having, you should be able to tell me who that person is and make the introductions in such a way that the external party is positively disposed towards me (i.e. they like you so they like me by extension). This skill is so helpful in so many situations; you really can't be effective without it.
7) Care About Me As An Individual
Call me selfish but I like to think that I am more than just a cog in the machine that is my software team. I really appreciate a dev manager who takes an interest in my personal development beyond just what I am able to do for the team. You don't need to manage my career (I can do that fine), but an occasional one-on-one to ask whether I need anything, or maybe an offer to send me to a conference or course once in a while will not go unnoticed. It makes the team environment that much nicer – a great place to work and you can make it happen with just a few hours per year out of your time (per person obviously :)).
8) Participate In Team Social Activities
Team members bond more during one shared social experience than during weeks of working together. You don't want to miss out on that. And if you think the team doesn't want you there – you're mistaken. It is truly great to work with a dev manager who can be a friend (and drinking buddy) outside work. It's hard to explain, just trust me on this one.
9) Be A Process Champion
You can't be a decent dev manager if you don't care about how your team does it's work (the processes they use). You need to lead by example in this case and champion all the best practices that the team is trying to employ. This means you endorse the practices the team comes up with and suggest some if necessary. It also means you educate people about the process you team is using, not just people internal to your team but also customers and other stakeholders. This doesn't have to be a major part of your day, but the team does have to know that you're behind them and will back them regarding their process if necessary.
10) Have Boundless Energy
This one is the most important in my opinion and probably the hardest to maintain consistently. There is a lot of stuff every day that demands your time and it is often hard to get through everything – so some things get put on the back-burner and often, never get done. You have to watch out for that one and do your very best, be as efficient as you can be, to get through everything that is on your plate. You have to chase people up, get issues resolved, obtain commitments from people (concrete ones not fluffy ones) – don't let things drag on. It's hard to describe, but you know when you're working with someone like this. Roadblocks seem to disappear quickly, no-one feels left out, and stuff just seems to happen (stuff that you thought had no chance of happening). This trait is not just good for dev managers, everyone can benefit. The most important thing about this is that it works in conjunction with most of the other traits I described above and makes those traits that much more effective.
Even having some of these skills will make you a decent dev manager in the eyes of your team and having most will put you well on your way to being highly regarded not just by your team but also by customers, stakeholders not to mention your own management. And don't despair if you believe you're missing some of these, as long as you're aware of your limitations you can work on them as you grow in your role. Like all skills practice really does make perfect, if you endeavour to develop these traits they will eventually become second nature. And when they do, give me a call – I'd love to come work with you 🙂.