How to be discerning without being invalidating
First, some context:
It’s the carwow 2017 Christmas party and I’m on a boat. It’s a relatively classy affair, we’re cruising along the Thames while people mingle and talk, enjoying the faux casino that’s been set up on board.
I’m at the bar chatting with our Head of People, Samantha Perry and the conversation turns towards hiring. Sam asks if I’d had the opportunity to speak much with one of our newer hires. I tell her I haven’t.
She tells me I should; we’d get on very well she feels, particularly because of my personality — I’m “very cynical”. I’m pretty sure it was meant as a compliment, akin to being realistic or discerning; however it sticks with me and I can’t help but return to the thought over the next few weeks.
I’m cynical.
Being realistic
I’d like to think I’m realistic (or pessimistic?), not cynical.
In some ways, realism is a fundamental quality of good software engineers. A keen eye for detail and a methodical, logical approach to problems. Being able to connect to the reality of a situation and planning accordingly.
Whilst a more optimistic or hopeful person may see a feature or requirement and think of all the problems it will solve, the eagle-eyed engineer will look at it and think of all the scenarios in which it will fail. (On a side note, this reminds me of Chris Hadfield’s TED talk on dealing with difficult situations - it’s well worth a watch if you haven’t seen it.)
Both are essential of course. You need hopeful optimism to build a vision of a better future and you need grounded realism to achieve it.
When harnessed correctly, this “grounded realism” can be extremely powerful and useful. As a developer it’s a useful skill for focusing in on edge-cases and “sad-paths” when building a feature or analysing a codebase or system; as well as being able to accurately scope a piece of work and build a reliable product.
The danger of being too realistic
This ability or quality of being realistic has it’s value when applied to a work context as mentioned above. However it’s a slippery slope and this mentality can easily lead to you becoming overly judgemental and critical of other people’s choices. You start to assume that your way of thinking is the only one of any value, and other approaches / styles are invalid.
I found this a difficult transition as my role has changed. I spent a decade as a software developer, and honed my ability to think in terms of code and logic, spotting edge cases in a world that is pretty black and white and failure is more binary. But I have now moved into a head of engineering role that is much more focussed on people and management, where the scope goes beyond the system/code and there are more shades of grey.
An immediate example comes to my mind. We run a regular book club at work themed around management/leadership; the current book we’re all reading is Legacy by James Kerr. I’ve never read it before, but some of the team are big fans, and it is one of Sam’s favourite books.
I’ve almost finished the book (around 20 or so pages left to go) and it’s been a complete slog. I strongly disliked the book and it’s taken some effort to try and read the whole thing. It’s not so much the message of the book that I took issue with; in fact the lessons on humble leadership and the importance of team over self are ones I agree with. It was more the style that jarred with me. I found it overly clichéd and the scattered style of story-telling overwhelming.
My first instinct was to be aggressively dismissive and critical of the book, without regard for other people’s opinion. It was only after my wife challenged me that I realised what I was doing.
Yes I disliked the book, it clearly wasn’t something that I enjoyed or resonated with. Yet it was equally clear that others had the complete opposite reaction to it; they found it inspiring and captivating.
There is nothing wrong with the book. There is nothing wrong with the people who liked it. There is nothing wrong with me. There is just a mismatch, and that’s fine. The book isn’t written for people like me, but that doesn’t make it inherently bad. I need to learn to stop and think before rushing to criticise something, and instead try to recognise/appreciate that I may just not be the intended audience.
It’s the difference between
“This is shit”
and
“This isn’t for me”.
Adapting to a new role
With this shift in my role, I’m learning that the most important thing for me is no longer being able to spot edge-cases and failure scenarios from a hundred paces. There are far more skilled developers than me working here that can do that.
My focus now needs to be on creating a validating environment at work in order to nurture the people and the culture of the organisation. I need to learn to maintain an ability to be discerning yet balance that with an ability to encourage and nurture.
Squashing bugs and inefficiencies when building a product is a skill to be proud of. Squashing ideas/dreams/opinions is not.
