Interruptions, skip levels, and good handbooks 💡
Monday Ideas — Edition #156
1) 🤖 AI dev tools are solving the wrong problem
This idea is brought to you by today’s sponsor, Unblocked!
Every year Stack Overflow releases their developer survey, and year after year the results remain the same: most developers feel that they are not as productive as they wish they could be. In the 2024 survey:
📚 Knowledge gaps — 53% of devs get blocked every day by knowledge gaps
🔍 Search for info — 63% spend more than 30 mins a day looking for info
💬 Help others — 49% lose more than 30 mins a day answering questions
This shows that the biggest challenge in software development isn’t writing code. It’s finding the context to know what code to write.
What you need is a way to find answers without having to search across a dozen tools or interrupt teammates.
2) ⚖️ Continuous work vs interruptions
I have a thing for obscure laws about human behavior. Two of my favorites are the Carlson’s and Illich’s Laws.
Carlson’s law — or the law of homogeneous sequences — states that:
Interrupted work will always be less effective and will take more time than if completed in a continuous manner.
Sune Carlson (1909 - 1999) was a Swedish economist and a pioneer of what today we call deep work. He preached about doing one thing at a time and minimizing interruptions. And he didn’t have the Internet!
Carlson’s Law may seem at odds with Illich’s Law — a.k.a. the law of diminishing returns:
Optimal productivity is reached with an appropriate balance between working time and resting time, as productivity decreases after a certain period of continuous work.
Illich also created the concept of negative productivity. After a certain amount of time, productivity decreases so much that mistakes due to fatigue have a higher impact than the actual things you get done.
These laws aren’t really at odds, because Carlson was against involuntary interruptions that make you switch context, but, like Illich, was all in favor of short breaks that allow you to recharge and regain focus.
I wrote more about I manage my time and energy, especially since I am a solo writer, in a previous article 👇
3) ⤴️ On skip level 1:1s
If you are introducing skip levels for the first time, be prepared for people to be confused about them. Both your reports (managers), and reports of your reports.
In both cases, you want to tell them exactly why you are having those.
Especially to managers, you should clarify that you are not going to step on their toes and take away ownership from them. Skip levels are 90% about feedback, while most of the action stays on the manager’s side.
So, as the one holding skip level 1:1s, how should you act on items that come up in conversation?
It may seem weird, but 80% of the time the best answer to anything you hear is "have you talked about this to your manager?"
What follows is most often useful, and you want to learn more about it before you take any action. A “yes” may imply the manager didn’t act on this (why?), while a “no” may hint at some communication/interpersonal problem.
The trickiest part of skip levels is being helpful—so that meetings feel valuable and the report keeps coming with good ideas/feedback—while not stepping onto the managers’ toes.
It is kind of an art, even more than with regular 1:1s.
We published a full article on how to run good skip levels 👇
4) 📖 How to maintain engineering handbooks
A well-structured handbook is great, but the real challenge for most teams lies in maintaining it. We discussed how to make it work in a recent mastermind session:
1) Kicking off 🚀
If you don’t have a lot in place, or what you have is old / unreliable / not much used, you should probably restart from scratch.
Starting fresh creates positive momentum and allows everyone to contribute without biases/attachments to what exists. If you are doing that, consider a three-step process:
Document what you have — start by writing down your current practices. Don't aim for perfection, just capture what you're actually doing.
Identify gaps — as you document, you'll naturally spot areas where guidance is missing or unclear. Just make note of these and move on. Don’t aim to fix everything on the spot.
Prioritize and fill — schedule the work to fill the gaps, starting with the most critical ones. Get to a first version that is acceptable, and move on to the next phase 👇
2) The Gardener 🌱
Maintaining docs is often compared to gardening: good gardeners do a few small things everyday, instead of big batches of isolated work:
Assign a gardener — have a direct responsible individual for your handbook. While contribution should come from everyone, it’s important to have someone who has the meta-job of keeping the whole work relevant.
Encourage contribution — the gardener should prod team members to contribute to the handbook, and make it easy for them to do so. Is the structure clear? Are there good templates in place?
Establish the boy scout rule — just like they should do with code, people should always leave the handbook in a better state than they found it. When anyone finds a small gap, fill it on the spot.
Prune outdated content — a lot of content simply becomes irrelevant over time, and it’s important to prune it to keep the space decluttered. This can be done by anyone, but in my experience it is mostly up to the gardener.
3) Integrate into existing workflows 🔗
Finally, for the handbook to stay relevant, maintaining it should feel natural, not like an extra chore. To do that, integrate it into existing processes:
Onboarding — make new hires update relevant handbook sections as a part of the onboarding process.
Retrospectives / Postmortems — after significant projects, incidents, or simply in periodic retrospectives, update the handbook with lessons learned.
Tech decisions — whenever you make important technical decisions, ask yourself if you should reflect these in your handbook. Structured formats like ADRs (Architecture Decision Records) can be linked or integrated directly.
So my TL;DR is: 1) start with a solid (if small) first version, 2) assign an owner, 3) distribute the responsibilities, and 4) link to processes.
We published a full article about creating and maintaining handbooks, which you can find below 👇
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. 1700+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.
2) 📣 Advertise with us — we are always looking for great products that we can recommend to our readers. If you are interested in reaching an audience of tech executives, decision-makers, and engineers, you may want to advertise with us 👇
If you have any comments or feedback, just respond to this email!
I wish you a great week! ☀️
Luca
Thanks Luca!