Creating cultural policy documents can be hard, because getting started on these documents from scratch is hard. Fortunately there are fewer and fewer documents that you need to start from scratch to create, as more people are sharing publicly their policies and processes for everything from career paths to pay scales to incident management. However, just having a starting point and copying it is not always enough. I learned this the hard way when I tried to roll out my first engineering career ladder. As I said earlier in this chapter, there comes a time for adding structure, and that time is usually when things are failing. The failure that drove me to create a career ladder came when our HR team was doing a salary review for the engineering team. I realized that we had no salary structure at all. Because of that lack of structure, most people were paid based on a combination of their previous jobs’ salary and their negotiating skills. Additionally, we had a hard time figuring out who we needed to be hiring in. Were we only hiring “senior” engineers? What did that mean? What about management or other roles?
After a nudge from our HR team, I set out to create a ladder, which I’ve cited in pieces throughout the book. I did this by asking my friends who ran other startups if they had one. One of my friends did, and he shared it with me. It had eight levels, from entry-level engineer to executive, broken into four categories: technical skills, getting stuff done, impact, and communication and leadership. I took this ladder, added a few more details, renamed the levels, and rolled it out. This makeshift ladder was very basic. For each level, at each skill, you got one or maybe two sentences on what classified a person as working at that level. Even with some additional information from me, there were perhaps four points you could look at for each category. The worst were the earliest levels, which were the most basic and provided very little guidance to early-career engineers. I delivered the new ladder to my team, and even communicated the new ladder in the same style that my friend used to communicate it to his team. I told them the ladder existed to make sure we were being fair with things like compensation, and it was something they could use to discuss their level with their manager and learn how to grow. I told people it wasn’t a big deal, that they shouldn’t obsess over their level. I then spent some time talking about John Allspaw’s blog post “On Being a Senior Engineer” in an attempt to inspire the team to push themselves.
Long story short, my first ladder was a flop.
Why did a ladder that seemed to work fine for my friend fail so badly for me? I can only speculate, but there were some pretty big differences between our companies. My company was very diverse in terms of background. I had a team that was mostly pulled from small companies and startups, with a handful of people like myself who had worked at big finance companies and only a couple who had mostly worked for big tech companies. We had no real shared cultural habits to pull from because of this diverse set of work experiences. My friend, on the other hand, managed a team that had a very large, strong core of people who had all worked for the same large tech company, so there was a lot more shared understanding that didn’t need to be made so explicit.
I share this story for a very important reason: where my friend was able to succeed, I failed, despite following the same template. This lesson is crucial for anyone who wants to create good team culture. What works for one company — a company that is creating a certain type of product or working in a certain industry — will not always translate well to another company, even if the companies have a lot of things in common. We were both managing startups when we rolled out our respective ladders, and our teams were similar in size, but we needed very different things for our teams to be successful. My first ladder was a flop because my team needed more details. The goal of the lightweight ladder was to keep the team from obsessing over their levels and promotion, but instead the lack of detail caused many of them to obsess even more. Engineers argued that they deserved to be at higher levels because the details were vague. It caused a constant series of headaches.