Hey Reader,

Early in my career, I told my boss a job would take two days.

It took five.

The worst part wasn’t being wrong. It was that when he asked what happened, I had nothing.

I couldn’t tell him whether I had been slow, whether I had spent half a day learning something new, whether I had missed something and redone the work, or whether the drawings had changed.

It all just felt like “design time.”

Something nobody explained to me until much later was that when your boss asks how long a job will take, they usually already have a number the job needs to fit within.

The fee has normally been agreed with the client before you touch the project.

Say the fee is $10,000.

Drafting uses $2,000, which leaves $8,000 for engineering.

At an internal rate of $200 an hour, the business has roughly 40 engineering hours to deliver the job.

That is where the deadline comes from. It was never completely arbitrary.

So I started thinking about how to track this properly.

Not with traditional timesheets. I’ve never managed to keep one of those going for more than three days.

The main idea is that you need to track two things, not one:

1. What you were working on, such as the roof, walls, bracing or footings.
2. What kind of work you were doing, such as designing, documenting, checking, redoing something or looking something up.

Once you organise the hours that way, they start falling into four broader categories:

Design work is the job itself.

Learning is the early-career tax. It isn’t wasted time, but it should reduce as you repeat similar projects.

Internal friction is rework, distraction and unnecessary switching between tasks. This is the fixable leak.

External changes aren’t necessarily your fault, but you still need to see them separately.

Two jobs can both take 40 hours and tell completely different stories.

One might have been 40 hours of clean design, checking and documentation.

The other might have included 15 hours of rework that you never identified properly.

Here’s what I’d suggest doing this week:

Pick one small project you’re about to start.

Write down how many hours you think it will take.

Then track it honestly until it is issued. Include the research, emails, interruptions, changes from outside and anything else that consumed time.

At the end, compare your estimate with the actual hours.

There will probably be at least one surprise.

To be clear, this isn’t about rushing the engineering.

Proper checking and documentation are never wasted time.

It’s about understanding where the hours went so that the next time someone asks how long a job will take, you’re not guessing.

And once you eventually start pricing your own work, this information becomes even more valuable.

Cheers,

Gabriel

P.S. I think this process is much easier to demonstrate than explain in an email, so I’m running through the system with BengLab members tonight at 6 pm Brisbane time. I even built a simple AI tool to make the tracking easier. Regardless of whether you’re inside BengLab, I genuinely think every engineer should test this on at least two or three different project types.