If you're thinking without writing, you only think you're thinking.
(с) Leslie Lamport

If bonuses are necessary
Bonuses are about more than just business metrics. Focus on what truly matters.

It’s no surprise most companies prioritize business metrics when assessing bonuses. This isn’t the right approach. If a bonus system is essential to your company’s culture, consider the following metrics structure:

• Roadmap focus (40%): Contributions to top priorities (~60% to roadmap).
• Initiative completion (30%): Timely and quality project delivery.
• Business metrics (15%): Company financial performance.
• Product stability (15%): Keeping the product stable with minimal outages.

This way, you primarily reward engineers based on their contributions to what matters most, not just the organization’s overall financial success.

If you don’t have clearly defined metrics, your team will turn against you.

Make sure these metrics are clearly defined and communicated to avoid misunderstandings. You’ll lose your team’s trust if they interpret them differently or feel they’re inconsistently applied.

Watch out for these traps
• Don’t link engineer compensation too closely to variables they can’t control. Performance-based incentives can backfire as engineers have limited influence on product outcomes.
• Align incentives with what engineers can impact. Missing targets can result in lost motivation and talent.
• Focusing on OKRs can boost metrics but create a culture where people prioritize their products/projects at the expense of others — where everyone looks out for themselves instead of working together.

“Leadership is the art of getting someone else to do something you want done because they want to do it.”

Management by exception is a style of business management that focuses on identifying and handling cases that deviate from the norm, recommended as best practice by the project management method.
...
Managers only intervene when there are significant deviations from the norm, whether positive or negative. In all other cases, the managers set the standards and employees have autonomy and accountability. This way the managers can focus on higher-impact activities.
...
They intervene only when something big happens, overlooking smaller mishaps and giving frequent, continuous feedback. Good and even excellent behavior is not celebrated, thus employees don’t know what behaviors to do more of.
Manage by exception also promotes reactivity to problems over preventing them.
...
What to do instead of manage by exception
• Set clear goals and standards, clarify the autonomy levels, explain an repeat the “why”
• Have weekly 1:1s to build trust and rapport
• “Catch them doing something good” – give constant positive and negative feedback The recommendation is to give 5 times more positive feedback than negative one
• Coach, prepare individual development plans
• Delegate
• Set psychological safety
• Celebrate wins and recognize both small and meaningful achievements
• Focus on taking advantage of and improving your directs’ strengths rather than improve their weaknesses

DORA suggested using four key metrics, which predict organizational performance:

Deployment frequency (DF): How often does your organization deploy code to production?
Lead time for changes (LTFC): How long does it take to go from code committed to code running in production?
Change failure rate (CFR): What percentage of changes to production result in degraded service and need remediation?
Time to restore (TTR): How long does it generally take to restore service when a service incident or a defect that impacts users occurs?

There are four approaches to saying No:
• Direct: Thank, decline, and express interest.
• Redirect: Refer to someone else who is better suited for the ask
• Change Their Perspective: Is this ask phrased correctly? Does it really need me?
• Stonewall: Ignore, and follow up a few days later.

Other relevant tips:
• Communicate boundaries to be clear on expectations
• Involve your manager if needed
• Set up focus blocks so no one can bother you
• Scale yourself through notes and wikis
• Manage your reputation carefully – say “No” often but “Yes” sometimes!

Testing in prod is not trolling. It's the only way to confirm that your code is working, and *how* your code is working.

Time spent thinking about code to be written is much more important than time spent writing code.

"pull request metrics provided value in creating awareness around inefficient code review processes. But there were no real benefits beyond that. I was dismayed to find leaders frequently using the metrics for inappropriate purposes like performance reviews, or requesting we add metrics like lines of code to the product which I knew were harmful.
...
We built an initial product and piloted it, but shut it down after we found that teams didn't get much value out of it and most hardly used it at all. Although our product vision for "data-driven engineering" resonated with leaders and made for compelling sales pitches, there wasn't real value to back it up.
...
I’ve personally yet to come across an example of real benefit gained from these metrics other than shining a light on inefficient code review processes, which is a problem that’s easily solveable without dashboards.
...
If you’re a leader looking for insights on how to improve developer productivity, steer clear of these types of solutions and instead focus on developer experience."