Softwire Blog


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.

 

Getting more Women into Technology


9 December 2015, by

9378548_origAs a successful woman working in technology, I often get asked how to attract more women into tech roles. I get asked by diversity officers of large corporates like BT and I get asked to share my experiences as a women with young people through organisations like STEMNet and TeenTech. “Where are the women?” has become a topic across many areas of modern life, such as business, academia and politics, as well as technology. My favourite question on the topic was from a young founder of a tech company: “There are only four of us in the startup and we’re all white males – what do we do?”.

Step one: Don’t panic It’s not your job to fix the whole tech industry. There are fewer women than men in tech right now, and you’re not going to change that by redesigning your marketing materials or having more female-friendly office perks. If there are only four of you and you care enough to accost a speaker to ask what you can do differently, your company make up likely reflects the industry and you will be OK.

Step two: Realise that there is no magic “women thing” that you can do One mistake that crops up time and time again and will alienate rather than attract women is the tendency to think of them as a homogenous group. I’m a mid-thirties woman without children so painstakingly outlining your maternity policy will not make me feel more welcome, whereas for some women this will be a key factor in considering where to work. Similarly booking in “girly” events or perks without finding out what your female employees like can seriously backfire. As one of our developers said recently “women in tech don’t tend to want manicures”. (Of course I’m not saying that generalisation is true either – just remember that different women like different things.)

Step three: Find information specific to your business What do the women who work for you already think you do well, or not so well? Perhaps even more tellingly, why do women leave your business? Make sure you hold exit interviews and when you do try to ascertain whether you are finding out what people really think. Consider using a member of the HR team or someone who hasn’t been involved in the day to day work of the exiting team member, to make sure that they are not holding back from criticising the person who is holding the interview.

Step four: And if all that fails… If you are really have problems recruiting and retaining women, here are some suggestions.
• Train all of your staff in relationship building and personal interaction. Soft skills are classically considered female territory, but even more importantly these skills will help you to uncover what people really think and help them to feel welcomed.

• Value diversity. The best way to think of diversity is not whether an employee is a woman, or of a different race or sexual orientation, but whether they actually think differently from you. Hunt out different opinions. Think through the “obviously stupid” ideas for a bit longer – maybe you are missing something. Be suspicious when everyone you hire agrees with you.

• Finally, quotas for hiring are risky for all kinds of reasons, but quotas for shortlists are not. Force yourself to find diverse candidates, especially for senior roles in the company (note that you may find this very hard – don’t give up!) and you may well find yourself surprised to end up hiring a woman.

What does it mean to be a charity trustee?


28 September 2015, by

699ab1ad4c0460592e8f8dc296be17ca5bb5793f

I’ve been volunteering with Ghanaian charity Ashanti Development for nearly 7 years. Ashanti Development was started when Martha Boadu came to England from Ghana. Her plan was to save money that she earned for working so that she could personally pay to install clean water into her home village of Gyetiase. She teamed up with her neighbour in London, Penny David and they quickly found that this was achievable. Luckily lots of people believe in this as a goal and so they raised the money and put in a piped water system.

Following on from this they continued to received grants and expanded their work to include building latrines, hygiene training, health and micro-credit and economic development. They also expanded geographically to help the villages surrounding Gyetiase. In 2013 Softwire sponsored the local village of Bonkron and we continue to provide support to them. (We just built a kindergarten.)Cutting the ribbon

This year Penny asked me to become a Trustee of the charity. As a trustee, I attend board meetings and help make the executive decisions of the charity, to make sure that it is fulfilling its objectives and delivering as well as it possibly can. Like being a director of a private company, I am now (jointly with the other directors) responsible for ensuring that the charity is complying with the law and completing any necessary paperwork.

 

It’s early days for me, but I’m delighted to be able to contribute more to the charity, using skills that I have developed in my business career. As a trustee I do of course continue with all my other activities to support the charity – Softwire are going on a trip to visit Bonkron for the first time in January 2016.

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.

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.