John O’Hara’s QCon Keynote - A Growth Checkpoint

Table of Contents

TL;DR: As a technologist, taking point on projects is dangerous not because you might not be up to the task, but because you have an impact beyond the technology. Anyone can learn to write code and build stuff, and yes, I also believe that over time anyone can learn to build stuff well. However, it requires a deep fundamental change in oneself to take on the mantel of leading humans.

Context

A few months ago, I had the pleasure of being selected to go to the QCon Developer conference in London. As these conferences go, QCon was done super well with a focus on senior engineers, common industry problems and a distinct segregation of your classical promotional talks and ones with real depth of content.

There were numerous talks with many lessons and epiphanies abound. However, the one that stood out to me, as someone currently aspiring to be more human than robot in my engineering career, was the keynote on day 2 by John O’Hara. Along with holding high positions in various well known companies like J.P. Morgan and Fidelity, the thing that probably earned his place on the docket was him being one of the principle inventors of AMQP, the famous and highly effective “Advanced Message Queuing Protocol” considered the gold standard of it’s kind.

The talk

His talk was titled “Advanced Message Queuing Politics” (which, as a massive appreciator of witty word play, I considered the first indicator of this talk being outstanding). Besides the man oozing wisdom and experience from his very demeanour, his talk left such a lasting impression on me that I had to write this post.

His account of the journey from J.P. Morgan needing a messaging middleware for traders to there being a global consortium consisting of the “who’s who” of the tech industry was such a novel story, however one part of his talk stood out the most to me. In the early days of them opening the movement up to many other organisations and people with many other thoughts and opinions, he had a sit down with himself and defined the mindset that he had started to realise he needed being one of the principle leads on the project that he knew and believed in his bones, had so much potential.

That mindset was 4 main points:

  1. It’s likely that my ideas on this won’t survive the process
  2. It’s still success if it commoditises without us
  3. Contributors should always leave their mark
  4. I love technology, but my role is to make it happen

This resonated with me.

My thoughts

This put into perspective my junior days and interactions with otherwise amazing engineers being so shitty that at its worst, it made me want to quit. It made me understand that in some cases the times I had been shot down and made to feel inferior, weren’t because I didn’t have the skill (although some of those times, I probably didn’t tbf) but more because the person in that position was grappling with their own conflict against one or more of the 4 points above. The amount of times I had been unhappy and frustrated at being told things by a lead that essentially boiled down to them not having this mindset was staggering. More scarily though, it got me thinking about my own behaviour as someone with significantly more experience and reach now.

The Checkpoint

As a technologist, taking point on projects is dangerous not because you might not be up to the task, but because you have an impact beyond the technology. Anyone can learn to write code and build stuff, and yes, I also believe that over time anyone can learn to build stuff well. However, it takes a deep fundamental change in oneself to take on the mantel of leading humans. As a person who is deeply passionate in what I do, deeply interested in learning how to improve and deeply invested in becoming excellent, I have so so much to learn and grow in this area and I can’t fathom ever perfecting it.

Although - I now know where to start.