Tactics to Strategy: Stop Doing, Start Leading
By Darryl Brown
When I moved from Director of Software to CTO, two things changed that fundamentally shaped how I operated.
The first was accountability. For the first time, there was no one above me in the technical organization to escalate to, defer to, or share the weight with. My peer executives provided much needed guidance on people issues, budgets, and other enterprise-wide topics, but when it came to technical challenges, I owned them. That was a clarifying and somewhat uncomfortable realization.
The second was how I spent my time. I stopped doing the work and started thinking about it instead. About the team. About what we were trying to accomplish. About what should matter to us and why. I was no longer expected to write code regularly, and that freed up space to think strategically in a way I had never done before.
I did actually receive an instruction book of sorts — about twenty pages describing the recurring tasks, daily rhythms, and monthly activities of my predecessor. But alongside it came something as valuable: the explicit direction that I should make the role my own. The basics needed to get done, but how I did them was up to me.
What I inherited was a description of activities. What I had to figure out for myself was the purpose behind them. This was the early days of asking “Why?” — a habit that, as you’ll see throughout this series, turned out to shape almost everything we did.
Before this role, I’d been CTO at smaller companies — teams of ten or fewer — where the job looked a lot like my directors’ jobs do now: part strategy, part getting the work done. I know what it feels like to be pulled in both directions simultaneously, to have a meeting about team structure immediately followed by a problem that needs fixing. That experience gave me empathy for what I was asking of them.
That transition, for me, happened because I embraced it. My directors didn’t have the same choice — and in my view, they have the harder job.
They manage their disciplines, contribute to the daily work, and were now being asked to think strategically about their domains at the same time. The immediate, visible work never stops demanding their attention. Strategic thinking, by contrast, doesn’t produce immediate, visible results. It’s exactly the kind of important-but-not-urgent work that gets crowded out — and without a conscious effort to protect time for it, it will always lose to the urgency of the day.
Some of my directors were already in their roles before I became CTO, and their expectations had been shaped around tactical execution: doing the work, managing the daily flow, keeping things moving. When I began asking them to step back and think strategically about their domains, I was effectively changing their job description on them. I’m certain that was uncomfortable.
We set strategic goals together in our one on ones. But in some cases those goals weren’t getting the time they needed — the daily work kept winning. In one case I eventually had a more direct conversation. I suggested to this director that perhaps they were not in the right role. I said it without accusation and with genuine openness — they did excellent work in what they were accomplishing, but it wasn’t strategic. I was open, but I also said it plainly: their first priority was being a director, not doing the work. If that meant some tasks took longer and some schedules slipped, that was a consequence I was willing to accept. What I was not willing to accept was that strategic thinking kept getting crowded out by tactical urgency.
That was a tricky conversation for me. In the past, I’ve had a hard time saying things that could be construed as negative to people who work for me. Over time, and in this role in particular, I’ve come to see that impulse as ultimately unkind. The people who work with me deserve my honest viewpoint. That is the most compassionate and fair thing I can offer them, even when it’s awkward or causes discomfort in the moment. Saying “we might have you in the wrong role” is not the same as saying “you are doing terribly.” It’s an honest assessment that gives someone the information they need to make a real choice.
This person wanted to give the strategic work a serious try. And something shifted around this time.
They began making time for strategic goals. Our one on ones became regular reviews of those goals rather than status updates on daily work. They started keeping a running list of ideas — smaller items that could be worked on independently, and larger ones that fed into their annual goals. That list became the actual fodder for their strategic projects, not an aspirational document that sat untouched.
But the biggest change was harder to measure and more important than any list. They started asking why.
Why are we doing weekly status reports for this customer by hand? Why are we collecting detailed time tracking data for every minute of everyone’s day? Those questions , asked genuinely, about things that had always just been done, are exactly what a director should be asking. They are also, not coincidentally, the same questions that drove most of the transformation described throughout this series. The “ask why” discipline doesn’t just apply to software pipelines and process automation. It applies to every layer of how an organization operates. When a director starts asking it about their own domain, the leverage is significant.
Each director began spending time asking a different category of question than they had before. Not “What needs to be done today” but “What is causing stress on my team?” Not “How do I move this task forward” but “What friction keeps this task from moving forward on its own?” Not “Did we ship this week?” but “Are we doing better than last week?”
Those questions sound simple. They’re not easy to make time for, and they don’t get rewarded in the short term. But they are where the real leverage lives. The changes described in most of the other posts in this series — the process redesign, the automation work, the sprint structure, the shift to quality engineering — all of them started with someone stepping back and asking one of those questions seriously.
In Post 4 I wrote about the practice of asking “why” five times to reach the root cause of a problem rather than treating the symptom. A director asking “Why are we doing weekly status reports for this customer?” is making exactly the same intellectual move as an engineer asking “Why does this step exist in our process?” The question is the same. The leverage is just different. When that habit takes hold at the leadership level, it doesn’t just improve a workflow. It changes how an entire domain is managed.
Patrick Lencioni’s “Five Dysfunctions of a Team” identifies absence of accountability and lack of commitment as two of the five ways teams fail. Looking back at that director conversation, I can see both at play. and in a specific sequence. The absence of accountability was on me. I hadn’t held my director to the strategic expectations of the role clearly enough until that conversation. The lack of commitment was on him — he hadn’t fully committed to the director role while the pull of the daily work remained so strong. What Lencioni’s model makes clear, and what that conversation confirmed, is that the two are connected. Commitment rarely precedes accountability. Once I held the expectation plainly, the commitment followed.
This is one of the areas where we are still actively working. The tension between doing and leading is real and ongoing. What I’m most proud of is that the strategic questions now have a permanent place on our agenda. We’ve created enough space to think about the organization deliberately, rather than letting it simply happen while we’re busy doing everything else.
If your team rarely feels done, it’s worth asking how work is being structured.
Up next I will talk about one of the harder lessons of the last two years. I was realizing that my value as a leader wasn’t in solving problems. It was in making sure problems got solved. The next post is about what that distinction looks like in practice.
