Scribd
Upload
26 views2 pages

High-Quality Inputs

Uploaded by

bhaskar.jain20021814
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
26 views2 pages

High-Quality Inputs

Uploaded by

bhaskar.jain20021814
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 2

High-Quality Inputs

alifeengineered.substack.com/p/high-quality-inputs

Steve Huynh

I used to obsess over the Amazon stock price.

My compensation at Amazon was mostly based on the stock's performance. It would go


up and down. My mood swung with its seemingly random fluctuations, especially around
vesting time.

“How’s it going Steve?”


”Not good. AMZN is down 3.5% in anticipation of the earnings call this week.”

You know when you refresh a page and nothing changes, so you refresh it again?

A Life Engineered is a reader-supported publication. To receive new posts and support


my work, consider becoming a free or paid subscriber.

Output metrics show the results of your work, like page views or the AMZN stock price.
Input metrics track what you put in, such as coding time or customer interviews
conducted.

The fixation on output metrics isn't just an individual problem. Many tech teams obsess
over results. They track user growth, revenue, feature velocity, and other KPIs. But this
output focus can be a mistake. Why? Because you don't directly control outputs, just like
when I was refreshing the stock price.

A smarter approach is focusing on what you can control, scaling up high-quality inputs.

The problem with output metrics is they masquerade as things you can control. The trick
is to go deeper to find the high-quality inputs that will actually make a difference.

I once worked on a team with a huge operational load. Our ticket queue topped 100
tickets, so I aimed to close as many as possible as quickly as possible. I can control that,
right?

But the tickets kept resurfacing and the queue was still over 100 tickets. I soon realized
tickets were a symptom of poor quality software, and that I was treating the output metric
like an input.

The solution was changing the target. The new goal, which worked much better, was to
identify and fix root causes. While still an output metric, it clarified how I should spend my
time. I needed to examine application logs, diagnose issues at a deeper level, and really
understand the code. This eventually led to our ticket queue dramatically plummeting,
until the only tickets that were open were waiting for action external to my team.

1/2
When I found a bug, I didn't just fix it. I considered the conditions that led to its creation. I
thought about release processes that missed defects. About the time pressure on
developers to code at breakneck speeds to hit arbitrary deadlines.

Many inputs resulting in high ticket counts weren't technical. They stemmed from new or
junior developers unfamiliar with team practices. From high attrition. From massive code
check-ins. From lacking a culture of unit, integration, or 1-box testing. From testing in
prod. From not profiling our code or having adequate cross-system logging.

No developer intends to write bad code. It's an output of a company's engineering


culture. As I became more senior at Amazon and my scope grew, the new goal was to
impact the culture. Fixing individual root causes wasn’t enough.

I sought out teams with poor operational focus within my org and helped them bootstrap
operational mechanisms for them so they could regularly address their own root causes. I
scanned for large check-ins and people consistently approving bug-prone code without
comments. They knew what the right thing to do was, they just needed a reminder from
their friendly principal engineer what the consequences of skipping steps was. I aimed to
get as many teams and code pipelines as possible to adopt continuous deployment (CD),
automatically pushing code to production after check-in and automated tests. It was their
job to figure out how, it was my job to nudge them in that direction and provide resources.
I help dozens of teams and thousands of developers transform their pipelines to CD
before I left the company.

Paul Graham said “In the short run, the (stock) market is a voting machine but in the long
run, it is a weighing machine.” At Amazon, with over a million employees, I had no direct
way to affect the stock price. There were simply too many inputs for one person to
influence. Because I couldn't identify a high-quality input that I could control to impact the
stock price, I stopped obsessing over it. Instead, I focused on inputs I could affect.

Just as I learned to stop obsessing over Amazon's stock price and focus on my daily
work, teams can benefit from shifting their attention from fluctuating output metrics to the
quality of their inputs. In the long run, like Graham's weighing machine, the market (or
your users) will recognize and reward consistent, high-quality work.

I challenge you to examine your own work and your team's focus, whether you work in
tech or not. Are you fixating on outputs you can't directly control? What high-quality inputs
could you scale up to drive meaningful improvements?

Start small, measure the impact, and watch as your outputs naturally improve.

2/2

You might also like