Tag Archives: teambuilding

Team leadership in IT

Its accepted that team management should be situational, based on a) the goals of the team and b) the team itself. The classic situational leadership diagram below goes from a directive model (lower right) anti-clockwise based on the competence of the team to one of delegation (lower left).


I have always found supporting / empowering far more effective in IT than directive. This is for two reasons. Firstly, I believe that most people in IT are highly trained and motivated to do a good job, and the role of the manager is to ensure they know what a good job is (what’s required) and to facilitate the doing of it (to remove blockers and problems).

Secondly I believe that management is best when it is about both delivering what the organisation needs and growing the members of the team. This was probably put best by Ralph Nader when he said “I start with the premise that the function of leadership is to produce more leaders, not more followers.”.

That’s my personal approach. I keep in touch with thinking on team management though, because it is so important to the business I am in. As part of this I came across some research that I think is worth sharing.

Project Oxygen

In the late nineties Google undertook a project to analyse all of the data they had regarding what made effective managers. The project, Oxygen, was widely written up at the time – mostly along the lines of “is that it?”. And in fact most of the rules they came up with are what you would perhaps expect.

The interesting thing though, is that the rules are in order of importance and the order is absolutely not what you would expect. Here are the rules they came up with:

Eight good behaviours

1. Be a good coach
– Provide specific, constructive feedback, balancing the negative and the positive.
– Have regular one-on-ones, presenting solutions tailored to your employees’ specific strengths.

2. Empower your teams and don’t micromanage
– Balance giving freedom to your employees, while still being available for advice. Make “stretch” assignments to help the team tackle big problems.

3. Express interest in team member’s success and well-being
– Get to know your employees as people, with lives outside of work.
– Make new members of the team feel welcome and help ease their transition.

4. Don’t be a sissy: Be productive and results-oriented
– Focus on what employees want the team to achieve and how they can help achieve it.
– Help the team prioritise work and use seniority to remove roadblocks.

5. Be a good communicator and listen to your team
– Communication is two-way: you both listen and share information.
– Hold all-hands meetings and be straightforward about the messages and goals of the team. Help the team connect the dots.
– Encourage open dialogue and listen to the issues and concerns of your employees.

6. Help your employees with career development

7. Have a clear vision and strategy for the team
– Even in the midst of turmoil, keep the team focused on goals and strategy.
– Involve the team in setting and evolving the team’s vision and making progress towards it.

8. Have key technical skills so you can advise the team
– Roll up your sleeves and conduct your work side by side with the team, when needed.
– Understand the specific challenges of the work.

Three pitfalls of managers

1. Have trouble making a transition to the team
– Sometimes, fantastic individual contributors are promoted to managers without the necessary skills to lead people.
– People hired from outside the organisation don’t always understand the unique aspects of managing at Google.

2. Lack a consistent approach to performance management and career development
– Don’t help employees understand how these work at Google and doesn’t coach them on their options to develop and stretch.
– Not proactive, wait for the employee to come to them.

3. Spend too little time managing and communicating

So technical skills – which you would perhaps expect Google to major on – was the least important (a common mistake though – see my post on Recruiting project managers for my thoughts on this point). Having a clear vision and strategy (which almost always comes in at number one on similar lists) is similarly less important. What was at the top were soft skills – coaching, empowering, taking an interest in people.


What does this tell us?

Well remember these were people at Google – managing highly paid, highly motivated, intelligent self starters. But then so are most people in IT. So the key point for me is that most of your team members need support rather than traditional management. Which fits in with the point I made at the beginning – obviously we need to ensure people know what is needed and are focussed, but then think mentor and facilitator rather than director and dictator.


Project oxygen

Recruiting project managers

In the past I have put a lot of effort into recruiting, mostly project managers. In terms of delivering, the project management level is key. You can have a successful project with a bad PM, but in my experience only if someone else (typically the team lead) takes over the PM role. So having spent a long time doing this, I thought I’d write down what makes a good project manager and how you know when you are interviewing one.

Lists of qualities

If you ask people what makes a good PM they will typically say things about Communication, Vision, Enthusiasm, Delegation, Calmness (I could go on).

The problem with these definitions is that they focus on defining the person rather than what the person can achieve. They’ll get you a project manager, yes – but not a great one.

What a candidate has done is plainly important. But just as important is how they have done those things. There are two types of things we should be looking for in a great PM.

Look for excellence

Aristotle said that “We are what we repeatedly do. Excellence, then, is not an act but a habit.” If somebody has that habit it will show, not just in their work but in everything they have done (including their approach / preparation for interviews).

Therefore you should look for achievement in any area of life – what you are looking for is not so much what they did but the approach they took to doing it and the result. Yes, many people can say they are in a band or their hobby is keeping fit. Dig deeper. What have they achieved in that hobby? What role did they play in it? You are not necessarily looking for overachievement (although that is no bad thing) – you are looking for a clear goal and plan followed by excellence in the achievement of it.

Learned behaviours

Well OK, we would all agree that excellence is something we want to see in all of our people.

Learned behaviours, however, are role specific. A project manager needs a different set of behaviours than a developer, and both of them to a tester. I think a great project manager should consistently show a history of:

  • Finishing tasks
  • Building good teams
  • Dealing with complexity

Let’s look at each of these.

Finishing tasks

A talent for finishing is different to the Completer Finisher role. The Completer Finisher is a perfectionist and as we all know this can actually get in the way of finishing.

Good project managers are focussed on the final goal. They prioritise so that the most important stuff happens soonist and are happy to sacrifice the unimportant activities to do this. They are impatient with tasks that are 95% complete and the people who never seem to get past that. They know what is happening on the ground, and they can spot problems in advance. They are thorough and have high standards yet know that “perfect is the enemy of good”. They do the work themselves if there is nobody else to do it. Nothing will stop them until they are finished and complete.

So look for project managers that have a history of finishing. At work and in their personal lives.

Building Great Teams

Great project managers have a history of forming great teams. They know that they can get more done with a strong team behind them. They focus on people as well as tasks. They are expert at managing-up and include wider stakeholders such as sponsors and customers in the team. They trust and are trustworthy. They apply tough love. They deal with under performance quickly as they know it threatens the team. But they believe everyone can do well in the right role. They are proud of their team and what they’ve done together.

So look for a history of team work and team building.

Dealing with Complexity

Great project managers are used to dealing with complexity. They think clearly, easily cope with a lack of complete data, are creative in solving problems, and balance risk confidently. They are flexible, adapt processes to fit the local need, and reject a one-size-fits-all approach. They know when to bend the rules to make progress, when to intelligently disobey. They can deal with many tasks at once; they might drop something, maybe even a lot of things, but they never seem to drop anything important.

So look for recurring patterns of adaptability and creativity in the face of complex challenges.

What about Knowledge and Experience?
I think knowledge and experience are less important than the points listed above. I have met lots of people who know all the theory, but who are complete failures when given a project to lead. The project manager needs to understand what they’re doing and what the team is doing but this understanding isn’t, by itself, any guarantee of performance.

The most useful understanding usually comes from a combination of learned knowledge and practical experience. Look for understanding in three areas to supplement behaviours:

  • Project Management Understanding
  • Technical Understanding
  • Domain Knowledge

Project management understanding

A project manager has to know the their profession. Know what a Gantt chart is. Know how to put together a valid, workable plan. Know what to put into a status report and know when it is okay to have a discussion instead.

Regarding software development, a project manager has to know user stories, velocity, story points, sprints, stand ups, release management, sprint reviews, planning poker, team estimation and so on.

This stuff is all trainable, but generally to have turned this into deep understanding, the person will have had practical experience.

Technical understanding

Technical Understanding means the project manager can understand the job being done by the people on the team. Usually that knowledge comes from having done the job in the past. So most of the good software development project managers I know have been developers in the past. They don’t have to have been good software engineers, or still be able to do it, but they do need to understand what developers are talking about when describing tasks and problems, and understand the problems developers face.

Domain/ market knowledge

Whereas project management understanding and technical understanding are critical, domain knowledge is nice to have. It helps if the project manager knows what the business does. But a good person can pick this up as they go along.

Its odd that domain knowledge is ranked so highly by HR teams and recruiters. I think this is because its easy to do. Recruitment today is – unfortunately – a numbers game. Searching for key words, be it sector background or technical background, is a simple way to cut those numbers down. Unfortunately it misses out the really important points we should be looking for.


So there it is. If you need a project manager look for somebody with a proven history of building great teams, who can handle complexity, and most importantly, with a background of finishing. They need to understand project management practices (ideally Agile and waterfall/ gate based) if applicable, and the technical job as well. Sector knowledge is a bonus. But pick talent over knowledge every time.