Good managers will always encourage you and tell you that you’re doing a good job. Great managers will challenge you to mature as a software engineer. In my career I’ve observed EMs who “silent fire” someone by not spending enough time as a coach. The goal of this article is to remove this veil for software engineers so they can improve their manager’s effectiveness. Managers: your team is your responsibility. One rower in a boat can slow down the team.

A great engineering manager maximizes these key traits:
1. Problem solving
2. Project management
3. Effective communication
4. Emotional intelligence
5. Great attention to detail
6. Technical skills
7. Delegation skills
8. Time management
9. Maintain a good work/life balance
10. Provides effective feedback
11. Fosters trust
12. Motivates

All of these twelve are important, but an engineering manager’s ability to be a multiplier as a coach and mentor relies on effective communication and feedback.

Have you ever received feedback like this:

1. The feedback I received from others is that you aren’t meeting the bar (but the specifics of that feedback are left out)
2. You could be doing better (but better is left up to chance)
3. We need to see an improvement in the next few weeks (without providing specifics)
4. You are doing great! Do you have any plans for the weekend? (Where a discussion about your performance is shunted to weekend chat)
5. I don’t think you’re ready for this project, so I’m going to put this other person on it

The abstract things that bad EMs say

Indirect and abstract feedback creates a negative flywheel, downward trend, 📉 that looks something like this:

1. An engineer has a clear gap in ability where coaching could help
2. During several 1:1s an engineering manager lacks radical candor (caring about someone enough to give direct feedback) to rumble and have a direct conversation about it
3. The engineer continues to fail because this gap isn’t addressed
4. Performance reviews come and a poor rating is given with abstract and unhelpful feedback
5. The engineer doesn’t feel valued
6. The manager is asked for a ranked list of talent on their team
7. The company decides to make budget cuts and sets a 10% layoff target for low performers (likely with other qualifiers like: in a high cost location, not near an office, working on a product that isn’t returning on investment or hasn’t been delivered fast enough).
8. The engineer is caught in a layoff

The keystone here is the manager. A manager who doesn’t dare to lead will eventually find the truth, but it takes years for that truth to play out while engineers who might have contributed more to the company are let out the door.

One of the clearest patterns I’ve witnessed is the “nice manager”. Someone who is extremely personable, makes friends with everyone, and is mostly optimistic about the company and people. This creates a halo effect: engineers see them as an ally, the manager is well-liked. During upward feedback surveys, direct reports tend to give glistening feedback. During calibrations this manager believes that every single person is performing above their level. Since they have a halo effect, people tend to take them at their word (another reason for checks and balances in a calibration system). Outside of this team, people question why milestones are missed and quality is poor – on their merits, the team may not be producing, but it’s challenging for that feedback loop to have any impact. This manager is “silent firing” because they never provide valuable feedback for fear of their kind image. Left undetected, correction can take years.

The second pattern is the “lack of trust” manager. This manager doesn’t believe in people from the start and limits their opportunities, but also doesn’t give them feedback to improve. For engineers that become managers, it’s hard for them to risk slowing down their project deliveries by migrating away from a known-good workhorse on the team who might have more experience in a domain. These managers “silent fire” by not coaching people who have low task relevant maturity. In a 9-box system, this expediency bias (and these others) limits the potential the manager sees in the employee.

As a manager, how can you avoid this?

1. Practice giving direct feedback. You can still be well-liked and give good feedback.
2. Read Dare to Lead and Radical Candor. Check out this DevInterrupted podcast episode. Engineers: suggest that you’ve read these books and recommend them to your manager.
3. Listen to others around you. Model your behavior after leaders who you see giving clear feedback to others. If you can’t figure this out on your own, ask another engineer: what was the last impactful feedback you received? You rely on tools to debug memory leaks, why not rely on others as a self-improvement tool?
4. Fix your scaling problem. If your team is too large (more than 12 people) and doesn’t allow you to go deep in 1:1s with each person, look to hire another manager or instead of load balancing over everyone, only focus on specific people for a given week. Take notes in your 1:1s and follow-up – write-to-disk, trying to keep everything in-memory will not scale.
5. Debug external feedback. Did you receive feedback about someone on your team? Ask for specifics. Try to understand if it’s a pattern or a single event. Take notes for each person on your team like you’re preparing a research paper without a due date. During your next 1:1, say “hey, I received some feedback about ______ and wanted to discuss this more with you.”
6. Ask others for 360 feedback for each person on your team. Put it through your own filter: not all feedback is valuable or actionable. Over time, identify patterns and create an action plan to address them.
7. Give people on your team a chance. Start newcomers with smaller projects, test the water with longer tenured people by giving them projects outside of their comfort zone. If everyone on the team is extremely specialized, you cannot effectively pivot to new asks, and at some point not providing opportunity will undermine your potential as a manager. You ramp features in production, why not ramp your trust in people?
8. Check your peers. If you see that teams aren’t consistently performing because of a “nice manager” or “lack of trust” manager, give that feedback directly to that manager. Not providing this feedback prioritizes short-term gains, look to influence over the long-term to keep that team engaged and people performing well. Ignoring deprecation warnings will eventually bite you.

Engineers, what can you do?

1. Check yourself. Are you checked out and not contributing to the team? According to this HBR article, by checking out, you might be creating a self-fulfilling prophecy where your manager is likely to “silent fire” you. Turn on your own linter.
2. Apply BFS to your work network. Ask for feedback outside of your team, find a mentor where you observe admirable traits.
3. Improve your survey responses. In the upward feedback company survey, make it clear by selecting the lowest options available for questions that indicate you’re not receiving quality coaching. If you can, add text comments that validate this. Most company surveys are anonymous, as long as you don’t add specifics. If your manager keeps dangling carrots for “just this one more thing” to justify a promotion, you may bias towards giving a great upward review – check your own biases each time you’re asked to review your management chain.
4. Feedback horizon. If you’ve been on a team for about 4 months, you should have received some kind of feedback about the work you’ve been doing. At a minimum, after 6 months, a manager should be giving you feedback on your strengths and opportunities. You wouldn’t push code without a logging statement to validate your feature is working, why would you go months without instrumenting logging in your job?
5. ⭐️ Ask for specific feedback. That presentation you gave, that document you wrote, that product you pushed to production – ask for some direct feedback on an artifact that you created. This is a good unit test – it should force your manager to give you feedback and can be a warning sign if this doesn’t occur. I added a star to this one because I think it’s the most important. If your manager can’t give you specific feedback for growth, ask them for more challenging projects or stretch goals. Think of this as pen testing – keep testing until you find a way in.
6. Humble brag about yourself. In public docs (like a Wiki), maintain a table of contents that link to everything you’ve worked on. Make it easy for leaders to see that canonical document so they can jump to various artifacts and give direct feedback.