Blog

“That some of us should venture to embark on a synthesis of facts and theories, albeit with second-hand and incomplete knowledge of some of them – and at the risk of making fools of ourselves” (Erwin Schrödinger)

Feedback Loops

I've been reflecting on feedback loops since reading The Information. Coming to work on a Monday morning, with fresh eyes, I jotted down a few factors affecting feedback loops in my day to day life.

Tickets

As an engineer, I expect the tickets in the queue to be appropriately prioritized, requirements explicit and clear, and reasonably scoped.

When tickets don't meet these criteria, there's friction - sometimes small, sometimes large. Perhaps this ticket is no longer relevant. Perhaps this ticket is a vague bug report without reproduction steps ("XYZ is broken"). Or perhaps the queue is full of multi month projects.

Over time, that friction becomes internalized. When I have time (waiting for code review, in between projects, etc.), I hesitate before looking into the queue. I prefer to work on developer initiatives, where I can control scope, understand requirements, and prioritize myself.

Time from code to release

Maintaining context for tickets is a significant challenge in software engineering. When I try to work on multiple tasks simultaneously, alongside overseeing others' tasks, performing code review, and planning future projects, I struggle to context switch multiple times a day and dozens of times a week.

A long turnaround time between writing and releasing code implies a lengthy period of juggling multiple contexts. I am reluctant to pick up additional tickets while several are in code review, QA or pending release.

Momentum and motivation fade quickly, and I've noticed lack of interest in monitoring and bug fixing from engineering as well as product when tickets are deployed weeks or months after ideation. The sentiment is "the excitement is gone, so let's move on."

Yet another aspect is decreased hustle. If code I write today will take days to be reviewed, then another week to be tested, and yet another week to release - then there's little difference between finishing my code today or tomorrow or even later in the week.

Shifting winds

Business priorities shift - in a healthy market, that's a sign the company is re-aligning itself towards success, responding to changing market conditions, reacting to or getting ahead of a competitor, and so on.

When business priorities constantly shift, it's a drag. How can I stay motivated on my current project, that's absorbed the attention of management, if I know from experience that in a month we'll have de-prioritized this "critical" project? It says to me that the work is disconnected from business outcomes, and that business outcomes are disconnected from the market.

Ideally, product work makes tangible impact, and failure to produce has consequences. When work is disconnected from outcomes, when success is disconnected from investment, then lethargy is a natural consequence. This applies not only to actual outcomes but perceived outcomes and company culture: if wins are objectively successful but not celebrated, if failures are not analyzed, then passion is incentivized against.

Wrap up

Feedback loops permeate my life, from work to home to spirit. Getting a grasp on them, becoming aware and then taking action, has the potential to yield large rewards for small changes.