Conrad Davis Jr.

My management philosophy comes down to one question I ask myself: how can I make myself replaceable? People grow most when they have clarity on what success looks like, the autonomy and trust to find their own way through, and consistent, pointed feedback along the way. My engineers would describe my style as collaborative, structured, trusting and autonomous. I am a hands-on coach early on, then I deliberately step back so people can grow into ownership.

Five tech leads I coached now own their roadmaps and operate without me in the room. One of them is an engineering manager. That is the measure I actually care about.

The hardest part of working this way is the discipline to refrain from stepping in, especially when you can see something about to go wrong and you know exactly how to fix it. Letting someone experience it and then coaching them through the reflection is almost always more effective than solving it for them. The risk is stepping back too early, before somebody is ready, and I guard against that by being explicit about what success looks like and staying closely observant at the start.

When somebody wants a decision from me, I ask for four things: the problem, the options they considered, the tradeoffs, and their recommendation. I call it the Decision Stack. It turns "here is a problem" into "here is my call, tell me if I am wrong", which is the difference between reporting and owning.

I evaluate engineers on two pillars. Impact, which is reliability, performance and scalability. And communication and leadership, which is alignment, clarity and knowledge-sharing. The higher the level, the more each dial turns from replicating systems to designing ones with leverage across the organisation. AI usage is written into every rung of that ladder rather than sitting beside it.

On team structure, I aim for roughly thirty per cent senior, forty per cent mid and thirty per cent junior. It creates growth paths without sacrificing delivery on complex work. I keep a primary and a secondary on every project so no single person is a point of failure. Team structure should not be static: my job is to evolve it to serve the business and the engineers at the same time.

Leading outside my own depth taught me the most. My strongest background is the front end, and early on I could not always pressure-test a backend proposal in the moment. Rather than trying to become an expert in everything, I made RFCs mandatory for significant work and changed the questions I asked. Instead of implementation details, I anchor on production risk, scale and maintainability: what happens if this fails, how do we mitigate it, what will this cost in production? My job leading outside my core depth is not to match the experts technically. It is to build the conditions that let the right decisions surface.