#11 Scaling Myself & Beyond
Hi.
The last 2 weeks were weird. The first week felt stressful and unproductive. The second felt calm(er) and quite productive. Polar opposites. This week’s newsletter is a reflection on how and why that happened. First I’ll share the tactics I used to be less stressed and more productive. Next I’ll tell you about a way of scaling my insights beyond myself.
Enjoy.
Scaling Myself
Working at a big company sucks. Sometimes.
When you get daily emails about some crap that may or may not affect you, sent to an all-staff or all-country or all-department or all-tech or all-project mailing list. We’re re-living the horrors of email spam of the early oughts.
Another case of suckiness is the attitude towards coworker’s time. Why it’s generally acceptable for anybody in the company to book your time? If you think about about it… that’s ridiculous, isn’t it? It’s one of those things you cannot unsee.
A third example is the conniving nature of communication tools. 2 years ago I turned off all notifications. But that’s not enough. Slack is designed for FOMO. Even without notifications, Slack presents you with a list of 10s-100s of unread messages. Most of which are not addressed to you, really, they are… CC to you? Just FYI? Maybe. The whole experience is tailored around inbox-0 anxiety and instant gratification of the “you’re all caught up”. As if that means something.
I complain a lot, but complaining doesn’t accomplish much of anything. Instead let me be clear about why this is an actual problem to the organization. And then how I try to deal with it.
Deep Work
I build software to make Rakuten’s business successful. Building software is creative work, it is knowledge work. It is the type of work that requires concentration and deep thinking. Deep Work. For me, deep work happens in 1-3h burst of uninterrupted time. Working by myself, talking to nobody. On a good day I have 2 burst of deep work (on company time). On most days I get 1. On bad days 0. That’s my personal experience, but many coworkers have told me that their experience is similar. We need this valuable, meaningful, deep work to make our business successful.
Meetings, set by other people, destroy potential deep work by reducing your free time and, more importantly, uninterrupted free time. Email Spam & Slack FOMO have the same effect: eat up your time & interrupt you.
If I get 100s or 1000s of emails a day (no joke) I have to triage them and delete most.
Oh my god, has my job really come to this? Is my job deleting email?
— Scott Hanselman, Scaling yourself ~ 27:20
Obviously triaging and deleting email takes time. In some cases a lot of time, up to 2 hours a day. That’s a quarter of the work day. Would you pay someone to delete email 25% of their time? I wouldn’t. It gets worse, that triage-and-delete is sprinkled all over the day, it interrupts contiguous free time, the time you could use for deep work. If it wasn’t for all that damn email.
The worst offender is instant messaging. Slack and all of its buddies. IM is like email on crack - a stream of in-your-face, noisy, rambling, half-baked fragments of thoughts. Plus it comes with fomo-by-design, it gets you addicted. I’m not exaggerating. 2 weeks ago I was completely disrupted by all of the above, I barely got anything done. Sure I sent messages, email and attended meetings. But the truth is, that week was very, VERY inefficient.
OK, quick summary:
Deep work - good.
Big company practices - bad for deep work - therefore bad.
Once a year I revisit tactics to create more space for deep work, here’s this year’s arsenal.
The 1-2-3
At the start of the day I write down 3 high-impact goals for the day. Almost all of the goals require deep work. Once I get free time I work on the first thing - until it’s done or until the next meeting. On average I achieve 2 goals, because I only get 2 deep work stretches per day. Writing that list enables me to actually do deep work when I get a chance. It prevents me from contemplating all possible task, priorities, different approaches… let’s quickly check slack… and now teams… and now email… and now viber… back to slack… NONE OF THAT.
The Grand Gesture
In Deep Work they tell a story about how J.K. Rowling checked into a 1000 £ / night hotel to finish writing one of the Harry Potter novels. She needed peace and quite, but on top of that the grand gesture of splurging on this fancy hotel enabled her to get deep work done. So what’s my grand gesture? It’s not a fancy hotel unfortunately. It is going offline. Well I don’t go fully offline, I only turn off all communication tools. I give my team a waring, something like:
Last week instant messaging has destroyed my productivity. As a counter measure I will be offline for half of the day.
If you need me for something important send me an email.
If you need me for something urgent and important call me.
👋
Going offline for half a day has made a big difference in self-perceived productivity and satisfaction with my work at the end of every day.
Schedule Work Time
One way to prevent other people form chopping up my day with their meetings is to block my calendar. I schedule 3h blocks whenever my calendar gets too crowded.
Aggressive, Automated Mail Triage
Over the years I’ve setup an uncountable number of outlook rules to sort my email into 3 categories:
Spam: I won’t ever read it, I don’t want to even know it exists
FYI: Mails sent to relevant mailing lists, for example technical infrastructure changes, and mails with me CC. I skim those, but might miss something in there.
Inbox: Mails sent to me.
By aggressively filtering I keep my Inbox in the low double digits, some days even single digits.
So that’s what I do to scale myself and my time. Give ‘em a try and let me know what you think. Or tell me about your tactics - just reply to this email.
Scaling Beyond Myself
I run the software architecture group in my department. (I’ve written about designing that team and defining a working definition of software architecture for it in the past.) The team is virtual, i.e. everybody works in their own product teams and has a little bit of time allocated to work as architecture champion. We meet and talk about design, practices, process and good software. That’s fun, we have good discussions and everyone is learning. The impact on individuals in immediate, visible. However the impact on each champion’s product team is less so. It is hard to incept change in a product team, to convert the knowledge we share with the champions into positive impact for their product teams. I could join teams for a short period of time and execute the desired change myself. But that doesn’t scale. I want each team to improve on their own. I want to scale my impact beyond myself.
One successful attempt at doing so was a scorecard. Basic, I know.
We discussed continuous delivery by the book with the architecture champions. I commonly see continuous delivery reduced to infrastructure or tools. “Jenkins is CD”. “Concourse is CD”. “K8s is CD”. But that’s so far off. It’s like saying “the compiler is programming”.
Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.
— Bliki
It’s not about tools, it’s all about practices. To highlight the often ignored facets of continuous delivery I created a scorecard for every team to fill out. Here’s a copy of the scorecard.
When I introduced this scorecard I emphasized that we are not comparing teams. It’s a tool to visualize the difference between idealized state and reality. Then I asked every champion to define the low-effort-high-impact actions they could take to improve the continuous delivery in their product team.
Over time the teams filled their copy of the scorecard and came up with really good ideas. More importantly, I can sense a motivation in the architecture champions for improving their team’s continuous delivery practices. Seeing that motivation gives me confidence that the architecture champions will create a positive change - without me. I removed myself from the equation. Giving them a cheap way to self assess made them more motivated than any coercion could.
Don’t Tell, Don’t Show, Make Them See
I’m fascinated with this success. Originally I was discontent with the state of continuous delivery and grew more discontent the more I read the continuous delivery book. If I had pulled a Linus Torvalds and complained about “all the things that are WRONG!!1!” I’m pretty sure nothing would have changed. Instead of telling them I enabled them to see. That made all the difference. A couple of checkboxes on a wiki page.
Creating content is incredibly high-leverage (one of the reasons I hone my writing skills with this newsletter every week). But content is only impactful if others read & use it. Making the scorecard dead-simple and cheap to use one half of its success. The other half is incepting an insight or idea in others, which is a powerful motivator. I think.
What about you?
Do you have stories of successful attempts at scaling beyond yourself?
Do you disagree with my ideas?
Let me know! Reply to this email!
Hyperlinks
Code reviews are not (primarily) for finding bugs
Only about 15% of comments provided by reviewers indicate a possible bug in the code.
[..]
In contrast, at least 50% of all comments provided by reviewers give feedback related to the long-term code maintainability.
Starvation
That’s it. If you enjoyed this ☝️ subscribe or share it with a friend.