Sources of Power, remote bandwidth, and ROI of ceremonies 💡
Sources of Power, remote bandwidth, and ROI of ceremonies 💡
Monday Ideas — Edition #92
This week I am happy to promote Build: Elements of an Effective Software Organization — a new book from Swarmia’s Rebecca Murphey and Otto Hilska.
It’s a fantastic read for any current or aspiring engineering leader interested in improving the three key perspectives of engineering effectiveness: business outcomes, developer productivity, and developer experience.
I have read it personally and I am happy to recommend it 👌
You can read Build for free online, or order your copy on Amazon.
Back to this week’s ideas 👇
1) 🎽 The Five Sources of Power
Last year we read Good Strategy / Bad Strategy, by Richard Rumelt, in the community Book Club.
One of the ideas that stuck the most with me is what the author calls the five sources of power — from which you can draw elements for your strategy.
Here they are:
🏗️ Leverage — Rumelt often compares good strategy to a lever that focuses all your strength onto a single, pivotal point. Likewise, a good strategy focuses resources and actions onto a crucial goal that makes everything else fall into line. He argues that you should find your own pivot points — the opportunities where such energy has the most effect.
🎯 Proximate Objectives — Setting the ultimate goal is not effective unless you don’t also plot out the path to achieving it. Such a path is usually made of smaller sub-goals — the author calls them proximate objectives — that set you in the right direction.
🔗 Chain-link Systems — A good way to spot your weaknesses, especially in the diagnosis phase, is to think of your company as a chain. A chain is only as strong as its weakest link. Find such a link and define policies to remove the weakness.
🔭 Focus — this is one of the key lessons in the book. Focus means finding the one or two most critical issues in your organization, to the exclusion of other, less-critical ones that might distract from the former. If you don’t feel genuinely bad for having excluded some areas, chances are you are not focused enough.
🌊 Dynamics — in most markets there are shifts and turns that create opportunities you can leverage. This is especially true in tech. You can try to anticipate fundamental shifts in your landscape to exploit them before others do.
You can find our full summary + review of the book here:
2) 📏 Remote communication bandwidth
Last week I interviewed Farhan Thawar, VP of Engineering at Shopify, on the podcast.
Shopify is remote-first, which is unusual for a company of its scale, so we naturally talked a lot about this.
In fact, most big tech back-pedaled on remote work. You can’t 100% blame them: they were forced into the transition overnight, didn’t figure out how to adjust, and often ended up with extremely inefficient hybrid setups.
The result, though, is that in many circles, bad examples have created a backlash against remote work. This backlash is in turn baffling for productive remote companies, who have been doing their thing for years, and blame bad management / hustle culture for the push back.
I believe that, at its core, this conversation shouldn’t be about remote — it should be about how communication and collaboration happens.
Today, in 2024, we should all agree on three ideas:
🔨 Engineering work is creative work that requires deep, uninterrupted focus time to be performed at its best.
🔀 Sync communication (like meetings) is expensive and disruptive of such work, so it should be used sparingly and for stuff that truly deserves it.
🔌 Modern tools today allow to handle asynchronously a lot of stuff that used to require sync comms — think project mgmt tools, Looms, AI meeting notes, and more.
To do your best work, as a team, you need to optimize how people communicate, whether you are remote or not.
Now, the main tradeoff of remote work, to me, looks like: more flexibility, in exchange for a smaller communication bandwidth. And here is the thing: good teams can totally work on a small communication bandwidth. They retain a few, key meetings, and move most of the non-urgent, non-complex decision making to async comms.
This makes remote a natural choice because, at that point, the flexibility argument trumps the communication one. But you have to get there.
You can find below the full guide I wrote about creating a great engineering culture 👇
3) 📈 The ROI of ceremonies is not linear
We recently had been a big debate on the community about Scrum and good dev processes, which gave birth to not one, but two Refactoring pieces.
Much of this debate revolves around ceremonies. No one wants to waste their time on useless meetings, so you should always cut those whose value is lower than the opportunity cost of attendees' time.
This is tricky to judge, though, because in most ceremonies the cost component is constant, while value is not.
Example: I may find that daily standups are 80% of the time not worth the hassle. But roughly once a week you may have one where you discover a crucial roadblock, and that value possibly repays the cost of all the other standups.
Same goes with retros, 1:1s and other processes that look unnecessary until they don't.
As humans we are bad at assessing situations where the value distribution is uneven. We only get better with experience.
More about ceremonies and dev process in this recent edition:
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