Engineering productivity, career frameworks, high-velocity product dev ๐ก
Monday Ideas โ Edition #101
๐บ QA Wolf โ get automated test coverage
Testing is an ever-controversial topic, and I write a lot about it in the newsletter.
I have known the founders and the team at QA Wolf for a long time, I am a fan of their product, and I am happy to promote it in the newsletter this week.
For 1/3rd the cost of a full-time hire, QA Wolf automates, maintains, and runs your team's E2E test suite in 100% parallel and provide unlimited runs.
You can look at multiple case studies where they saved customers $200k+/year in QA engineering and infrastructure costs.
Back to this weekโs ideas! ๐
1) ๐ Engineering Productivity == clarity + focus time
One month ago we published our report on the state of engineering productivity, where we explored factors that enable engineers and managers to be productive.
The report is backed by a long survey, where we asked all kinds of questions about productivity boosters, offenders, work setups, and more.
It turns out, the recipe for good productivity looks surprisingly simple, and it stays the same across roles and setups. Itโs two things:
๐ฏย Good clarity โ people know what is the most important thing they should do.
โณย Plenty of focus time โ people have the space and time to go after it.
These look like simple items, but you only achieve them when you have taken care of everything else: context switch, meetings, collaboration, etc.
The degree to which engineers and managers suffer from this is also different.
๐จย Engineers suffer more from lack of focus time โ they largely know what they should do, but would like less interruptions and more room to do it.
๐ฝย Managers suffer more from lack of clarity โ they feel more productive in the sense that they do many things, but they are unsure if these are the right ones. They pedal fast, but in an unclear direction.
So, while for most engineers the direction is clear, but they would like to pedal faster, managers feel like they pedal fast, but in a questionable direction.
You can find the full results of the survey in the free edition below ๐
2) ๐ช Single-track career frameworks
There is wide consensus today that companies should separate management and IC career tracks, because itโs different skills, different aspirations, etc.
Even though this is right in principle, there exist situations where a single track makes sense.
If you are a small team, say under 20 people, you may not need full-time managers and you may conflate the management + tech leadership duties on the same people.
So, in such a scenario, senior engineers can only be promoted into managers.
I know, outrageous!
But in small companies there might be no way for an IC to progress further, because you simply donโt have the kind of work for which you need Staff+ Engineers.
Will all the people want to turn into managers? No!
Are you providing equal growth opportunities to people who want to stay ICs? Also no!
And thatโs fine โ not all opportunities exist everywhere at a given time. Just be transparent about what exists in your company and what not.
I wrote more about designing career frameworks in this two part-series ๐
3) ๐ข High-velocity product development
I often speak with early-stage startup CTOs. To me, their #1 duty at that stage is to optimize their engineering process and culture to be high-velocity.
People often disagree on what high-velocity looks like in practice, so I also created a simple checklist:
[ ] You ship daily โ you deploy code to production everyday. It may be a small feature, or an incomplete one gated behind a feature flag, but you do it everyday.
[ ] Progress is observed weekly โ something meaningful is shipped every week, and e.g. you have demo time on Friday. Bi-weekly is ok-ish, but weekly is better.
[ ] You do one thing at a time โ people work best when the amount of work in progress is manageable.
[ ] Engineering prizes speed and value โ your team values cutting down scope, shipping things fast, and delivering value to the customer, as opposed to building tech for its own sake.
I wrote a full guide about what good continuous delivery looks like ๐
I also created a larger checklist with all-things-startups in this recent piece ๐
And thatโs it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ๐ Subscribe to the paid versionย โ if you arenโt already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about theย benefits of the paid plan here.
2)ย ๐ปย Read with your friendsย โ Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.
I wish you aย great week! โ๏ธ
Luca