Title: From Firefighter to Architect Author: Nikki Dulas Date: June 22, 2026 Category: Operations / Leadership

There is a certain kind of satisfaction that comes from putting out fires. A problem pops up, something is unclear, a deadline is at risk, a customer needs an answer, a process breaks, or a teammate needs help, and suddenly, you are in motion. You jump in, troubleshoot, make the call, clear the blocker, calm the room, and keep things moving.
That kind of work matters. In operations and leadership, it is often part of the job. Most teams need someone who can step into the mess, connect the dots, and help get things back on track. I have often been that person. But over time, I have learned that constantly putting out fires can create a trap. You can become so good at reacting that you never get enough space to redesign what keeps catching fire.
That is the shift I have been thinking about lately: moving from firefighter to architect. It is the difference between fixing what is urgent and studying what is repeatable. Both roles are necessary, but if I spend all my time firefighting, I may be helping in the moment while quietly allowing the same problems to come back again and again.
In business operations, the fires are not always dramatic. Sometimes they look like the same question being asked repeatedly because documentation is missing, outdated, or hard to find. Sometimes they look like decisions stalling because ownership is unclear. Sometimes they look like a meeting that keeps happening simply because it has always been on the calendar. Sometimes they look like a manual workaround that solved one urgent issue and somehow became the process. And sometimes they look like a leader becoming the default answer because it is faster to ask one person than to build clarity into the system.
At first, these things may seem small. But small fires have a way of becoming the background noise of a company. They steal focus, create drag, and make smart people spend too much energy navigating confusion instead of doing the work they were hired to do. For me, the harder part is pausing long enough to ask what the chaos is trying to show me.
That might mean building a better process, clarifying ownership, documenting the answer, creating a decision framework, or simplifying a workflow that has become harder than it needs to be. It might also mean admitting that the real problem is not the fire itself, but the fact that the team has accepted fire drills as normal.
This shift is not always easy. Firefighting feels productive because it is visible. You can point to the thing you fixed, feel the urgency, and see the immediate relief. Architecture is quieter. It requires patience. It may not create instant applause. It often means asking questions before offering answers. It means resisting the urge to solve every problem yourself so the system can become stronger without you at the center of everything.
That part can be uncomfortable, especially if you are used to being helpful. But being helpful does not always mean being the one who jumps in fastest. Sometimes the most helpful thing you can do is slow down and build something that prevents the next interruption. A template. A checklist. A clearer handoff. A cleaner workflow. A shared definition of done. A better meeting structure. A documented decision. A conversation about ownership. A boundary around what truly requires escalation.
None of these things feel especially exciting in the moment, but they make the next day a little easier. And over time, that matters.
The first time may be an exception. The second time may be a coincidence. The third time is probably a system asking to be redesigned.
The goal is not to eliminate every surprise. Business is always changing, people are always learning, and new problems will always appear. The goal is to stop treating repeat problems like one-off emergencies. It is to protect time for the kind of work that makes tomorrow easier than today.
Ultimately, the shift from firefighter to architect is about moving from being the person who can fix everything to helping build an environment where fewer things need to be fixed in the first place. One keeps the lights on. The other improves the wiring. And I am learning that strong operations require both, but the real growth is knowing which role the moment actually needs.
