A Few Things I’ve Learned About Managing People in Tech
… mostly the hard way
I have a theory that the more you advance in your career into tech leadership, the less your job is about actual technology, and the more it is about dealing with people.
As it turns out, people are much harder to manage than technology — they don’t work on the basis of simple binary logic, they do not operate to a clear, accepted standard, and if worst comes to worst, you can’t just reboot them and hope for the best.
Most of this I have learned the hard way, so in the hope it may be of use to someone, here are some things I think you really need to know if you are in a tech leadership role.
You are not the unquestionable source of truth on every subject.
Too often tech leaders make the mistake of assuming that their seniority means they know more than their reports on their areas of day to day responsibility, and as a result micro-manage.
Steve Jobs had this one right:
“ It doesn’t make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”
You provide the objectives, guidance, and goals for your team, along with the framework and support they need to achieve those goals. If you really think you then need to tell them exactly how to achieve them, you are hiring the wrong people.
If you are doing most of the talking in your meetings, you are doing them wrong
Nobody really wants to come to your meetings to listen to you talk to them (or as is often the case, at them) for an hour. If you feel the need to hold a meeting in the first place, it should be because you need an exchange of views and opinions on a particular subject, and you need the knowledge and input of the assembled cast.
Your role is not to dominate conversation, it is to guide it — if you are going to have a bunch of well paid people all burning a chunk of their (expensive) time, you should be using it properly.
Worth pointing out here that it also should not mean going through the motions and then just making sure everyone agrees with you (check out the HiPPO effect for more on that).
Don’t be dogmatic about agile — find something that works for you.
On day one of my Scrum Master certification course, several years ago, I pointed out to the instructor that my company didn’t have someone to fulfil the traditional duties of Product Owner and asked what we should do.
We then got into the following loop. Me: “So, what should we do?”. Her: “Well, that is not Scrum”. Me: “Yes, I know that, but what should we do?”. Her: “That is not Scrum”. And so on.
My take away from that was that chasing a perfect agile implementation is pointless. It won’t win you any shiny medals. Use the bits that work for you, ditch the bits that don’t, but don’t waste your time trying to tick all the boxes.
Something which works is much more valuable than something someone else tells you is ‘right’.
Beware The Hero Complex
In the wider world, the term ‘hero complex’ usually refers to a person developing a narcissistic view of themselves — the hero, the person who comes to the rescue.
In tech, it is slightly different, it refers to a (usually) particularly talented employee who becomes seen as the ‘hero’ when things go wrong. The default ‘go to’ guy. The guy senior management automatically want to get involved when faced with a crisis.
Much as it is nice to have an ‘outlet’ of this type when faced with a problem, in the long term, it is not a good idea.
You are creating a single point of failure — what happens when that person leaves? Or goes on holiday, taking all their domain knowledge with them? You can not afford such a concentration of knowledge.
Furthermore, what about the stress it places on that person, carrying the burden that when things go awry, the whole company is looking to them? You have a responsibility for the mental health of your team, placing unreasonable burden on one person is not good.
Your job is to mitigate the risk to the business, wrapping up your ability to do that in one person is a very bad idea.
No heroes.
Creating leaders is much more satisfying than buying them in.
You do not just offer your employer the benefits of the technical and industry knowledge you have accumulated over the years, you are also there for the people experience you have gained.
For me, easily the most rewarding part of my job is mentoring others and helping create new leaders. When you have a senior position open, don’t react by immediately picking up the phone to your preferred tame recruiter, look to see if there is someone you can give a chance to — spotting talent should be a key part of your brief.
Don’t be too worried about formal qualifications, look for potential — some of the best developers I have worked with didn’t go the usual Comp Sci degree route, they started in support or test.
Give them the back up and support they need to succeed, and when they do, it will be the most satisfying thing you achieve.
With staff retention the little things matter
Working with highly qualified, intelligent, talented people is great, but the flip side of working with people like that is that they are in demand, they will always have options elsewhere.
Good people like to feel valued. Yes, the obvious factors — salary, progression, job satisfaction — are important here, but do not underestimate the value of the ‘little things’.
Give them the best tools, in the best environment, you can to do the job. Nobody wants to work on a five year old laptop which looks like it was fished from the bottom of a skip. Give them training, help them develop themselves.
Hiring the right people is only part of the equation, you need to work hard to retain them, and the ‘little’ things matter.
A good developer is a good developer regardless of the language.
I always encourage developers not to say things like “I am a C++ developer” or “I am a Javascript developer”. I prefer to hear “I am a developer”.
The best developers will be continually learning - technology changes, skillsets come and go, languages shift in and out of fashion, and with all this employment markets change. Remember five years ago when there were thousands of Flash developers? How many of those are there today?
Being a good developer isn’t about learning the syntax of a language — anyone can do that — it is about understanding how to apply logic to solve problems effectively and efficiently.
Encourage your developers to always be learning, and if you can, give them chances to use new tech in their day to day role.
The Importance of ‘No, but…’
A depressingly common feature of tech companies is the ‘them and us’ divide which exists between development teams and the rest of the business, but particularly the sales / commercial function.
In simple terms, the developers think the sales guys have no idea what they’re saying, and the sales guys just think the developers say no to everything.
When asked to do something they think is unfeasible, I ask developers to always look for a “No, but …” rather than a straight “No”. That is to say, go back with “We can’t do that, but we could do this”. Surprisingly often, it turns out that this then leads to a compromise which is acceptable to all.
Finding that compromise is a big part of your job.
Not everybody is like you.
Or, more precisely, not everybody wants to be a leader — whether it be a CTO, a Department Lead, a Team Lead, whatever, and that’s absolutely fine.
Over my career, of all the times I have asked a developer if they would like to move up into a Team Lead position, more often than not, the answer is ‘no thanks’. The usual reason is “I don’t want to get further away from the code”, which makes sense, really — one of the reason good developers are good is that they enjoy what they are doing, after all.
There will be cases where you think you can persuade the developer in question to give that Lead role a go, but you have to accept, not everyone wants to take on a management role - and there’s really nothing wrong with that at all.
Putting in big hours is not always a good thing.
Don’t assume that the guy pulling lates every night of the week is your star employee — look at why he is doing it. Of course, he might genuinely be in the grip of an incredible work ethic, but there is also the possibility he is actually struggling with his work. It may be your help he needs, rather than your admiration. Don’t underestimate what people will do to avoid asking for help.
A working late anecdote. A long time ago, my employer asked me how come the development team never found itself doing long hours into the night, surrounded by empty pizza boxes, overflowing ashtrays and empty beer cans as we pulled a death march to hit a deadline (‘like you see in the movies’). A few weeks later, he asked again.
So, one weekend, we agreed as a team we’d come in to the office on a Saturday night, order in a load of pizza, listen to loud music, and drink beer all night. Basically, a party on work premises, no actual work done. The boss came in on Monday morning, saw the resulting mess of food packaging, beer cans, cigarette packets and whatnot, and was happy.
We’d been ‘putting the hours in’, so everything was fine.
I hope some of that makes sense, if so, I’d love to hear your feedback.
