How to take credit for all the work as a Manager

The middle manager ends up in this weird position. The company works on big projects and everyone has a hand in making sure the perfect result is released to the world. The VPs act as stakeholders, defining the high-level criteria (New widget that makes more money!). The architects design the infrastructure, the developers write the code, and QA tests to make sure it's up to spec. Sometimes, somewhere in the middle, there's a manager who can't easily show off his work. Sure, they "manage" the project, but in the end it's hard to look at a feature and say "This manager is responsible for it." Unlike developers who can point to a specific feature and say, 'I built this.'

So I often see a particular behavior that comes from managers that seemed trivial at first, but now I know it's a pattern. This is not to make you feel bad about your job as a manager, but to bring it to light so you can identify it when you see it.

No product is perfect. Usually during a review or demo of the final product, developers might accidentally let a bug slip through. Something that even the QA team will miss. In fact, during the demo, no one will catch it because it's small and trivial. A manager on a Zoom call, multitasking while the developers are showcasing their demo, will take one glance at the screen and spot it.

"I'm sorry, can you go back to the preview screen?" the manager will interrupt. Right there, in the middle of ten different widgets on the screen, one of them will have a formatting issue. Where all the numbers are displayed in the correct currency format, one of the numbers just happens to be unformatted. The API returns numbers in cents, and the client application is supposed to use the _currencyFormat(amount) function to display it properly. For that single line, developers missed it, QA failed to see it, and a manager recognized an opportunity.

"Right there on the second widget. Isn't that supposed to be subtotal? It looks like the numbers are completely off."

"Right," the developer says. "Good find. The number is correct, but it seems like we didn't format it."

"Yeah, but the number looks much larger. It almost looks like it's 100 times bigger than expected," the manager continues.

"Correct, the numbers are returned in cents. That's why it looks this way. We just have to format it."

"Customers will freak out if they see such a large number. Imagine you get to your shopping cart and you see that the item you're purchasing is 100 times more expensive? Yikes. That will definitely affect sales. Let's create a ticket and make sure this is resolved."

"Sure, no problem," the lead developer, desperate to move on from this small oversight, continues.

"No worries, I'll create the ticket myself," the manager makes a point. "Somehow this got past QA. I want to make sure we have something in place so we don't miss something so obvious."

This of course is a real bug, trivial since it is just a display issue. The developers view it as a quick fix, like hitting the currency button in Excel. But the manager will continue bringing it up throughout the project cycle, not as a formatting problem, but as a testing failure that he prevented from reaching customers. He creates an anchor where none existed before. He is now the person who catches what others miss. Soon the currency issue fades from memory, but his role as the quality watchdog remains. When you think of this project, you won't remember the specific bug, but you'll remember that the manager saved the team from a potentially embarrassing mistake.

Whenever there's a crucial project coming out, this is the manager every stakeholder will want in their meeting. He will never fail to deliver. He might not participate in the project at all, but he will be remembered as the most important person in it.

When the manager's recognition obscures the work of the rest of team, it's because they play a very different game. In large projects, managers often look for these hooks, something flawed in the logic, or even a small UI error. They aggrandize the issue and turn it into something tangible they can stand behind. Once it's publicly recognized, no other part of the project is important until their issue is resolved. In a demo that showcases an entire project, a keen observation by a manager overshadows the rest of the work. It might sound silly to the developers, but this appears as quality leadership that differentiates pencil pushers from leaders.

This is not to trivialize the role of a manager. They lead projects and act as stakeholders themselves. They coordinate work with other teams, and ensure projects are delivered on time. That deserves a blog post on its own. The majority of their work however, doesn't get proper recognition because it is not visible. Instead, it's the trivial, visible changes that catch the attention of VPs. Not because they're more important, but because they're more memorable. Delivering on time is expected; catching a customer-facing bug is noteworthy. When a manager repeatedly references an issue they discovered ("like that currency formatting problem I flagged"), they're not just solving a bug, they're creating a narrative of vigilance and quality control.

By the time it's resolved, what started as a minor display issue has been elevated to a success story of proactive management. Complete with process improvements and quality initiatives that bear the manager's name.

So this is the pattern. When you see a small, trivial issue getting blown out of proportion in a project, just remember that sometimes, someone is just craving recognition.

---