Traits That Make A Good Development Manager (guest post)

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.

Over the last few years of my career as a software developer I've had the opportunity to work with several development managers. Fortunately for me, most have been good – some very much so. This however is certainly not the rule in our industry (or any industry for that matter). Being a good manager is tough and not many people get it right. But, it is even worse when it comes to software development. Developers are ornery beasts, with strange ideals and strong opinions, and even if you come into development management from the "trenches" you need to develop a whole new set of skills to succeed in your new role.

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 :)).

95033454_d5cf0ecc31_o 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 🙂.

(images by mshades and showmeone)

Twitter TwitterRss SubscribeEmail NewsletterDelicious Bookmarks

Latest, greatest and favoritest posts:
Checklist for the Agile Manager (Presentation)
Empowered, Whether You Like It or Not
Great Managers Have No Secrets

  • Blog Post #300 (Almost)
  • Less Is More: Swimming in Sweden (guest post)
Related Posts
free book
GET MY FREE BOOK!
“How to Change the World”
  • anonymo

    What should I do about a developer who’s level of programming is really low.
    It is a junior programmer, but the code he writes has code-smell written over it, in practically every line.
    Naming conventions, he does not follow them,
    Copy pasting a LOT, plunks of code (+20 lines) are duplicated in the code all over the place.
    OO concepts, since he’s copy-pasting that much, I don’t think he gets it.
    I was thinking about code-reviewing some of his code, and explaining what’s bad why. But I’d have to completely erase his code…
    Any thoughts on how to handle situations like this?

  • http://www.skorks.com/ Alan Skorkin

    It is a tough situation and there are two scenarios.
    The first is, he is simply a junior developer and doesn’t know any better, (i.e. he is pretty much a blank slate and has no idea about practices conventions etc), but he is eager to learn. In this case you can shape his thinking. Pair programming would be the first thing I would suggest to you. I am not sure if you do this regularly at your work place, but in this case, there are no downsides to it since you’re not getting much productivity from him right now. You can grow this this developer in leaps and bounds if you pair him up with a more experienced developer. Other things you could do is to recommend books, articles etc. for him to read. And when I say recommend, I mean recommend in the strongest possible terms. Really young developers sometimes need very clear boundaries (not always but sometimes). So try being very explicit with your expectations, i.e. that you don’t want to see copy/paste, that you want to see proper naming conventions (and explain what they are) etc. Do all these things and within a few months you’ll get a reasonably decent and productive junior developer. You also will have helped a person grow personally and professionally.
    Of course the second scenario is, this person is willfully ignorant, i.e. they don’t really want to learn and may not have the capabilities or mindset necessary for development work (i’ve seen this a few times). In this case you have two courses of action, one is to find a different role for the person to which they are more suited e.g. they might make a good tester, or maybe a business analyst if you have those, if you can do that, it would be ideal. If doing that is not a possibility, you’re pretty much left with one course of action, you need to let them go, there is no point to have the rest of the team carrying a person if that person is not willing to learn and there is no other place for them.

  • http://agileconsulting.blogspot.com Jeff Anderson

    Absolutely amazing article, for sure I am sharing this with my clients,and be more diligent in following the advice you have given…
    Regards
    Jeff
    my blog

  • http://hnaser.blogspot.com Hussein Nasser

    Great tips,
    I wrote an article exactly the opposite
    http://hnaser.blogspot.com/2009/08/3-ways-to-engage-your-boss-into-your.html

  • KP

    Hi,
    This is really good article. I have just been promoted to Development manager, but i am really confused from where to start with, i want to improve team in various areas like coding, communication etc.
    If you can provide few pointers, it would be helpful to me.
    Thanks,

How to Change the World - free Workout - free
CLOSE