Monday 3-2-1 – continue/stop/start, developer experience, bottlenecks 💡
Hey, Luca here 👋 welcome to the Monday 3-2-1 ✨
Every Monday I will send you an email like this with 3 short ideas about engineering management, technical strategy, and good hiring.
You will also receive the regular long-form one on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!
p.s. you can learn more about the benefits of the paid plan here.
1) 🚥 Continue / Stop / Start
In a retrospective, after you have gathered some ideas, you should have a discussion to converge on what to commit to.
To do this, the best way I know of is by using the Continue / Stop / Start framework.
This technique organizes action items into three categories:
🔵 Continue — things that are working well and you want to continue doing. These should be addressed explicitly to 1) develop gratitude, and 2) make sure the team doesn’t regress on the good things.
🔴 Stop — things you want to stop doing. Sometimes, problems are easier to be solved by subtraction than by addition, but we tend to be biased towards the latter. The stop stage counters this bias. Also, removing things creates the space to add new good things in the start stage 👇
🟢 Start — things you want to start doing. It comes at the end because it is the hardest. Many times it is perfectly fine to just acknowledge what is working well and prune a few things that are not. A healthy way of adding things is to focus on one at a time, asking “what is the most impactful thing we can start doing that aligns with our expectations?”
More on running good retrospectives 👇
2) 🔪 Bad DX is death by a thousand cuts
Engineers really leave and join companies because of good or bad developer experience (DX). This shouldn’t be surprising to devs reading this — but I suspect it is for many managers.
For those who do not understand, bad tooling for an engineer is death by a thousand cuts. In isolation it’s all small things, but in aggregate, they make people flip the table.
Conversely, good tooling does wonders:
You ship faster — with efficient CI/CD pipelines, preview links, and automated testing.
You automate repetitive stuff — with scripts, internal tools and frameworks.
You encourage / enforce the right behavior — with linting, engineering analytics, notifications for PRs, and more.
Good tooling also gives you the confidence to do ambitious work. By instrumenting your systems and making them observable, you can better test your changes in production and reduce your mean time to restore. That includes investing in logs, metrics, distributed tracing, and more.
More on engineering productivity 👇
3) 🛑 Hire because of bottlenecks
I believe you should hire because of bottlenecks, rather than opportunities.
Just like with funding — you should only raise money when you know exactly how you would spend it — you should only hire people when you are clearly bottlenecked on something, rather than to chase new things.
So for example, let’s say your product relies on integrations with external APIs, and the more integrations you build the more customers your sales people are going to win. It is a proven process where higher development velocity brings more business, so you may go for it with confidence.
Now, let’s make a different example — your product relies on sales and word of mouth, and you think you should now invest on SEO because it looks promising: decent volume and low-competition.
This is not a bottleneck, this is a new opportunity that may or may not play out the way you think. My preferred way of chasing it would probably be:
Learn the basic skills yourself (your existing team).
Prototype the work and get some initial results.
Get to the point where the opportunity turns into a bottleneck — that is, you validate the value that would be brought by a specialist.
Hire a specialist to make a 10x better work.
You may also work with an agency / consultants in the initial stages to bring in expertise while keeping risk low.
Overall your final decision of hiring somebody should be a double no-brainer:
Position — no-brainer to hire for that position.
Candidate — no-brainer to hire that candidate for that position.
More on hiring 👇
And that’s it for today! If you liked the article, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
I wish you a great week! ☀️