I opened the sliding door to a meeting room with a long white rectangular table and a TV at the end of it. The table was too big for the room, I had to squeeze through a maze of chairs just to get to my seat. It was my first team meeting at my first corporate engineering job. So naturally, I was the first to arrive.
But soon after, the rest of the team started streaming in. They moved chairs around, shuffled past the chairs. You could tell how long they’d been there just by how they went through the room. I was new, so I just sat quietly, making small talk.
The last to arrive was the team leader, Rick. He broke the quiet conversations with a brisk, “Alright, team, let’s get started.” He turned on the TV, connected his computer, and began introducing me to the rest of the group. After that, he moved straight into progress updates. Like clockwork, everyone around the table shared what they were working on. When it came to me, Rick said, “I think we can give Braden the section property calculator.”
Trying to sound calm, I deepened my voice and replied with what I hoped was a cool and casual “Sure, sounds good.” I think the sweat on the table from my palms betrayed that image. As Rick began explaining the task in more detail, I started nodding. Maybe a little too much because he ended with, “Don’t worry, I’ll sit with you later to iron out the specifics.”
The meeting wrapped up, and as we all left the room, I tried to match everyone’s pace, not too fast, not too slow. Even I could tell I was trying too hard to fit in. Rick followed me back to my desk and started laying out the requirements for the calculator. But even before he finished, I was confident. Section property calculations are something you learn in your first year of university. This was going to be easy.
The first two weeks were a blur of code and quick wins. I got all the simple and common shapes working. But calculating custom shapes was proving to me a nightmare. Two weeks turned into three, then four. Week after week, Rick patiently asked for updates at every meeting and all I could say was, “I’m working on it.” I could feel the disappointment in the air.
I started staying late, working nights, doing everything I could to make up for it. I wasn’t just some new graduate, I’d finished top of my class. A section calculator wasn’t going to stop me. But in the end, it took me three months to produce something and even then, I wasn’t happy with it. Rick told me that we needed to test it before actually using it.
So, I handed my duct-taped code over to John, our designated tester, and sat beside him as he ran it for the first time. At least it didn't fail instantly, it ran for a whole thirty seconds. My heart sank, but honestly, I saw it coming. All those late nights, I’d had this creeping feeling that I was building a sandcastle on top of loose sand. I didn't fell in control over the work at all.
It took three more major refactors, help from three colleagues, and six more months before Rick made the call to abandon the tool altogether. It turned out to be a far harder problem than we all thought. It wasn’t just about translating math into code, I had to create a library of geometric shape functions, design a user interface for custom shapes, integrate a third-party mesher, add a reporting library... you get the idea. It was much harder than we thought.
Working Harder Wasn’t the Answer
Sitting here now, years removed from that project, I now know that working harder was never the answer. What we really needed was a better approach. I dove straight in without pausing to understand the problem. Even everyone on the team assumed that more effort would bring better results.
It’s a common trap, not just for junior engineers, but for entire teams and companies. You start with a simple idea. You assume it’s a small task. And when things go wrong, you just throw more people or time at it, hoping that will fix things.
But more effort isn’t always the answer. You can't just beat a problem into submission. Sometimes what’s needed is space. Space to ask “Is this even the right problem to solve?” without feeling like your job is on the line.
Back then, as a new graduate, I felt a lot of pressure to prove my value. I thought if I didn’t get this project right, they’d regret hiring me. And the only way I knew how to prove myself was by putting in more time.
The Value of Stepping Back
I don’t regret the effort I put in. I learned a lot. But I do wish someone had stepped back earlier. No one was forcing us to build this tool. Any pressure that I felt was all self-inflicted.
That kind of pause might have helped us ask better questions:
If this was easy, why hasn't anyone done this already ?
Do we need to build supporting frameworks just to make this work?
Can we make a small prototype first to test the idea?
It’s hard to step back when you’re under pressure. But that’s often when it’s most important. Sometimes we’re so focused on proving ourselves that we forget to consider whether we’re solving the right problem at all.
A Lesson That Stays With Me
The hardest part of that project wasn’t the technical complexity (But it was pretty hard too). It was learning that effort alone isn’t enough. That I couldn't just brute force my way through every problem, I needed to step back and re-align myself.
But, in the corporate world, stepping back isn’t something we’re often encouraged to do. We rarely test things. We just think that if we work hard enough, we will solve every problem. So stepping back is a hard thing to do. You have project pressures and a general culture that doesn't encourage it, yet it's probably the most important skill to learn.
It's a skill I am trying to get better at. My default has always been to double down, work harder, and push my way through. But I’m learning that when things feel overwhelming, the most valuable thing I can do is to just step back.
Thank you for taking the time to read this. If you’ve enjoyed it, consider subscribing and sharing this with a friend if you think they might like it too. When you subscribe, you’ll also get a gift from me as a thank you.