Listen First: I Didn’t Have the Answers Yet

By Darryl Brown

I became CTO in January 2024. My first major act was to call a team retreat and spend most of it listening. It was the only honest option I had.

I’d been with the team for seven years, first as a developer, then as Director of Software. I knew the people, the product, the technical debt. What I didn’t know yet was what the view looked like from the CTO seat. And I’d learned enough in my first month to know: I didn’t have the information yet to lead with answers.

So I came in with a strong sense of trust in my team, and I listened with an open mind.

I didn’t conjure that approach from thin air. My CEO and the executive team gave me genuine latitude to figure out what needed doing and do it. The trust I was trying to extend to my team started with them.

The retreat happened at the end of my first thirty days. I asked the team to come with open minds and honest assessments of our process, our pipeline, our ways of working. I also conveyed that I was willing to allocate team resources to process and infrastructure improvement. This is not easy as we all know. We, like all teams everywhere, have an unending amount of work on our docket. The team needed to believe that I was willing to commit resources to making these improvements.

That commitment is harder than it sounds. Resources take away from customer deliverables, which drive revenue, which keeps us in business. Stephen Covey writes in “First Things First” about the difference between what is urgent and what is important — and the tendency of urgent work to crowd out important work indefinitely. Process improvement is almost never urgent. There is always a customer deliverable that feels more pressing. And so process improvement gets shunted, year after year, until the cost of not improving becomes impossible to ignore. We had done that. I felt the payoff potential was worth the investment, and it was the kind of team I wanted to be a part of — experimental, improving, dynamic.

The good stuff started to happen after I stopped talking. They had ideas. Not mild suggestions but real, considered, sometimes radical ideas about how things could be different. They’d been thinking about this for a while. What they hadn’t had was a chance to believe these ideas might come to fruition.

Organizations develop rhythms over time. Ways of working become familiar, and familiar things become hard to question, not because anyone decides they’re untouchable, but because that’s just how systems tend to calcify. The team wasn’t stuck because they lacked answers. They were waiting for the conditions to share them — to believe change was possible. I think about Simon Sinek’s concept of the Circle of Safety here — the idea that people will only take creative risks when they are in a trusting environment.

One way we incorporate this trust is in how we frame management decisions. We first present them as proposals to our team and ask for feedback. Occasionally someone raises a concern, and in our experience, those concerns are typically valid. When that happens, we try to iterate in the moment. If a clear path forward doesn’t emerge right there, we form a working group to explore options — a diverse group with the most useful perspective on the problem. The idea comes back revised. 

We extended this same approach beyond the development team. Our development organization had fallen into a habit of making decisions and announcing them — decisions that affect other departments: operations, sales, customer success. There were probably good reasons that pattern existed before I arrived, but it wasn’t serving the company well anymore. So we tried to apply the same principle outward: treat cross-departmental changes as proposals too, invite the people affected to weigh in, and iterate when useful. It made for slower decisions occasionally. It made for much better ones, and facilitated buy-in from others since they had participated. LEAN practitioners call this respect for people — the principle that the people closest to a process have the most valuable insight into how it should change. We just extended that respect beyond our own team.

That process — propose, invite objection, iterate — isn’t a formal policy. It’s a habit of framing. It changed the dynamic from a “here is what we are doing” to “what do you think of this?” That shift in framing changed what our meetings felt like. People who had been recipients of decisions became participants in them, and the quality of what we built together reflects that.

I’ll write more about what the retreat’s commitments looked like in practice in my next post. 

Spoiler alert: the ideas for specific transformations were not mine. They came from the engineers who had built and been living inside the system. My job was to create the right conditions for the team to generate the answers.

The results were extremely positive. The increase in productivity was something I and our board members appreciated. But at a more fundamental level, the changes affected the team itself. A senior developer put it best: “Once we realized we could change and be successful, it spawned a culture of experimentation that’s now embedded.” There is a palpable momentum that started after we implemented the changes from that retreat, and it is still here today.

I believe a critical part of being a leader is making it easy for the people around you to do what they’re capable of. Sometimes that means having the right answer. More often, it means getting out of the way.

If your team already has the answers, your job might be to make it safe enough for them to say them.

This is a series of what I’ve learned, and what my team taught me, over the last two years.