Writing

Essays written by Rowland Savage between 2019 and 2020, published on HackerNoon, while Genchi was being built.

They're worth reading in order. The first two, from January 2019, name optimism bias, the planning fallacy and the cost of reporting bad news — before there was a product. Everything Genchi does now was argued for here first.

Setting goals? All you have to do is point…

Babe Ruth pointing at the bleachers in the 1932 World Series, and why only a third of software projects meet their original goals. The argument is that goal-setting fails on articulation rather than ambition: write it down, share it, attach a date, and phrase it so an impartial observer would score it the same way you would.

"'Make our product better' is an example of a really bad goal… 'Increase response time by 100ms' is a great goal."

Related: How do you write a project goal a team can rate confidence against?

Are your tools the problem?

Written after around 50 interviews with product owners and leaders about status reporting. It names the documented biases — optimism bias, the planning fallacy — then argues the bigger problem is the tax on relaying bad news, and that the constraint is cultural rather than technical.

"It is akin to the oil light flashing on the dashboard of your car — and the reaction is to ignore it, or remove the bulb."

Related: Why do status reports not reflect what's actually happening? · How do you get honest status in a political organisation?

The real cost of transparency

Why transparency appears in every company's stated values and so few organisations actually practise it. Three principles are required at once: a willingness to be vulnerable, management reserve in the face of bad news, and enough practice to tell "not good" in a business-as-usual sense from "not good" in a we-need-help sense.

"Knowledge of a problem often provokes some kind of over-reaction… That disruption perversely encourages teams to be reticent in sharing problems, meaning the equilibrium point is less transparency."

Related: What do I do when the trend goes down? · Does anonymous team feedback become a weapon for management?

Can we apply DevOps principles to project management?

DevOps replaced batched, infrequent releases with a continuous feedback loop. Project status is still batched and handled in a waterfall manner, usually after problems have escalated. The proposal: a simple, common, continuously updated signal — a goal, and the team's own likelihood of achieving it.

"Leveraging the wisdom of crowds makes even a simple signal from a diverse group surprisingly insightful."

Related: Can the wisdom of crowds be applied to project status? · Why is a trend more useful than a status?

Slaying the hydra of remote work woes, one head at a time

Written after speaking to leaders at 16 fully remote companies. Remote work isn't one problem but many, and closing a 5% gap means improving five things by 1% each. Introduces the niko-niko calendar as an "old school" model worth reviving, and the reason "fine" is the most dangerous answer in remote work.

"'Fine' is a dreaded answer because fine might mean fine, or it might mean everything else up to the point where something is on fire."

Related: What is a niko-niko calendar, and does it work for distributed teams? · How do you track project status across a distributed team?

How confidence became the new happiness

If you could measure one thing about a team, what would it be? Happiness is the obvious candidate and the wrong one — it measures the career-page version of work and ignores that much necessary work isn't enjoyable. Confidence in achieving the goal turns out to be the better proxy, and a leading indicator rather than a vanity metric.

"Tracking the team's confidence doesn't provide the answers, but it does provide a useful place to start asking questions."

Related: Why doesn't project delivery have a metric?

Wax on, wax off: how going remote could be the best thing that ever happened to your team

A contrarian reading of the shift to remote work: the ad-hoc conversation isn't the solution to collaboration, it's the crutch propping up a process that was never repeatable or scalable. Its absence exposes the weakness, and being explicit about how teams communicate improves things whether or not anyone goes back to an office.

"Ad-hoc conversations… are neither repeatable nor scalable. Obviously they work, but they should be recognised as more of a kludge than a process."

Related: How do you track project status across a distributed team? · Is there a less painful way to do project status reporting?

Business as usual in a world that is anything but

Written early in the pandemic, and the argument outlives the moment: existing tools conflate doing the work with showing how it's going. Jira is a workflow engine, not a status view; Slack is a communication tool, not an operational summary. Transparency only works when paired with trust, and trust is built through structure and consistency rather than good intentions.

"People tend to think they only need to give updates when there is a problem. That's like thinking you only need to buy car insurance the day you have a crash."

Related: How do you get honest status in a political organisation? · Why does bad news get softer as it travels up?

The tool these essays were arguing for

A two-second check-in from every team member, aggregated into a current read of every project.

START FREE TRIAL

Free for teams under 10. Less than $1/user/month after that. No credit card to start.