I just finished Ben Horowitz's "What You Do Is Who You Are". I want to focus on the biggest lesson I took from the book about creating your own culture. I sum it up in this way; there is a specific belief or outlook you have, that others do not, which will determine the level of success of your endeavor.
It made me ask the question of myself. First off, my general "endeavor" has always been a well-functioning Engineering department, especially regarding "the Product" and Product Management. I admit, this is not the culture of a whole company that is looking to either "change the world" (Ha!).
I think everyone would agree that "not wasting other people's time" is an obvious thing we all agree about. However, I don't think most people actually take it seriously. One example from the book that I appreciate is from Bezos at Amazon. Meetings have agendas. They take the form of a written explanation/argument, it is not merely a set of bullet points. Every meeting starts with silence—while everyone reads the agenda. This also necessitates being on time. If everyone came on time, and was prepared, because they read the agenda beforehand, and learned what they needed to know, and read the agenda again—to get their head in the right spot for the meeting—you can finally have a productive meeting. Making shocking rules around being prepared for meetings, and living by those rules really has the chance to shorten those OODA loops, so you can waste less time as an organization, and have better reactions to the world.
But what belief do I have that is unique, that others would likely disagree with, that will make a critical difference in these teams performance? If I were to try and put this into words it would come out something like; "Build so you can walk away." In my career, this has been the defining element of my own success. Over the last ten years, every production system I've built, all four of them, are still running. And I've walked away from all of them to build the next one. This was absolutely based on a constraint—for three of those projects I worked at a three person company. In order to do more work, we had to stop doing other work. But the software kept running and people used it every day.
I view this topic as the primary difference in the maturity of the software industry versus other industries. What happens as we continue to work on our software products? We hire more folks, and create more features. More, and more, and more. But, at some point, you need more and more people to even keep up with managing what you've created. That is not scaling and does not scale. In other industries, like construction, the size of the crew doesn't change much. They move from site to site. Once they leave, the building is up and running and, more or less self-maintaining with some basic oversight no where near the level of investment to construct the building.
Underpinning this belief is an axiom that the most expensive part of any work is the cost of communication. That is why "adding people to an already late project makes it even later." Will Larsen's discussion about migrating services also sticks in my head on this topic. When you're in a growth trajectory your processes and software will be useless roughly every 18 months. Because so much has actually changed on the ground, that what worked at one size, no longer works at the new size. Who are the people most capable of building the new system? The people who are watching the current one fail (assuming everyone is reasonably equal in terms of technical ability). They won't have the ability to build the next one, if they can't walk away from the current one. There are many reasons people need to walk away from something, the largest of all is when they leave a job.
My favorite parts of the book were reading the various "shocking rules" of each of the cultures the book went over. What would my own shocking rule be? How would it enforce my culture of "build so you can walk away"? I'm still working on this, but something along the lines of a forced vacation or rotation every few months, or after shipping a project. I'm not sold that is precisely the rule, but, that is what my brain is stuck on right now.
This has a dynamic similar to the "should we release/deploy on Friday?" question. If I ask you how confident you are in what you're about to release/deploy, you say "Very confident!" If I said "Great, release it on Friday at 5pm!" would your answer change with the threat of having to work on the weekend if it goes wrong?
If I told you that tomorrow you will be working on something new, what would happen to your last work? Is there enough documentation for someone to figure out how it works? Are there enough tests so that other people can confidently make changes without worrying they're going to break the world? How many times a day is someone going to interrupt you with a question that only you know the answer to? How quickly will that exhaust you and mean you can't actually make progress on the new priority?
Moving people around regularly can build all these muscles. These muscles are valuable to creating the most value with the fewest number of people. Fewer people means paying less communication tax. That is scaling, not just getting more humans into the building. This process will also create a selection bias of people that are good at communicating. Why? Because I'm forcing them to. I'm forcing them to communicate ahead of time, through writing, through tests, through agendas and meetings, through good design and UX. Someone who stays on the same team, on the same codebase, for a long time, no longer has to communicate, because everything is known to them. And it's all in their head. How does this data get out? Usually by random osmosis of other people who need data asking random questions. It's almost never systemic. I want my culture to be one of systemic communication so that you can build something, and walk away from it—knowing that it will keep working, and that others have resources to onboard themselves to it.