Lengstorf: I want to talk about how to build a unicorn. More specifically, how we can create really highly productive teams so that we can make our companies into what a VC would call a unicorn. I want to talk about how we do that by lowering stakes. The first thing that I want to talk about is, what is a unicorn? What do we mean when we call something a unicorn? Specifically, when you hear a venture capitalist call a company, a unicorn, they’re usually talking about a company that is valued at over a billion dollars. I think there’s another way of describing a unicorn, which is, when you hear about these companies that achieve like an almost legendary status, everything they ship is amazing. Their teams are amazing. People would do anything to work there. They just get this ethos around them where everything they touch turns to gold. We’ve seen companies like this. Steve Jobs era Apple. The early days of Google. To a certain extent, like Apple now and Google now. These moments when these teams are just unstoppable. That’s another way of looking at a company being a unicorn. That’s something that I think we really want.
If we think about what makes a company a unicorn, it boils down to people. Because you can have bottomless pockets, you can have access to all the talent in the world, but if you’re not able to get the right people and the right ideas all working together and doing things well, then it doesn’t matter. We see companies with deep pockets, blow it all the time. They miss the market. They just can’t ship. They don’t get something out in time. They get beat to the punch by a team that’s delivering more effectively, and they just fade into irrelevance. I think instead of saying a unicorn, maybe we should talk about what makes a team work, because these are the things that are actually going to make the difference.
What Makes a Team Work?
Let’s talk a little bit about this. The best teams are going to ship fast. They get things out the door quickly. We’re moving, and everything that happens is happening at pace. You don’t see these big slowdowns. You don’t see people get stuck for months between delivery. They’re getting things out the door quickly. The best teams are also working together. You’re not seeing this siloed off or very isolated, unfriendly working environment. Instead, you’re seeing these highly collaborative, you can sense that this is a team that has gelled. They’ve found a way to really work together and to be a unit as opposed to individuals working towards the same goal. That really shows in these unicorn teams.
Ok, But How?
What I want to talk about is not just the abstract of this, what could be or what should be a great company. Instead, I want to get into a little more brass tacks, so how? How does this happen? What makes a team? What can we do? What do we actually control that allows us to get these wonderful teams put together and functioning? To talk about what we can do, I think it’s also important to talk about what goes wrong. We should talk a little bit about what causes teams to fall apart. How do we kill unicorns? How do we get ourselves into trouble and prevent ourselves from being able to do the things that we want to do. I think that a few of these end up being architectural, and a few of these end up being strategic.
Let’s talk about software architecture a little bit to start. The first thing that I’ll say is, we’ve all had a moment where we said, let’s just put all the code in a big pile. Unless you’ve got some really rigorous tooling around that, and some really rigorous documentation and safeguards, then you end up with something that feels a little bit like this. You walk into a room, or into a code base, in this metaphor, and you’re looking for something that you need to fix. You find yourself over in one section of the code base, and there’s tens of thousands, or maybe millions of lines of code. The thing that you’re looking for is actually way over here, and you have no way of knowing that. You have to go ask questions in a public Slack channel and hope that somebody who has enough context notices and can point you to the right person. It demotivates people. This gets messy. It gets hard to track. It gets hard to maintain. It really tends to just like drag a team down.
The next evolution of this was we said, let’s ship microservices. We’ll split the code up by its product domain, and that is going to give us the ability to do less. We don’t have to keep as much in our heads. We don’t have to manage millions of lines of code. We’re just going to do a little bit at a time. The problem is that this only tends to divide the app vertically. What that leaves us with is that if we’ve got frontend engineers and backend engineers, and we have a team that is all frontend, and a team that is all backend, and each one of them has a microservice they have to maintain, we end up with this problem, where, to misquote Carl Sagan a little bit, “If you wish to make an edit to the CSS, you must first install Docker.”
It was a really rude awakening for me when I went to my first microservices based company because I joined a frontend team. I was specifically hired as a frontend engineer. When I went onto this team, the first thing I had to do was install Docker, install NGINX, go into a bunch of config file, start running some backend scripts, and then configure some database. That was all just so that I could get a development environment up so that I could make my first commit to the code base, which was to tweak some of the styles. That type of complexity just to get up and running, that’s brutal. I came in where I used to do backend code, and so I maybe ramped up quickly. It still took me the better part of a day or two, to get my development environment up and running properly after I’d chased down all the right people to get the environment variables and all the things that I needed to get my microservices running on my development machine.
Complex Code Bases
Then, that type of complexity, that everything is in a big pile, or we’ve got microservices with this setup complexity, it leads to fragility. That fragility leads us to say things like, only Steve can merge pull requests. Steve’s got all the context, and so we’re going to make sure that he’s looked it over and that it’s all ok. Then to make sure that we don’t keep our DevOps team up all weekend, we only deploy on Thursdays. We only do one deploy a week. It happens on Thursdays. If you don’t get your code in by Thursday, it’s going to wait until the next week. Both of these things are done for safety purposes. We want to avoid risk. We don’t want to put ourselves in a position where somebody who maybe doesn’t have the experience with our app will push something that accidentally breaks production. We can’t have that. That’s not a good thing. Then only deploying on Thursdays, like that makes sense if your code base is really difficult to deploy, and really difficult to recover if something goes wrong.
All of that puts us in this weird situation where now we’ve got this gatekeeper. It’s not done because we don’t want people to be able to work, it’s done because we don’t want to break the build. It still puts us in this situation where it feels like, I have to ask permission to do my job. If I have to go ask somebody, can I merge? Then after they merge, I have to wait until Thursday to see the thing that I built go live. Then I find a bug on Friday. Then I have to wait until next Thursday to get my merge in to fix that bug that I created. That’s such a frustrating way to work. You have no way of getting things done quickly, because at best, you’re going to be able to ship once a week. That doesn’t feel good. It doesn’t feel fast.
Then the other problem that you end up with when you’ve got these complex code bases, and you’ve got a lot of contextual knowledge, is you end up hearing things like this, “We don’t touch that code, because we don’t know how it works after Laura left.” It can feel a little bit like you go in and you look at all these patch cables, and you don’t know what things do or why they’re there, or what they’re meant to be. An actual quote that I heard at one of my previous jobs was, “As far as we can tell, this code is never actually used, but everything breaks if we delete it. I’m sure that code was used somewhere, we just couldn’t figure out…
Read More:Create Autonomous, Highly Productive Teams By Lowering the Stakes