DEV Community

Cover image for Scaling Engineers Doesn't Mean Scaling Work
Sultan Fariz
Sultan Fariz

Posted on

Scaling Engineers Doesn't Mean Scaling Work

Been thinking about this for a while, so lemme just put it out there.

The Observation: Scaling People vs Scaling Work

Started from an idea about developers. Instead of keeping devs locked into frontend or backend only, we expand their scope. They become more general, but still keep their main strength.

With coding agents, this makes even more sense. Tasks that use to be blocked can now get done faster. More people can help. Work moves quicker. In short, we scale people.

And this part? It works well.

But then I started thinking deeper, and noticed another layer. Kinda interesting actually.

When we scale people, the work itself don't scale in the same way.

We got more people who can execute now, but the number of ideas and problems still depends on the product team. Their size stays the same. Coding agents help us build faster, yeah, but they don't create new product ideas or new directions.

So you end up with all these people ready to work, but the amount of meaningful work? It stays limited.

Not complaining or anything. Just an observation.

The Two Directions

From there, I started thinking about two possible directions.

1. Engineers Doing More Than Technical Work

What if engineers ain't limited to just technical tasks?

Today, a lot of technical stuff can be helped by AI. Writing code? Not the hardest part anymore. Understanding the problem is.

Some companies like OpenAI and Palantir got this role called forward deployed engineer. These engineers do stuff like:

  • talk directly with users or clients
  • learn the real pain points
  • help define the problem
  • shape the solution
  • build prototypes
  • iterate until it actually works

Might not fit perfectly in a small startup. But the idea behind it? Feels important.

Engineers are often really close to the product. Sometimes they see problems or improvements just naturally. But these ideas often stop early, not cause they bad, just cause there no clear path for them.

2. Faster Iteration Brings More Work

Second thought I had is about iteration speed.

When we iterate faster, feedback comes faster. That feedback creates more things to fix and improve. So faster iteration actually creates more work. Kinda wild right?

For example, instead of starting with design files only, what if we just start with a simple working web prototype. Something clickable and messy, but real.

I think software is becoming more disposable. With coding agents, building prototypes is cheap. Throwing them away ain't a big cost no more.

Real prototypes create stronger feedback. People react more honestly. That feedback turns into new tasks and new ideas.


I don't really got a strong conclusion here. Just thinking out loud.

As execution becomes faster and cheaper, the real challenge moves earlier:

  • Finding the right problems
  • Creating fast feedback
  • Letting more people help shape the work

Scaling people? That's possible.

Scaling meaningful work though? That the harder part.

Fin.

Top comments (0)