In an interview, I was asked about the achievement I was most proud of. I talked about a migration my team did, moving a high traffic product from RDS MySQL to Aurora Serverless with zero downtime.
Then the interviewer asked what my role in it was. I gave an answer that can feel risky in an interview. I said I did not build it, my engineers did. My job was managing the stakeholders, getting the approvals, and making sure nothing got in their way.
I know the usual interview advice is to take more of the credit, to say things like "I designed the approach" or "I made the key decisions." Some of that would even be partly true. But the answer I gave is how I actually think about management, and it would not mean much if I only said it when it was easy.
Why the credit belongs to the team
The way I see it, a manager's work is the team's results. That is the job. If a manager takes personal credit for something the team delivered, they are counting the same work twice. Once as "my team delivered this" and again as "I delivered this." Only one of those is true.
The engineer who wrote the cutover script built the cutover. What I did was create the conditions for it. I got the support to do it properly instead of quickly, I made sure more than one person could run it, and I kept the stakeholders calm while the work was happening. That is real work and I am happy to take credit for exactly that. But the migration belongs to them.
What giving credit actually looks like
Saying "great job, team" in a meeting is nice, but it does not change anything for anyone. The credit that matters is the credit that reaches the people who decide promotions and careers.
- Their names go in the email to leadership. Not "the team delivered this," but the actual names of the people who did it. Leadership should know who the strong engineers are without having to ask me.
- They present their own work. When leadership wants a walkthrough of the migration, the engineer who built it presents it. I am in the room only to handle any difficult questions, not to explain their work for them.
- My name comes up when something breaks. This is the other half of the same rule. Credit goes down to the team, and responsibility for problems comes up to me. You cannot do one without the other.
You can only give credit for work you let them own
There is one condition that people usually skip. You cannot give someone credit for work you did not let them own.
If the manager makes every important decision, reviews every line and solves every hard problem before the team gets to it, then "the credit goes to my team" is just something nice to say. Everyone in the room knows who really did it. To give real credit, you first have to hand over real ownership, with real responsibility and real production risk, before you know how it will turn out. That migration was my engineers' achievement because it was genuinely theirs to get wrong.
This is also why it builds over time. People who get real credit for real ownership take on more ownership next time. That is how two engineers I hired as interns went on to lead teams of their own.
The cost of doing it this way
In the short term, this makes you less visible to leadership as an individual. While you are putting your engineers' names in the email, another manager might be presenting their team's work as their own, and for a while it may work for them. That can be frustrating to watch.
I will not pretend it always balances out quickly. But when a manager's team keeps doing well, quarter after quarter, people start to notice who built that team. It takes longer, but it is the honest way to get there.
The migration is still one of my proudest achievements, and it still belongs to them.
Top comments (0)