I’ll start with a story.
The first ten years of my career were spent at Google. While not all the legends are true, it is undoubtedly the case that the quality of software engineering at Google was very high. Software had to be well designed, and every changelist (~=PR) had to be thoroughly and rigorously reviewed before being merged.
Most Google Software Engineers remember their first code review. The barrage of feedback, the many iterations, and finally the congratulations of team mates when it finally got that “LGTM” (Looks Good To Me). It was nerve-wracking, but the message was clear: your code had to be good before it made it into the repository.
When I left the Google nest to join my first startup as VP Engineering, I was rather shocked to find out that my team of engineers didn’t do code reviews at all. Instead, people merged straight to master and from there to production. Madness! Using my new executive boss power and a deep sense of righteousness, I mandated a pull request process within my first week.
Except it wasn’t. I monitored the reviews, and nobody was giving anybody any feedback. Reviews were being treated as rubber stamps, just useless bureaucracy. Frustrated, I gathered the team and impressed on them the importance of thoroughly reviewing each other’s work for the sake of the codebase.
Everything seemed to be going OK until a couple of weeks later, when one of my engineers (let’s call him Rio) furiously pulled me into a meeting room.
“You have to do something about Igor. He’s being such an arsehole!” he exclaimed.
“Why? What’s he been doing?”
“He’s blocking my code!”
“What do you mean by blocking?”
“He’s saying all this shit on the pull requests and stopping me from merging. It’s disrespectful.”
It turns out that Igor was doing exactly what I’d asked all the engineers to do: review code rigorously and uphold the quality of our codebase. I knew I’d failed completely when Igor came to me the following week to let me know he was going back to rubber stamping PRs in order to avoid offending his colleagues.
Process is bones, culture is muscle
I learned a valuable and brutal lesson from all this. A process without the cultural alignment to bring it to life is like a skeleton, inert and useless.
Similarly, I have heard from those who have worked at organisations where there was a strong culture of quality software but a lack of defined process. As the organisation scaled the lack of process meant that the culture started to become a liability, devolving into a maze of cliques and undocumented expectations.
Bones need muscle, muscle needs bones. The two together constitute an interdependent working system.
When I joined my next organisation, the lesson of the failed pull requests was seared into my mind. Things were in quite a bit better shape there, with code review already in place and some amount of discussion, but nowhere near the level of fearless rigour I had been used to at Google. The bones were there, and there was a muscle but it was a bit weak and underdeveloped. I saw that it was my job job to strengthen it.
I published a manifesto where I clearly spelled out the cultural expectations. I recruited allies inside the organisation. I repeated myself a lot. I repeated myself a lot. I had a lot of one-to-one conversations. And I watched. Slowly, over time, things got better. Time and reps built up the muscle.
Another thing to note: as any serious gym-goer will tell you, working on one muscle and neglecting others is a sure way to cause injury. I saw that a key part of my work on better pull requests was to build up the bones and muscle around architectural design as well. When creating processes and cultural expectations, consider where else stress points will emerge and work at the same time to strengthen your organisation there.
A circulatory system for information
A couple of years back we got a review on Glassdoor slamming us for a lack of transparency. Then, a few weeks later, another one. How could that be? As a management team we strived to be transparent. We shared our numbers with the team, discussed strategy, updated them on our capital raising efforts. There were few secrets. And yet: “management preaches transparency but does not practice it”.
Even more recently, frustration grew the other way. Upper management felt that we had no effective way of finding out what was going on in the teams that we responsible for. Any attempt to extract that information inevitably felt heavy-handed and unwelcome. What was going on?
On reflection, transparency is completely the wrong term for what people in an organisation really want and need. Information is not some inert substance that simply is put on display for viewing. Instead, it needs to get to people at a time and in a form that enables them to do their jobs. It needs to go down, up, and across. Simply but: in order for the the organisation to remain effective, information needs to circulate.
Circulation of context and information is way more than mere transparency. Many questions need to be answered: Who needs to know what information? At what times? What form should it be in to be digestible? How does information get updated and refreshed? And so on.
Indeed, the circulatory system itself requires significant process design, and significant cultural investment to get right.
It’s worth it though: without adequate circulation of information the many muscles in your organisation’s body will begin to wither and die.
Keep your organisation healthy
Every metaphor has its breaking point, and this one is no different. There are many ways in which organisations are not like the human body! But I have found these three parts—blood, bones, and muscle—to be foundational to a healthy, well-functioning team. Tend to all three, and it’s amazing how many other things will work themselves out.
If you found this post useful, I would like to request that you share it with other people who may similarly benefit from it: