I’ve recently just finished a 5 year stint working for an engineering company in the UK as a project manager and JEE lead developer. Like many other managers, I actually started life as a Java developer (and sole IT member of staff) and gradually evolved into a hybrid management and development role. Whilst in this role I grew a team of developers and support staff working underneath me and coordinated and ran a number of projects.

Earlier this month I left the company (and the UK) in to spend some time in Australia. Before leaving the company I was asked to write a description of my job role and the various responsibilities to help my successor when he took over. As I was compiling this list I also found myself inadvertently writing advice for performing these various duties, the essence of which I decided to flesh-out and convert into a series of blog posts. The first (this one) will deal with managing teams of developers and some tips/advice with regard to this. The second will go on to look at how to perform the management and development roles from a personal perspective (i.e. how to remain a productive developer but also cope with managing a team). I’ll them move on look at some of the tools and approaches I utilised to help me in this role and if I can think of anything else then maybe I’ll add more posts!

So, the points listed below are written in no particular order. Nor do I consider the list exhaustive in any way, these are just the areas that seemed to stick out more than most in my mind as important to consider. I must also admit that I probably in all honesty did not follow these religiously, the implementation is always harder than the intention! The last thing I guess to bear in mind is that every organisation (and really every job) is different and what worked for me obviously may not work for you.


Part 1 - Team Management

Managing a team of developers can be a daunting prospect, particularly if your background is purely as a software developer. Software development, whilst technically challenging, requires a rather different skill set to managing a group of people. In this first article I want to review some key areas that I’ve learnt are important to consider when successfully managing a team of developers.

I’m explicitly avoiding discussing different project management techniques or approaches (agile, scrum, waterfall etc etc - the decision to use any one of these could be a blog post in its own right!) and rather I’m focusing on more general team management principles.


Get to know your team

Sounds simple, but this is probably one of the most important things you can do as a team leader. Getting to know each of the members of your team, not just on a social level, but really more on a psychological level will give you a huge advantage when it comes to running your team on a daily basis. Learn your developer’s insecurities, strengths, weaknesses, what makes them tick, what makes them balk. Who you can trust to perform certain types of tasks? Who should you supervise more closely? Who can you let off the leash? Who can you give a 10 line component description to one day and get a finished component the next?

If you can answer these types of questions about your team members then it will help you with your decision making enormously. It makes matching different tasks to different developers much more straightforward and can help ensure you choose the right person for each job. Not just that though, it will also help you become a better people manager. You’ll know who in your team is independent and can be left to perform their tasks with little or no supervision. It will also show you who maybe needs more guidance or an occasional arm around them to boost their confidence. The bottom line here is, the better you know your team, the better you can manage them and the more productive and efficient you can become.


Don’t micro-manage - learn to trust your team

This is an important, but in many ways difficult skill to learn, particularly if you happen to know your domain well and your team members maybe don’t. It’s important you remember that you’ve hired (hopefully) talented developers who shouldn’t require your constant supervision. On the contrary forcing your involvement in every decision they make or ‘backseat coding’ is far more likely to annoy and unsettle than to add any real value. Try not to prescribe to them how they should do their job, don’t stifle their creativity by making decisions for them. Try not to second guess every decision your team members make. If you’re doing this then as the meme says, you’re doing it wrong!

Micro-management is a waste of your time and a waste of your developer’s time. It unsettles your team and shows that their line manager doesn’t have faith in their abilities. If you have concerns about how your developers are working then change your management approach. Encourage your developers to work on their own solutions. It shows you trust their judgement and respect their abilities. If you’re keen to keep slightly more control, or have more inexperienced team members, then get your developers to sketch out their design ideas prior to implementation. Spend a couple of minutes listening to how they propose to implement a solution, more often than not it will reflect the approach you would have taken anyway.

Try not to run roughshod over your developer’s ideas and don’t think yourself infallible, just because you’re also a developer doesn’t mean your implementation (ideas) are necessarily any better than a member of your team. Stepping back and stopping yourself from micro-managing will give you more confidence in your team, show them you respect their contributions and ultimately lead to a more productive working environment.



Be accessible to your team

I always considered it fundamentally important that my team members feel they could approach me about anything at anytime… well to clarify, almost anytime. I have always tried as far as possible to maintain an ‘open door’ policy with regards the teams I have managed. As a developer it can be hugely frustrating and time consuming if you reach a point in your work where you require input from a line manager before you can progress. Often this input might be as simple as a yes/no question or a 2 minute conversation. Being in a position to quickly answer your colleague’s questions can in the long term save time and promote greater efficiency.

The hard part with this of course is managing interruptions to your own work brought about keeping an open door policy with your staff. I might discuss this problem in more detail on my next post, but briefly one suggestion is to make sure your team members are aware of when you require ‘quiet time’. Thus your default status (for want of a better phrase) is always available, except when you say otherwise. The point of this really is that it’s important your team find you approachable more often than not.



Keep your team motivated and happy in their work

Let’s face it, although most of us as developers take pride and pleasure in the work we do and enjoy development work in general, the work we do in our nine to five is not always exciting and groundbreaking stuff. I’ve always felt that one of the key responsibilities of the team leader to try and help keep your team happy and motivated. If there are sets of tasks that are generally unpopular or just plain tedious then I will always try and split them between several developers. If you know a developer has had a tough time on a component recently then, if the project and timescales permit, suggest he take on an easier or more interesting task next.

Another suggestion is to try and take the ‘chore’ aspect out of the daily routine and introduce a fun element. One technique I implemented was to keep a log on a whiteboard of who had broken the build each month and how often. The person who broke it the most each month had to buy a round of Big Macs for the rest of the team. I know, this was hardly a health conscious strategy, but it helped keep our nightly build more consistent and was a source of entertainment for the team each morning when checking if the builds had run or not (I think it also had a team bonding effect when I was the one who had to buy rounds two months in a row!).

Remember also to protect your team members. I encourage my developers to go out into the user-wilderness on a regular basis to speak to the end users and gather feedback. As is inevitable in these situations conflicts can arise. Whilst I’m not advocating you fight your developers fights for them, it’s important that you be prepared to stand up for you team members if you think it’s right to do so. Doing so will strengthen your team and help keep the respect of your team members. 

Finally in this section just remember sometimes to have a laugh. Occasionally take your team out for drinks, a pub quiz or some food, whatever rocks your boat and gets people interested. Building a good relationship with your team members will pay dividends in the long run.


Don’t be mean - respect your colleagues and earn their respect back

This one is simple really, treat your team members as you yourself would like to treated. Try not to have an attitude, don’t let your ego stomp all over the people who work for you. Try and show patience, particularly with new or more inexperienced team members. Remember how you might have struggled to grasp particular concepts or learn certain techniques or frameworks in the past. Offer a guiding hand to team members through difficult times. Celebrate their successes, don’t be too harsh with failures but analyse and promote learning from their mistakes. Be receptive and listen to the ideas and suggestions of your colleagues.

When you meet with friends or peers outside of work, you’ll often hear stories of the dreadful-boss, the dragon?boss or the ignorant-boss. More often than not these stories will be punctuated not just by ridicule of the boss caricature, but by tales of how members of that team are slacking-off, actively looking for new work or even subverting their boss. Try not to become that caricature. Don’t expect the immediate respect of your teammates, but expect to earn this respect through your actions. Doing so will not only lead to a happier and more productive team but should also help keep your staff turnover low and consequently save on the time and expense of recruiting new team members.



Manage and develop the careers of your team members

Another important part of the role of team leader is to help guide and manage the careers of your team members. I’ve always felt it essential that you challenge your team members and push and encourage them to learn new skills and take on new responsibilities. Try not to let your team members stagnate, bashing out repetitive code day in and day out. This will probably lead to dissatisfaction, an unhappy team and drops in productivity. Instead, push your team members to expand their knowledge, learn new skills and step out of their comfort zone. Doing so will not only grow their skill-sets, but will show your confidence in them and ultimately make them better developers and your team more productive. If time and budgets allow, send them off on courses, encourage them to achieve professional qualifications.

Computer science is a dynamic and ever changing field. You should encourage your team members to embrace this fact. Push them to learn new skills, new technologies. Don’t allow them to be afraid of trying new technologies in the search for solutions to problems. You’ll find your developers are more motivated, more interested in their work and invariably they’ll contribute back to you (and your projects) knowledge and breadth of technical knowhow. Spring, DWR and Unitils have all become part of my core development skills, in part because my team members went and researched, tested and reported back favourably on them. Of course if you like this approach then it is also your responsibility as manager to make sure that your team members are given time to pick up these new skills and to learn these new frameworks.


Hire wisely

Hopefully in your role as team leader or project manager you will have a significant say in the makeup of your team. If you get the opportunity to influence (or better still organise and run) the hiring process for your team then take full advantage of this. Obviously technical competence, experience, salary expectations and a whole host of other factors come into play when selecting the right candidate(s) to join your team. What I also pay close attention to is in trying to gauge whether the candidates I am interviewing will fit in with me, my management style and also with the existing team. Obviously this is an imprecise art and an interview situation is probably not the best judge of someone’s character on a day to day basis. Nevertheless it is something that is probably sometimes overlooked and it’s worth bearing in mind the consequences of unsettling a balanced team with a new member who is a poor fit.

Whilst on the subject of hiring, the other benefit of my experience so far that I’d like to share is not to be afraid of hiring fresh graduates from university. Many employers are nervous about taking on fresh graduates, but my policy has for some time been the opposite. I’ve always found the graduates I’ve recruited to be keen, hard working and hungry to learn and impress. Yes there is always a learning curve for making the transition from student to productive team member, but in my experience (and with the right graduate of course) this can be bridged within the first month or two.

In my last position I maintained and cultivated a close relationship with my local university and particularly with a number of members of the School of Computer Sciences faculty. This relationship worked well for both parties, I would receive cv’s after graduating students were informed of a vacancy and in turn the university was seeing their role of preparing young people for employment through to fruition. Not only that, but recruiting direct from university saved a chunk of cash that might have gone to a recruitment agency, which kept my bosses happy :).

(In the past we also worked on a number of collaborative projects that saw the university get academic acclaim through papers and my department gain the technical expertise of the university. If you’re in the UK I’d really recommend at least taking a look at these government funded collaborative projects to see if they’d fit your organisation - Knowledge Transfer Partnership.)




If you’ve made it this far then I hope you’ve enjoyed what’s been said and can take some value from my own experiences. It’s clear that being a successful team leader is not an easy task. There are many different variables that can affect your success at performing this role, many of which are directly linked to your relationship with your team.

In part 2 of this post I’ll move on to discuss undertaking the role of lead developer and project manager from a personal point of view - how to juggle your leadership responsibilities along with your own development role and how to try and stay on top of everything. I’ll then finish up by discussing some of the technical areas and strategies that I’ve found useful in my own work in this role.