# Thinking Like an Engineer Does Not Mean Becoming the Engineer

- Link: https://opsquillstudio.com/notes/thinking-like-an-engineer-does-not-mean-becoming-the-engineer/
- Published: 2026-10-14T19:30:00+08:00
- Author: OpsQuill Studio

There is a sentence I have been thinking about since moving into a new working environment:

**“I need you to think like an engineer.”**

My first reaction was fairly simple.

That makes sense.

A good structural drafter should not be someone who merely moves lines around a 
screen because somebody marked up a PDF.

We should understand what we are drawing.

We should question details that do not make sense. We should notice when something
conflicts with another drawing. We should think about whether a detail can actually
be built, whether dimensions agree, whether information is missing, and whether 
what appears on one sheet is consistent with what appears somewhere else.

Experience should make us better at seeing those things.

So I do not disagree with the idea of a drafter thinking like an engineer.

What I am beginning to question is what happens when that expectation becomes unclear.

Because there is a difference between **thinking about the engineering** and quietly
becoming responsible for **deciding the engineering**.

And that boundary matters.

## A drawing is not just lines

Drafting has never really been just drawing.

Perhaps it looks that way from outside the profession.

Give the drafter a sketch. Put it into CAD or Revit. Add dimensions. Add notes. 
Print the drawing. Done.

Anyone who has worked seriously in engineering documentation knows it does not work
like that.

A drawing is an interpretation of design intent.

Some information comes from calculations. Some comes from sketches. Some comes from
discussions. Some comes from previous details. Some comes from architectural drawings,
specifications, standards or site conditions.

And quite often, some information is simply missing.

That is where experience starts doing useful work.

A drafter who understands nothing about the engineering behind the drawing may faithfully
produce something that looks beautiful and still makes absolutely no sense.

So yes, I believe drafters should develop engineering awareness.

I want to know why something is detailed a certain way.

I want to understand how the structure behaves.

I want enough technical knowledge to notice that something looks wrong before a 
contractor discovers it on site.

That kind of thinking improves documentation.

But understanding a decision is not necessarily the same as owning the decision.

## Documenting the decision and making the decision are different jobs

This distinction sounds obvious until you are actually working on a project.

Suppose I receive information for a structural detail and something is incomplete.

Experience may tell me what the missing information probably should be.

I may have detailed something similar dozens of times before.

I can suggest an arrangement.

I can show the engineer an example.

I can ask whether a previous detail should apply.

I can identify the inconsistency and perhaps even explain why I think one option
makes more sense than another.

All of that is useful.

In fact, I would argue that this is exactly where an experienced drafter becomes
valuable.

But there is still an important question:

**Who decides?**

If the missing information affects the actual engineering design, somebody needs
to consciously own that decision.

Otherwise something strange begins to happen.

A suggestion becomes an assumption.

The assumption becomes a drawing.

The drawing becomes a construction document.

And eventually everyone forgets where the decision actually came from.

That is not good collaboration.

That is responsibility disappearing somewhere between conversations.

## “Use your judgment” needs a boundary

Experienced people are often told to use their judgment.

Normally, that is a compliment.

Nobody wants an experienced drafter asking the engineer whether a text note should
move five millimetres to the left.

There are hundreds of documentation decisions that should not require engineering
approval.

Drawing layout, presentation, coordination, annotation, clarity, consistency and
many detailing conventions are areas where experienced drafters should be capable
of working independently.

There are also technical situations where experience allows us to raise better questions
instead of simply waiting for instructions.

But not every unanswered question is a drafting question.

That is the distinction I am learning to pay more attention to.

When an unresolved issue begins affecting structural behaviour, design assumptions,
member requirements, load transfer, reinforcement requirements or some other engineering
outcome, “use your judgment” starts carrying a very different meaning.

Maybe my judgment can contribute.

Maybe I can offer an option based on experience.

But the final technical direction needs a clear owner.

The exact professional and legal boundaries vary depending on the project, jurisdiction,
registration requirements and how work has been delegated or supervised. But the
broader principle seems much simpler:

**Authority and accountability should travel together.**

If someone has authority to make the engineering decision, that person should also
be identifiable as the person responsible for it.

## Unclear standards make unclear boundaries worse

This has become more noticeable to me because I have also moved from a workplace
where standards were already mature into one where some practices are still developing.

In an established system, many small decisions have already been made for you.

There is a standard detail.

There is a typical note.

There is a checking process.

There is an accepted way of documenting something.

You may not even notice how many engineering and documentation decisions have quietly
been embedded into those standards over the years.

Then you move somewhere where the same systems are not yet as stable.

Suddenly the absence of a standard creates a decision.

What detail should we use?

How should this be shown?

What information belongs here?

Is this merely a drafting convention, or does it affect the engineering intent?

Who decides?

That last question becomes surprisingly important.

The problem is not necessarily that anyone is doing something wrong.

Sometimes the organisation simply has not yet developed enough consistent processes
to make the responsibility boundary obvious.

And when the process is unclear, people compensate with experience.

That can work.

Until two people assume the other person was responsible for the same decision.

## “You help me, I help you” is still true

The engineer I work with said something that I actually agree with:

He helps me, and I help him.

That is exactly how a good engineering team should work.

An experienced drafter should reduce the engineer’s workload.

I should be able to organise information clearly, identify conflicts, improve constructability
of the documentation, maintain consistency, notice missing information and sometimes
suggest solutions before a problem becomes larger.

If every tiny drafting question has to travel back to the engineer, then I am not
really helping very much.

At the same time, the engineer helps me by making the engineering intent clear.

When a decision genuinely requires engineering judgment, I need enough direction
to document that decision confidently.

That relationship should not be engineer versus drafter.

It should be engineer **and** drafter.

But teamwork does not require pretending our responsibilities are identical.

In fact, I think good collaboration depends on understanding where they are different.

The best teams can overlap in **understanding** without becoming confused about **
accountability**.

## Maybe the pressure is partly useful

I also have to challenge my own reaction.

Perhaps being uncomfortable with the expectation to “think like an engineer” is 
partly because I am being pushed into unfamiliar territory again.

That does not automatically make the expectation unreasonable.

Maybe the engineer sees experience in me and expects more initiative.

Maybe I am being encouraged to develop a deeper understanding of the engineering
behind my drawings.

Maybe part of becoming a better drafter is learning to anticipate questions instead
of merely responding to markups.

Those are useful challenges.

I do not want professional boundaries to become an excuse for refusing to think.

“I am only the drafter” can become just as dangerous as expecting the drafter to
design everything.

One avoids responsibility entirely.

The other transfers responsibility too casually.

There has to be something healthier in between.

For me, that middle ground looks something like this:

Think deeply about the work.

Understand as much of the engineering as possible.

Question things that do not make sense.

Offer experience.

Suggest alternatives.

Anticipate coordination problems.

Make the drawing clearer than the information you received.

But when the question becomes a genuine design decision, make the decision visible
and put it in front of the person who has the authority to make it.

That is not refusing to help.

That is helping without allowing responsibility to become ambiguous.

## Boundaries are not walls

Perhaps that is the part I have been missing.

Professional boundaries sometimes sound negative.

“This is my job. That is your job.”

But a good boundary is not necessarily a wall.

Sometimes it is simply an interface.

It tells two people how their responsibilities connect.

Engineering and drafting probably work best that way.

The engineer should not have to dictate every line.

The drafter should not have to guess every design decision.

Somewhere between those two extremes is a working relationship where both people
contribute what they know, question each other when necessary, and still understand
who owns which decision.

I am still learning what that boundary looks like in my new environment.

Perhaps the answer will become clearer as I understand the engineer better, understand
the company’s developing standards better, and the engineer understands what experience
I can bring to the work.

But I think I have already changed the question I am asking myself.

It is no longer:

**“Should a drafter think like an engineer?”**

Of course we should think technically.

The better question is:

**“How far should that thinking become authority?”**

My answer, at least for now, is this:

As far as necessary to understand the work, improve it, question it and help the
team make better decisions.

But not so far that nobody can tell who actually made the design decision.

Because good engineering documentation needs collaboration.

It also needs something much less exciting, but probably just as important:

**clear ownership of decisions.**

### Share this:

 * [  X ](https://opsquillstudio.com/notes/thinking-like-an-engineer-does-not-mean-becoming-the-engineer/?share=twitter)
 * [  Facebook ](https://opsquillstudio.com/notes/thinking-like-an-engineer-does-not-mean-becoming-the-engineer/?share=facebook)
 * [  Telegram ](https://opsquillstudio.com/notes/thinking-like-an-engineer-does-not-mean-becoming-the-engineer/?share=telegram)
 * [  Threads ](https://opsquillstudio.com/notes/thinking-like-an-engineer-does-not-mean-becoming-the-engineer/?share=threads)
 * [  Email ](https://opsquillstudio.com/notes/thinking-like-an-engineer-does-not-mean-becoming-the-engineer/?subject=%5BShared%20Post%5D%20Thinking%20Like%20an%20Engineer%20Does%20Not%20Mean%20Becoming%20the%20Engineer&body=https%3A%2F%2Fopsquillstudio.com%2Fnotes%2Fthinking-like-an-engineer-does-not-mean-becoming-the-engineer%2F&share=email)

### Like this:

Like Loading…