Recognition isn’t just a “thank you” for a job well done: it’s also a key factor in employee engagement. As long as recognition is fair, specific, and deserved, it can help shape a positive culture and open new channels for feedback within the team. But while most of us know we should recognize individual contributions, two structural obstacles stand in the way.
The first is time. We often think of recognition only in terms of performance reviews, salary adjustments, and end-of-year bonuses. This limits us to thinking of recognition on a quarterly (if not annual) schedule—too long a cycle to make the most from the feedback. But praise, preferential assignments, and other forms of recognition or reward can take place on a daily timescale. We just have to use them.
Second, and somewhat less obvious, is knowing what to recognize.
For a dubious analogy, look to your datastore: while it’s critical to your product’s success, a significant fraction of the organization (nevermind your customers) will never see it. Just like a datastore, members of the team provide a variety of enabling services that won’t always speak for themselves—think of triaging bugs, improving slow builds, or managing an open-source backlog. These are indispensable tasks, adding geometric value to the team’s efforts by removing friction and distractions. But while the rest of the organization sees the big, forward-facing projects that benefit, the enablers themselves often go unnoticed.
Our story starts there, with the enablers, and with a curious question I like to ask software managers.
How do you recognize your enablers’ contributions?
Often, and even for veteran managers, this will be the first conscious thought they’ve given it. And those who are actively practicing it give a variety of answers:
We just track everything. Build improvements, test-suite cleanup, documentation, research—it all goes into the appropriate categories on our PM boards and gets tracked like anything else. When we do our quarterly reviews, we just pull up the tool, see where the team’s spending time, and adjust accordingly.
Our team holds an annual awards dinner to recognize the dirty work. We have categories recognizing our preeminent “Russian Novelist” (documentation) and “Exterminator of the Year” (bugs). It’s silly fun, but keeping those numbers requires us to track our effort throughout the year.
Our annual review includes a peer assessment. Asking, “who do you depend on?” isn’t exact science, but it helps us recognize and reward the folks that have helped everyone else win.
So far there doesn’t seem to be a single best practice. Teams vary. Situations change. Management is rarely straightforward. But even if the particulars are left as an exercise for the reader, most approaches form around a familiar process: benchmark, set goals, and assess.
You can’t give credit for important work if you don’t know who’s responsible or you can’t gauge impact. The first step, then, is to understand the cost and benefit of each “service” implicit in your team’s workflow.
To collect an initial benchmark, sketch your production process and ask the team to help identify the services they depend on at each step. For a software team, for instance, these might include:
- Requirements (who gathers product requirements, triages bugs?)
- Development environment (who manages the development environment and test harnesses?)
- Continuous integration (who is responsible for build tooling?)
- Code review (who is responsible?)
- QA (who is responsible for finding, documenting, and signing-off on bugs?)
- Deployment (who manages infrastructure? Releases?)
Next, list the team members who provide each service. These are your enablers. If you can’t already account for the time they spend at each step, explain to them what you’re hoping to learn and ask them very nicely—nothing inspires resistance like paperwork—to track their time over the next several weeks. Document the results and share them with the team.
If the benchmarking process turned up any surprises—hidden services or exemplary effort—odds are that the team members responsible haven’t been recognized for their work. Take a moment to correct that.
And now you know where the time is being spent, you’re ready to start improving it.
Enabling services address the bottlenecks that would otherwise slow the entire team. Knowing the risk, investment, and assumed responsibility of each, you can start considering services as a first-class part of the team’s duties and plans. Set goals for services that lend themselves to measurement or tuning (not all do) to help encourage the positive, geometric impact they can have for the team. Formal objectives like “eliminate false positives in our integration tests” or “improve build speed by 10%” will lend enablers’ work the same priority as the customer-facing features that benefit from them.
Incorporating internal services into mid-range planning can also help ensure the energy invested in them is well spent. While enablers tend to be civic-minded people, not all services provide equal returns. Setting specific goals can encourage work that improves the team’s effectiveness while saving energy on less-valuable tasks.
Of course, goals are a double-edged sword. Used well, they encourage entrepreneurship in the team’s service. But misaligned incentives can also be worse than no goal at all—consider the likely consequences of “reduce the time spent in code review” or “fix more bugs” as opposed to “reduce defect rates”. Don’t make that an excuse not to set goals: just stay alert for problems and correct them as they arise. Goals are an important tool for recognizing and improving service. They just need a bit of support.
With benchmarks established and goals set, it’s time at last to assess and recognize results. Repeating the benchmarking process can provide useful data, but as the exercise has progressed you’re likely curious about questions you may not have originally asked.
- Are there services we can simplify, outsource, or automate?
- What services are we overlooking?
- Are service providers valued / compensated relative to the importance of their work?
- What knowledge is siloed? How risky are the siloes?
Many of these questions won’t have immediate answers, and that’s OK! A clearer picture of the services the team depends on naturally inspires more questions. Now that enablement is shining through the same lens as feature development, we can use similar tools to resource, streamline, and recognize it. Give kudos for delivering features, squashing bugs, fixing CI, exceptional customer support or whatever metrics your team uses to gauge success. Do it frequently: there’s no need to wait for that end-of-year awards ceremony when a heartfelt “thank you” will make as much of an impression.
With that, I’ll turn it over to you. How do you recognize your enablers’ contributions? I’m looking forward to hearing from you!