Category Archives: Teams

The four types of goal driving reviews

Given the importance of staff motivation I’ve found it odd that many organisations have little structure around their annual review. Of course they have a process – typically timed around the annual pay review and bonus cycle – but often little guidance as to how the actual goals are arrived at. The most succesful reviews I have seen focus on four specific areas:

1 – task based. The fundamental tasks the business needs you to perform. An example might be “deliver the reporting subsystem for XXX within your initial time estimate”. These are the tactical things the business needs to have done. They are the most important goals, but also the most subject to change. In many companies these are the only goals given

2 – role based. These are goals aimed at increasing your effectiveness in your role. They might typically involve training, mentoring (being mentored), attendance on conferences or generally doing somethng which increases your effectiveness in your role

3 – strategy based. These are the longer term goals which contribute the overall IT vision, for example “work with QA to develop a robust set of automated tests addressing all bugs found within your sprints”. Of course this depends on having a goal and vision for IT itself, and we address that later

4 – personal development based. These are based upon your personal development goals. The trick here is to align personal develpment goals and aspirations with the needs of the company. Arguably these are the most important goals; after all,  if you only have (1) you have someone doing a job, if you have (2) you have someone learning to be better at their job but not moving on in their career, if you have (3) you have a person who feels involved with and part of a larger whole. Only when you have (4) do you have someone who is delivering, happy and has a career path within the company.

So lets look at each of these types of goal.

Task based

IT strategy and vision

The vision for 2013/14 is “Engineers feel that their job is important and they can make a difference. They are excited by the prospect of creating something new and innovative that matters to our customers. They work to a routine which they believe is the best in the world. They can be counted on to deliver new features faster and to a higher quality than our competitors.”

The strategy is “Embed a development culture to deliver to committed timescales in a deterministic, repeatable and predictable manner. Strengthen key strategic areas with the best skills and talent to build a highly energised, effective and disciplined team. Provide our customers with the best products by developing a culture that enables the development team to innovate and deploy new features faster than our competitors.”

The Goals for 2013/14 to deliver the strategy are:-
1. 80% Sprint Predictability
This means that 80% of the stories commited to are delivered within the planned sprint. Why not 100%? Well because if we consistently hit 100% then by definition we are not setting our sight high enough!

2. 80% bugs contained in Development/QA
This means that 80% of the total bugs found are within the sprint dev/QA process – not within Integration Test or UAT.

3. 90% Requirements and Design Stability during sprints
This means that 90% of stories within a release are not changed within that release. Obviously stories change – that is arguably the point of Agile. However there is a difference between changes due to more detailed technical planning and changes due to fundamental changes in architecture. These are what result in stories being stopped and re-planned/ rescheduled, and these are what we want to minimise.

This feeds into a maximum of 4 objectives:-
1. Role Based Objective – typically “deliver x by y”
2. Predictability Objective to help secure the 80% of deliveries being on time
3. Quality Objective to ensure that we contain 80% of bugs before we release
4. Requirements and Design Stability to ensure that we have stable requirements and design before we start our sprints
The R&D LT will track each goal at the department level and publish these on a monthly basis so that there should be no surprises at year end.



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

Personal productivity

In running teams and departments I have always been surprised at the variety of personal time planning approaches people adopt, ranging from the hugely organised to the completely event driven. I believe that personal organisation forms the bedrock for team productivity – for that reason I always encourage people to use some productivity approach and mentor them if they don’t.

There are a number, but the best in my view is still “Getting Things Done” by David Allen. It is the only approach to have a basis in formal theory, indeed philosophy. There is a website – in fact a minor industry – dedicated to GTD, I shall quickly summarise the basics.


Document all the tasks you need to accomplish in a system other than your memory. Include tasks to be worked now and in the future. Include both work and personal tasks.
Consult your lists often so you’ll make wise decisions about the next task on which to work.


Stress is reduced because you won’t have to worry that you forgot about important tasks, or that items have fallen down cracks.

You won’t forget about important tasks, and items won’t fall down cracks.

You will make better choices about what to do at any particular time, taking into account where you are and what resources you have available.

Managing Workflow

GTD is fairly straightforward. It consists of five stages:

1. collect inputs
2. process inputs
3. organize results
4. review options for next actions
5. carry out a next action.

GTD workflow copyright David Allen Co

Collect Inputs

Inputs include:

  • notes written on scrap paper, napkins, etc.
  • notebooks
  • email (the most common in our business obviously)
  • calendars
  • flyers/magazines
  • books
  • anything you’ve accumulated on your desk

Process Inputs

Here are the steps to follow when processing each of the collected inputs.

First determine whether some action needs to be taken at all.

If it does require action then determine the next action that is required. This must be a tangible activity. For example, instead of “update docs”, an action could be “produce quality strategy paper”.

1. Do it if it can be completed in two minutes or less.
2. Delegate it if you are not the right person to do it and it can be delegated to someone else then add it to your “Waiting For” list to track its completion.
3. Defer it by documenting it as something to be done later:

  • If it requires multiple actions, create a project for tracking the actions and document them (a project is just a task that requires more than one action to complete)
  • Document the required action(s) in either a calendar (for date/time-specific reminders) or a “Next Actions” list (for non-date/time-specific reminders).

If it doesn’t require action then select one of the following options.
1. Throw it away
2. Incubate it by adding it to your someday/maybe list
3. Store it in your reference filing system (ideally searchable such as Evernote).

Organise results

Information related to projects and tasks (actions) will be stored in the following locations.

  • project list
  • “next actions” list categorized by project and context
  • calendar for “hard” date or time specific actions that must be performed (for example appointments and meetings)
  • reference files
  • “waiting for” list list to track actions you are waiting for others to complete
  • “someday/maybe” list for actions which you will get to/ plan at some point but don’t want to forget

There are lots of ways you could maintain the lists and storage. The obvious for us is computer support.

Ah, but where to start? Google GTD and you will find hundreds (almost) of packages, advice, books on implementing GTD. Do whatever works for you, on the mac omnifocus and things are good, on windows I always found outlook great provided you created categories for NextActions, WaitingFor, Read/Review, Someday/Maybe and Projects.

Actions are also categorised by Context. A context describes a basic requirement that must be met in order to do an action. It can be

  • a location (such as home or office) where you need to be, or a meeting you need to be at
  • a specific tool (such as a phone or computer) that must be available
  • a person (such as your boss) that must be present

Review options for next actions

There are three techniques for deciding what task to perform at any given time.

Four-Criteria Model for Choosing Actions in the Moment

1. Only consider actions that can be performed in your current context (defined by your location and the set of resources available).
2. Only consider actions that can be completed in the amount of time you have available. Actions should be defined as small as possible and not require multiple steps.
3. Only consider actions that can be addressed given your current energy level.
4. Decide between the remaining actions based on their priority or payoff.

Threefold Model for Evaluating Daily Work

The next thing you do can be one of:

1. Do an action from your “Next Actions” list.
2. Do work as it shows up if it is more important than anything on your “Next Actions” list.
3. Define additional work (adding to your lists) based on new inputs in your in-basket, email, voicemail and meeting notes.

Carry out a next action

And away you go…


Reviews are what makes GTD work over time.

At least once per week, review all incomplete items in your lists and flag the ones that need to be addressed soon.

At least once per year review the content of all the folders in your reference filing system and throw out items that are no longer relevant.

Once a week or less, review your “Projects”, “Waiting For” and “Someday/Maybe” lists to see if anything in them needs to be addressed soon. This review can generate new items in the “Next Actions” list.

At least once per week but ideally daily, gather new inputs and add them to your system.

Six-Level Model for Reviewing Your Own Work

There are six perspectives from which to view tasks is order to assign priorities to them. Consider how completing a given task will help to achieve the following.

life goals
3-5 year goals
1-2 year goals
areas of responsibility
current projects
current tasks

So that’s it. Believe it or not, that’s a synopsis of the approach – for more information I recommend the book.

A word of warning. GTD and task management generally is easy to get sucked into and find yourself spending more time organising tasks than you do actually doing them (trust me, I’ve been there. It’s a geek thing).

But there is no doubt that in the fast paced business we are in you need some approach to organise our time. So find something that works for you. Then get on with the actual tasks you need to do!

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.