Monday 3-2-1 – parallelizing devs, gospel, time to quit💡
Edition #12
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
🎒 Hiring & Onboarding
You will also be receiving 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:
Before we start, I am happy to spend a few words to promote Swarmia, a great tool I have been checking out recently, about getting the most out of your engineering metrics.
In engineering, there are legitimately useful metrics like DORA and SPACE. There are also toxic vanity metrics, like code churn and lines of code written. Which are you measuring?
Swarmia helps you track only what matters to engineering teams: cycle time, deployment frequency, batch size, and other metrics that have a proven correlation with business performance.
Refactoring subscribers get a special, 30-day extended trial 👇
Now, back to this week’s ideas!
1) 🎽 Do not parallelize developers
While it is obviously good to parallelize a project across multiple developers, it is most often bad to parallelize a developer across multiple projects.
More projects means more context switch, more work in progress, longer merge times, and more overhead for coordination. So, the impact of moving from working on a single project, to frequently switching between (e.g.) two, can have an enormous impact on productivity.
It’s hard to measure, but I wouldn’t be surprised if you lose 20-30% of a developer’s output.
So, when planning long-term:
Round up to wholes — as much as possible, instead of expecting people to do fractional pieces of work.
Create small releases — so people can switch between projects often anyway, but without leaving things in progress.
2) 🔨 What’s productive for good teams may be bad for bad teams
A recent tweet by Paul Graham about remote work caught my attention and made me think:
Prediction: There will be a bimodal distribution of remote work. At the top end it will allow organizations to employ the best people regardless of their location, and freed from the drag of commuting and distractions of the office, they'll be even more productive.
At the other extreme, remote "work" will become, like meetings, one of the main mechanisms by which unproductive organizations burn time without achieving anything.
It strikes me that this bimodal distribution stands true for many engineering practices as well. Think about automatic tests, writing documentation, and async communication instead of meetings.
These things are clearly good for teams who know how to handle them, but turn into a drag in teams that don’t know what they are doing.
People may waste time by testing the wrong things; by writing docs that no one reads and updates; or by exchanging slow, inconclusive slack DMs instead of sitting together to solve a problem.
These seem like extreme examples, but it may happen to any of us whenever we do something because it’s gospel, without truly understanding why.
We should always question what brings value to our team and what we can do without.
3) 🎒 Tracking when it’s time to quit
I found just recently this great blog post by Cate, where she enumerates the five main signs that it’s time to quit your job:
You are not learning — sometimes, five years of experience is just the same year… five times over.
You’re learning coping mechanisms rather than skills — are you investing more of your energy on politics and managing up, rather that actual work?
You feel morally conflicted about hiring — would you recommend your close friends to come to work with you?
Your job is affecting your confidence — do you feel more capable over time, or less?
Your job is affecting you physically — stress is physical, and it may show in many different ways: sleep disorders, eat disorders, feeling of energy depletion or exhaustion, increased cynicism, and more.
You should think critically about what you are getting from your job. Recognizing some of these signs doesn’t necessarily mean you should quit — but you should reflect on what’s behind them, and how to get back on track ❤️
More on dealing with stress and burnout 👇
And that’s it for today — I wish you a great week! 🚀 If you liked the article, consider doing any of these:
1) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. That gives you access to all the full articles, to the community and the curated library.
p.s. 30-days money-back guarantee, no questions asked!