Ideas for the AwkEng to Try (If anyone would let him!)

Hi all!

Today's post shares some management ideas I'd like to try (if only anyone would let me). I don't have any pressing needs or problems which would drives impetus for change, but I'm curious if these ideas reflect better ways of working.

The Four Day Work Week

I'm not talking about a compressed work week, with 40 hours in 4 days, I'm talking about a true, 4 day work week. The upsides for workers are obvious (more free time!), but would productivity really go up? I'm not sure, or even how productivity for knowledge workers can be precisely measured.

I know that personally, my brain is never really "off", and that extra time is really spent processing ideas in the back of my head. I've often said that my most productive time (in terms of value creation), is when I go for a regular daily walk and do nothing except let my mind wonder. I'll also compose the outlines and entire paragraphs of my blog posts before sitting down to write while on my walks, so in a way, it's like I have "processing" modes and "execution" modes.

I'd be willing to believe that the extra day and free time would improve the quality of the mind wondering/pondering/processing modes, which would make the 4 days of "execution" mode more productive. I think this could work for me and I'd love to be in a place that's willing to try.

Pair Programming / Pair Engineering

Pair programming is the practice of two software engineers sitting together (physically or remotely) working on the same piece of code. I'm told it takes a little while to get used to, with "driver" and "passenger" roles. I've also heard that it's excellent for junior engineers to get mentorship from senior engineers. Other benefits include improved knowledge of the code base.

What's wild to me, is that placing 2 engineers on the same piece of code doesn't cut productivity in half, and in some places, actually increases productivity. This is because reviews go faster, code is higher quality, and less likely to have bugs.

I also think there's a psychological effect going on, that working in a pair like this makes it easier to focus and stay on task. This is jan effect exploited by "work with me" youtube channels, livestreams, and organizations like Caveday.

I've also heard that the focus and social interaction of pair programming can be exhausting, senior engineers don't benefit from being paired with other senior engineers, and of course, it can be affected by interpersonal dynamics, and the idea can be an uphill sell and take some getting used to.

I've also heard you can get a lot of the benefits (mentorship, shared knowledge) from pairing for only a couple hours per week, and I'd be really curious to see it tried outside of software development, for example, with mechanical CAD modeling, or electrical schematic capture.

Abolishing email

I've ranted about email (a to-do list made by other people) before and the importance of deep work. In short, the idea is that while email is easy to send, it places a burden on the receiver. It creates a sort of locally optimal, globally suboptimal behavior. You may think that dashing off an email, or quickly pinging someone for an answer on chat improves productivity if you're stuck waiting for an answer, but globally, it means everyone gets interrupted all the time.

Now personally, I don't mind the chit chat of Slack, and I've done some reflecting on why.

This is where I've landed

• my work chat messages are organized by sender or topic channel, so the context is much easier to catch up on. Email subjects are nearly random, with no structure. (And outlook's UI makes organization by sender effectively useless to me).
• people tend not to send long, multi-paragraph chat messages, whereas that's not the case with work email.

So in my view, there should either be short chat messages, or longer documents that exist outside email, where collaborative written editing/commenting/discussion is possible. So I'd like to try working at a place that in practice no longer uses email for any internal communications.

Abolishing Chat, Too? Ideas in semi-synchronous days

But what if we really did want to abolish chat? It means that people couldn't get answers right away, which is locally sub-optimal, but it would encourage lots of deep work.

In my experience, most things can wait half a day, or a day, and you can find something else to do while waiting for an answer.

To avoid email or chat, I'd have scheduled synchronous working time. This is slightly different than a daily standup, or a meeting. In some of the earlier hyper-growth days of Youtube, and then at Coda, they have a practice to do this called "Bullpen". The idea is that for about an hour, you have to be available and sitting on a video call (or in person). So if someone needs you, or a serendipitous conversation or group starts to form in a breakout session, they can get you right away if needed. If you're not needed, you still need to be there, but you're allowed to work on your own stuff.

This preserves deep work time, eliminates the need for chat (if you can wait a day for an answer), encourages some spontaneity and serendipity, and precludes the need to coordinate meeting schedules, because Bullpen time is universal across everyone's schedule. Again, I have no first hand experience with this, but I'd sure like to try.

Shape Up

Shape Up is an alternative to more typical Scrum/Kanban processes. The idea is that people are better at budgeting and shaping/scoping what can fit in a 6 week time chunk, than estimating how long a given, well defined piece of work will take. Ideas are shaped at a "fat sharpie" level of resolution, which means you can't get too into the details. Then, a small team of 2-3 designer/engineers are given free reign to execute on the idea in the 6 week window.

Supposedly, there's a lot less time spent defining the work, the individual contributors experience a lot less micromanagement and are given more creative freedom, and it's less stressful, overall. Definitely sounds worth trying, to me.

Anyone have experience with the above?

Anyway, these ideas are in the realm of "hmmm... that sounds interesting" for me right now. If you've had experience with them, I'd love to hear about it!

best regards
Sam Feller