Two Years, Ten Lessons: Why I’m Writing This
By Darryl Brown
In 1993, I graduated with a Master’s degree in Artificial Intelligence. At the time, that was a great way to confuse people at parties. AI was an academic curiosity, not an industry. Nobody was hiring for it. I pivoted into traditional software development. I spent the next two decades working through many startups, including running my own web design and development company. I eventually landed at TRU Solutions ten years ago as a developer. I became Director of Software, and two years ago I became CTO.
I’m writing this series for two reasons.
The first is to learn from what we have done. Reflecting on what our team has accomplished over the last two years — writing it down, putting it in order — is how I hope to not lose sight of how we did it. The practices that changed everything could quietly become the new normal, and the thinking behind them fades. I don’t want that to happen. So I’m writing it down.
The second is a small act of gratitude. This industry has given me an extraordinary career over thirty-five years. Hopefully, something in these posts will prove useful to someone in that journey — a developer who wants to lead, a new CTO figuring out the role, someone trying to understand why their team isn’t moving the way they want it to.
Ten posts. Ten lessons. Each one is about something specific: how we simplified our release pipeline, how we redesigned our process to reduce friction, how we approached automation, AI adoption, quality engineering, and more. As I’ve reflected on all of it, I’ve come to think there’s a single thread running through every one of those changes.
We started asking why.
I should mention that I had an unfair advantage in recognizing that thread. My partner (and fiancée) works as an operations improvement consultant and is a LEAN manufacturing expert. As I described changes we were making, she would help me understand how they connected to LEAN principles — small batch sizes, eliminating waste, continuous improvement, creating safety to experiment and fail. What I was doing intuitively, she could validate and name. I got regular free consulting from someone with deep expertise in the subject, and the combination of her knowledge and my instincts turned out to be a great combination. The LEAN principles didn’t drive our transformation from the top down — but looking back, they were present in almost every decision we made. I’ll point to those connections throughout the series.
The other significant influence on my thinking was Simon Sinek. I’ve read several of his books, but Leaders Eat Last struck the deepest chord. His human-centric approach to leadership — the idea that a leader’s primary job is to create an environment where people feel safe, valued, and able to do their best work — helped me find my own why as a CTO. And my why turns out to have little to do with technology. It is about my people and my company. It is about following the principles I have come to believe in deeply — protecting and lifting up the people I work with, excelling together as a team, and serving one another in this shared endeavor – capitalism as a force for good. The technology is the vehicle. The people are the point. You’ll see Sinek’s influence throughout this series, particularly in the posts about culture, safety, and leadership.
And it turns out that leading with people in mind and leading with curiosity are not separate things. The same orientation that asks ‘what does my team need?’ also asks ‘why are we doing it this way?’ Both questions start from the same place — a refusal to accept the status quo without understanding it.
Why are we walking code through five separate environments before it reaches production? Why does this ticket prescribe how something should be built before we’ve understood what problem we’re actually solving? Why can’t releasing software be as simple as merging to a branch? These questions, asked genuinely, repeatedly, at every level of the team, turn out to be a powerful tool. It surfaces assumptions. It exposes complexity that exists out of habit rather than necessity. It creates the conditions for people to propose better answers.
I don’t think I would have named “ask why” as our guiding philosophy while we were in the middle of it. I was applying it deliberately in specific moments without recognizing it as the theme. It took stepping back to write this series to see it clearly. Which is, I suppose, its own small argument for reflection
If any of this feels familiar, I’ll walk through exactly how we applied it in the posts that follow.
The posts that follow are about what we did and, more importantly, how we did it. The what is interesting. The how is what’s actually useful. I hope something here earns its place in your thinking.
