Mandatory on-call, career autonomy, and network calls 💡
Monday Ideas — Edition #88
This edition is brought to you by Product for Engineers, a newsletter from PostHog dedicated to helping engineers improve their product skills.
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.
1) 🫡 Should on-call be mandatory?
Being on-call can be considered part of the duties of any engineer, so there is no wrong in making it mandatory.
Especially if you are introducing this from scratch, mandatory on-call for all engineers is healthy to build ownership and to make sure no critical areas of the code are left uncovered by docs and playbooks.
Eventually, however, consider making it voluntary.
People may be more or less okay with being on-call depending on things going on in their lives, like family duties. If the team is big enough and the process is battle-tested, then it's best to let people choose.
I wrote more about on-call strategies in this previous piece:
2) 🪴 Chase autonomy for your career
Maybe this is a bias from my time as a founder, but I strongly believe in chasing ample autonomy in any job you have. To me, high autonomy enables ownership, which in turn amplifies impact.
I have found that autonomy is enabled by two factors:
🎓 Adequate skills — e.g. as a developer, being proficient on the whole stack so that you can own features from top to bottom.
👑 Healthy work environment — a working process where people are given the opportunity to own meaningful tasks.
So, I am a believer in chasing full-stack experiences, especially early in your career. When I say full-stack, it’s not just about the tech — it’s about doing more:
Making meaningful decisions about the product
Talking with customers
Being on-call for your code
Collaborating with designers
Going wide early in your career has some strong benefits:
📈 Efficiency — for most skills, Pareto applies: you can go from 0 to 80 in just a few years, and then it takes 10+ years to get from 80 to 100. So it is a better deal to spend some initial time building a few 80s, before committing to 100%-ing one.
➡️ Direction — getting in touch with different things helps you figure out what you really enjoy and want to get better at. You develop a more balanced perspective and avoid bias 👇
🔑 No lock-in — when you specialize too early in something, you risk getting cornered into a local optimum that is difficult to escape. You have all your eggs in one basket, which also makes you less resilient to changes in the industry.
So, if to you this seems like an ode to generalists, it kind of is, especially in your early years.
To build your own T shape, it is more effective to go after the horizontal leg before the vertical one, which it also informs you on which vertical leg to build later.
This is a lesson I learned from my chat with Thiago Ghisi last year 👇
Thiago is also coming back soon as a podcast guest, so stay tuned!
3) 🗿 Microservices are hard because of network
We hear all the time that microservices are hard — but what makes them so? In my experience, a big role is played by… network.
In a monolith, you don’t have to necessarily think at how to factor things precisely, because all the code lives in a single place and can be used and referenced easily.
Microservices, instead, interact via network calls. Network interaction is expensive and hard to change — so you need to be sure about how you split functionality.
Grug said it best:
grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
Design complexity makes microservices less than ideal in situations where the problem scope is unclear or fast moving — like a startup. Monoliths, instead, pay a lesser price for the wrong abstraction, because they can be more easily reconfigured.
This is, of course, just a part of the story. For more ideas about monoliths vs microservices, I wrote a full article a while back 👇
🗳️ The State of Engineering Productivity
Finally, I have a quick ask! 🙏
Together with the guys at Hatica, I am conducting a survey about what makes engineering teams productive: practices, usage of metrics, tools, etc.
If you want to help me out on this, you can fill out the survey below 👇 it takes less than 5 mins.
Thank you, it means a lot!
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) 🔒 Subscribe to the full 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 someone who would like it, and get a free membership through the new referral program.
I wish you a great week! ☀️
Luca
Very solid post. Thank you for sharing it. We also write about DevOps, you can check out one of our articles here https://www.metridev.com/metrics/code-review-guidelines-best-strategies/
Great ideas in here, Luca!
I can verify that chasing autonomy is worth it. Almost a decade ago, I ditched Java to focus on a single language and have less overhead as a full-stack engineer. It was the best bet of my life, and it paid off.
About being on call - I never did it. But I’m applying to an organization that has mandatory on-call. However, my understanding is that if you’re confident in the pieces you deploy, you might sleep well. What is your take on this? Is mandatory on-call a bad thing? What does it tell about an organization?