The idea is simple, have a primary respondent, and a secondary respondent. Primary First point of contact We expect immediate response We expect full ownership of incidents to be taken Secondary Backup, in case primary contact is unable to respond If the primary doesn’t acknowledge an issue within specified timeframe, secondary kicks in If the load on primary is too much, they step in Misc Make sure to clearly define escalation policies …

Another excerpt from a chat with Ibra & Victor.

This has come up in enough conversations that I thought I should write it down. A few weeks ago, my bro said to me If you can’t make an economic case for an engineering decision/initiative, you might wanna leave it alone. And while I agree, consideration should also be given to the opposing perspective. Don’t neglect the human side Software development is a human process. We are humans with human needs.…

Excerpts from the devops book, Accelerate

More heuristics to help you figure out if your problem is complicated, or complex.

Excerpt from a chat with Ibra & Vic

I’ve routinely seen team morale at its highest when everyone is focused on the same goal. One task, one feature For an extended period of time Extended period of time allows people to learn each others’ rhythms. That’s not something you can speed run unless you have very self aware, or very experienced people who can also communicate well The shared context makes for reduced overheads of coordination & communication cross teams This also goes hand in hand with autonomy.…

It's one thing to write code that does the thing. It's another to write code that tells the reader what it's doing

A few things I’ve learnt about handling incidents.

Some heuristics on how to pick the highest value thing to work on when embedded in a product team.

Book Notes

discusses the concepts of flow efficiency and resource efficiency and emphasizes the importance of optimizing flow to achieve real efficiency.

The title here is misleading, because I’m here to make a case for not assigning your team to full capacity.

We’ll look at this from two perspectives, the pull request author, and the reviewer

Shared room, different tasks

Some long form content

An asynchronous pair programming method

Communicating our understanding of the problem and Forecasting completion of the solution

If a task is big enough, multiple small & focused PR's are a solid way to approach it

Some musings & observations on refactoring

Putting together all related resources around this topic.

Feels weird to tag this one under productivity, lol.

Steps I take to preserve and make time for flow state

An alternative or add on to time management

Some things to think about when considering feature flags

Heuristics, mental models, practical, immersion

Optimising Mean Time To Recovery is more important than trying to minimise Mean Time Between Failures.

highlights, quotes, & other interesting bits from Engineering Management For The Rest of Us

I often open Pull Requests immediately when I start on a task.

How WIP limits can help your team ship software faster, & more effectively

How can this theory can be a helpful heuristic for effective team design

highlights, quotes, & other interesting bits from Team Topologies

Thoughtworks' James Lewis shares his experience & research on Team Topologies, software architecture, & complexity science

A case study of ING bank and their experiments with team topologies

Notes from an insightful talk by Dan North

highlights, quotes, & other interesting bits from Accelerate

My values, and how that translates to my preferred ways of working & communicating

Various lessons and clippings from Martin Fowler.

Summary of the ingredients that make up a pitch…

Summary of Part 1 of the book…

Ryan Singer shares how the Basecamp team builds software…