I’ve written about promotions before, particularly in contrasting the differences between prescriptive and descriptive promotions and generally favoring the latter. In quick summary, the former rewards excellence with current responsibilities by showing confidence in a broader assignment, while the latter is a lagging acknowledgment of solid execution at the next level. It’s generally really hard to be descriptive when transitioning to new roles, and there’s an anti-pattern of being expected to perform at both levels simultaneously to receive a promotion, making them unnecessarily challenging.
Another framing of this is to think about executing at Level N+1 as enabling other Level N colleagues. From this blog post:
It is great that an engineer could fix a particular problem efficiently. Though, a common trait we see in more “mature” engineers is go beyond “just” patching these problems. They take the extra step to make sure the next person won’t have to spend the same level of energy fixing the same issue, or eliminate the problem class altogether for their team.
This is a great archetype of a mature, senior engineer! I’ve looked to define the Tech Lead role in this way, as a figurative force multiplier for others on their team and increasing their own impact via building systems and frameworks that fellow engineers can leverage. There are a couple of prerequisites: understanding the problem domain, appreciating existing workflows and constructs to build something better1, and perhaps most importantly, working through issues and garnering support to roll out the improvement more broadly.
A brief aside: I see most engineers, in following this pattern of showing increased impact, struggle to completely follow through. Of course, fixing a bug or streamlining the solution to a problem no one else can solve is straightforwardly beneficial. But building a new system, and getting teams to buy into your implementation so they make time to migrate their own projects—that’s a challenge even with the best of intentions, with success requiring ample empathy, support, and patience. It’s analogous to the step up from invention to innovation.
Anyway, senior engineers are capable and usually motivated to solve classes of problems with reusable frameworks. Most promotion systems recognize impact and force multiplication, and this type of work squarely fits the bill. Framework engineering, if you will.
But—I also want to give credit to another archetype of senior developer: the “gets shit done” engineer.
Granted, most of the time this amounts to hacking a bunch of stuff together, sometimes with no regard for quality or best practice. It doesn’t take much experience to code something that barely works, or to resolve surface-level issues by brute-forcing bug fixes. It isn’t clever, nor is it efficient, and it’ll likely have to be rewritten before long.
This kind of software development is less glamorous for most engineering organizations, but I still find it to be an important element of successful teams. Framework engineering is building for the long term, but getting product out in the short term matters just as much. It’s about quick feedback loops, taking calculated risks and shortcuts, and embodying skills across the totality of product development so the project isn’t bottlenecked on missing personnel. It’s about understanding the business to make informed tradeoffs between speed, quality, and reusability.
As you can imagine, mature engineers of this mold are proud generalists and are amazing assets for startups. Of the handful that I’ve been fortunate to work with over the years, I’ve always been amazed at their resourcefulness and willingness to prioritize the bigger company picture over what everyone understood was right from an engineering perspective. I’ve seen CEOs tap these engineers for help in critical situations, leading greenfield efforts that would eventually be inherited by entire teams2.
A thoroughly uncommon trait, but one that’s immensely powerful under the right conditions.
