What are we actually doing as engineers?

2026-04-14T08:30:00.000Z

Every engineer, at some point, has to turn uncertainty into a decision — and own the consequences.

We like to think we’re implementing requirements. Following a plan. Building what’s been defined.

But most of the time, that’s not reality.

We’re asked to build things that don’t yet exist - to meet needs that aren’t always fully understood, with constraints that only become clear over time.

And we’re expected to do it within the time and budget pressures set by the business.

There isn’t a single “correct” solution waiting to be found. There are options.

• Trade-offs.
• Unknowns.

And someone has to decide. So we:

• Interpret what’s actually needed (see my previous post on requirements translation)
• Bring clarity to something that is initially unclear
• Explore possible approaches
• Weigh costs, risks, and consequences and then choose a direction all while the picture is still incomplete.

That’s the job.

Not just building the system but deciding what the system should be, and what it shouldn’t.

Because every decision shapes the outcome:

• What works
• What breaks
• What it costs to change later

And those decisions don’t come with certainty.

They come with risk.

And they come with accountability.

We can delegate the work. We can’t delegate the responsibility - not even to AI.

We don’t get to say “the requirements were wrong” or “there was no perfect answer”.

We still carry the responsibility for what gets built.

That’s what makes engineering hard.

Not the code but the judgement.

And the fact that we own the consequences.

(And if you’ve read my earlier post on clarity - this is where it really matters.)