This edition is brought to you by my friends at QA Wolf! Kiss bugs goodbye with 80% automated E2E test coverage in 4 months 👇
For 1/3rd the cost of a full-time hire, QA Wolf automates, maintains, and runs your team's test suite in 100% parallel and provide unlimited runs - all while guaranteeing zero flakes.
The benefit? Your developers can ship faster and more confidently 🚀
QA Wolf has multiple case studies of customers saving $200k+/year in QA engineering and infrastructure costs.
Now back to this week’s ideas! 👇
1) 🚪 If you are thinking of quitting, you probably should
Now that I work solo, I try to stay in touch intentionally with some friends and past co-workers by having monthly or bi-weekly 1:1s with them.
Last week I spoke with a friend who is not happy at work and is thinking of quitting, but he is not sure.
He asked for advice, which I don’t feel qualified to give because these situations are very personal — they depend on work just as much as they depend on the rest of your life.
There is something I can say, though: quitting is hard.
Everything is stressful: looking for a new job, interviewing, negotiating, joining a new team of strangers — this is all way out of our comfort zone.
So, if you find yourself pondering to go through all this, chances are you already know it’s the right thing to do.
Most often, gut feeling knows it best — if you are thinking of quitting, you probably should.
I wrote a full piece about potential reasons to move on, and signs you should pay attention to. It explores three angles: growth, money, and wellbeing. You can find it below:
2) 🏆 Cycle Time vs Velocity
I am wrapping up the report from the engineering productivity survey which I have been promoting on the newsletter for a while (if you participated, thank you so much 🙏).
I can anticipate that, when it comes to engineering metrics, there are two KPIs that are clear winners: Cycle Time and Velocity.
I believe, however, that they represent two different generations of metrics: Cycle Time is practical and useful in plenty of situations, while Velocity is kinda overrated.
Let’s see why.
Cycle Time
Cycle Time is a subset of the overall Lead Time.
Lead Time covers the whole cycle from ideation to release, including analysis and design phases, whose duration can vary a lot based on the breadth of the initiative.
However, once the initiative itself has been broken down in deliverables, the delivery process should move in short and predictable cycles, which are more useful to measure. These are measured by Cycle Time.
Cycle Time possesses all the hallmarks of great KPIs:
It is objective: it doesn't need context to be interpreted, you know exactly what it means.
It is easy to understand: it can be easily discussed and explained to management, as it works like the engineering equivalent of sales cycle and product funnel metrics.
It stays relevant as you scale: it doesn't depend on the size of the team.
It is actionable: it shouldn't fluctuate much. Significant increases usually point to specific problems that can be identified and resolved.
A healthy Cycle Time in real-world scenarios is anything within a few days. Further improvements are fine, but striving for less than one day brings diminishing returns.
So, breaking down work in small batches is important, but there is kind of an optimal batch size — under which you are only pedaling faster without delivering more value.
Velocity
Conversely, in my experience, velocity has limited utility. You can use it for rough sizing when planning work, but nothing more. For anything else, it is just misleading.
In fact:
It is not a measure of productivity — you can’t optimize velocity, at least not reliably. Since story points (or t-shirt sizes) are arbitrary, people will eventually just inflate the points. And it’s not because people are evil, it’s a natural, even unconscious, reaction to a bad way of defining productivity.
It is not useful across teams — velocity is only meaningful locally to the team, because of the arbitrary nature of estimates.
It is too high-level — if you get bad velocity in a sprint, you can’t drill down into it to figure out what went wrong, as you can do instead with e.g. cycle time.
You can find out more about engineering metrics in the full (free!) guide I wrote last year:
3) 🔍 Checklist for choosing tech
Choosing the right tech is a daunting task that depends on a large number of factors. At the end of last year I surveyed people in the community about their favorite criteria to make the right picks, and here they are, organized in a checklist:
✅ Success stories — the #1 thing I look at is whether I can find examples of other products using that tech. Bonus points if such products are related to mine, in terms of scale or industry.
✅ Good Github repo — for open source tech, the repo contains an awful lot of information you should consider. Look at the number of stars, frequency of commits, number of contributors, and open vs resolved issues. Is this a healthy project? Is this actively maintained?
✅ Governance — on top of the above, is the project roadmap public? are issues visible? Is the decision making itself visible?
✅ Skin in the game — who maintains this? Is this a company pet project? Or is it core to their business? Does the company have a track record of good support to projects like this?
✅ Good docs — are docs comprehensive and clear? Do they refer to the latest version? Do they include my use case?
✅ Community — is there good enough community support? If I have any issues, is there anyone to ask?
I wrote a full guide about choosing technology that covers a lot more, like creating a good decision process with your team, and how to make buy vs build decisions 👇
📬 Product for Engineers
One of the clearer trends in tech careers in recent years is having engineers get more ownership and make meaningful product decisions.
I wrote about Product Engineers in the past, and this is only growing stronger with time.
So today I am happy to promote Product for Engineers, a newsletter from PostHog dedicated to helping engineers improve their product skills.
You can subscribe for free to get curated advice on building great products, lessons (and mistakes) from PostHog, and deep dives into the strategies of top startups.
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ✉️ Subscribe to the newsletter — 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
Interesting idea about quitting. However, how do you differentiate a rough patch from actually wanting to quit? What if later on you regret your decision?
I would personally add fearing to regret the decision in the future to the list of things that make it hard to quit.
For me, feeling like quitting should persist for three to six months before acting on it. You can mark it on your calendar and try to revisit out of context, and see if you still feel the same.