I’ve been managing teams on and off for more than 15 years. It came with a lot of lessons and brought a lot of humility. Here are 6 things I have learned about team leadership. I talk about software teams because that’s my gig, but I’ll go as far as to say this applies to most intellectual work management.
1. You’re not boss
Forget the Gunnery Sergeant Hartman approach to work. This is not the Army (and frankly, I doubt it works like that even in the Army). A leader is a force multiplier, not someone who disciplines or bullies people around.
Early in my management career, I once told a team member they “had to” implement something a certain way. I was technically right, my solution was clearly better. But what happened is that they implemented it exactly as I specified, and when it didn’t work perfectly they came back to me for more instructions. I’d removed their ownership and agency in one sentence.
The fix? Ask questions instead of giving orders. “What do you think about this approach?” or “Have you considered X?” works infinitely better than “Do it this way.” Your job is to help them think better, not to think for them. When people own their decisions, they own the outcomes too.
2. You’re not your reports’ friend
There is something attractive in being part of the social group of the team. I get it. You want to be liked, you want to belong, you want to grab beers after work and complain about upper management together.
One day though, you’ll need to tell someone their work isn’t meeting expectations. Or that they’re not getting promoted. Or worse, that you need to let them go. If you’ve built a friendship rather than a professional relationship, that conversation becomes infinitely harder - for both of you.
I’ve seen managers avoid giving critical feedback for months because they didn’t want to upset a “friend.” That meant that the person never improved, got blindsided during review season, and the friendship was destroyed anyway. Along with their career.
Be professional, be friendly, absolutely care about your team’s wellbeing. But keep appropriate boundaries. You can be warm and supportive without being their drinking buddy. Your reports need a manager who will help them grow, not a friend who makes them feel good about themselves. Understand different personality types to build these professional relationships more effectively.
3. You’re in charge
Your team is doing the work. They’re good, smart players. They are focused and dedicated. They’re creative, they’re amazing. They also still need you to tell them what’s the goal, what are the priorities, and what are the resources that they can use.
Your team needs clarity on:
- What we’re building (the goal)
- Why it matters (the priority)
- What success looks like (the metrics)
- What they can use (budget, time, resources)
And then, when shit goes down you suck it up and take responsibility. When there’s a tough decision that will make somebody unhappy, you take it and own it. Not by committee, not by consensus. You make the call. That’s what you’re here for.
4. Own up failures
Watermelon goals are the fastest path to failure. What’s a watermelon goal, you ask? Easy: it’s a goal that’s green on the outside but red on the inside.
I’ve watched a manager tell leadership everything was “on track” for three months straight while their team was clearly drowning. They kept hoping someone would figure it out, or that they’d somehow catch up. When the deadline arrived and nothing was ready, the project failed and clearly they failed too.
I know another manager who taught me that “you can’t break the laws of physics”. When leadership asked, say, for a tight deadline and a full fledged product, they would reply that “they would not make the date with current resources, as much as they wanted to. But they couldn’t break the laws of physics, so we can either extend the timeline by a month or cut features X and Y.” Leadership wasn’t happy, but they had options and time to adjust. That manager was trusted and loved trusted.
Reassuring your leadership everything’s amazing and great when it’s not, while waiting for some sort of miracle to happen, will only result in having to explain what happened at the last minute. This will destroy your reputation and any trust you had built with leadership faster than you can say “status report”.
Own your shit. Early and often.
5. You have a different job now
I know managers who will occasionally (or, sometimes, frequently) sit down next to one of their developers and “pair program” with them. For the love of Peter Drucker, don’t be that guy.
I get it. You miss your IDE. You miss the simple, predictable craft of making computers do what you want. You miss seeing your code run successfully. Management feels fuzzy and unpredictable by comparison - you’re never quite sure if you’re doing it right.
But here’s what’s happening when you “help” by coding: you take away someone’s opportunity to learn. You create a bottleneck. You neglect your actual job - which is removing obstacles, setting direction, and developing people.
Your value is not in writing the best code anymore. It’s in:
- Unblocking your team when they’re stuck
- Making sure they’re working on the right problems
- Growing their skills so they can handle more complexity
- Protecting their time from organizational chaos
You became a manager (hopefully) because you were good at coding. You’ll be good at management when you accept that coding isn’t your job anymore. Your team member doesn’t want your “help” - they want space to figure it out themselves.
6. The easiest way to work for you is the worst for your team
I’m not quite sure if it’s because people adapt so quickly, or because their personality is already that way (and that’s why they moved to management), but too many bosses pepper their team’s calendars with meetings, social events, catch-ups, and a myriad of other context-switch-to-talk-to-people-about-some-random-topic.
I’m guilty as charged. As a manager, my calendar is a mess and jumping between meetings is just how I live. So it feels natural to schedule “quick syncs” with my team throughout the day. Just 15 minutes here, 30 minutes there. What’s the harm?
The harm is that your engineers aren’t like you. They need 2-4 hour blocks of uninterrupted time to get into flow state, understand complex systems, and solve hard problems. Every meeting you schedule fractures their day into less usable chunks.
Look at your team’s calendars. If they can’t find a 3-hour block of meeting-free time at least three times a week, you’re the problem.
The fix: Cluster your 1:1s and team meetings into one or two days. Make “no meeting Thursdays” (or whatever day works). Send a Slack message instead of scheduling a meeting.
Most engineers want large stretches of time to focus on a problem. Your job is to protect that time, not fragment it. Leave them alone most of the time - it’s the kindest thing you can do.
The Pattern
I either made or witnessed first hand all of these mistakes. What I saw is that most management failures come from forgetting that your job fundamentally changed.
You’re not into delivering directly anymore: you’re now the multiplier. You need to fix problem through others.
What would you add to this list? What management lessons took you the longest to learn?