Tips for managing technical people: Set Goals


1 March 2015, by

Galvanizing the geeksThe following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.

Micro-managing your super-bright and super-knowledgeable team isn’t going to work well for you. The alternative is to set high-level goals for output. To be meaningful these goals needs to have specified dates for completion. Development tasks will usually also have task estimates (for example, ‘this task will be successful if it takes 10 days or less’), but these are really just a variation on end dates.

It’s very tempting to make your own ‘correct’ goals for your team. If you used to be a coder, you probably know how long it would have taken you, and you don’t want to be giving the people beneath you an easy ride. If you’re not technical, it will be even worse – I have heard many cries of ‘It can’t possibly take that long!’ But rather than being motivating, tough, one-sided goals give the people responsible for delivering them a get-out clause. The goals were unrealistic, everyone knew they were unrealistic, the business requirements changed, someone else let the team down. For a goal to be an effective motivator, the person who is delivering the goal needs to be signed up to it. The best way to get someone bought in is for them to set their goals themselves.

A lot of managers will worry that their teams will set themselves goals that are too easy. Funnily enough, teams often do the exact opposite: they set goals that are too hard. And these are even worse! If you know a goal is too hard, how can it be motivating? If a team knows that whatever they do they won’t hit the goal, how can they work towards it?

Until your team is well-trained in setting goals, it may not be sensible to just leave them to get on with it. Setting goals that are achievable and challenging is very difficult. It requires a lot of understanding of exactly what is possible, and it includes (however you dress it up) the necessity of having to estimate pieces of work. You can do it via Scrum story points, or estimate in hours or days, but you do need an idea of how much work there is.

The good news is that setting and hitting goals is quite addictive. Once you get into a pattern of successfully achieving what you set out to, you start to feel like a winner – especially if other teams are often late or behind on their goals. Teams with a strong goal-hitting culture will not only deliver more reliably (‘one feature for sure’ is almost always better than ‘two features, maybe’), but will also start to increase the difficulty of their own goals as the ones that they are hitting get too easy.

Of course, your job also requires you to pass on requirements from the business. Sometimes these are the most effective goals. The business needs a new feature two weeks on Friday, otherwise we won’t be ready to launch. The business needs this extra screen, but only if it can be developed within 10 days – can you do it? This communication must work both ways. The incentive for the business is to get as much done as cheaply as possible; left to itself, the business will stipulate unachievable goals every single time. The technical team needs to feed back to the business in this case, before the business makes commitments based on deliveries that simply aren’t going to happen.

Agile development also has a concept of short-term goal-setting. All development is done in ‘iterations’, regular time periods, usually between one and four weeks long, in which the most important subset of the total functionality is developed.

A good example of how successful goal-setting can turn a project around was a team working on a payment provider. The project started slowly, with framework setup eating up more time than expected. The first stories were completed much more slowly than they should have been. There was a sense of fatalism on the team; they had a number of story points to complete each week, but they knew that it wasn’t going to happen so they didn’t even try. The project was behind, but no-one seemed to have a sense of urgency about it.

The first step to recovery was examining why the goals weren’t being hit. The most obvious reason was the one that everyone knew: the framework setup was taking too long, and the early stories were having to absorb some costs that would pay off later in the project. But by how much? By unpacking the framework points into separate stories and re-estimating accordingly, the project manager was able to communicate what was needed for the project to be successful, and the team immediately worked with more conviction towards the realistic (although still pretty tough) goal. They became one of the best-delivering teams, and turned the project round from a disaster to a triumph.

Tags:

Categories: Technical

«
»

Leave a Reply

* Mandatory fields


− one = 8

Submit Comment