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.


Categories: Softwire, Technical


Leave a Reply

* Mandatory fields

seven + = 12

Submit Comment