I enjoy the Tim Ferriss podcast, where he interviews top performers in all fields. I find that success leaves clues and even though I may not have much in common with Neil Gaiman or Arnold Schwarzenegger, I sometimes stumble upon a nugget that transforms my map of the world. His interview with Eric Schmidt, Google’s ex-CEO was one of those. Naturally, we can learn a lot about Eric’s tenure at the famous internet giant, but he appeared on the show to promote his latest book – “Lessons from the Trillion Dollar Coach” – the history of Bill Campbell’s coaching career.
Bill was a football coach at Columbia University, but he also coached Eric and Steve Jobs to achieve extraordinary results they enjoyed in both business and tech worlds.
Fun fact: Tim’s blog (Tim.blog) is hosted on WordPress.com.
The revelation that stuck with me was that Bill would first and foremost make sure to acknowledge people’s Ego. That makes sense when you think about the world of sports. High profile players are portrayed as these supernatural creatures worthy of more than we mortals will ever grasp. Naturally, they would have an inflated sense of self-importance, and personal achievement would be on top of their minds. It made sense for me that the primary concern of a coach would be to have this high-octane mix of individualities work as a team.
Until I learned that one of his most significant contributions was to do the same thing for Google and Apple. Its translating so well into the supposedly logical world of a global tech giant was a sobering reminder, that no organization could escape human nature.
At Automattic, I have the privilege of working with the most brilliant, kind, funny and productive people I have ever met (and a few I’ve not had the chance to meet in person yet). Since we are a distributed company, we are not limited to any country or city. We hire from the talent pool known as planet Earth and I would wager that as of 2019 there is no better source of quality contributors.
But, again – as of 2019 – they are all human beings. Beautiful, amazing and kind, but humans.
The past three years in our distributed office were a wild ride. I worked from amazing libraries, cafes, my home and mountaintops. Professionally, I would gladly tackle any technical problem that would come my way and time, and time again I have discovered that everything is solvable.
In the end, technical problems are manageable. You grind at them, experimenting with different solutions until you solve them. If you hit a brick wall, you back up a bit and try to do something that has not been done before – usually, that will get you closer to your destination.
What is hard, however, is dealing with Ego.
Especially mine.
On paper, I work primarily in code (although, as I am trying to point out – code is where I rest, people are real work).
In every discipline, there comes a moment where you have to show the work. In Art School, there are “Crit Sessions”; Hard Science has Peer Review; book authors have to deal with reviewers. We, developers, have code reviews. My code would get comments, suggestions or criticism from my peers, before making it into the product.
Here is where things start to get tricky because it’s not only a question of, “is it good or bad.” I haven’t seen a single piece of blatantly bad code during my time in Automattic. Our review is more about providing the best experience for the user and the future maintainer. In my mind, the hundred or so lines of divine inspiration that I coded are the best possible way to address any problem, including world hunger.
My coworkers rarely agree, for various reasons.
We all have a different context.
Sometimes, despite a clear design, we are still not in sync regarding what specific behavior is best for the user. We have our preferences and experiences. What is evident for me, may be confusing for someone else.
Should user experience be prioritized above ease of maintenance or not?
I have a strong bias towards early prototypes because I want to get them faster to the users. But some of my colleagues argue that ease of maintenance should be the priority since users will not be happy with an unreliable solution. This points of view clash and each side can become attached to his / her own opinion.
What tool should it use?
Developers tend to have their favorite tools. Usually, they get the job done equally right, but we are famous for arguments over things that are of no consequence.
Mammals have trained for this moment for millennia. Flight or Fight reaction is something ingrained so deep in my psyche that I would convince myself that the only choices laid out before me are:
- I can implement the suggestion, but it will derail the whole process a few days. Afterward, there is no guarantee that another person won’t make a slightly different suggestion
- I can push back, giving good, technical reasons why the proposed solution is not better. In an ideal world, there would be no hard feelings, but people often get defensive about their ideas. I sometimes get defensive about mine, and I may have a skewed perspective.
This situation is especially tricky for technical people. We work with code and code is clear, concise and objective. Human minds and reasoning is not. People have their preferences, biases, and things to prove. For high performers, most of this is unconscious. We all want to contribute the best solution possible, and it happens only by chance that the most logical tool to use is the one that I am an expert in.
And yet, when we discuss things we act as if people were machines too. We expect them to accept logical arguments and weigh the pros and cons without any preconceptions.
To combat this, I tried taking lessons from Ryan Holliday’s “Ego is the Enemy” and Jocko Willink’s “Extreme Ownership.”
Ryan’s work is heavily inspired by Stoic philosophy, in particular, Seneca the younger.
In the book, he argues that Ego is the driving force behind many individual’s successful careers. However – if left unchecked – can lead to their downfall.
Jocko’s book was an important discovery, as it started my journey to think of myself as an “intrapreneur.” He introduces a concept of “leading up the chain of command,” where:
- It would be your job to prove your worth to your superiors,
- You would take responsibility of keeping them appropriately informed,
- It would never be “someone else’s problem.”
Take responsibility for leading everyone in your world, subordinates and superiors alike.
Jocko Willink
I am consistently impressed by the actual leaders at Automattic, and it is essential to point out that I am not a leader. But what Jocko’s mental model has allowed me to do is stop being complacent. Thinking of myself as a leader (or again, an intrapreneur) gave me a clear benchmark to get rid of excuses and focus on getting the work done. I would care less about getting credit, recognition or upper hand in a discussion.
Leading up the chain of command or vertically was a useful metaphor that has let me curb my Ego. But after hearing about Bill Campbell’s feats, I start to wonder if I should replace the word “Lead” with “Coach.” This is a subtle distinction, but it resonated with me so strongly that Bill would proactively take care of his team’s Ego.
Now it seems obvious to me that actual Extreme Ownership must take into account the human element as well – with all needs and imperfections. People need to be heard, but they also need a feeling of being heard.
I run a site and a newsletter about living a deliberate life. I focus on promoting remote work and forging a purposeful relationship with technology.
What do I plan to do with this newfound knowledge?
For one (and this is a recurring topic for me), I need to stop coming up with technical arguments. I constantly find myself in the pattern, where I am trying to get the job done, and I get defensive when somebody suggests a bit of a different direction. The acknowledgment that everybody has this problem is why I find this interview so valuable.
It means that I am not the only one privately waging guerrilla warfare against my own Ego, neither is it a problem inside Automattic.
Bill Campbell helped build the early teams of Google and Apple. He worked with engineering leadership, executive teams, and the board and coached them into the massive success they now enjoy. And his number one concern was acknowledging people’s feelings first and then getting Ego’s out of the way to foster collaboration.
Next time a colleague will “slow me down” with the comments and suggestions, I’ll try to listen and listen not for rebuttal and not even for judgment of the comment, but for understanding.
Yes, you have good ideas.
These are awesome. I value them a lot.
Yes, you have an Ego as well. You are a great professional and should be proud of that.
I am a professional too. And I, also, should be proud.
Now, let’s talk about this issue. And let’s talk about the concern behind the problem.
I am becoming increasingly convinced that solving technical problems is a minor aspect of developing a technical product. Working as a team is much harder and in the end – a worthy goal. Because technical issues come and go, but if you have a great team – you can tackle all of them.
Making sure your teammates are being heard is not your team leads responsibility – it’s yours. Regardless of your position in the organization, you have to remember that you are interacting with human beings. Their feelings are not something that you have to “weather” or avoid. It’s what makes us different from machines. Let’s celebrate that while it lasts.
Public domain.
Automattic Design 