At the start of my career, my role was simple; I built systems that solution architects had designed. I didn’t need to think too hard about the bigger picture as my job was to build my part well.

As I’ve grown in my career however, that’s started to change.

Now I’m much closer to the design side of things, and that’s forced a shift in how I think. I’m no longer asking myself “how do I build this?”, but “what should we actually build?”, “what does the whole system need to look like?” and “what does the client actually need?”. That’s been a bigger mindset change than I expected.

These are some of the lessons I’ve learned as I’ve shifted into a more delivery-centred mindset.

The Power of Asking Questions

Earlier on, if an architectural design was put in front of me, I’d mostly just accept it and focus on implementing it as well as I could.

As I moved closer to delivery and design, that approach stopped being sufficient.

A big part of my mindset shift has been learning to ask better questions. That includes questions about the infrastructure itself and why certain architectural decisions were made, as well as questions that help uncover what a client actually needs.

Questions like:

• What problem is this meant to solve?
• What constraints led us here?
• What assumptions are we making?

The same applies when talking to clients. Sometimes what they ask for is a solution they have already decided on, rather than one that solves the problem they’re trying to fix. Asking clarifying questions helps surface that underlying need without making anyone feel challenged or talked down to. It also reduces the risk of delivering something that doesn’t truly solve the problem.

Architecture Is Really Just a Trail of Decisions

I used to think of architecture as a static thing, something that you draw up, agree on, and then implement. In reality, even if you start with a diagram or a high-level design, the real architecture is shaped over time by lots of smaller choices:

• A service that seemed right at the start turns out not to quite fit
• A deadline forces a simpler approach than originally planned
• A “temporary” workaround sticks around longer than expected

Each of these decisions moves the system slightly, so that by the end of the project, what’s running in production is the result of all those choices combined, not just the original design.

That’s where my idea for an architectural diary came from.

Instead of trying to perfectly document an architecture, I write down key decisions as they happen. What we decided, what other options we talked about, and why we landed where we did. This has changed how I think about solution architecture by helping me focus on making sensible calls with the information available at the time.

The diary preserves context, which is usually the first thing to get lost once a project ends.

Don’t Let Perfect Be The Enemy of Good

As an engineer, my scope tended to be quite narrow as I’d only focus on the thing that was in front of me. How clean is the solution? Can it be more elegant or more scalable?

With a delivery mindset, those questions haven’t disappeared, but now they sit alongside others.

I now spend more time considering trade-offs. Is this good enough to get us live by the deadline? Is the extra complexity actually worth it? Does this decision help or slow down delivery? In many cases, the most technically impressive option is not the one that best serves the project.

That took some adjustment. Letting go of perfect solutions in favour of pragmatic ones feels wrong when you’ve spent a long time being rewarded for how technically neat your solution is. But once I started focusing on outcomes rather than individual components, I realised that architecture often involves deciding which problems are worth solving now, and which ones can wait.

Take Initiative

One of the biggest mindset changes for me has been realising that delivery doesn’t reward waiting.

As an engineer, it was easy to wait for clear requirements or explicit instructions. Working in delivery, that often means progress stalls.

Taking initiative means proposing options and moving conversations forward even when things are unclear. It can be as simple as saying, “This is what I’m thinking, does that align with what you need?” This has pushed me outside my comfort zone, but it’s also where I’ve seen the most growth. Delivery and architecture both involve uncertainty, and initiative is what keeps progress moving.

Shifting from an engineer mindset to a delivery mindset has been less about changing roles and more about changing how I think. Asking better questions, taking initiative, and capturing decisions as they happen has helped me learn from real projects, not just complete them. Over time, that has shaped how I approach solution architecture and delivery as a whole.