I’m now a very senior engineer. I don’t even know what the right title is (once I got “CTO” titles kind of stopped mattering), but at Gusto I’m an L6 and there are seven levels at the company.
One of the great things about working at a larger company is how many people I get to work with, and how many opportunities I have to mentor more junior engineers.
We spend so much time early in our careers just learning the mechanics of our immediate job: how to write code, make it maintainable, how to test it, how to make it performant, etc, etc, etc. That takes years, and is a lot. And then someone promotes us, tells us we’re now a “senior” engineer and we’re now presented a whole new scale of problems, and all of those problems involve people.
I think the industry does a pretty terrible job of preparing software developers to deal with people problems. We tell them to focus on code, which is important, because that’s the first layer of what’s expected of us.
If we think about the problems we deal with as we get more senior as layers, I think it’s easier to understand them. To me, in this very much first draft of me putting this into words, the layers are:
- Code: We have to be good at this to be asked to do anything else (even though almost all code problems are also caused by people).
- Individuals: We have a manager (at least one), people on our team, product managers, designers, etc. We need to deal with them individually and make sure we get what we need, and meet their needs.
- Processes: Everything we do at work is some kind of process – the meetings we have, how we deliver code, how we get rewarded for our work, all processes.
- Systems: Collections of processes in action – I think of them mostly in code, but “the patriarchy” is a system.
- Organizations: Organizations are just groups of people who create systems in order to accomplish their goals. Depending on the size of your company, you may in a nesting doll of organizations and may interact with several more.
As you get more senior, you’re expected to be able to solve problems on and across all of those layers. The hard part is figuring out what layers are “crossed by the problem you’re trying to solve, and then peeling them off and solving them – because the tools you can use are wildly different at each layer and require different skills.
The good part is that solving problems across layers is extremely valuable to organizations, so if you can do it, you’ll be just fine. The bad part is that as soon as you start crossing layers, people are always the problem.
