One of your jobs as a technical leader is to “shift the curve” of impact v. effort.

In general, a tech team has some primary “output” of business value that it is the team’s job to deliver.

In a company like Envoy, most teams need to deliver product features that power the workplace.

On every team, there is some implicit tradeoff between

• Impact — “the business value they can produce” and
• Effort — “the time and energy to deliver and maintain that value over time”

As you become more senior, your job shifts from making good tradeoffs to changing what the possible tradeoffs are.

I’ll explain more…

Senior Engineers should be able to present execution options that tradeoff between impact and effort.

At a high level, there shouldn’t be major, obvious “easy outs” when a product execution plan is made. For example: “we could obviously do more with the same or less time.” Note that in economics, these choices without clearly better alternatives are called pareto-efficient choices.

Often, senior engineers should also pick between the options if the choice is fairly obvious. For example: “it will take an extra 4 hours of time, but we would probably double the discoverability of this product.”

On product teams, this often requires Senior Product engineers to have some product sense along with technical capability.

There’s no obvious “better” option in the top left of this chart

But, many times, these decisions involve multiple stakeholders. So, should we ship our MVP with the extra feature even if it takes us an extra 2 weeks?

• Question: Is this a real tradeoff? ← Job of any project lead / senior engineer is to provide these options such that there are no obiously better options.
• Question: Is this worth it? ← Good EMs / PMs / (sometimes executives!) will make good decisions or at least principled ones when faced with these question. Of course, as a tech lead and a project lead YOU are also constantly making these types of decisions too.

As a Staff Engineer, your job is now to also shift the curve

While leaders are focused on this too, your job as an IC Eng leader is to constantly think about ways to shift the curve.

So you’re not just making elegant decisions on this curve (that’s your job too!) but you must shift the curve.

You can shift the curve by improving team processes, mentoring others, helping to hire, etc., But one of the key areas that you have the most influence in is evolving the technical architecture of the team.

Depending on the needs of the company the biggest need for staff engineers might change over time. Sometimes, it’s to help lead by example in pursuit of a cultural shift, sometimes it’s to coordinate across teams.

But in almost all cases, you will have a lot of influence on the technical evolution of the stack.

You can shift this curve for your team, for the org, for the company overall.

You should be working on the structures of the system, not just within it. And, part of the expectation is that you are consistently and constantly doing this quarter to quarter and half to half :).

How can I find ways to “shift the curve”, especially technically?

There are a lot of “hacks” to get there, but here are a few patterns I’ve found most common:

1. For an engineer that is less expert than you (or someone else on the team) the impact / effort tradeoff doesn’t make sense to invest in the underlying architectural improvement. But, if you have a clear vision and experience in that area (e.g. “I am a typescript expert and can set up our migration in like 3 hours”) then you can just do the work quickly and/or mentor the engineer to use the optimal tradeoff. I see this more commonly at startups than at big companies because I think all engineering leaders at small companies need to be closer to the details. Still, while engineers of all levels should be doing this (pitch in, mentor others, support P0 projects) there ought to be an expectation that you’re seeing opportunities to do this a lot, you’re just good at identifying and snatching these opportunities.
2. Many new projects can benefit from the same solution, but it’s not worth it to build that solution for any individual project. (e.g. “if we had a component library this project would be faster” or “but for not using typing in this language, we would not have had this bug.”). For any individual product or post-mortem follow-up, the impact / effort ratio doesn’t make sense to invest in the architectural upgrade. If you notice a pattern across many of these projects, you can centralize the work and make an “investment thesis” that even if it doesn’t make sense on this project to also do a migration, maybe you’d want to do it because across the board it’ll be helpful.

Note that the first “hack” is easier to convince people and get investment in than the second.

Some example “shifting the curve” type of work is:

• Introducing typescript to a javascript codebase.
• Creating a “async tier” for your system to centrally define, produce, and process all async jobs.
• Creating shared RPC abstractions for all services.
• Introducing continuous deployment to your company.
• Creating shared product abstractions like demandAck for common problems in many execution roadmaps.
• Structuring code / abstractions so engineers fall into the “pit of success”.

Warning

At the end of the day, the goal of the team is usually still to ship maximal business value.

Often, I see engineers shift too far in the other direction: they are just focused on “technical things” at the cost of producing business value and lose sight of the bigger picture. Don’t do that!

And…I’ll write a following blog post later about one suggestion on how to best drive architectural evolution, hope this is helpful!

EDIT: here’s the follow-up blog post.