This guest essay is by my former student Nathan Lin.

At age 30 I was able to retire from my software engineering career to pursue my interest in day trading. I had advanced rapidly as a software engineer, climbing through multiple promotion cycles. Combined with some good luck and timing, by my 30^th birthday I had enough of a bankroll saved for the next 5 years.

I didn’t start my career in Big Tech, although I did end my almost decade-long career there. I’ve worked in various sized companies with as few as 50 engineers to over 30,000. What I discuss here should work regardless of the size of company.

I didn’t knowingly create this framework of expectation management at the time. Only by reflecting back on my career and identifying the recurring themes am I now able to put a name and a method to it. It’s largely inspired by Jake’s essay on How to get coaching, mentoring, and attention, which I read in college, and changed the trajectory of my academic and professional career.

My framework of expectation management is built on the same foundations, and is like a “Part 2” applied to software engineering. 

Cycles

A key part of the framework of expectation management requires you to understand cycles. Cycles continuously repeat themselves throughout your career, and it is imperative that you understand:

1. What cycle are you at in your career? (The primary cycle)
2. What cycle are you at in your specific job? (The secondary cycle)

Just as the seasons change and pass, so too does your location in the cycle change, and that location determines how you must manage expectation and performance. Note that the primary cycle also applies to other corporate 9 ­– 5 jobs:

1. The novice (0-2 years)
2. The intermediate (2-4 years)
3. The expert (4-10 years)
4. The guru (10+ years)

These cycles apply not only to you where you are at in your career, but also where you are at in your job. I discovered this first-hand as I followed the software engineering maxim of moving every 18 months to maximize compensation. There’s always a “rampup period” where, even though you may have a few years of industry experience, you’re given time to learn your new employer’s technology stack.

After that period, you’re expected to perform at a meaningful level. And after even more time, you’ll be expected to handle expert-level questions and solve tough problems. The cycle is compressed from years to months compared to the career cycle. I call this the secondary cycle:

1. The novice (1-4 months)
2. The intermediate (4-12 months)
3. The expert (12 – 36 months)
4. The guru (36+ months)

If you want to advance rapidly, you must know your location in both cycles, and destroy the expectations placed on you. The expectations are cycle-driven and tacitly acknowledged. The industry itself is aware of these cycles, as this is how roles and expectations are defined. However, these cycles are never really explicitly discussed, which is what makes exceeding expectations and rapidly advancing difficult. I’m trying to make tacit knowledge explicit. Most CS programs don’t include class called “the software engineer career,” but maybe they should.

The secondary cycle is reflexive, based on your location in the primary cycle. So, if you’re a novice who just graduated college as a 22-year old, you may be given 4 months at your first job to be brought up to speed. Some companies will even give slightly more. But as you progress to intermediate and expert, you’ll be expected to ramp up faster.

After all, if you’ve been in software for 8 years, why would it take you 4 months to ship your first meaningful pull request?

Expectations

Understanding the actual expectations is the last piece before getting to the framework. The framework itself is quite easy to apply once you understand cycles and expectations.

You must understand the cycle you’re in so that you figure out the expectations for both the primary and secondary cycles. They’re pretty much identical, so I’ll discuss the primary cycle:

1. The novice – junior engineer
   1. Requires supervision and frequent check-ins
   1. Needs to be told what to do next
   1. Sees the 10 foot view
2. The intermediate – midrange engineer
   1. Requires minimal supervision
   1. Capable of self-direction and identifying the next task in a larger project
   1. Sees the 100 – 1,000 foot view
3. The expert – senior engineer
   1. Supervises intermediates and novices
   1. Plans entire projects to solve business needs
   1. Sees the 1,000 – 10,000 foot view
4. The guru – staff/principal engineer
   1. Supervises experts, intermediates and novices
   1. Plans large-scale initiatives that break down into projects, coordinates with multiple teams to do so
   1. Sees the 10,000 – 100,000 foot view

Another way of viewing the cycle: at the novice level, you’ll always have someone you can ask for help. If you get stuck, ask your mentor/team lead/a senior engineer. But as you advance, you work on harder and harder problems and the number of people you can ask for help approach 0 at the expert and guru levels.

When you get to those levels, you are the one person you can approach for help, and you must ultimately figure out the answers by yourself. Note that you can (and should) consult other experts for ideas. Peers often spark new perspectives and ideas. In the end, however, you’ll have to do the heavy lifting yourself.  

The Framework

The framework is actually very straightforward:

1. Find your location in the career cycle
2. Find your location in the secondary cycle
3. Exceed expectations

Now, you don’t necessarily have to exceed expectations. This really depends on your goals and how motivated you are. You don’t have to do it the way I did it, working 60+ hours a week to climb furiously. I had a goal in mind and I was determined to get after it. 

If you enjoy the 9-5 corporate life, there’s nothing wrong with meeting, instead of exceeding, expectations as the third step. The 9 – 5 corporate life can yield a great career, and if you know which companies have a healthy work life balance, you can have a very fulfilling job.

How do you exceed expectations? I only gave a high-level summary, so you may have some trouble with the details. But the rough idea can be found in Jake’s essay: prove to your team, especially your team lead and manager, that you’re here to get shit done. 

And the only way to prove that is to actually do it. This is where the rubber meets the road, and where the buck stops. Delivering results is the measure by which all top-level performers measure themselves and others by. So you must start speaking their language. The easiest way to do this is to deliver a small result as fast as possible, in your first week if you’re experienced, or your first month if you are a new graduate.

I’ve found fixing a low-risk bug, or improving test coverage especially reliable.

This is where the concept of cycles comes into play if you want to do this efficiently. You can quickly demolish expectations when you first arrive at a new job. Expectations are low, your team is giving you space to learn, so this is therefore the most logical place for you to make a first impression.

The beautiful thing is that this small result compounds. You’ve established a foothold in the codebase, and it’s now easier to work outwards from there. There may be some starting effort to establish the initial foothold, but it’ll pay off as the next pull request becomes easier. And as you continue to add code and make improvements, you’ll end up holding entire swaths of the codebase in your head.

Word on the team will travel fast. Good engineers are hard to find, and your mentor will mention your results to your manager. Your manager will begin to pay attention to your development. You may end up working on projects designed to promote you to the next level. And you may work with the heavy hitters on your team, and it won’t be a coincidence.

Skills compound over time. Mentorship opportunities open up to those most worthy of them. Life isn’t always fair, but over time, merit wins more often than not.

Promotions

If you want a promotion you must exceed expectations. At a certain point in time, you must begin signaling the attributes of the next rank above you, which requires two things. First, you must be proficient in your existing role, and second, you must begin to model the people on your team who are already at that next level.

Reverse engineer the next role, and ask yourself: “What does someone in that role do that I don’t?” So if you’re a junior engineer and you wish to become a midrange engineer, start proactively taking on tasks. Identify the next logical step to do without waiting for your mentor/team lead to give you the task. 

There’s an element of critical thinking here where you should ask, “What’s the next thing I should work on to efficiently move the project towards the finish line?”

Ship some code, then go back and refactor it, or move to the next task: “This is in a part of the codebase I was just in, I’m already familiar with these files.” 

Model the people who are already at the level you want to be at. If you think the way they think and code the way they code, then you’ll automatically begin operating at their level. They’ll see how you do it in code review and they’ll think, “Wow, she coded it the same way I would have. She’s pretty smart”. These people are also usually the ones your manager will solicit to determine if you’re ready. 

This brings me to my promotion rule: The more frequently you signal you are ready, the faster you’ll get promoted.

The Resting Rate

I haven’t talked about when to take a break. If you continue to smash expectations day after day, week after week, you’ll undoubtedly burn out (I speak from experience). When’s the ideal time to take a breather? There are actually a few places to strategically do so.

The first is after your team ships a major project. Everyone is happy: the project is complete, the deadline has been met. On most teams, the workload lightens substantially. Don’t do what I did and take on more work to keep padding your resume. There will be plenty of that down the line, so take a breather.

The second is after advancing through a phase in the cycle. But doesn’t this look bad if you get promoted and your work output drops? No, because never in my career have I seen someone demoted or put on a plan right after they were promoted. Your manager and skip level have gone through weeks/months of work to promote you, HR is involved with your compensation increase, so demotion or similar would look terrible on all parties involved. 

Now, I’m not saying to slack off and do nothing. But take a breather. If it doesn’t get done today, that’s okay. Your career will last for decades. This is something I did not really understand. 

I thought that in order to advance, I had to signal I was at the next step every single day. I suspect this is something that plagues a lot of other high performers in tech, causing burn out.

It’s true that the more you signal you’re at the next level, the faster you’ll get noticed and promoted. But there’s also a ceiling to the amount of signal you give off. There’s a point at which all the additional signal you produce will be ignored.

This is due to factors outside of your control, such as bureaucracy or company/HR policy. So you should really push as close as you can to this ceiling, and then no further. Additional effort at this point will be wasted. If you want to make it to staff/principal level, this is really important. You don’t want to be burned down to the ground by the time you make it. 

Why It Works

Several key quotes from Jake’s essay have stood the test of time in my career and life in general:

“…professors (and others with knowledge and competence) are most inclined to help people who won’t waste their time.”

“If a student really wants to learn, the professor will usually help, but most students don’t—so the professor builds a wall between herself and her students to make sure that the only students who breach the wall are the ones who do care about learning.”

“Secondarily, your professor will often recommend reading to test your seriousness…If you go away and don’t come back, you’ve demonstrated that you would’ve wasted her time had she spent an extra hour talking to you outside of class and office hours.”

This is why I recommend you immediately fix a small bug or improve code coverage. You’re going to be asked to do this anyway. Everyone is busy, and no one has time to sit you down (unless you are a recent grad) and walk you through the codebase. If you do this proactively, you’ll have taken one more item off their plate and shown, in a small way, that you’re worth their time.

The wall to getting a top performer to mentor you might even be more difficult to breach than a professor. Every minute of time spent talking to you is a minute she could be spending on advancing her career for a big raise or promotion.

You’ll often be shooed away with a simple bug fix. And if you come back asking trivial questions that can be answered by the README or a cursory glance at the code, their guard immediately goes up. How are you worth their time if you demonstrate you’re not capable of the basics?

But if you come back with a pull request, and a follow-up question about the architectural design of the system, now you’re showing you’re worth their time. You’ve produced the result and you’ve dug deep enough into the code to ask a harder question.

You have shown you are worth their time, maybe they could learn something from you. 

“People who really want to do something… do it. Or they make changes so they can… But most people say they want to do something and then they don’t. Over time, others notice this (like me), and they start to assume that most people who say they want to do or know something are full of shit.”

This is why you must signal you are at the next level for a promotion, and why you must signal often. 

Do you know how many times a year your manager gets asked for a promotion? It happens all at once, during the annual performance review, and it won’t get brought up again until the next year. Most people will get rejected and complain to their spouse, “Ah my damn manager doesn’t want to give me that promotion”.

But if you make it a recurring theme in your 1:1s, and you ask, “How am I progressing towards the next level?”, then the question sounds very different. Don’t just ask your manager to be put on a project. Find a problem that needs to be solved, come up with a plan of attack, and then build a proof of concept.

People react in one of two ways when expectation does not match reality. When reality is worse, they’re angry and disappointed. When it’s better, they are happy and excited. And that’s why expectation management works, because you’re demonstrating that reality is better. 

Completing The Cycle

I don’t want to drag this out and turn it into career management advice, so I’ll end on a few notes on advancing as efficiently as possible. 

First, you have to advance through the cycle no matter what. You can’t remain a novice forever or you’ll get fired. At best you’ll never reach your potential. If you’ve been in the industry for 10 years but produce the results of a novice, you’ll be viewed with suspicion because you’re breaking the expectation in the wrong direction.

Second, you don’t have to push as hard as I did if you don’t want to. The key is to work backwards and figure out your goals, then match your signaling frequency to that goal. 

There will be so many more projects down the line. Don’t tunnel vision on padding your resume and working 24/7. It’s okay to rest, and relax, because this is the natural cycle of things. 

Third, you have to know when, where, and how much to signal. 

When you are fighting to make it to expert status, you will need to signal more often. You have the energy and vitality to do so when you’re young. When you reach expert status, the game is more about conserving energy. You can decide whether or not you want to reach true guru status, or stay at your current level. Both are acceptable.

Thanks for reading. I hope this helps you, both in your career, and in your life, the way Jake’s essay helped me.