Leadership Garden
You get the behavior you reward. Announcing the behavior you want does approximately nothing, and I say that as someone who has announced it several times.
Charlie Munger put it better in 1995: “Show me the incentive, and I will show you the outcome.” He was warning people about their advisors, and the line survives because it works anywhere people watch each other for signals about what counts. Engineering orgs are one of those places.
It matters most when you are trying to fix something in the culture.
The town hall does not work
The instinct is to address the culture head-on. Quality matters. Slow down and do it right. Own your systems. You say it at an all-hands, then again in Slack, and then you write a doc on engineering standards and pin it in the channel. (I have written that doc. Twice.)
None of it moved anything, and not because anyone disagreed with me.
They agreed. They also knew who got promoted last cycle.
An engineer who stops caring about the fundamentals is usually behaving rationally. If product work is what gets seen, and seen work is what gets rated, then two weeks spent on a flaky test suite is two weeks spent invisible. Nobody sits down and decides to stop caring. They keep making the locally sensible choice over and over, and a year later you have a group of people who ship features quickly and cannot tell you how the system behaves under load.
Then somebody calls it a culture problem. Culture is where the problem shows up. Whatever is causing it sits one level down, in what the org actually rewards, and words aimed at the top layer never reach that far.
What you actually control
Most writing on this ends at “align the incentives,” which in practice means redesign the ladder and the compensation plan. If you run a domain rather than a company, you usually own neither.
What you do own is attention. Attention is an incentive, and because it costs nothing on any budget line, leaders treat it as decoration.
So we started spotlighting deep engineering work the same way we spotlight product wins. Same demo slots, same all-hands, same language about impact, same audience. The main stage, not a side channel that eleven people have muted.
Once that path existed, people walked down it. That is the entire mechanism. There was never a shortage of engineers who wanted to do the harder, less visible work. There was a shortage of evidence that anyone would notice if they did.
The test for whether the path is real
The fair objection, and I have heard versions of it from my own engineers, is that praise is cheap and everybody knows it. A shoutout costs me nothing. A promotion costs money and takes a slot away from somebody else.
That objection is correct, and it gives you the test.
Ask who was last promoted mainly for deep engineering work. If you cannot name the person, the second path is a rumor, and your team figured that out long before you did. Recognition with no promotion behind it is the same town hall with better staging.
Do not turn it into a metric
The next instinct is to measure the thing. Put tech health on the scorecard, count refactors, attach a number to reliability, and review it monthly.
Then Goodhart arrives, and you get the number without the work. Migrations get declared done at eighty percent. Coverage climbs while the new tests assert nothing in particular.
Keep recognition a judgment call. Train your leaders/managers to recognize and celebrate. It is slower, it is harder to defend in a spreadsheet, and it is much more difficult to game, because a person has to look at the actual work and decide it was good.
Read your own signals
If you do not like what you are seeing in your team, the answer is rarely in what you have been saying.
Look at your last three promotions and your last three demo slots, and read them the way your engineers read them. That list is your culture statement. Everything else is commentary.