No one has ever asked about my management philosophy in an interview. They really should.
When companies hire a people leader for engineers, the questions center on what the person knows: frameworks, architecture, their tech stack, things like that. That’s fair enough; a manager with no understanding of what the team builds will struggle to earn trust.
Almost no one asks the harder question: how do you manage?
Here is my answer.
One of my proving grounds as I started managing people came when a client’s email API key leaked to the public through a careless engineer’s mistake. – copying it to what they thought was a private clipboard. It was not private. Side note: watching a million emails spool into a sending queue in real time is both fascinating and terrifying in equal measure.
We killed the key, rotated credentials, and had the client on the phone within a half hour. Cleanup ran several days, but was ultimately covered. Total damage: several hundred dollars in extra “send” tokens and the irritation of having to rotate all of the credentials.
Then came the real decision. Firing was on the table as an option. The final decision came down to my recommendation.
I went a different direction. I put him on a performance improvement plan built around one subject: security. I wanted a learning standard, and provided a curriculum: learn secrets management, learn the WordPress attack surface, and learn how to better handle client data. Their ‘final homework’ was to deliver the next lunch and learn on the topic to the whole engineering team.
They delivered. The session was one of the best we ran all year. They went on to become one of our most security-minded engineers, and was in the mix with any security discussions we were having
The leak also exposed a gap on my side. One engineer with one bad commit should never reach live client credentials unchecked. We added secrets scanning to the pipeline, did a full sweep of our repositories to check for secrets, and set a rotation schedule. One person made the mistake, but it’s ultimately our system that let the mistake ship.
My rule is simple. Mistakes can happen, but they should only happen once.
Once carries conditions:
- The engineer reported the problem instead of burying the problem
- The failure came from inexperience, not from skipping a process we had already trained on
- The person owned the outcome without deflecting
- The most important part, to me: the same failure does not repeat.
Miss those conditions and the conversation changes. Repeat negligence, concealment, and dishonesty get handled differently, and fast. Grace is a great policy, but not a blanket policy. Grace is a response to how someone behaves during the worst hour of their year.
That doesn’t mean that I’m a doormat manager, however. There’s a big difference between an honest mistake and a purposeful negligence, and it’s usually very easy to tell which one it is based on the evidence.
From an operations perspective, firing them would have cost more than keeping them. Replacing a mid-level engineer runs several months of salary once you count recruiting, onboarding, and lost project context. The bigger cost sits elsewhere: knowing that every engineer watching would have learned one lesson: hide your mistakes. Teams who hide mistakes surface problems late, because mistakes equal failure, and failure leads to termination. Mistakes, instead, should be a learning experience – one that teams come out of having learned something.
