Today I closed a chapter in my life. After nearly 4 years tenure at a company I wanted to reflect on the things I learned over that time.
I have been very lucky to have a few excellent – world-class even – mentors here who have taught me things that will stay with me for the rest of my life, and I wanted to share the reflection process with you in the hope you gain something valuable too.
Individual Success Isn’t Success
For a long, long time I adopted the ‘aircraft oxygen mask’ approach to my career: I’ll get to where I want to be first, then I’ll help others. This company has taught me that isn’t the right thing to do.
My thinking was always “I’ll be in a better position to help others” once I hit my objectives, but that simply doesn’t work in practice: without respectful, cooperative development across your team(s), you risk yourself hitting your goals at all, and if you haven’t helped others hit theirs too, nobody wins.
Dare I use the management-bullshit-bingo term ‘synergy’?
My current role here is a technical leadership role – that means I don’t have people reporting to me but I do have authority over technology direction and a remit to ensure conceptual integrity of the solution. I have led project teams before, I have even run small businesses before, but being a leader in a larger company was new to me when I began this chapter of my life, and I wanted to be good at it.
I’ve seen all the memes about the difference between a boss and a leader but for some reason I struggled to enact the differences. However, after some time spent being (in retrospect) a terrible boss, some sage advice from one of those mentors made everything ‘click’, and I was given the mental tools to develop the techniques required to become a good leader instead. (Note, a good mentor won’t give you the answer, but the means of finding it on your own!).
“Take people with you.”
So what does that look like in practice? Last year I was offered the chance to travel to our American HQ to present some new work to 1,500 customers. ‘Prestigious’ isn’t even close – this is a huge event, so compelling that our customers pay us to listen to our plans and roadmap. The trip dripped with a significant amount of attached ‘kudos’ and the opportunity to rub shoulders with the highest of the high in the business. Not only that – the opportunity to ask probing questions to 1,500 customers about our technology direction is such a rare occurrence it was unmissable. The old me would have started packing immediately.
In truth, I have been embarrassingly guilty of hoarding such trips. I have racked up tens of thousands of air-miles and spent plenty of time wearing out the shoulder fabric of Vice Presidents and members of the Board with my own (inferior fabric). Sure, it’s incredibly important to ask questions of our customers to make sure we’re on the same page: but did I really have to be the one asking them?
More than a few ambitious, hard-working people had made their mark on the team and were obvious candidates to take my place and, sure enough, one of those leapt at the chance when we discussed it. As we knew they would, they did a great job presenting the roadmap to our customers and asking the right questions. They returned with a deep insight into what our customers wanted and with a well-deserved heightened profile within the business.
That sort of thing breeds loyalty, it shows everyone that those opportunities aren’t for ‘the select few’ or ‘the inner circle’, it drives employee engagement, and it can break the perception of empire-building. These are subjective things, they are hard to measure directly, but can be gauged by reducing attrition rates, or improved output.
Only ask questions
An ex-colleague turned globe-trotting agile consultant gave me this little gem when I transitioned into a more senior leadership role and asked for some advice.
That simple mantra of “only ask questions” is rooted in a simplification of the cognitive bias that people will buy in to their own ideas more easily and completely and conversely have a natural resistance to ideas that are not theirs.
It touches upon known techniques for achieving buy-in, such as presenting a problem with a loose solution (even though you know exactly what you want), and guiding group consensus through leading questioning to the concrete solution you’d already arrived at. That ‘consensus’ creates a feeling of a combined achievement, and binds people emotionally to the result they feel they earned through successful collaboration. And sometimes (often, let’s face it) the group hits on a new, much better solution!
But most importantly, ‘only ask questions’ is about challenging people to think for themselves, so that next time they have that extra bit of cerebral muscle-memory to call upon so that they can try to figure out the problem themselves.
The difference between being a people leader and a technology leader are pretty obvious – however the skills are very similar. Questioning, instead of simply instructing invites collaboration and the opportunity to learn (in both directions). Instruction only serves to reinforce the organisational hierarchy which can generate resentment – and also stymies the chances of a leader learning from a subordinate (which happens far more often than many managers would like to admit!).
Never raise your voice
“It takes only a second to lose your temper, but it can take years to regain the trust lost from doing so.”
This was advice about becoming a parent, which I did 15 months ago, but it is good advice in business too.
It’s OK to be passionate about what you do. In fact, I’d suggest if you’re not passionate it’s time to look for something else.
Passion can be manifested in many different ways, and it’s OK to get angry and frustrated, but what isn’t OK is losing your composure, blowing your top, or shouting at a colleague. That’s worse than embarrassing, that’s unprofessional.
Problems are problems only while they are considered to be such, then they become candidates for fixing, and most importantly learning.
Let’s face the cold hard truth: we’re all fallible, we’re all human, and mistakes are a part of that. If mistakes become a reason to castigate people then you’ll see your innovation drop off a cliff – people will become averse to risk, and averse to trying new things.
The alternative is to decriminalize failure, make it a positive thing. It is something Spotify are famous for doing – even setting up a “Fail Wall” to document things that simply didn’t work so they can be learned from.
“Success is a series of failures” has been attributed to Thomas Edison who famously tried over 10,000 designs before settling on his ‘version 1.0’ lightbulb. And it’s true.
I don’t like the term ‘fail’, as it seems very final, it also hints at a ‘this or that’ approach, or a ‘right way or wrong way’. That’s not true either, usually success involves ruling out options, and finding out something doesn’t work isn’t failing, it’s invaluable information and should be openly, and positively, shared.
So next time someone comes to you with a show-stopper consider not biting their head off, instead thank them for letting you know and then start the process of repairing, and then learning. Above all else, it’s better the devil you know.
The importance of language
During this phase of my career I’ve learned a lot, and so has the technology industry as a whole.
The seismic shift from waterfall to agile methodologies has resulted in an explosion of new software applications and features. Combined with Eric Ries’ ‘Lean Startup’ processes, time-to-value (TTV) is decreasing rapidly, while output and innovation have gone through the roof.
Eric Evans’ ‘Domain Driven Design‘ distils decades of painful learning about how to remove a major contributor to complexity in large (software) projects: the lack of a common ‘ubiquitous’ language.
The ability to converse with technical and business people, and also customers, with a common dialect is one of the most powerful productivity multipliers I’ve ever experienced. Being able to translate a customer’s requirements into code, without losing anything in translation means everyone deeply understands a project. It’s not easy, but it’s worth it.
One of the major challenges we face at this company is globally-distributed teams. We have offices in GMT, GMT+3.5, GMT-5, GMT-8 and GMT+10 (as well as some satellite offices). That separation is about as bad as it can possibly get. But as legendary cricket batsman Sachin Tendulkar says, “control the controllables”. We had to be flexible, and we became very disciplined in ring-fencing the overlapping office times for meetings with those teams.
Having a common understanding of a project, and developing a common language to talk about it, we reduced the amount of time wasted explaining away ambiguity, and that meant we could squeeze every last drop of value from those short overlaps.
Thanks for reading! If you have anything you’ve learned that you’d like to share, or if your experiences differ from mine, I encourage you to please use the comments section below.