On SWE Levels
I've worked at a few different companies as a software engineer. Most have an Eng Levels ladder of some kind, describing what sorts of work and impact are expected for someone with a given title. Want the higher title? Deliver results commensurate with the next level of the ladder.
The purpose of the ladder is to provide guidance to individuals on what they need to do to progress, and to provide a more objective framework for Deciders on whether an individual qualifies for promotion. Are ladders effective in these roles? Perhaps. But I'd like to share an alternative lens that may be useful to some readers.
It's the job of every Software Engineer (perhaps even every Human, but we'll stay focused) to do two things:
- Figure out what to do.
- Do that.
The question then is: How, or how well, do you do those two steps?
The second one is relatively straightforward: What is the quality of your work output? This is well-covered by existing leveling ladders. How technically challenging is your work? How well do you collaborate with other teams?
But that first step is more important and often less considered.
How does a software engineer (or anyone) figure out what to do, what work tasks to tackle on any given day, hour, or minute?
The answer varies.
You're a new grad software engineer just joining the workforce, and a company, for the first time. You have no idea what to do! So you ask your manager. They likely assign a small task in an existing system. You do the task, report your success, then ask again for the next task. For an engineer just starting out, this is a great strategy for "figure out what to do"!
The cycle repeats a few times, with your manager assigning new tasks surrounding the same problem or system space. Eventually, you build up some context and start forming your own ideas. The next time you need a new task, you instead /propose/ a task to your manager, within the space of the context you've been working: "I noticed [A] in the current implementation, so I thought I might do [B] to address that." If this is a good idea, your manager approves the proposal. Congratulations! Or, if it's not quite the right task at this moment: "That's a great idea, but actually the priority is [C] right now."
Either way, you've leveled up, just a little!
Over time, your proposals will have a higher and higher hit rate, until eventually your ideas are getting approved most or all of the time. You stop asking permission to work on items, and instead just take the initiative, get things done, and report your successes. You have a high-trust relationship with your manager. They know you'll make smart decisions, so they stop micromangaging your work tasks.
You've leveled up again!
But your manager still has more visibility, context, and strategic vision. You're effective in your space, but one day your manager says "Hey, you're doing great work on all those features for [D], but we need someone to build a new service that does [E] and [F]. Think you can handle that?"
You thought you had independence and trust! Now you're being told what to do again! What happened?
The work you're being assigned is now at a larger scope. The tasks are fewer, bigger, and longer term. There's room for independence in the details of how you execute.
You haven't regressed at all. Rather, you've leveled up yet again.
This process repeats. You gain experience and build trust within a space, making decisions for yourself within that domain. Then you're once again be assigned work, this time at a broader scale. You move from microtasks, to broader problems within an application, to owning entire services, to architecting collections of services, and then full business domains. At each level you go through the process of being assigned work, to proposing new work yourself, to attaining trust and independence.
Don't try to force the progression. It can't be forced. The experience to be effective within a given domain or scope must be earned. The trust of your manager must be earned. To wield independence too soon is to go rogue. You risk working on the wrong things, being out of alignment with the broader strategy, and ultimately hampering the effectiveness of yourself and your team..
As an IC, ask yourself: How do you decide what to do? What skills, knowledge, and context do you need to be effective at the next level? What opportunities do you need to learn those traits?
As a manager, consider: How much detailed guidance do your reports require? If you're overwhelmed by tracking the micro-details of work on your team, can you delegate some of the details to team members that you trust? Maybe the details of the work don't matter so much, only that the business objectives are accomplished, and that someone you trust is vouching for the quality of execution. And, how do /you/ figure out what to do?