The Stress in My Company Was Not Coming From the Work. It Was Coming From the Waiting.

Daniel Brinzan is the founder of Nika Finance, a non-custodial mobile application that brings spot trading, perpetuals, staking, yield, and prediction markets into a single interface. He has spent several years building consumer financial products, and writes about organisational design, autonomy, and the way a company's structure shapes what it feels like to work inside it.

There was a Thursday last year when one of my colleagues finished a piece of work on Tuesday morning and still hadn't been able to send it. Nothing was wrong with it. I was the person who had to look at it, and I was two days deep in a routing bug. By the time I got to it, I changed one word.

She had carried that thing around for two days. I'd carried nothing. That was roughly when I noticed the pattern I'd been missing for a year. Our heaviest weeks weren't our worst weeks. The weeks that left people flat were often the quiet ones, which made no sense to me at all under the model I was using.

I run a three-person team building Nika Finance. We ship five product lines and the volume doesn't move much month to month, so I had a reasonably stable thing to observe. Someone would come out of a brutal sprint fine. Then come out of a slow fortnight looking wrung out. I assumed for a long time that I was reading it wrong.

What I had wrong

I was treating strain as a volume problem. Work in, recovery out. Most founders run on that model because it's the only one you can see on a calendar, and when someone looks tired the obvious move is to take something off their plate.

It just didn't predict anything. Cutting someone's load didn't reliably help them. Piling it on didn't reliably hurt. The thing that actually tracked was something I wasn't measuring: how long somebody had been sitting on a decision they weren't allowed to make.

In a company of three, every approval step is a bottleneck by construction, because whoever is reviewing is also mid-way through building something. So work would finish and then sit. Not because anyone objected. Because the reviewer had their own problem open. The work was done and the person still wasn't free of it.

That gap is where the strain lived. It never showed up on any workload metric I had, and it stacked.

This turns out to be well documented

When I finally went and read properly, I found I was about forty years late. The sociologist Robert Karasek published a model in the late 1970s that has held up remarkably well. His argument was that psychological strain doesn't come from demand by itself. It comes from high demand sitting on top of low control over how the work gets done. Demanding jobs stay sustainable when the person has real decision latitude. Take the latitude away and the same job starts doing damage.

Deci and Ryan's work on self-determination arrives at something similar from another angle, treating autonomy as a basic psychological need rather than a nice-to-have. If that framing is right, then being unable to act on your own judgment isn't a mild annoyance. It registers as an actual cost.

Gallup's burnout research is worth sitting alongside those two, mostly because it keeps putting unclear communication and weak role clarity up near unmanageable workload rather than somewhere far below it.

None of this was new to the people who study it. It was new to me, because I'd spent a year managing the variable I could see.

What we changed

We deleted the approval layer. The specific rule that went was the one saying outbound work needed a second pair of eyes before it shipped. What replaced it is a short document with three questions in it, and everyone applies them to their own work before it leaves their screen. Does this read like plain language or like a press release? Is this describing the product that exists or a version that doesn't yet? Would this help someone who is never going to use our app?

Yes to all three, and it goes. Otherwise, you fix it yourself, then. No queue. The whole thing collapses into one sentence we actually say out loud: if you own it, you ship it, and if it breaks we fix it together.

Two things made that work, and I'd only have guessed one of them in advance. The questions had to be nearly binary. Plain language versus press release is a four-second call almost anyone can make. If we'd written something like "make sure it's on brand" we would have quietly rebuilt the approval layer inside everyone's head, which is worse than leaving it where you can see it. Vague standards don't remove the waiting. They just move it somewhere you can't audit.

The part I didn't expect was how much genuine tolerance for rework it needed from me specifically. Things now go out slightly wrong sometimes and get fixed in public. I had to stop treating that as a failure. It costs us far less than the coordination it replaced, but it took me a few uncomfortable months to believe that.

What actually changed

Operationally it was quick. Work that used to wait three days for clearance started going out same-day. The bit I hadn't planned for was the drop in background tension, and the fact that total workload didn't fall at all. We didn't get calmer by doing less. We got calmer by deleting the interval between finishing something and being allowed to put it down.

I want to be careful here, because this is exactly where founders overclaim. Restructuring a workflow is organisational design. It isn't treatment for anything. If someone is genuinely burnt out in the clinical sense, changing their approval process is not the answer and I'd hate for anyone to read this as suggesting otherwise. What I'm describing is a narrower thing: a common, fixable source of low-grade chronic strain that tends to get filed under ordinary overwork.

It also doesn't generalise as cleanly as I'd like. Three people who trust each other's judgment is close to the easiest case that exists. Where a mistake is expensive and can't be reversed, review is doing real work and should stay exactly where it is. Custody of user funds is that kind of decision for us and nobody ships alone on it, ever. So the question was never whether to have review. It was which specific reviews were protecting against something real, and which were just habits nobody had looked at since the day they were installed.

Two tests

Pick any approval step in your company. Ask what share of the time it changes the outcome. Not how often the reviewer opens the file. How often what ships is different because they did.

When that number is low you're not looking at quality control, you're looking at a delay with a job title. And the real cost isn't the reviewer's hours, which are usually trivial. It's borne by the person on the other end who finished days ago and can't put the thing down.

The second test takes about a minute. Ask people what they're waiting on. Not what they're working on. In my experience the answers come back immediately, which tells you they'd been carrying that information the whole time and nobody had asked.

I spent a year adjusting how much work people had, when the variable that mattered was how much control they had over the work already sitting in front of them. Karasek had published that before I was born.

You cannot build a world-class product with a slow organization. You must be relentless. The teams that win are the ones that stay closest to users and ship faster than everyone else. What I didn't understand until fairly recently is that the structure making an organisation slow is very often the same structure making the people inside it tired.

Related Stories