The Ramping-Inflection Trap

I recently had a conversation with an engineer who was very busy but wasn’t making progress on projects at the rate they had expected. Despite being fully ramped up and consistently performing well, they struggled to keep up.

The pattern was all too familiar. In the past, whenever I struggled with feeling overwhelmed (which still happens!), I would incorrectly concede that there wasn’t enough bandwidth to tackle my growing set of responsibilities. I would remain in an overstretched, unstable equilibrium until my responsibilities somehow reset. This usually involved switching teams internally or switching companies altogether, causing the overwhelming feeling to dissipate. Unfortunately, changing jobs whenever you struggle to stay afloat isn’t a sustainable solution.

After a few overwhelm-switch-reset cycles, I noticed a pattern. The feeling of overwhelm typically began after I had fully ramped up – at the point when my top priority shifted from ramping to execution. At that point, I had developed more skill and context than I needed to employ day-to-day. However, every new task presented an opportunity for learning or was impactful, so saying “no” was not an option. Developing expertise does not create more hours in a day.

Ramping

During the ramping phase, your goal is to learn as much as possible and become a contributing and high-performing member of the team. Ramping looks different for every company and role. It usually starts with a lot of learning and eventually moves on to intentional projects that help you get familiarized with the product, codebase, and system architecture. Everything is a learning opportunity during this phase. Staying focused is less of a challenge when you’re ramping up because you have less expertise and context than bandwidth, so there are fewer distractions.

Inflection

The inflection point is when your expertise reaches escape velocity and the “big picture” comes together. You can contribute fluidly to team discussions and execute independently. By this point, you have likely developed some domain expertise and ownership and are able to assist others. Suddenly, you feel empowered because you have a deep understanding of the system you are working with.

Execution

You’re fully ramped up and are tackling increasingly ambitious projects. You’re now building highly coveted institutional knowledge, others depend on you, and it feels great to be a team linchpin. You want to have multiplicative — as opposed to additive — impact so you can’t let others who depend on you down. You’re productive and very valuable to your company.

The Ramping-Inflection Trap

The inflection point is where things can go awry if you’re not careful. You may be capable of making an impact in many areas, but that doesn’t necessarily mean you have the bandwidth to do so. The team has learned to depend on you, and you’re tempted to deploy the expertise you’ve built at every opportunity, but you haven’t yet learned how to scale yourself. Telltale symptoms start becoming clear:

Feeling compelled to participate in every technical discussion and design review.
Staying tuned into way too many Slack threads.
Jumping to the aid of others without an emphasis on training and education.
High amount of context switching.
Fixing low impact, low effort bugs.
Becoming your team’s de facto fire fighter for bugs and outages.

Although you’re capable of juggling everything, it’s draining. If you’re optimizing for long-term impact at your company, being a hero and thrashing is not a sustainable way to get there. Longer term, your expertise keeps growing, but your bandwidth stays constant.

Maintaining focus and sanity after getting to this point requires selectively applying energy. There’s an endless amount of literature about working on what matters, focus, and prioritization so I’ll leave that out of scope. The important thing is to recognize when you reach the inflection point, stop, take stock of your time and energy, and adjust accordingly.

Good interviews vs. great interviews

I have interviewed hundreds of candidates and have been interviewed more times than I’d like to admit. From my experience, most interview loops under-emphasize building the candidate’s understanding of the team, role, and company they’re interviewing for during interviews and instead defer this to the later “selling” stages of the process. I think this is a missed opportunity.

The approach I use to gauge interview quality starts by evaluating them in two dimensions. The first dimension is the strength of signals the interview provides to evaluate key competencies for the role. The second is how effectively the interview provides signal to candidates about the role, team, and company.

Good interviews focus on a specific set of competencies and yield a strong signal for interviewers to inform a hire/no-hire decision. Many interviews fall into this category.
Great interviews also maximize signal for the candidate about the role, their future team, and the company. These are gold.
Sell interviews may not yield a lot of signal to interviewers, but deliver a lot of signal to the candidate. These are necessary, but should be saved for later stages of the loop.
Weak interviews provide low signal in both dimensions. Replace these as soon as possible.

Interview loops with good interviews produce confident hire/no-hire decisions. Interview loops with great interviews also leave candidates with a deeper understanding of the opportunity, areas of ownership, and ideally, the confidence to accept an offer without much selling if they reach that stage.

Minor tweaks can produce great interviews

During a coding interview with a team working on routing at Uber I was asked: given a set of places and routes between places, write a function that determines if a route exists between a specified start and destination. This is a straightforward graph traversal question, but framing the problem using places and routes, instead of nodes and edges, gave me a deeper appreciation for the team’s mission.

Interviews that explore yet-to-be-solved problems are also very powerful. For example, I love Notion and think it’s a great product, but the search functionality is quite slow for workspaces with a large corpus. Instead of being asked generic design questions, candidates interviewing at Notion could be asked to design a search index for Notion workspaces to build an understanding of product and technical challenges.

Identifying weak interviews

Weak interviews can do more harm than good because they leave candidates with a negative impression of your company. One basic smell test is to ask: are there any interviews in your process that leave candidates confused about why the questions asked are relevant to the role? Ask candidates for feedback after they complete the interview loop. Some candidates will shy away from providing negative feedback (they’re trying to get hired after all) so it’s effective to directly ask questions like “what was your least favorite interview?”

Another approach is to score each interview on signals that are important to candidates. Potential priorities like future team, company and culture, product, technical challenges, and role are important factors to consider for engineering interviews. This will help you identify weak interviews that need improvement.

Assign a 0 to 3 rating for each signal and focus on the lowest scoring interviews.

This framework has served me well for both technical and non-technical interviews. That being said, great interview topics aren’t effective without amazing interviewers. Perhaps that’s a topic for a future post, but for now I’ll leave you with this excellent post about the interview skills ladder.

If you tried any of the strategies above, I’d love to hear how they worked for you.

Ownership is a requirement

One of the cultural values at Tecton is “be an owner, not a renter.” We’ve iterated on these values as the company has grown, but this particular value has been set in stone since the day I joined.

Ownership means taking initiative and treating your sphere of influence as if it’s a business and you’re in charge. Being an owner is a mindset that transcends title, role, or equity.

I care about ownership more than anything else when building a team. Owners are better engineers, build better products, and push the team forward. Growing companies have more problems to solve than people to solve them and any “that’s not my responsibility” attitude is damaging.

There are easy ways to probe for ownership signals when interviewing candidates. The simple question “tell me about a time you went above and beyond in your current role?” usually yields telling responses. But don’t stop there. Dig deeper. Why? What prompted their actions? What was their individual contribution? What was the outcome? What would have happened if they didn’t take any action?

For junior hires, I look for signals of them doing something without being asked. For example, independently fixing a bug they unexpectedly found. For more experienced hires, the scope can be larger and take many shapes. Several years ago I worked on Google Photos. I later learned the entire product was nearly shelved in favor of focusing on Google+. Google Photos was saved by an independent effort by a product and design lead to design and pitch a prototype using an 80 inch TV turned on its side to simulate an iPhone — ownership at its finest.

Each member of a team, especially at a startup, plays a critical role in the company’s path to success. The cost of non-owners is too high and they should be avoided.