Being a director means accepting that you can’t review every PR personally or weigh in on every architectural decision. Trying to do both produces engineers who stop thinking for themselves because they know you’ll think for them. The job is to build a team you can trust, and then trust them.
That’s harder than it sounds. As an engineer, your judgment is grounded in what you know. You can evaluate a solution because you understand the problem. But a director is regularly asked to evaluate solutions to problems that sit outside their immediate expertise. The question stops being “is this technically correct?” and starts being “do I trust the person bringing this to me, and have they earned that trust?”
How trust gets built
Trust on a technical team isn’t given, it’s built over time and effort. I track it through the things that are actually visible: a developer’s commit history in the codebase, the quality of the code reviews they give and receive, the features they’ve shipped that have passed QA without drama.
Over time, a picture forms. Some engineers consistently bring clean, well-considered work. Others bring good instincts but need more guidance. A few surface tech debt that genuinely improves quality of life for the whole team, which tells you they’re thinking beyond their own ticket.
At the same time, I’m working to earn their trust as their director. They need to know that when they bring me a real problem, I will either help solve it or find someone who can. That consistency is what makes them comfortable surfacing issues early rather than sitting on them until they become crises.
Trusting the track record
My tech lead came to me with a proposal to refactor one of our smaller apps around a state machine pattern, using Jetpack Compose. The pitch was that predictable inputs and outputs for any given screen would reduce our error rates significantly.
Jetpack Compose was still relatively new, and our team didn’t yet have deep experience making it work well in production. I couldn’t evaluate the technical specifics from first principles. What I could evaluate was his track record: consistently well-regarded by his peers, thoughtful in his reviews, right on his previous proposals. That was enough to work with.
Rather than defaulting to skepticism, I worked with him to develop the proposal into a full development plan to bring to the product team. The refactor took about two months. Since then, that app has needed only minimal updates to add new hardware support.
This project wouldn’t have gotten off the ground without trust working in both directions. He trusted me to champion something he believed in, and I trusted his judgment on how to accomplish it.
What building trust actually looks like
Trust flows naturally from the structures you put in place: code reviews that give engineers real visibility into each other’s work, training that raises the floor across the team, clear expectations about what good performance looks like. The more deliberately you build those structures, the more confidently you can trust the judgment that comes out of them.
The goal is a team where everyone is bringing their best thinking to the table, and where the director’s job is to synthesize that thinking, clear the path, and back the right ideas. When it’s working, the team can do things that no single engineer could do alone.
Dowell Dev 