In a previous role, I joined a small engineering team that was still finding its footing. Some members were early in their careers—smart, capable, and eager, but still learning how to turn code into systems thinking. They could build anything if you showed them the path, but they hadn’t yet built the instinct to question where that path should go.
Instead of stepping in as the expert, I approached mentorship as shared exploration. I was new to their platform myself, so I asked one of the engineers to walk me through how things worked. As he explained, I’d ask simple but pointed questions—“What happens if this part fails?” or “Why do you think it was built this way?” I wasn’t looking to test him; I was trying to help him slow down and think about the design, not just the syntax. When he didn’t know, I’d let it sit. Sometimes, the most useful feedback is just giving someone the space to realize what they don’t yet see.
That early dynamic set the tone for how the team grew. We built collaboration into our daily rhythm—not as a process, but as a habit. We paired often, swapped tasks when someone got stuck, and made reviews a shared responsibility rather than a performance metric. I also sent my own code out for review, even as the team lead. That single gesture changed how people engaged. It told them, You get to challenge my work too. And once that door opened, real feedback started to flow.
It took time, but quiet approvals began to turn into thoughtful conversations. Engineers began asking each other “why” more than “how.” We stopped measuring success by the number of features shipped and started caring about the quality of our decisions. Feedback stopped being a top-down checkpoint and became a two-way dialogue. That’s when collaboration became something deeper than coordination—it became ownership.
When the time came for a full system rebuild, all that groundwork paid off. It was one of those massive undertakings that could easily split a team in half if trust isn’t solid. Everyone had an opinion on what was broken and what needed to be done first. The first few sessions were messy—people defending their code, their ideas, their frustrations—but we found our rhythm by grounding everything in real user pain. Each day, I brought in the most common support tickets and said, “This is what our customers feel every day. Let’s start here.”
That focus on real impact cuts through ego. Instead of arguing about frameworks or languages, we started solving problems. Somewhere in that process, a co-op student pointed out a dependency the rest of us had completely overlooked. For a second, the room went quiet. Then everyone turned, realized they were right, and began reworking the plan based on that insight. It was one of those moments where the culture you’ve been building finally shows itself—the most junior voice in the room reshaping the architecture, and everyone listening.
That’s what empowerment looks like in practice. It’s not a pep talk or a slogan. It’s a thousand small moments where people learn their voice matters, and you prove it by how you respond when they use it. Empowerment is about giving people permission to question and hold themselves responsible for what comes next.
By the time we wrapped the rebuild, the system was cleaner, modular, and ready to scale. But the real win wasn’t technical—it was cultural. We’d become a team that trusted each other enough to disagree, to experiment, and to learn in public. We’d built a rhythm where collaboration, feedback, and empowerment weren’t policies—they were instincts.
Looking back, that’s what mentorship in engineering leadership really is. It’s not teaching. It’s creating the conditions for people to grow confident in their own judgment. It’s showing that leadership isn’t about control—it’s about clarity.
