# Down, Across, Up: What It Actually Took Me to Learn to Lead


> A manager once told me I was an enigma.

It came up in a 1:1 that had otherwise been unremarkable. He told me that if you talked to my reports, or my peers, I was one of the best tech leads around. Talk to him, though, and he couldn't get a straight answer out of me. At the time, I shrugged it off. It didn't feel like a big deal, just one comment in an otherwise ordinary conversation, and I honestly don't remember what I said back. Probably something that proved his point, since not having a good answer was sort of the issue in the first place. But the comment stuck with me in a way ordinary feedback usually doesn't. It took me years to understand why, and longer still to notice that the same mistake kept finding new places to hide.

The short version of how I got there starts with my mother. At 12, she taught me that leadership meant responsibility, not entitlement. Never show up to someone's home empty handed. A few years later, a class teacher made me class monitor, then I became a prefect, and I learned early that leading through influence beat leading through authority. That part I got right, for years. What I hadn't learned yet was what my manager's comment was about to teach me.

### What my manager actually saw

I started my career as a junior developer, like most of us did back then, and worked my way up through intermediate developer to tech lead. That's where the rubber met the road, and where the comment landed. I was good at the technical work, and good with my team and my peers too. My manager was a different story.

What he meant was specific. He had no real visibility into what was happening with the team. I was making decisions, fielding problems, and mostly keeping them to myself unless something forced my hand. Worse, when the team underperformed, I spent more energy defending them to him than I spent helping them improve. I thought I was protecting my team. I was actually shielding them from accountability, and shielding my manager from information he needed to do his own job. Very noble of me. Also, in hindsight, useless to everyone involved.

Here's the lesson I'd want any engineering manager reading this to sit with: your manager should not have to guess what is happening with your team. Leading your team well and keeping your manager informed aren't competing priorities. Treating them like they were is exactly the mistake I made. It sounds obvious written down like this. It took me years of getting it wrong to actually believe it, not just repeat it.

What I didn't understand at the time was that shielding and guessing were really the same avoidance wearing two different names. I found it easier to manage the story than to have the harder conversation, whether that conversation was with my manager or with my own team. I thought I'd learned a lesson about visibility. I had actually learned that avoiding friction had consequences. I just hadn't yet figured out how often that habit would show up in my leadership.

### What I got wrong with high performers

I carried that same instinct into my next job. I hadn't fixed the underlying habit, I'd only patched the one place where it had been caught. This time it wasn't my manager I was avoiding friction with. It was my own reports.

The first mistake was trying to make my reports my friends. There is nothing wrong with having a good relationship with your team. I think you should. But there is a difference between having a good relationship with someone and needing that person to like you. I would soften feedback because I knew how it might be received. I'd delay difficult conversations because I didn't want to damage the relationship. Once you blur that line, hard conversations get harder, honest feedback gets harder, and holding someone accountable gets harder. You start making decisions based on the relationship instead of what is best for the person and the team.

The second mistake was how I handled high performers specifically. One senior engineer on my team wanted to write a script to migrate our email templates into JSON blobs, localizations included, real technical debt he'd clearly already thought through and just wanted to go fix. My first instinct wasn't, "Let's figure out if this is a good idea." It was closer to, "Who approved this?" I don't remember exactly what I said, only that it was enough to make him go quiet in a way that told me I'd shut something down rather than redirected it.

That wasn't an isolated moment. I tried to control high performers rather than challenge them, and when they pushed back, I read it as a challenge to my leadership. It wasn't. It was high performers doing what high performers do: push boundaries, ask questions, challenge assumptions. I had that energy right there in front of me, and I spent most of my effort containing it when I should have been pointing it somewhere useful. High performers don't always need more direction. Sometimes they need a bigger problem to solve.

### The migration that taught me to manage stakeholders

By the time the next problem showed up, it wasn't really a new lesson. I just hadn't recognized it yet. I was tasked with migrating a service from one team to another. The migration itself went well. On paper, we did exactly what we were supposed to do. The problem was that our service had upstream partners depending on it, and I didn't do a good enough job managing those stakeholders or communicating what was happening and what they needed to prepare for. I focused on getting the migration done. I didn't spend enough time making sure everyone around the migration was ready for what came next. The technical work was sound. The project still shipped late.

That distinction mattered more than I expected. You can execute the technical work correctly and still fail at the project. Leadership isn't just about getting your part done. It's about making sure the people around you, above you, and downstream of you can succeed too.

### If you're leading right now, with or without the title

You don't need a title for any of this to apply. I didn't have one the first time I learned to lead by influence instead of authority, back when I was just a prefect trying to help classmates without abusing whatever pull I had. The same blind spots show up whether you're officially in charge of a team or just the person people already come to. If any of this sounds familiar, someone above you who can't get a straight read on what you're actually doing, a capable person who feels like they're pushing back on you personally, or a project that's technically fine but still lands badly on people outside it, here are the three questions I wish someone had made me ask myself earlier.

Is your manager working from what you actually know about your team, or only from what you've chosen to tell them? Are you challenging your best people, or just trying to keep them contained? And when a project touches someone outside your team, have you told them what to expect, or are you assuming they'll find out when it ships? I didn't ask myself any of those questions the first time around. I found out the answers from a comment, some pushback I mistook for insubordination, and a deadline I missed, three different costs for what turned out to be one habit: choosing the easier conversation over the necessary one, and calling it something else each time. I'd rather you find out from the questions.

Learning to manage up didn't automatically teach me to manage my high performers, and learning that didn't automatically teach me to manage stakeholders. I had to get caught avoiding friction in three different directions before I recognized the pattern. The lesson rarely announces itself as the same lesson twice. Most of us don't become better leaders because someone hands us the title. We become better because we eventually notice the pattern connecting the specific ways we keep getting it wrong.

Leadership was never the title I was given, or the identity that was handed to me as the firstborn. It's the accumulation of every direction I've had to learn to lead in: down, across, up, and sometimes, most importantly, within myself. I'm still working on a few of those directions. I expect I will be for a while yet, and if you're leading anyone right now, whether or not the title says so, I suspect you will be too.

---

If any of this resonated, or you're working through something similar, I'd like to hear about it. Reach me at [hello@georgekamunya.com](mailto:hello@georgekamunya.com), or find more of my writing and work at [georgekamunya.com](https://georgekamunya.com).