Performance Is Not Speed: It’s Accumulated Technical Capital

You probably know this meeting.

The sprint just ended. The board is on the screen. One engineer has a long column of “Done” tickets, almost overflowing. Another has a handful.

Everyone sees it.

Someone says it out loud:

“Wow, John crushed it this sprint.”

People laugh. The manager nods. There’s a subtle, unspoken conclusion in the room:

“John is a high performer.”

Six months later, the same pattern repeats.

But now there is a twist.

The areas of the codebase John owns have become a minefield. Every new feature there takes longer than it should. Bugs keep popping up in strange places. Deploys are tense. Incidents wake people up at night.

And who saves the day?

John.

He jumps on the call, types fast, throws in a hotfix, restarts services, calms everyone down. The issue is “resolved”. Slack fills with messages:

• “Thanks John, you’re a life saver.”
• “Once again, John the hero.”

No one says the other half of the sentence:

“John is also the one who made this area so fragile in the first place.”

Meanwhile, there is another engineer in the same team.

She rarely breaks production.

Her features land quietly.

People who touch her code can follow the logic.

New developers onboard faster when they start from her modules.

She doesn’t have a long list of incidents to “save”.

So she also doesn’t have many “hero” moments.

In meetings, no one says:

“She saved us from a problem that never happened because she designed it right.”

But that’s exactly what she did.

Over time, John is seen as “fast”, “intense”, “committed”, “heroic”.

She is seen as “solid”, “quiet”, “reliable” – and often, simply invisible.

This is the core paradox that silently destroys engineering teams:

We celebrate the firefighter and ignore the engineer who built the fireproof building.

And if we are honest, a lot of our “performance culture” is built on top of this illusion.

We look at:

• tickets closed,
• apparent speed,
• how loud the impact looks in the short term,
• how often someone is involved in “critical moments”.

We almost never look at:

• how much rework they generate,
• how much cognitive load they add to the system,
• how much risk they quietly inject into the future,
• how much long-term ease they create for everyone else.

Why?

Because speed is visible.

Heroics are visible.

Technical depth and clean design are often invisible.

So we end up with teams where:

• the “fast” engineer is celebrated while slowly turning the codebase into concrete,
• the thoughtful engineer is undervalued while making the entire system safer and faster over time.

And leaders, under pressure for results, slide into the simplest assumption:

“High performance = the person who ships the most, the fastest.”

I’ve been in enough teams, from small startups to larger systems, to see this pattern repeat.

When you zoom out, the truth is very clear:

• The engineer who looks fast can actually be slowing the whole team down.
• The engineer who looks slow may be the one compounding value every single week.

The problem is not just how we talk about performance.

The problem is the mental model underneath.

We think performance is a moment.

We treat it like a race.

We ask, “How fast did you run this sprint?”

But high performance in software is not a race.

It’s more like building capital.

The best engineers are not just fast.

They are accumulating something deeper inside themselves and inside the codebase:

• knowledge,
• execution maturity,
• pattern recognition,
• design intuition,
• production scar tissue,
• and the ability to make other people better.

All of that together is what I call technical capital.

In the rest of this article, I want to show you a different way of seeing performance:

• why “fast” is a terrible primary metric,
• what technical capital actually is,
• how it shows up in real work,
• and how both engineers and leaders can intentionally build it.

Because once you start measuring and rewarding technical capital, something powerful happens:

Your team doesn’t just get fast for one sprint.

It gets faster every month, with fewer fires, less drama, and a lot more peace.

Performance as Accumulated Technical Capital

Let’s change the lens.

Forget, for a moment, about sprints, tickets, and deadlines.

Imagine instead that every engineer carries an invisible balance sheet.

On that balance sheet there are two sides:

• what they can do right now (their visible output),
• what they have built inside themselves over years (their invisible capital).

Most companies only look at the first line.

“How many tasks did you finish?”

“How quickly did you deliver this feature?”

But the second line is the one that actually determines the future.

That second line is technical capital.

What is technical capital?

Technical capital is the accumulated asset that an engineer brings into every problem, every project, every decision.

It’s not a buzzword. It’s very concrete:

• the depth of their knowledge about systems,
• their ability to reason under pressure,
• their pattern recognition across different architectures and failures,
• their design intuition,
• and their impact on the thinking of the team around them.

Two engineers can write the same feature.

One just “gets it done”.

The other upgrades the system while getting it done.

Same visible output.

Very different capital.

Technical capital is what allows someone to:

• look at a vague requirement and see the real shape of the problem,
• choose the right level of abstraction,
• anticipate the edge cases before users hit them,
• design for change, not just for “today’s ticket”.

They are not just coding.

They are investing.

Stock vs. flow

A simple analogy helps.

Think of speed as the flow of water through a pipe.

“How much passed through this week?”

Think of technical capital as the size and quality of the pipe itself.

“How much can this system handle, consistently, without breaking?”

Speed is what you see in a short time window.

Capital is what defines what’s possible across many windows.

If you only optimize for flow, you push more and more water through a small, fragile pipe.

It looks impressive… until it bursts.

If you invest in the pipe itself, something different happens:

• capacity grows,
• pressure becomes easier to manage,
• the system can handle more without drama.

Technical capital is the pipe.

The compounding effect

Capital has a special property: it compounds.

An engineer with high technical capital:

• writes code that is easier to extend,
• chooses designs that reduce future rework,
• avoids classes of bugs entirely,
• creates patterns others can reuse,
• adds observability that makes future debugging trivial.

Every good decision today removes friction from tomorrow.

Every avoided incident frees time for deeper learning.

Every clear abstraction becomes a foundation for the next feature.

The result?

Their work gets faster over time.

Not because they type faster, but because they have:

• fewer surprises,
• fewer regressions,
• fewer late-night emergencies,
• and far less “mysterious behavior” in production.

Speed becomes a side effect of their capital.

By contrast, the “just-be-fast” engineer experiences the reverse effect:

• quick hacks accumulate,
• inconsistencies spread,
• complexity grows in strange directions,
• every change gets scarier and slower.

Their apparent speed today creates a hidden debt that slows everything down tomorrow.

That’s negative compounding.

Changing the core question

When you adopt this lens, the performance conversation changes completely.

The shallow question is:

“How many tickets did you close this sprint?”

The deeper question is:

“How much technical capital did you build or deploy that made the system better for the future?”

You start to notice different things:

• Who consistently simplifies complex areas of the codebase?
• Who makes it easier for others to work in certain domains?
• Who reduces the number of incidents and the blast radius when something breaks?
• Who designs APIs and modules that are still holding up a year later?

These are capital questions, not speed questions.

Why this matters for the business

This is not a romantic view of engineering.

It is a pragmatic one.

Companies don’t suffer because a feature took two extra days.

They suffer because:

• every new change feels risky,
• onboarding takes months instead of weeks,
• incidents become more frequent and more expensive,
• rewrites consume entire quarters.

All of that is a capital problem.

When you build teams that value technical capital:

• change becomes cheaper,
• incidents become rarer and easier to fix,
• product can move faster with more confidence,
• and engineers are less burned out because everything is not a constant emergency.

Speed comes, but as a byproduct of the right investments.

In other words:

Performance is not “how fast you run this week”.

Performance is “how much capital you’ve built that makes every future run easier.”

In the next part, we’ll go deeper and break technical capital into clear layers — a stack you can see, measure, and intentionally grow as an individual and as a team.

The Technical Capital Stack

“Technical capital” sounds abstract.

Let’s make it concrete.

You can think of it as a stack of layers that sit on top of each other.

Each layer changes how you see problems, how you make decisions, and how your code behaves in the real world.

The more layers you develop, the more “unfair advantage” you carry into every project.

Here’s how I break it down.

Knowledge Depth

This is the foundation.

It’s the difference between:

• “I know how to use this framework”
• and
• “I understand what’s happening under the hood.”

Engineers with deep knowledge of algorithms, data structures, databases, distributed systems, and performance don’t just plug libraries together. They can:

• reason about trade-offs,
• predict how the system will behave under load,
• avoid designs that look simple now but explode later.

It’s like the difference between someone who can read a music sheet vs. someone who only memorized a few songs on YouTube.

One can adapt to any new piece. The other struggles as soon as the pattern changes.

Knowledge depth doesn’t mean you’ve read every book.

It means your mental models are strong enough that new technologies make sense faster.

Execution Autonomy

Knowledge alone is not enough.

High-performance engineers can take a vague problem and move it from idea to production without constant help.

They can:

• clarify requirements,
• break work into clean, testable chunks,
• define a sensible sequence of steps,
• communicate progress without drama.

If you’re a leader, you know the difference:

• Some people need you to hold their hand through every step.
• Others send you a message: “Here’s the plan. Here’s the risk. Here’s when I’ll have something to review.”

Execution autonomy is not about working alone.

It’s about being able to move without being pushed.

It turns managers into partners instead of babysitters.

And it turns engineers into adults in the system, not just “ticket consumers”.

Pattern Recognition

After you’ve built enough things, you start to see the same shapes.

• The same kinds of bugs.
• The same architecture smells.
• The same “this will bite us in three months” signals.

At this layer, engineers don’t just solve the specific bug in front of them.

They recognize it as “one instance of a bigger pattern”.

They can say:

• “This is basically the same race condition we had last quarter.”
• “This data model is the same anti-pattern we hit in service X.”
• “This API design will make filtering and pagination painful.”

Pattern recognition turns experience into acceleration.

You stop paying the full price for every new problem.

You recycle previous learning.

Junior engineers rely on trial and error.

High-capital engineers rely on accumulated patterns.

Systems and Design Maturity

Here, you stop thinking only in terms of “code” and start thinking in terms of systems.

Questions change:

• from “Does this work?”
• to “How will this evolve? Who will depend on this? How easy is it to change?”

You begin to design for:

• modularity instead of shortcuts,
• clear boundaries instead of big balls of mud,
• explicit contracts instead of hidden assumptions.

You remember that every decision today is a future constraint.

So you ask different questions:

• “What is the simplest design that will survive real usage?”
• “Where do we want to pay the cost now, and where later?”
• “What happens if we need to double this, or cut it in half?”

This isn’t about over-engineering.

It’s about choosing sustainable designs that reduce the total cost of ownership.

A mature design doesn’t just solve today’s ticket.

It reduces the friction for the next ten tickets in that area.

Production Experience (Incidents and Edge Cases)

Some lessons you only learn in production.

You can read about incidents.

You can watch conference talks.

But when you’re on a call at 2am, and real users are impacted, something changes in how you think.

Engineers with real production scars:

• think about observability up front,
• instrument logs and metrics that actually help,
• design safe rollbacks,
• avoid clever hacks that are impossible to debug later.

In an incident, they don’t thrash around.

They:

• narrow down hypotheses,
• use data to eliminate possibilities,
• stabilize first, optimize later,
• and always leave the system a bit stronger than before.

This layer of capital transforms fear into respect.

You don’t become paranoid, but you stop being naive.

You know where systems usually break.

And you build with that in mind.

Mentorship and Technical Influence

The last layer is where technical capital starts to multiply.

At this level, your value is not just what you personally ship, but how much you:

• unblock others,
• raise the quality bar,
• transfer your mental models to the team.

You do this through:

• clear, thoughtful code reviews,
• small design sessions,
• writing down decisions and their reasons,
• pairing with people at the right moments.

You’ve probably met engineers who are strong individually but leave no trace:

when they’re gone, the team doesn’t get any better.

And you’ve met others who are force multipliers:

after a year with them, the whole team thinks differently.

Mentorship is not about having “Senior” in your job title.

It’s about taking responsibility for how your knowledge flows into the group.

When this layer is active, technical capital stops being a private asset.

It becomes a shared advantage.

When you look at performance through this stack, the picture changes.

You stop asking, “Who closed more tickets?”

You start asking:

• Who is growing their knowledge depth?
• Who can execute with autonomy?
• Who shows strong pattern recognition?
• Who makes design choices that age well?
• Who handles production reality with maturity?
• Who makes everyone around them better?

That is technical capital.

In the next part, we’ll look at how this stack shows up in real, everyday situations – and how you can start recognizing it inside your own team and career.

How Technical Capital Shows Up in Real Work

Let’s take this out of theory and drop it into everyday life.

Because once you see technical capital in action, you can’t unsee it.

The Ticket Machine vs. The Builder

Imagine two engineers on the same team.

They both work on the same product area.

They both have access to the same tools, same process, same sprint board.

On paper, they look similar.

In reality, they are playing completely different games.

Engineer A – The Ticket Machine

Engineer A is fast.

He grabs tickets quickly.

He writes code quickly.

He pushes PRs quickly.

In Jira or Linear, his name is everywhere.

Standups sound like:

• “Yesterday I finished X and Y, today I’ll start Z.”
• “Yeah, that bug is already fixed, I pushed a quick patch.”

He knows how to “get things working” under pressure.

But he rarely:

• writes clear tests,
• simplifies existing code,
• questions vague requirements,
• takes time to design the shape of the solution.

He ships.

What you don’t see at first:

• functions with too many responsibilities,
• hidden coupling between modules,
• weak boundaries around domains,
• little traps for future changes.

In the short term, he looks like the top performer.

In the long term, he quietly raises the cost of every future feature.

Engineer B – The Builder

Engineer B moves at a different rhythm.

She picks up fewer tickets.

Her PRs are not massive, but they are deliberate.

She:

• asks questions to clarify edge cases,
• proposes a small refactor when the current design is clearly in the way,
• leaves behind tests that encode her understanding,
• adds one or two small improvements to logging or structure when she sees a chance.

She is not trying to be clever.

She is trying to be clear.

In sprint reviews, her name doesn’t dominate the “Done” column.

But her changes are the ones that:

• don’t break three other things,
• don’t require hotfixes,
• don’t surprise other engineers a month later.

If you only look at raw speed, Engineer A wins.

If you look at technical capital, Engineer B is playing a different sport.

Six months later, most bugs and incidents come from the areas touched by Engineer A.

Most “this is actually easy to change” moments happen in the areas owned by Engineer B.

Who is really performing?

Incidents: Panic vs. Pattern

Now picture a production incident.

Something is broken in a flow that touches money.

Metrics are red. Support is on fire. The channel explodes.

Two engineers join the call.

Low-capital Reaction

• They start changing things randomly.
• Add logs everywhere.
• Restart services.
• Try “that thing that worked last time.”
• Hope.

The mental model is: “If I do enough things, one of them will fix it.”

When something finally appears to work, they say: “It’s fixed.”

No one is quite sure why.

The patch stays in production.

The system becomes a little bit more mysterious.

Next time, the same pattern repeats.

More fear. More hacks. More unknowns.

High-capital Reaction

Another engineer joins the same incident.

Their behavior is different.

They:

• slow down mentally (even if the situation is urgent),
• ask precise questions,
• look at the right dashboards,
• compare what changed recently,
• form a hypothesis, then test it.

They use their experience with similar patterns:

• “We’ve seen this kind of spike when a background job loops.”
• “This looks like a cache invalidation problem, not a database issue.”
• “Response times changed before error rates went up – let’s trace that path.”

When they apply a fix, they:

• validate the behavior,
• write down what happened,
• add one or two guardrails (a metric, a log, an alert) so next time is easier.

In the first case, you “got lucky”.

In the second, you invested capital.

Same incident.

Same urgency.

Completely different long-term outcome.

One approach makes the system more fragile.

The other makes it more understood.

Onboarding: Sink or Lift

Here’s another place where technical capital shows up: onboarding.

A new engineer joins the team.

In a low-capital environment:

• there are almost no docs,
• code is full of surprising side effects,
• nobody can explain why certain decisions were made,
• tests are flaky or missing.

The new person spends weeks just… guessing.

They ask questions and hear:

• “Yeah, that part is weird, you kind of have to know it.”
• “Don’t touch that module, it’s dangerous.”
• “We were planning to refactor that, but never had time.”

They don’t feel stupid.

They feel lost.

Their performance looks low, but it’s not a talent problem.

It’s a capital problem.

In a high-capital environment:

• key flows are simple to follow,
• there are diagrams or short docs for complex areas,
• tests act as living documentation,
• senior engineers explain not just what but why.

The new engineer can:

• clone the repo,
• run tests,
• follow clear seams in the design,
• read a few decisions and understand the trade-offs that shaped the system.

They ramp up faster.

They make fewer dangerous changes.

They gain confidence.

Same person.

Two different environments.

Two completely different performance curves.

Again: performance is not just speed.

It’s the amount of technical capital already present in the code, the tools, and the people.

What Metrics Miss (and What They Reveal)

To be clear: metrics are useful.

The problem is how we use them.

If you only look at:

• tickets closed,
• lines of code,
• raw velocity,

you will always overvalue Engineer A (the ticket machine).

But if you widen the lens and also look at:

• how often their changes cause incidents,
• how many times their code needs rework,
• how many dependencies their modules create,
• how easy it is for others to build on top of their work,

the story changes.

You start to notice patterns like:

• This person ships a lot, but their change failure rate is high.
• This person ships less, but their areas are stable and evolve gracefully.
• Features in this domain are always expensive – what does the design look like there?
• Features in that domain are predictable – who shaped that part of the system?

DORA-style metrics (deployment frequency, change failure rate, mean time to recovery) can help.

But you need to interpret them through the lens of technical capital.

High technical capital tends to produce:

• frequent deploys,
• low failure rates,
• fast and calm recovery when something does break.

Low technical capital tends to produce:

• infrequent, risky deploys,
• “surprise” incidents,
• long and chaotic firefights.

The key is this:

Metrics are not the truth.

They are signals.

Technical capital is what explains those signals.

Once You See It, You Can’t Go Back

After you’ve seen these patterns in your own team, it’s very hard to go back to:

“Who wrote the most code this sprint?”

You start to ask more honest questions:

• Who is quietly preventing incidents we will never see?
• Who is making this system simpler every month instead of more complex?
• Who is turning pain into patterns and patterns into shared knowledge?
• Where in our codebase is technical capital high – and where is it dangerously low?

And maybe the most important one:

“Are we rewarding the people who build capital,

or just the ones who create drama and then rescue us from it?”

In the next part, we’ll go from observation to action:

how to intentionally build technical capital as an individual engineer, even in a busy job, without needing permission from anyone.

Building Technical Capital Intentionally (Playbook for Individuals)

Here’s the good news:

Technical capital is not a gift.

It’s not reserved for “geniuses” or people at big-name companies.

It’s a practice.

You don’t control your starting point.

But you absolutely control your trajectory.

If you treat every week as an opportunity to compound capital, your performance curve will look very different one year from now.

Let’s make this practical.

See Your Job as a Training Ground, Not Just a To-Do List

Most engineers wait for the “perfect job” or the “perfect project” to grow.

That’s a trap.

The reality is: your current work is your dojo.

• Messy legacy code? Training ground for refactoring and design.
• Confusing requirements? Training ground for clarification and communication.
• Sparse tests? Training ground for adding safety nets and learning what to test.

Instead of thinking,

“This codebase is bad; I can’t grow here,”

try:

“This codebase is imperfect; it’s full of opportunities to practice.”

You don’t need a greenfield system to build capital.

You need a posture: “Every task is a chance to leave things better than I found them.”

Choose Depth Over Noise

If you are constantly consuming random content, you feel “busy learning” but not actually growing.

Capital doesn’t grow from scattered noise.

It grows from focused depth.

Pick a few core themes that matter for your work and your future, for example:

• databases and data modeling,
• distributed systems and reliability,
• testing and automation,
• performance and profiling.

Then commit to them.

Read one good book instead of ten threads.

Follow one long course and implement the ideas.

Study one system you admire and reverse-engineer its design.

Ask yourself regularly:

“What am I choosing to go deep in this season?”

If the answer is “everything and nothing,” your capital is not compounding.

Turn Everyday Tasks into Deliberate Practice

You don’t need a separate life to grow.

You can use your day job as the main gym.

For every task, you can ask:

• “What is the one skill I want to practice here?”
• “How can I leave this area slightly better than I found it?”

Examples:

• When touching a messy module, do one small, safe refactor that clarifies intent.
• When fixing a bug, add a test that would have caught it earlier.
• When designing a feature, sketch a simple diagram before coding.
• When adding logs, make them structured and meaningful for future debugging.

These are small moves.

Done consistently, they change who you are as an engineer.

You’re not just closing tickets.

You’re training your judgment.

Build a Reflection Loop on Your Own Decisions

Capital grows faster when you don’t just do things, but learn from them.

After a feature ships or an incident closes, take five minutes and ask:

• What did I assume that turned out to be wrong?
• Where did I guess instead of reason?
• What did I not see early that became obvious later?
• What would a more experienced engineer have done differently here?

Write down short notes.

They don’t need to be perfect.

They just need to exist.

Over time, you’ll see patterns:

• recurring mistakes,
• recurring blind spots,
• recurring “I should have asked this question earlier”.

That’s your personal roadmap for capital growth.

Most people repeat the same year of experience five times.

Reflective engineers actually turn five years into five different levels.

Use Mentorship in Both Directions

One of the fastest ways to grow technical capital is to stand in the middle:

• learn from someone ahead of you,
• teach someone a few steps behind you.

When you ask for mentorship, make it easy to help you:

• Bring specific questions: “Can you walk me through how you’d design this?”
• Ask for review on your thinking, not just your code: “Does this trade-off make sense?”
• Request feedback on one dimension at a time: “How can I make this API easier to evolve?”

And when you mentor others:

• Explain your reasoning, not just your conclusion.
• Show them how you read code and navigate a system.
• Share mistakes you’ve made so they don’t have to pay the same price.

Teaching forces clarity.

You discover where your understanding is fuzzy, because you can’t explain it cleanly.

Mentorship is not “extra work”.

It is capital transfer – and you always keep a copy of what you give.

Protect Time for Deep Work and Deep Learning

Capital does not grow in the cracks of an overloaded calendar.

You need protected time.

Two types of time are critical:

1. Deep work time

   • Focused, distraction-free blocks where you push one hard problem forward.
   • No Slack. No email. No context-switching.
   • This is where you practice design, reasoning, and high-quality execution.

2. Deep learning time

   • Time reserved to study fundamentals, read postmortems, explore architectures, or practice in a focused way.
   • This is not random YouTube. It is intentional study aligned with your growth themes.

You don’t need full days.

Start with:

• one or two 90-minute deep work blocks per day,
• two or three 60-minute deep learning blocks per week.

Defend these on your calendar like meetings with your future self.

Because that’s exactly what they are.

Build a Simple Weekly Capital Routine

To make this sustainable, turn it into a weekly rhythm.

Here’s one example you can adapt:

Every Week

• 1 hour – Fundamentals

  Study something that will still matter in 10 years: algorithms, distributed systems, database internals, testing strategies, architecture patterns.

• 1 hour – Systems and Postmortems

  Read about real incidents (yours or others).

  Ask: What failed? Why? How did design choices contribute? What would I have done?

• 1–2 hours – Capital Upgrade Inside Work

  Pick one feature or bug you’re working on and intentionally:

  • improve design,
  • write clearer tests,
  • add better observability,
  • document a decision.

• 1 hour – Mentorship (give or receive)

  • Pair with someone junior and explain your thinking.
  • Ask a senior to walk through your design.
  • Write a short internal post: “How we solved X and what we learned.”

This is not a rigid formula.

It’s a template for compounding.

Most engineers drift week to week, reacting to whatever comes.

High-capital engineers run a quiet system in the background: learn, apply, reflect, share.

Over time, that system changes everything:

• your confidence,
• your opportunities,
• the trust people place in your judgment,
• and the impact you have on the teams you touch.

In the next part, we’ll shift perspective.

So far we stayed at the individual level.

Now we’ll look at how leaders can design teams and cultures that reward technical capital instead of accidentally punishing it – and how that changes the trajectory of an entire organization.

Designing Teams Around Technical Capital

If you’re a leader, here’s the hard truth:

You can hire brilliant people and still destroy performance with the wrong incentives.

Most “performance problems” I see are not about talent.

They’re about what the system rewards.

If you only celebrate speed and heroics, don’t be surprised when you get shallow decisions, fragile systems, and constant drama.

If you want technical capital, you have to design for it.

Let’s make that concrete.

Stop Rewarding Drama, Start Rewarding Stability

Look at who gets praised in your team.

Is it mostly the person who:

• pulled an all-nighter,
• shipped a risky hotfix,
• “saved” a broken deployment,
• jumped into every fire?

Or is it also the person who:

• designed the system so there were fewer fires,
• reduced the blast radius of changes,
• quietly simplified a critical flow,
• made it easier for others to ship safely?

If you only celebrate the first type, you’re telling the whole team:

“Create exciting problems and then rescue us from them. That’s how you get noticed.”

Instead, you want to send a different signal:

“The highest praise goes to the people who make things boringly reliable.”

You can do this very simply:

• In weekly updates, highlight incidents that didn’t happen because of good design.
• Call out engineers who reduced complexity or clarified a messy area.
• Share before/after stories of systems that are now easier to work with.

Make “boring stability” aspirational.

Redesign Performance Reviews Around Capital, Not Just Output

If your performance reviews are secretly just:

• “How many things did you ship?”
• “Were stakeholders happy with your responsiveness?”

then you are measuring flow, not capital.

Add different questions:

• How does this engineer handle ambiguity and design trade-offs?
• Do their changes age well, or do they frequently require rework?
• How often do they improve the structure of the system, not just its surface?
• Do they help others understand the system better?
• What happened in the areas of the codebase they own over the last 6–12 months?

You can explicitly assess things like:

• Design quality (clarity, modularity, evolvability)
• Production maturity (incident handling, observability, risk management)
• Influence (code reviews, mentoring, documentation)

This doesn’t mean ignoring delivery.

It means balancing delivery with the capital that makes future delivery possible.

Create Learning Loops: Design Reviews and Postmortems That Teach

Most teams have ceremonies.

Few have learning loops.

A design review can be:

• a gate to “approve” something,
• or a space to sharpen thinking and build shared capital.

A postmortem can be:

• a blame session,
• or a structured moment to understand causes, choices, and patterns.

You choose.

To build capital:

• Run design reviews where the goal is to expose trade-offs, not just nitpick names.
• Ask: “What are the risks?”, “How will this evolve?”, “What are we intentionally not doing now?”
• Treat postmortems as assets: capture the story, the root causes, and the lessons for future design.

Then make these visible:

• short written docs,
• diagrams,
• checklists that come out of incidents (“next time we design X, ask these questions”).

Over time, your team’s “collective brain” gets sharper.

New people can plug into those lessons instead of repeating old mistakes.

That’s technical capital at the group level.

Protect Time for Capital-Building Work

If everything is urgent, nothing is important.

You cannot build technical capital in a system that runs at 110% capacity all the time.

There is no room to improve anything — only to survive.

As a leader, you have to create slack intentionally.

A few simple patterns:

• Reserve a fixed percentage of capacity (e.g. 10–20%) for:
  • refactors that unblock future work,
  • improving tests and observability,
  • paying down the worst tech debt.
• Explicitly schedule “capital work” as part of the roadmap, not as a side quest.
• Tie tech debt items to real business pain: “this slows every release by X days”.

The message should be:

“We’re not cleaning things up because we’re perfectionists.

We’re investing because we want to move faster six months from now.”

If you never make that investment, you’re choosing speed now and pain later.

And your best engineers will feel it — and eventually leave.

Promote Force Multipliers, Not Just Solo Stars

Who gets promoted in your org?

Is it the individual who:

• ships the most impressive solo features,
• hoards knowledge,
• likes to be the only person who can fix certain things?

Or is it the engineer who:

• raises the level of the entire team,
• documents their area so others can contribute,
• designs APIs that are easy for everyone to use,
• gives thoughtful reviews that teach, not just judge?

You want to promote force multipliers.

These are the people whose technical capital:

• de-risks projects,
• accelerates onboarding,
• improves the decisions of everyone around them.

Make that criteria explicit:

• In promotion rubrics, include “impact on others’ performance” as a key axis.
• In career ladders, show a clear path where influence and mentoring matter as much as personal throughput.
• In calibration meetings, ask: “If this person left, how much collective capital would we lose?”

When people see that helping the team get stronger is a real path to recognition, they change how they behave.

Hire and Onboard With Capital in Mind

Technical capital starts at the door.

When hiring, don’t just test if someone can solve a puzzle under pressure.

Look for:

• how they think about trade-offs,
• how they reason about unknowns,
• how they design for evolution,
• how they talk about past incidents and failures.

Good signals include:

• candidates who can explain not just what they built, but why they made certain choices,
• stories where they simplified something complex,
• awareness of real-world constraints (latency, cost, reliability, team skills).

During onboarding:

• show new engineers your architecture decisions, not just your tickets,
• walk them through past postmortems and what changed,
• make it normal to ask “why is it designed like this?”

If you introduce them to your capital, they will be more likely to add to it instead of eroding it.

Designing teams around technical capital is not about being idealistic.

It’s about being honest:

• Speed without capital is a sugar high.
• Speed with capital is sustainable strength.

When you, as a leader, intentionally reward the engineers who build capital — in their code, their decisions, and their influence — you create a very different organization:

• fewer emergencies,
• more predictable delivery,
• healthier people,
• and a codebase that becomes an asset instead of a liability.

In the next (and final) part, we’ll look at the common traps and misinterpretations that show up when people first adopt this lens, and how to avoid turning “technical capital” into just another buzzword.

Common Failure Modes and Misinterpretations

Any powerful idea can be abused.

“Technical capital” is no different.

If you misunderstand it, you can actually make things worse.

Let’s walk through the most common traps I’ve seen — in myself, in teams I’ve led, and in people I’ve mentored.

The Over-Engineering Trap

The first misuse is almost predictable:

Someone hears “technical capital” and concludes:

“Great. Now I have a reason to design something extremely advanced and complex.”

Suddenly, every small feature becomes a candidate for:

• full-blown microservices,
• five layers of abstraction,
• three message buses,
• a configuration system so generic that nobody understands it.

All in the name of “future-proofing” and “good architecture”.

But here’s the test:

If your “capital” makes the system harder to understand, harder to change, and harder to debug, it’s not capital.

It’s ego in disguise.

Real technical capital:

• makes the system clearer,
• reduces the number of places you need to touch,
• uses the simplest solution that will survive real usage,
• balances today’s constraints with tomorrow’s possibilities.

Sometimes the most capital-rich decision is:

“We’ll keep it simple on purpose, and when X or Y happens, we’ll split this out.”

You’re not building monuments.

You’re building systems that should be easy to live in.

The “I’ll Never Catch Up” Story

Another common failure mode is internal, and it’s quiet:

You read about technical capital, you look at people you admire, and your brain whispers:

“I’m too far behind.”

“I didn’t start in Big Tech.”

“I wasted too many years in simple CRUD apps.”

“This is not for me.”

So instead of growing, you shut down.

Here’s the reality:

• Everyone started with zero capital at some point.
• Many “senior” engineers have simply repeated the same year of experience multiple times.
• You don’t need a fancy job title to start compounding.

What matters is not where you are on the curve.

What matters is whether your curve is flat or rising.

Ten deliberate hours a week for a year will radically change your level:

• reading one good book deeply and applying it,
• owning one critical flow and making it simpler and safer,
• leading a few design discussions and reflecting on them,
• learning from real incidents instead of just patching.

Technical capital is built in regular hours, with regular people, in regular jobs.

The question is not “Am I behind?”

The question is “What do I want my trajectory to be from now on?”

Blaming the Environment for Everything

There is also a very tempting external story:

“My company doesn’t care about this.”

“Here it’s all about deadlines and pressure.”

“Leadership only looks at velocity.”

“There’s no way to build technical capital in this place.”

Sometimes that’s true.

Some environments are truly toxic and short-sighted.

But often, this story is half-true and half-escape.

You might not be able to change the culture overnight.

You might not get explicit time to refactor or study.

But you almost always have some room:

• You can choose a slightly clearer design instead of a slightly messier one.
• You can add one or two tests that protect against regression.
• You can leave a short note explaining a decision for future you (or someone else).
• You can do a mini-retro on your own work even if nobody asks for it.
• You can mentor one junior engineer in the way you wish someone had mentored you.

Are these perfect conditions? No.

Are they enough to start building capital? Yes.

There is a point where a misaligned environment truly caps your growth.

At that point, the most capital-rich decision might be to leave.

But many people use “the company” as a shield to avoid facing their own passivity.

A useful question is:

“Given the constraints I have, what is the next small way I can build capital here?”

If the honest answer is “nothing” for months, you have your signal.

Until then, there’s usually more room than you think.

“This Is Only for Seniors”

Another subtle misinterpretation:

“Technical capital is a senior thing. I’m junior, so this doesn’t apply yet.”

This is backwards.

Juniors who understand technical capital early grow much faster than their peers, because they:

• pay attention to design and trade-offs,
• treat incidents as learning opportunities,
• ask better questions in reviews,
• look beyond “does it work?” to “is this a good shape?”

You don’t need 10 years of experience to start thinking about:

• boundaries between modules,
• how your code will be read by others,
• what could go wrong in production,
• what tests really matter.

In fact, the earlier you start practicing these things, the more capital you’ll have anyway after 10 years.

“Senior” is not a time-based title.

It’s a reflection of your judgment and impact.

Technical capital is how that judgment is built.

Turning Capital into a Buzzword

Finally, there’s the organizational risk:

Leaders hear this idea, like the sound of it, and suddenly:

• performance docs mention “technical capital” everywhere,
• people add it to slides,
• it appears in promotion rubrics.

But nothing in reality changes.

• Tickets are still the main thing that matters.
• Heroic firefighting still gets praise.
• Refactors and design improvements are still “nice to have, if you have time.”
• Postmortems still look for someone to blame, not something to learn.

In that case, “technical capital” is just another phrase on the wall.

If you’re a leader, you have to go first:

• change what you ask in 1:1s,
• change what you highlight in public,
• change what you write in reviews,
• change how you tell the story of “good work” in your team.

If your behavior doesn’t move, your culture won’t either.

All of these failure modes have one thing in common:

They forget the core purpose.

Technical capital is not about:

• fancy architectures,
• titles,
• ego,
• or sounding smart.

It’s about building engineers and teams that can move fast with wisdom:

• fast without constant emergencies,
• fast without sacrificing trust,
• fast without destroying themselves in the process.

In the final part, we’ll bring everything together — and I’ll leave you with a simple reframing you can carry into your next sprint, your next promotion review, and your next career decision.

From Ticket Speed to the Capital Flywheel

If you’ve read this far, you probably already felt this tension in your gut:

There is something deeply wrong with how our industry talks about “performance”.

We say things like:

• “We need to move faster.”
• “We need more output.”
• “We need to hit this deadline.”

But we rarely ask:

• “At what cost?”
• “On top of which foundations?”
• “With what long-term effect on our people and our systems?”

We treat performance like a sprint scoreboard.

We compare ticket counts and reaction times.

We celebrate whoever is loudest in the crisis.

And then we wonder why:

• our systems feel heavier every quarter,
• our teams feel more tired every year,
• and delivery feels less predictable the more we ship.

The answer is not more speed.

The answer is better capital.

You can think of this as a simple shift in lens.

Old lens:

“How fast did you move this sprint?”

New lens:

“How much technical capital did you build and deploy

that will make the next sprint easier, safer, and faster?”

One question looks at a moment.

The other looks at a trajectory.

That’s the difference between speed and a flywheel.

The Capital Flywheel

When you invest in technical capital, a quiet flywheel starts turning:

• You learn fundamentals →
• You design clearer systems →
• You have fewer bugs and incidents →
• You spend less time firefighting →
• You have more time and energy to learn and improve →
• You design even better systems.

Each cycle makes the next one easier.

For individuals, this looks like:

• work feeling more under control,
• more confidence in decisions,
• less fear every time you hit “deploy”.

For teams, it looks like:

• sprints that don’t end in chaos,
• incidents that become learning moments instead of blame sessions,
• juniors who grow faster because they stand on solid foundations.

For companies, it looks like:

• the ability to move fast without constantly breaking trust,
• a codebase that starts to feel like an asset, not a liability,
• a culture where good engineers want to stay.

This is what it means to build a performance system on capital, not adrenaline.

What This Means for You

If you’re an engineer, you don’t need anyone’s permission to start.

You can decide that from this week on:

• you will treat every task as training,
• you will leave every area you touch slightly clearer than you found it,
• you will reflect on your decisions instead of just moving on,
• you will protect small blocks of time for deep learning,
• you will share what you know with at least one other person.

You are not just “doing your job”.

You are building an asset inside you that nobody can take away.

If you’re a leader, you can change the story your system tells.

You can:

• stop glorifying constant heroics,
• start recognizing people who prevent problems,
• adjust reviews to include design, maturity, and influence,
• carve out space for capital work in your roadmap,
• promote the engineers who make everyone else better.

You are not just “managing delivery”.

You are deciding whether your organization will age like a healthy body or a fragile machine.

A Different Kind of Ambition

There is a quieter, deeper ambition available to us as engineers and leaders:

Not to be the fastest person in the room,

but to be the person whose presence makes the whole room wiser,

calmer, and more capable over time.

That is what technical capital really is:

• the integration of knowledge,

• execution,

• experience,

• judgment,

• and influence

  — expressed through code, systems, and people.

Speed matters.

But on its own, speed is a snapshot.

Speed is a snapshot; technical capital is the story.

In the long run, the people and teams who win are not the ones who sprint the hardest for one quarter.

They are the ones who quietly, consistently build the capital that makes every future sprint lighter.

So the next time you look at a sprint board, a promotion case, or your own week, try asking a different question:

• Not just “What did we ship?”
• But also “What capital did we build?”

That shift, repeated over months and years, is how you move from a culture addicted to ticket speed to a culture powered by a capital flywheel that doesn’t stop.

Best,
Linecker Amorim.