Optimizing the team’s workflow can be more impactful than building business features. It defies logic, but it’s true.

I work with and talk to a lot of engineers, and to explain my point, I’ll describe two engineers on the same team.

💪 Engineer 1

The first engineer churns out a lot of code and user stories. They’re focused, consistently finishing on time, and often doing more than they’re assigned.

When it comes to shipping business features, this person does a great job.

But this person is also more than happy to let their build run for 3 hours.

🦾 Engineer 2

The second engineer completes their assigned user stories, but when they encounter inefficiencies, they spend time fixing them. Sometimes it’s improving the build pipeline, fixing flaky tests, making code more maintainable, etc.

While this engineer may finish fewer user stories because they are distracted by these “side quests,” they make a bigger impact.

🏋️ Enabling Others

While avoiding the 10x engineer trope, Engineer 2 has a bigger impact by resolving issues affecting the whole team.

A slow pipeline slows everyone’s work.

Open a single change, then wait 3 hours. A test fails—wait another 3 hours. Feedback comes in—wait 3 more.

Broken workflows turn simple changes into long, inefficient endeavors.

So fixing these not just for themselves but for everyone means the whole team can ship code faster.

📈 Invest in Workflows

Investing time in optimizing your workflow and the team’s workflow usually pays dividends.

Sometimes it’s hard to quantify, but the smallest optimizations can be huge.

Someone on the team who gets frustrated with inefficiencies and decides to fix them is incredibly valuable.

👩‍🔧 Do you take ownership of your codebase?

If you want to make a greater impact, look at how you work.

When you fix a bug, do you search the codebase for the same bug elsewhere?

When your build pipeline is slow, or you have flaky tests, do you fix them or live with them, complaining while nothing changes?