Softwire Blog

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.

How would the internet work on Mars?

2 April 2015, by

Maslov's Hierarchy of Needs - updatedThe news is full of big hopes that Mars will be colonised soon, with reality TV show MarsOne suggesting that we could have people there in under 10 years.

Scientists are grappling with the challenges of providing air, water (for a swimming pool, obviously), food and shelter. Here at Softwire we’re concerned with a more fundamental issue. How will we get access to the internet?

The communication time delay is reported by NASA to be 20 minutes. This might not be too much of a problem for some internet services, but for watching YouTube and browsing BBC News? Worse than dial-up.
The most sensible way to build a functioning internet is to build a data centre on Mars. This data centre would hold a copy of all websites and all regular website traffic from Mars would go between the Martian and the new data centre.

Anything that needed to be communicated to Earth (for example if you placed an order with Amazon, they’d need to check stock back on Earth) would be done in an off-line process after you’ve finished your action e.g. after you’ve placed your order it will remain as “unconfirmed” until the website hears back from Earth. Delivery times may also be slightly extended.

Luckily NASA is one step ahead of us. They have already designed an Interplanatery Internet. This is an internet structure specifically designed to cope with the long delays and fragile connections that we can expect in space. NASA has tested this new internet by sending “space pictures” to a spaceship 20 million miles from Earth.

So if you’re one of the lucky contestants who win a place out on a one way trip you might not see your family again, but you can see their holiday snaps.

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 – 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?

Tips for Managing Technical People – Take Pride in Technical Excellence

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

Pragmatism or sloppiness?

From a developer’s point of view, customers (external or elsewhere within the business) are always forcing them into compromises. They want another week to finish a feature properly – the customer wants to ship now; they want to use a new technology as an experiment – the customer wants to use a well-established standard tech to ensure that they can maintain the codebase going forwards.

Pragmatism has many benefits. Indeed, it’s not possible to run a business without it. At a more detailed level, however, ‘pragmatism’ is often simply a euphemism for sloppy work. While sometimes it makes sense to leave large features that can be implemented later to a future sprint, or to choose a simpler implementation now that may have to be rewritten later, it’s never correct, in my view, to ‘save time’ by writing poorly documented, poorly structured or poorly tested code.

Tips for Managing Technical People – Be Inclusive

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

In some businesses, workers are still viewed as drones to be perfunctorily informed of their employers’ decisions – much as they were in the days of the Industrial Revolution. Decisions were taken and instructions given. This will not work in a technical environment.

Your techies are smart. If you’ve focussed on your recruitment, they are really smart. And if you’ve perfected it, they are smarter than you. Smart people think about things. They will not only want to know the ‘why’ behind every decision; they will also formulate their own opinions. They will ferret out the complications and the special cases, and wonder why you aren’t considering them. This will happen even if you are considering them – and even if you’re communicating them, too (we’ve all switched off at company presentations before, right?).

The best way to deal with this is to include everyone directly in the decision making process. I’m not suggesting that you invite everyone to board meetings, but do consider setting up other forums for input, such as monthly meetings that everyone can attend once a year (and maybe the keenest people can attend more often), where any topic of conversation is up for debate.

This is a key belief of mine. It’s always tempting to hold back some information. This could be because you don’t want to have to spend time debating the decision (again…), or because you know that certain groups of people will be unhappy with the outcome and you’re hoping that, if you don’t discuss it, they won’t notice that the decision has been made.

The former is laziness; the latter is gutlessness.

Debating your decisions is a key part of communication and is a part of your job that you need to embrace even if you don’t relish it. Attempting to ignore the problem is sure to come back and bite you further down the line.

Sharing information and encouraging input will also bring benefits that can’t be realised in any other way. Aside from the positive effects on your team’s happiness, which it is very much in your interests to maximize, you will discover new options that you hadn’t previously considered. There are myriad ways to approach any problem, and you won’t find them all on your own. By openly explaining what you have considered and what the parameters for the decision are (and why), you’ll allow your techies to present you with other, often better options.