Programmer's log. Epoch time 1647096323. We're visiting Boston to see the in-laws and it snowed! This is our rescheduled trip since we had to cancel Christmas travel due to the pandemic, so it was fun to have a belated white Christmas...
Hi all,
This is a weekly digest for my blog, Simulated Annealing. Reach out with thoughts on Twitter @vivqu or by replying to this email.
Recent posts:
Working without an engineering ladder
Advice for engineers and managers at early-stage startups
Early-stage startups don’t usually have an engineering ladder. When you only have a handful of engineers and no HR team at all, implementing a formalized evaluation and promotion process for engineers generates unnecessary bureaucracy. On these very small teams, engineering leaders can typically just get in a room together to align expectations for the team.
But once an engineering team reaches a certain size, an explicit engineering ladder becomes necessary overhead for a smooth functioning team. The engineering organization can no longer reach a consensus on performance by all getting in a room together and having a conversation. Advice differs on exactly what team size forces the creation of an engineering ladder, but informal expectations likely start to break down around 20-40 engineers.
There seems to be a general perception of engineering ladders as a necessary evil, a less-than-ideal “management artifact” that is required because coordinating large teams of humans is a messy endeavor. I know quite a few senior engineers who find the formalization of engineering ladders quite tedious and the hoops to jump through promotion very irritating.
And these explicit performance frameworks do not entirely eliminate subjectivity and bias, and often end up incentivizing the wrong behavior. By definition, engineering levels are attempting to translate a subjective set of requirements into a consistent evaluation standard, so they will inevitably miss important nuance and context. The lack of 100% objectivity is frustrating to technical folks, myself included, because we want such frameworks to neatly capture every possible edge case.
So an early-stage startup can be ideal for experienced engineers. The informal environment allows high-performers to be recognized and rewarded without a convoluted HR process. At the same time, it’s easy for these experienced folks to forget how much latent knowledge we have accrued about engineering career progression and industry expectations.
Junior engineers do not have a mental framework for how to grow as an engineer. Though engineering ladders are imperfect, they help provide reassurance to engineers that they are gaining skills and progressing in their careers. When there is no formal engineering ladder and managers don’t communicate well, it isn’t clear to engineers that they are doing work that will help them grow into senior engineers or accumulate experience that will be transferrable to other companies.
One thing we can do as engineering leaders in early-stage companies is to decouple skill progression from a bureaucratic promotion/leveling process. It’s important to give early-career engineers the knowledge to contextualize their career growth. Managers can outline expectations clearly and provide a growth plan, even if engineering levels don’t exist at the company. And educating these junior engineers on industry standards can also help highlight the unique advantage of being at a startup: namely, that they can level up their skills and title much faster than at a large company with formalized level requirements.
...
(Click here to read the rest)
That's it for now! Hit me up with your thoughts @vivqu.