Softwire Blog


Tips for managing technical people – Blog Post wrap up


14 October 2016, by

Galvanizing the geeksOver the past few months, we’ve been posting excerpts from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.

This post serves as a reference to all the snippets that are freely available here.

(more…)

Tips for managing technical people – Recommended reading


7 October 2016, 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.

These are some of the books – not all of them aimed specifically at the technology sector – that I’ve found useful throughout my career.

(more…)

Tips for managing technical people – Train technical leadership


21 September 2016, 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.

You need to ensure that there’s a technical career path as well as a management one open to your managees. Many companies nowadays ensure that there’s a path by which their technical people can reach the very top of the company, whether this is via a Technical Advisory Board (favoured by companies such as Thoughtworks and UBS) or by other means.

Creating the technical path and putting people on it isn’t enough. You also need to train people to fill the relevant roles. A common misunderstanding of the technical lead role is to see it as a sort of glorified developer, who gets to tell the other developers what to do. While a progression to project manager is seen as a move to a different role, the role of the technical lead can be seen as ‘more of the same’.

(more…)

Tips for managing technical people – Talk to the Duck


10 August 2016, 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.

‘Rubber duck’ technique is one of the innovations that I have seen introduced by a project manager who was willing to try something new. He didn’t invent the practice, but no-one works in a vacuum; the best project managers build up their skillsets through others’ experiences as well as their own.

(more…)

Tips for managing technical people – How to both learn and deliver


25 April 2016, 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.

Being able to learn is a key part of being happy. It is also widely cited as a good reason to take a job – books such as the cheesily named The Start-up Of You by LinkedIn founder Reid Hoffman advise you to consider how much you will learn as a key criterion in deciding whether or not to take a job. My favourite maxim (probably because it involves a rhyme, as all good maxims do) is from Never Eat Alone by Keith Ferrazzi: ‘Learn in your twenties, earn in your thirties’.

(more…)

Tips for managing technical people – Embrace Failure


25 April 2016, 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.

Whatever we do, whether it’s software development, building cars or policing a city, we are all trying to do it well. We are all trying to succeed. We set our sights on the end point, and aim towards it. We do everything in our power to avoid failure. We carefully manage a list of risks so we can deal with the unexpected and stop it from throwing us off course.

Some organisations go further. You’ll have heard the expression ‘failure is not an option’. This seems like a reasonable way to go about business, surely?

(more…)

Tips for managing technical people – There is never a substitute for using your brain.


9 March 2016, 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.

In most organisations, when there is a problem with quality or productivity, the answer is to introduce a new process. Too many faults in your widget output? Introduce a quality check or refine the widget-head-putting-on steps. Customers not buying enough? Give your checkout staff an upsell script.

I‘m not saying that there isn’t a place for process in software development. For any mechanical steps, such as those required to make a software release, process – or better still, automation – is essential. But process can’t help with the basic process of software creation.

The reason for this is very simple, and apparent to anyone who has ever done the job (if you’re not technical yourself, your team will find it bizarre that you don’t understand this). For all that we are working with logical, rational, calculating machines, the process of controlling those machines is a creative endeavour. Trying to do it by rote is like trying to paint a picture by rote. You’ll get an outcome, probably much more quickly than you otherwise would, but it quite simply won’t be very good.

The processes that do exist tend to be aimed at keeping arduous administration away from the developers, and allowing them to get ‘into the zone’ – a place where their creativity can be unleashed.

The problems that software developers have to solve are not mundane or routine. There are almost always dozens of different ways of approaching the same problem, and the subtleties of the situation will mean that a solution that may be the correct approach to take in one case could be disastrously wrong in another. So, while you should make sure your developers are aware of best-practice approaches such as dependency injection, you shouldn’t be trying to get them to apply them formulaically.

As a developer, some of the least constructive conversations that I’ve had have been those in which I’ve been trying to discuss what approach to take with someone who’s following a rulebook. One of my colleagues, working on a client site, was terrified of explaining the correct way to do something to the client’s tech lead – open debate wasn’t welcome, and if he didn’t give the answer that fitted with the tech lead’s learned architecture patterns he’d be accused of insubordination. The project that they were working on is now three years behind schedule, and still hasn’t been released.

Tips for managing technical people – Insist on an explanation


24 February 2016, 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.

In Respect your team, I talked about why you need to give clear explanations to your team in order to increase buy-in and, of course, to show that you respect your team enough to let them in on your decision-making. One great advantage of this is that, if you are in the habit of giving explanations, you are also in a position to demand them when you are unsure about exactly why something has to be a certain way, or why it should take so long.

As a manager, who probably doesn’t often have the time to go into the detail, you need to be able to assess proposals and plans at a high level. Some transactions can just be done on trust: with your longest serving managers, you can get to a situation where they have such a history of delivering on time that you can let them put together plans and simply look at whether the cost works for you or not. Even then, there may be times where you need to clarify exact approaches or establish why a certain approach doesn’t work.

You should develop a healthy suspicion of being given the ‘right’ answer. If you get the answer that you expected (or were hoping for), it might be that everything is tripping along swimmingly – or it might be that this is the obvious answer to stop you enquiring further. It could also be that, in your rush to assume that there are no crises for you, you don’t hear the substance of what is being said and interpret the answer according to your own expectations. It’s too easy to hope for and assume the best. Look for further details and reasons to ensure that you’re not being misled (accidentally or deliberately).

If you’re uncertain of something, blind trust is not the answer. Good, challenging questions and a culture of explaining what you’re doing and why will help you to get to the best answers.

 

Tips for managing technical people – Who’s the Expert?


20 September 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

As a busy manager, you want your technical team to deliver the work you need so that you can hit your targets. You don’t need to know how they do it, or the finer points of their problems. Or do you?

I don’t need to explain why being a cog in a giant machine over which you have no control is demotivating. The opposite of this is having a manager who is interested in what you are doing and why you are doing it.

You’ll never be able to build up the level of expertise that your team has, but you can use that to your advantage. There is nothing more flattering than being asked to explain what you do by someone who respects how useful it is and acknowledges that they couldn’t do it themselves. And of course, building up your knowledge can only increase your ability to make decisions and communicate them upwards.

If you’re not from a technical background, taking an interest at more than a superficial level will open up a new world to you. If your senior developer is off, you may be able to point junior developers at the right resources. You can have a constructive discussion around issues that arise, rather than an argumentative one. You can do this, not because you know better, but because you’ve learnt enough to know how to listen to people who do know better.

The other key way to gain respect from your technical team is to make it clear how you can be useful to them. The best way to help is by using your own expertise: management. If you respect and value their space of execution, and show them how it would be useful for them to align it with yours, you’ll have an unbreakable bond.

As a developer, I was close to the bottom of the pack. As a result, I started developing along different lines in the support team, where I got more credit for being nice to people. This led into management – and suddenly, the techies whose ability to construct elegant, performant functions had dwarfed my own were suddenly reporting to me.

It was a little bit of a shock to everyone concerned. Like most new managers, I was keen and enthusiastic. I didn’t stop to think how this might look to people who were already doing the job better than I could.

I soon realised that only by making the effort to make myself useful would I come to be regarded as such. So I started to focus on how I could actually be helpful. I took away troublesome admin tasks. I helped open up new opportunities that the developers were trying to move into. I asked the question ‘How can I be of help?’ And I didn’t stop until I got an answer.

Tips for managing technical people – Rules for accepting feedback


18 September 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 geeksI’m a great fan of continuous improvement, and feedback is the lifeblood of continuous improvement. Whenever you undertake something, you should be thinking carefully about what could have been done better; this will provide you with some great improvements without any outside help.  But there will be a whole class of things that you could be doing better that you won’t be able to spot.  In order to become the best manager that you can be you need to find out this information, and act on it.

To get to the position that you’re in now, you will have already had to learn how to act on feedback.  At the bottom of an organisation, feedback is usually relatively easy to come by: if you do something wrong, you’ll find out about it; if you upset your boss, they’ll tell you. You’ll also be keen to ask for feedback, and your manager will be happy to give you it.

Things change a little when you are the one in charge. It’s no longer obvious to others that you want people to feedback to you frequently and honestly, even if you state as much in departmental presentations. It can also be easy when you are rushed and busy to respond to feedback curtly or peremptorily, even if you do find it useful and later go on to act on it. Or you may have an emotional reaction to feedback, especially if you do feel deep-down that you have done something badly. Add that to the fact that giving useful, honest feedback is actually really hard, and you might find that people fear giving you honest feedback in case they upset you.

I have previously blogged the following rules for accepting feedback.

  1. Whatever the feedback is, immediately say ‘thank you for the feedback’. This shows them that you appreciate their taking the time to help you, and will mean you get more feedback in the future.
  2. Before disagreeing (or agreeing!) with the feedback, take 15 minutes, or however long you need, to absorb the information… or calm down.
  3. Only then think about whether you agree with the feedback or not, and what you plan to do about it.
  4. Feed back to the feedback giver on how useful their feedback was! Remember, this is something that they probably didn’t find easy, so take the time to let them know how they did and provide any constructive comments you have to help them get better.

It’s not necessarily the case that all feedback you receive will be equally useful – if you let people know which bits were most helpful and which were less so, it will help them to practise continuous improvement on their feedback giving.