Softwire Blog

Tips for managing technical people – Let your managees lead meetings

30 July 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.

Gone are the days when companies were ruled with an iron fist. The old way of managing involved one person at the top making all the decisions, and everyone else implementing them. As long as everyone did what they were told, everything worked well.

The problem with one person making all the decisions is that, rather obviously, one person is only one person. The limit to how much knowledge one person can usefully act on may be quite large, but it is still a limit. Distributing the mental processing across everyone in the organisation rather than getting one individual to do it all just seems sensible.

And there’s another reason to get more people involved in the thinking process: people think differently. There are even benefits to having two people, rather than one, think about the same thing; they might come up with very different ideas.

I see an organisation as a series of ‘thinking parts’ working together to achieve an overall aim. The people who are working on specific deliverables do the thinking about the detail of those deliverables.  Other people will do their thinking at a level that agglomerates data across a group of deliverables; they can form general ideas and principles from this, and, because they have all the information, are best-placed to do so. But they are still not best-placed to decide on the detail, even if they are considered more ‘senior’.

However, people within a company are still human. This means that they often stray down the easier path of simply doing what they’re told and no more. So prevalent is this concept that people often do what they think they’re about to be told to do, even if they don’t feel threatened or coerced. It’s just quite an easy way to do your job.

The best way to tackle this issue is to try and reverse the usual management relationship. Your manager may set goals for you (or help you to set your goals), but once you know what you’re aiming for it’s your job to work out how to get there. You may need help and advice from your manager, but not because they’re telling you what to do – rather, because they’re a resource that’s available to you to use.

I have a meeting-plan format for two-person status chats that I use to help underline this idea. The key component is to get the more junior member of the chat to lead the meeting. This seems back-to-front for most people; when I ask them to set an agenda, they don’t know what to say. But once someone is happy with this format, I’ll get them to email their agenda in advance; I’ll also ask them to demonstrate good action tracking afterwards by emailing through the list of what was agreed in the meeting. This gives them a starting point for the next chat.

This can be quite scary as a manager, because someone might not ask you the ‘right’ questions. But provided that the brief is clear, either someone is not going to hit their targets (in which case you can – and must! – intervene), or they will hit their goals despite doing something that you consider suboptimal. This is the point at which you need to let them make their own decisions; otherwise you’ll undo all the good work of setting up an environment in which they can make their own decisions. ‘You can make your own decisions except when they disagree with mine’ is simply not effective.

Tips for managing technical people – Is burnout a management problem?

24 July 2015, by

The 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.

Galvanizing the geeksAs a rule, you should set goals and let people choose their own path towards hitting those goals.  This implies a certain level of trust that they will go about these in the way that they believe is best.

Looking at it this way, it seems that, if an individual chooses to overwork in order to hit their goals, then this is their choice. Most company reward systems means that working all hours of the day will earn you more money. So should an individual be allowed to choose this path?

I can understand the argument that says yes, they should be free to choose. Personally, however, I think that there’s a very good reason to cut off this particular choice. If your incentives are set out to reward people who work harder, it’s fair for people working to those incentives to assume that all-out, non-stop hard work is what you would most like from them.

But as a manager, that’s not what I want. I want productive, happy individuals who are hitting their short-term productivity goals and long-term career goals by doing a decent weeks’ work.

Some people will enjoy their job more if they work a few extra hours to hit their goals. No problem! In fact, I applaud this attitude. Some people will achieve their career goals sooner by taking an interest in technology and reading around the subject at the weekend. Again, I see this as a positive step that will make them happier as well as more productive.

But routinely working 14-hour days and weekends hardly ever makes people happier. And it doesn’t always make them more productive. It’s not what I personally want for my colleagues.

Telling people that you’d rather they didn’t do something while paying them more for doing it is not always a very effective message. So I intervene quite strongly if I feel that people are overworking. I’m not prepared to remove personal choice, but I can make it clear what we as an organisation consider to be a reasonable effort, and what we consider to be beyond the call of duty.

It sounds like a contradiction, but I believe in trying to curb people’s choice slightly in such cases. The unpalatable alternative is that they think you’d like them to be taking a certain course of action, when in fact that isn’t how you’ll be measuring them.

Tips for managing technical people – Be nice to the customer

12 May 2015, by

The 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.Galvanizing the geeks

A good relationship with the customer is absolutely key to delivering a good service – and, as it’s the customer who is judging your outputs, you need them to be involved in setting the goals that define what success looks like.

To do this, you want to avoid your team developing a combative relationship with external decision-makers. If the customer agrees with every suggestion they make or is happy to be uncritical of technical decisions, there will be peace. But if the customer doesn’t effectively communicate the constraints they’re working to and passes on ultimatums as a result, they are likely to lose the team’s respect and any chance of a solution-focused discussion. Instead, it’s likely that the team will try to work out how to impose the plan that they already intended to implement.

The problem here is that your team are guardians of expertise that the customers don’t have. And because their focus isn’t on communication, they assume that if the customer wants something different they must just be stupid or pig-headed.

It’s therefore important to train your technical staff to think about helping the customer –to think “They’re so inexperienced they think putting it on one server is a good idea. They need our help to not make the wrong decision” – rather than reacting against a customer ultimatum. But without training them to think in this way, you can’t assume that your team will immediately understand good customer relations the way you do.

Tips for managing technical people: Set a vision

8 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.

As well as goals, you may also need a “vision” for your team. These two concepts overlap slightly, but essentially by ‘goal’ I mean a description of a task or other discrete output that needs to be produced, whereas by ‘vision’ I’m talking about an overarching ethos or way of producing the output. 

Only sophisticated and well-functioning teams can be led by vision. In high-level terms, as a team, what you need to deliver is always going to be the same: high-quality code at the best value for money. There may be additional requirements in your team, or different balances between quality and productivity, which will combine to produce an overall vision. If your team is well-versed in setting their own goals and delivering in accordance with the vision, you need only communicate that vision well and sit back and watch the team deliver.

I once worked on a long lived product for a digital media client. The software ran across several mobile and desktop platforms and had a very sophisticated feature-set developed over five years. At any one point, there were many things that need to be managed: support requests on the existing platforms, development on new platforms, underlying maintenance of the code, and a long backlog of new features and enhancements that will allow the client’s sales team to sell more products.

The client provided us with a product owner. The product owner met with the technical team at least once a week and explained how the business was prioritising different development efforts. On top of that, the team had been set a vision: the product was the core of the client’s business, and needed to be both robust and scalable to keep existing users, as well as feature-rich in order to expand to new users. This vision was well understood by the team, and meant that, rather than the client product owner setting us detailed goals, the team could (and did) challenge the immediate prioritisation of work when it didn’t conform to the overriding vision that they have been set. This ability to ‘work to the vision’ resulted in, for example, critical server availability work being carried out in preference to more exciting new development. This server availability work paid off in spades when a server fault took an entire disk array out. If you have a team of highly-skilled technical staff, make sure they understand the bigger picture to which they need to deliver. This will allow them to deliver the best results.

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.

Tips for managing technical people: How to make people happy

15 January 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.

With the advent of modern management techniques, we understand that happy and engaged employees do better work and stick around for longer. Of course, it’s not always easy to make this happen. Sometimes, ensuring that every single member of your team is happy can appear to be in conflict with your other responsibilities, such as delivering a great service and making the bottom line add up. But it doesn’t have to be.

First let’s consider what we mean by ‘happiness’ in this context. I would suggest you’re looking to engender the following types of happiness in your employees:

  • A feeling of belonging
  • A sense of being respected
  • Challenging and fulfilling work
  • A career plan that means that the work you are doing now will lead to personal development and the ability to meet your goals in the future

This is not an exhaustive list, but it illustrates the kind of happiness that I’m talking about. Thinking of happiness in this way, you can see that the real value of freely available chocolate biscuits and access to fussball and other amenities is not in the short-term pleasure that people get from engaging with them; they are valuable because they are evidence that employees’ happiness is valued, and that they are respected enough to be allowed to manage their own time.

So how to achieve this ultimate state of happiness? The high-level answer is simple: you need to find out what people want, and you need to provide it. The useful answer is a lot more complicated. The distinction between short-term gratification and longer-term happiness is not always apparent to everyone. The classic example – which will be recognised by anyone who has tried to lose weight or just to keep healthy – is the difficulty in deciding between the food you want to eat now and the bodyshape and lifestyle you want later on.

Simply asking people what would make them happy, or happier, is likely to elicit short-term happiness responses. Instead you need to engage with what they really want to get out of life, and find out how much of that you can help them to achieve within your organisation. I won’t pretend that you won’t sometimes end up shooting yourself in the foot this way: helping people to achieve their dreams may mean that you help them to be somewhere other than your organisation. I think that this is an acceptable trade-off in return for committed, engaged and happy staff, and for a great incentive to retention for everyone else.

When I’ve stayed with an organisation for a long time, it has been precisely because I have continued to have the opportunity to learn. When I’ve been learning skills that make me very valuable in the marketplace, this has increased my ability to jump ship and work somewhere else. But a learning culture and great environment removes incentives to leave as long as I’m continuing to learn – and enjoying myself while I do so!

Tips for managing technical people: turn issues into challenges

28 November 2014, by

In technical work, problems happen. If they didn’t, you could replace your crack development team with the automatons that everyone else suspects them to be. It’s the problems that mean you need clever, inventive people around to fix them.

When you’re working as a developer, this doesn’t always seem so clear. You have a piece of software to build and a plan for how to build it. You can easily feel that unexpected obstacles are going to derail you.

But your best people thrive on problems. Some want to be seen as a ‘fixer’; they want the respect that comes from having others know that they can step in and sort everything out. Even better are the guys who love the problem for the sake of the problem. If the development environment isn’t playing nicely with the new library you downloaded, the best response is ‘That’s interesting!’ (Rather than ‘Not again!’ or ‘I wanted to get this software shipped tonight!’).

Self-belief is an important part of this. Your guys need to believe that they can solve the problem. Not their pal, or someone on the other team, or someone at the other end of a forum. Themselves.

A personal breakthrough for me when I was working as a developer was moving to Australia. I still had support overnight, via email or in calls at the end or start of the day, but if I wanted to get something done now, I needed to sort it out myself. The first time I hit a problem, I tried a well-known technique. I went to make a cup of tea. It had always worked for me in the past: make a cup of tea, have a cigarette, stare blankly at the code… and soon I’ve spent nearly two hours struggling with the problem and feel perfectly justified in asking for help. But it didn’t work in Australia. I made my cup of tea, came back to my machine – and the problem was still there. I didn’t have any choice but to sit down and start thinking about it.

A funny thing happened once I’d got to the end of my cup of tea. I wasn’t thinking about tea any more, or staring idly out of the window. I’d been gripped by the problem that I needed to solve. I was thinking of answers and verifying solutions. It took me most of the day to solve an issue that one of my colleagues could have sorted in 10 minutes, but I learnt the most important lesson of my career. I could do it myself.

So watch out for the developers who let other people solve their problems. Work on plans with them so that they can build up the confidence to do it themselves. Take away the easy route – they’ll thank you when they’ve made it as a guru two years later.

Tips for managing technical people: Beware large numbers

11 November 2014, by

The 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.

Why people underestimate

The single most common cause of failure for software projects is misalignment between the time that the project is expected to take to develop and the amount of time that it actually takes. There’s a good reason why estimating is known as ‘the black art’. Assuming that you’re far enough down the line not to be estimating against tasks that bear little resemblance to those that you’ll eventually undertake, there are two main ways in which your estimates can be horribly, horribly out.

Firstly, single tasks may overrun by hundreds of percent. The coarser-grained your estimate is, the more likely this is to happen. I’ve found that tasks that are in the order of a day or two are easiest to estimate. It is too easy to underestimate the size of a ‘large’ task; there are very few tasks that don’t feel like they will fit inside a 20-day estimate – that is, until you break them down. Even a task of five days is likely to be concealing hidden gotchas, simply because, to get a five-day estimate, you don’t need to know exactly what you’ll be doing on each day. So Rule One of estimating is to break down large estimates into smaller ones.

The second most common cause of overrun is The Missing Task. You can have a whole spreadsheet of perfectly estimated line items, but, if there is just one task that isn’t on there, your project will slip by the amount of that task. To help avoid such omissions, it can be useful to have a standard set of tasks that you always estimate (or explicitly omit) for every project – and to make sure you think carefully about what exactly needs to be done. Estimating in small numbers, as described above, can help in dealing with omissions that may or may not have been included as part of a line item.

It’s hard for anyone to assume that there are tasks hidden within a single day estimate – but however thorough your process and however rigorous your analysis, you will still miss some tasks. It is inevitable. So you need to leave some contingency, preferably just by adding a big fat contingency task as a new line item. Without any contingency, you are guaranteed to fail.

Tips for Managing Technical People – Do the Hard Things First

13 October 2014, by

The following is an excerpt from Zoe Cunningham’s new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on her website, here.

They won’t go away

Every team and individual works to some kind of ‘to do’ list. It might be in their head, or written down in the form of stories, or stored elsewhere, but we all have one, and some sort of ordering will be applied to this list. 

One very common means of ordering is in fact the very opposite of a good order for development tasks. If your subconscious is inclined to lead you along the easy path through life, then you will find that the more simple tasks will tend to drift to the top of the pile. This may result in you feeling very efficient – you’ll be burning through loads of tasks, and probably even getting ahead, which has to be good, right?

Wrong. The apparent gains you make by taking on the easy tasks first are in fact the opposite; they constitute a debt of hard tasks and risk that you’re building up for later in the project. Your burn-up chart will eventually tail off as you hit the harder, less-well-estimated and riskier tasks. And the later you uncover these problems, the fewer options you have for dealing with them.

The best tasks to do first are therefore the hardest ones – the ones that fill you with dread just from looking at them – the ones that you really do not have a clue how to approach – the ones that you hope might go away if you ignore them. They won’t.

They represent uncertainty

Hard tasks are essentially risks. If you don’t know how you’re going to do something, how do you know that it’s even possible? You certainly don’t know whether it can be done within the time allocated. If something is difficult, there’s a good chance that it will take a lot longer to solve that you’ve allowed for.

The other tasks that should be prioritised first are those that are in some way dependent on other parties. If you have developers who don’t like to interact with irrational, unhelpful and unreliable third parties (and let’s face it, who does?), they may be naturally inclined to leave such tasks until they have no choice but to do them. Of course, it’s the unreliable nature of third parties that means that you need to leave plenty of elapsed time (if not actual working time!) to deal with whatever inconsistencies and changes you might uncover, and to work around system outages, holidays and all the other blockers at their end. How many times have you been given a third-party interface definition and tested against the test site successfully, only to find that the live site doesn’t use quite the same format? How many times have you left your testing to the last minute only to find out that the test server is down? The weapon with which you can overcome these pitfalls is time. Make sure you have enough of it.

They might include delivery tasks

‘Release tasks’ deserve a special mention at this point. They’re easily overlooked, for all the reasons I’ve just mentioned. They can be very much ‘out of sight’ during the development phase of a project – they are simply not part of the tasks that you’re doing now; they are part of the next phase. What’s more, they often hinge upon many unknowns. You might not even know whose job it is to figure out the unknowns. If you’re going to have to deploy on to hardware that’s owned by another department or even a different company altogether, there are all kinds of potential hurdles that you’ll need to just identify before you can start planning for the rollout of your software. Some of these things you can do yourself, but some will need the involvement of the guys who run the hardware. Whilst development is still ongoing, dates, exact user characteristics and all kinds of other essential facts can be completely unknown. And this is exactly why you need to start planning this phase nice and early.

If your team is going about its tasks in the wrong order, it will manifest itself in late or rushed deliveries, last-minute changes and a general air of panic as you approach the end of a project. Don’t be tempted to leap in! Managing your team to help them achieve their objectives in such a situation must still be done in the same way: through empowerment and delegation rather than micromanagement. Insist that they try a new way, and let the results speak for themselves.


Tips for Managing Technical People – Productive Time is Money

26 August 2014, by

The 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.

Time management is important

Time is money. Sometimes people take a while to work this out – or completely fail to take it into account – when planning. In software teams it is not so often forgotten. If you work for a software services company, you can’t but notice the amount you could be charging to a client for your time – or, if it’s you that’s charging the time, then your client will certainly notice! This culture extends to other software departments too, although there teams are often managed more by deadlines – it’s less ‘time is money’ and more ‘there isn’t enough time in the day’.

In a senior role you don’t have the luxury of squandering your own time. There are countless things that you need to do, and you need to be ruthless in setting your priorities. When you’re working every hour you can find and fighting so hard to fit everything in, it becomes really tempting to try to squeeze more out of your developers. Why are they playing pool? They could be coding up that extra feature for you. Are they optimising their email-reading around their coding? Should they be working on this piece of code today, and that other tomorrow?