Jul 22, 2021 10 min read Mental Models

Unraveling Title Insanity: 59, L5, Senior, Staff, Principal, and Gandalf

What are levels for? Do you understand the career ladder at your company? How do you read job histories? What do examples look like?

As a developer there comes a moment when we start to reflect and realize that our growth is not linear. Like the states of matter in physics (solid, liquid and gas), we also move through different states in our careers. In the same way that the relationship between ice and water isn’t obvious by just looking at a photo, I needed some experience to understand career stages.

For more than 15 years, I have used three coarse labels to model developers’ career stages: Needs Guidance, Works Independently and Leads Others. I use it in interviews as an intermediate to map career ladders across companies. I use it while counseling developers, doing promotions, and calibrating opportunities. I use it for non-developers.

I have riddled over the simplicity of this model for many years, and while it lacks the precision of other career models, I return to it as a first order tool. It just feels natural and effective across companies, job families, and even industries. It is essentially the same stages used by medieval craft guilds (which are also still used in some trades): apprentice, journeyman, and master.

In this article, I will define the model, apply it with examples, share the backstory, and look into the distance.

Definition

While my labels have an intuitive mapping for most people, over time I have refined how I classify behaviors and people based on their actions and explanations. It also works when I need to evaluate my own behaviors. It’s not a flat judgment, since we are not at the same stage for all dimensions.

As soon as I start listening for someone’s stage, I find that people self-classify pretty easily as they explain what they are working on. I ask some questions, but mostly I just need to listen and observe behavior and they will reveal the truth. I prefer to look for positive strength signals for this exercise. I also know to probe for risks (negative atributes) that need to be considered, but I like to keep them separate when identifying the career stage.

Listening for: Needs Guidance

I demonstrate value almost exclusively through building Product (90%).

I look to my leaders for vision and tasks. I am trusted to implement solutions. I plan for myself in days and weeks. I am most successful when I deliver on sprint tasks.

When I see something, I say something. I follow best practices. I manage risk by avoiding ambiguity.

I am receptive. I aspire to own and build features.

Listening for: Works independently

I demonstrate value mostly through building Product (75%), and I have side gigs building Process and People.

I look to my leaders for vision and goals, and I am trusted to design and deliver features. I plan for myself in weeks and months. I am most successful when I deliver on our team goals.

When I see something, I do something. I discover and analyze processes and tools that I can use to make myself more efficient. I see external changes and ambiguity as risks to manage. I know when I need help and how to find it.

I am opinionated. I am intrigued by emerging technology. I use research and data while presenting my ideas. I aspire to architect and build systems.

Listening for: Leads Others

I demonstrate value evenly through buiding Product, Process, and People (33% / 33% / 33%).

I look to my leaders for vision and opportunities and I am trusted to develop goals for the team. I plan for myself and others in months and quarters. I am most successful when my team delivers on our goals.

I anticipate when others need help and intervene. I balance the needs of the team against the needs of the business.

I am comfortable admitting ignorance of technical topics. I am skeptical of cargo cults and paradigm shifts. I listen for and seek to disconfirm my biases while presenting my ideas. I see external changes as a challenge to learn and an opportunity to shine.

I seek ambiguous problems to drive clarity. I synthesize and drive adoption of new processes for myself and organization. I aspire to build networks and businesses.

Usage

I use this model most regularly in hiring. As part of the prep, I also compare their resumes with sites like levels.fyi and progression.fyi, but a lot of companies aren’t listed. I will share some example behavioral questions, but for brevity, the answers skip over technical specifics that would normally be required. All the answers are reasonably strong at different stages.

Question: Tell me about a time you knew a colleague needed help and decided to step in. How did you identify the need? What did you do? How did it turn out?

Answer from Needs Guidance: We had a new joiner on the team. After their onboarding, my lead asked me to help out with their first sprint task, while they were getting to know our systems. They were stuck in one of the same spots I had trouble with in the beginning. So I sat with them and we worked through it together. We were able to get the task done and it was only one day late. Now they know about this problem and can help the next person who gets stuck. I told my boss that everyone gets stuck there and we should fix it.

Answer from Works Independently: We had a new joiner on the team. After their onboarding, they took their first sprint task from our backlog. During standup, they didn't say they were blocked, but I saw they were making slow progress. I knew what they were working on, and sent them some documentation that could help. Teach a man to fish, you know? They still needed a little more help, but we got it done and it was only one day late. Afterwards, I updated the documentation with what we did.

Answer from Leads Others: We had a new joiner on the team, and I always setup an intro and followup checkins to track progress. With the intro conversation, I knew they would need some extra help on their first task. I sent them our documentation and asked the previous newbie to be a buddy if there were any problems. The first task had a hiccup, but the buddy helped out and it was only a day late. In my follow up, I realized hiccup was a pattern for newbies. I double checked with the team, and then added work to our backlog, with a deadline before the next joiner. When the next person joined, I made sure to verify the issue didn't cause problems any more.

Question: Tell me about a recent incident you handled as part of DevOps? What was the timeline? What did you do? How did it turn out?

Answer from Needs Guidance: I got paged during the night. I followed the runbook and rolled the deployment back to mitigate the issue. In the morning, I looked at the commits and narrowed it down to two changes. I brought it to stand up and someone explained why it broke. I volunteered to fix it, knowing who I could go to for help.

Answer from Works Independently: I got paged during the night. After rolling back, I made sure the bug was mitigated and tracked down the bad change. In the morning, I got a fix ready and submitted for code review. Our team is new to incident response, so I have also started using 5 whys process, to get better root causes. I added the root cause to our tech debt backlog. Honestly, we have a lot of tech debt, and I have been frustrated that we never seem to have enough time to fix it.

Answer from Leads Others: We had a major outage in the night. One of my colleagues got paged and handled the mitigation, which was a good sign for our runbook. I have been formalizing the incident response processes, which now includes root cause analysis. The good and bad was that this latest outage was a known risk in our backlog, and we hadn't fixed it. TK

Backstory

I already had the idea to become a developer when I joined Microsoft as a contractor. I started out answering phones for Product Support Services (PSS) in 1994. My plan was fuzzy on many details, but it was audacious for someone unemployed and without a degree. I wrote that I wanted to “liberate information on a global scale,” for the objective on my first resume.

I still get tingles up my spine when I remember Garth Brown introducing me to NCSA Mosaic running on a SPARCstation. I knew that I wanted to be a builder of the web, even when the web’s potential was mostly hypothetical. My passion for this idea fueled my growth in those early years, urging me to take risks.

Once inside PSS, I found an autodidactic dream world. The learning materials were completely open and full of top notch applied knowledge. It was as if they took all the manuals that were in publication and then condensed them to just the good parts.

I was a hungry sponge. I learned to support new products every month: MS-Works, Multi-Media, WFW311, MS-Office Setup, etc. I was so pumped that I took risks, like turning down that first-in-my-life promotion in PSS. It would have been a smart career step, but I was looking for jumps.

And jump I did! I redefined my role as rapidly as I could prove my new skills.

I moved to building 5 as a tester (STE) after Bruce Johnson showed me an opening on Internet Explorer (IE). There I got to watch Raymond Chen debug raw assembly when my tests caught crashes in Windows 95. I shipped code for the first time, which was a tool the public could download via FTP or BBS. It was a dialog box written in one long ugly C-function that converted Netscape bookmarks to IE favorites. Neil Smith saved me from being fired for talking to a reporter at my first launch, when all the excited people were lined up outside stores at midnight to buy 13 Win95 floppy disks.

I went blue badge as a developer in test (SDET) on IE3 and moved to building 27. There I wrote my first production feature, doing link coloring persistence. That wasn’t technically my job, as an SDET, but Bharat Shyam convinced me to run with my idea and sneak it in. And Chris Guzak convinced me make it a COM object, thus IUrlHistoryStg was born. I was so clueless, that when I made my first push to mainline using SLM, I stayed alone in the office until 4am fixing all the build breaks. Some lessons can only be learned by breaking the build.

And then I became real live actual developer on IE4/Shell. I had been lurking on the uri@bunyip mailing lists for a while, so I took on unifying all the independent copies of URL parsing in IE, and learned the first rule of coding for the internet: NEVER WRITE YOUR OWN URL PARSER. Which I never really learned, but I tell other people often. I found out what a good developer boss looks like from Chee Chew, who also taught me how to play go and Age of Empires over lunches in building 31.

After we shipped IE4 and Windows 98, my career was code complete. I had a achieved my goal of becoming a developer. In some way, it felt like I had over-achieved by creating platforms that powered the dotcom boom: We were transforming the world and information was being liberated.

I was triumphant. I loved being developer. I loved working with brilliant people. I loved working on products with such an impact.

But I didn’t have a second act planned. Without the pressure to reach the summit, I found out plateaus are a nice place to catch your breath and see the view. I started paying more attention to the developers around me. I listened for their plans. I heard their schemes and dreams. I heard their victories and disappointments. I heard their theories and promises. I collected stories that resonated.

I observed 3 stages for devs: Clueless, Hotshot, and Inscrutable. Most fell into the clueless to hotshot range. And I knew that’s where I was, too. I didn’t feel utterly clueless anymore (that was reserved for interns ;) but there were some crazy smart and experienced developers who made it obvious how much there was to learn. And some devs, like architects, really seemed impossibly far away. I couldn’t tell if they were cryptic on purpose, or if I was really more of an intern than I wanted to believe.

At that point, I was looking at potential career paths, but I ignored the path of switching to manager or another job family. I also read, but mostly ignored, the tools that Microsoft HR used to define ladder levels. They were abstract, and I had a hard time matching them with what I saw in my day to day.

So I was cruising into my hotshot zone, enjoying my life, sharpening my code, but without much of a plan for what comes next. And then in 2000, Microsoft revamped the career ladder levels. They also changed all the tools, documentation, and I assume manager training, which verified for me how arbitrary these things are. This was accompanied by the dotcom crash, which flipped the tables on the job market, compensation models, and for many people their personal tech stock fortunes. It was a time of much navel gazing around the company.

In one of the frequent cafeteria discussions on the changes, someone pipes up that the new levels actually changed nothing. They said, “You can just map the old system and new system to the real levels: Needs Guidance, Works Independently and Leads Others.” A light bulb popped; it was just that simple!

Further thoughts

What about other leadership qualities? There are many other career paths, of course. Similar to war time and peace time leaders in politics, companies require leadership styles that fit the phases: exploration, crisis, scaling, gardening, etc. Promotion paths become just as diverse as the needs of the businesses they are in, especially for individual contributors (ICs).

What about the manager track? I can recommend it! I have done it before and would do it again. I love the feeling of investing in people, and making them stronger. We often measure scope of influence by checking how big the organization is, and where they sit in it. It’s pretty obvious for managers, but the softer influence of ICs makes this more subtle. But just managing people doesn’t magically make someone into a leader. You can also have someone who has reached leads others, but has a role of limited scope, by accident or on purpose. And there is the converse, where someone has a role with a large scope but still doesn’t demonstrate leads others.

What about Gandalf the White? It’s true that as people grow further in leads others, they don’t remain evenly split between buiding Product, Process, and People. The focus becomes increasingly on how to amplify impact by working through other people. They understand how the mission requires building value in many dimensions simultaneously.

What’s up with all that name dropping? I wasn’t alone. All those people made difference in my career. I am thankful that they were allies, sponsors, or simply inspirational. It doesn’t matter if I discovered them or they discovered me, because I was changed either way. I know I still have a lot to learn, and I seek people that will challenge and support my next growth stage.

Zeke Arany-Lucas is a senior principal engineer from Seattle, living and working in Berlin since 2014. He has been in tech industry for more than 25 years, starting with web browser development in the 90s, including long stints at both Microsoft and Amazon in multiple leadership roles. You can also follow him on LinkedIn and Twitter, and his podcast, The Introspective Developer, on Spotify, Apple Podcasts, Instagram, and Facebook.