The Trifecta of Appreciation
Tech companies are pretty good at hiring engineers based on skills. The industry has a standard process, at the end of which the hiring panel has conviction.
When it comes to hiring managers, tech companies largely revert back to hiring based on experience. It could be a lack of interview formats for managers, but tech companies invest a ton on hiring. I think the deeper reason is a lack of consensus on what correct leadership looks like.
In the hacker tradition, I will share my perspective. If you were to reduce everything I know about technical leadership into a single rule, it would be: individual contributors and their work must be appreciated.
It sounds pretty simple, but there are 3 angles to consider:
Stakeholders appreciate the work for the value it provides.
Individuals feel appreciated for their work.
Team members appreciate the work as integral to success.
Driving Outcomes
The first part of the trifecta is that stakeholders appreciate the work. This is table stakes, otherwise the team is wasting time. The stakeholder might be internal, the form of appreciation might be numeric, but all work needs this kind of appreciation.
The common failing for work that is not appreciated is building a solution before defining a problem. There are a couple ways to prevent this kind of waste:
Define projects in terms of the desired outcome for stakeholders. The framing of a measurable goal without a prescriptive plan focuses the engineers on solving the problem and allows creativity. Otherwise you limit the solution space to the creativity of the leader. Too many leaders hold all the cards and dole out marching orders.
Disintermediate access to primary data. Encourage the team to engage directly with stakeholders and monitor feedback as empirical evidence. If a metric ticks up or a customer gives positive feedback, the signal is definitive. The alternative is outsourcing thinking to the leader and blindly following orders, which doesn't scale.
Individual Recognition
The second part of the trifecta is that individuals feel appreciated for their work. The idea is hardly new. Dale Carnegie taught a course on the subject ~100 years ago that people ‘work for money but go the extra mile for recognition.’ Yet many leaders neglect this basic need. There are a few reasons that teams fall short:
Attribution is a prerequisite for recognition. It does more harm than good to recognize the wrong person. To recognize the right person for the right outcome, you need to have a good handle on what is going on. It takes energy to follow the status of each project and technical depth to understand the proportional contributions.
Finding the right time and place. It can feel out of place to give kudos in random meetings or project channels. The other challenge is unbalanced recognition. If giving kudos is completely ad-hoc, flashy stuff will get more recognition. It skews the incentives to work on high visibility instead of high impact projects. A great time and place is a regularly scheduled meeting.
It feels like a waste of time. The reality is that recognition is more valuable to the recipient as the size of the audience increases. Presenting at all hands, receiving an award, or public endorsements carry more weight than a private message. The largest audience that is appropriate for the majority of work is the cross functional team. It can be tempting to move the kudos async to a channel. The problem is that nobody will read it, which reduces the audience, which reduces the value. The majority of recognition should happen at the group meeting.
Taking credit as the leader. If a leader neglects to mention the people who did the work, the leader is effectively taking credit for planning and organizing the work. The leader is visible and the contributors are invisible. It implies the people on the project were undifferentiated labor, which even if true, doesn't feel great. The anti-pattern is announcing that "we" accomplished a goal without naming the contributors. Plural nouns are toxic to recognition.
Winning Together
The third part of the trifecta is members of the team appreciating the work of others. I don't mean for prosocial diversions like pairing on a problem or refactoring. I mean genuine appreciation for completing projects. There are some interesting properties that must hold for peer appreciation to take place:
Work happens in public. In order to appreciate the work of others, there must be awareness in the first place. The details of the project also must be transparent. Reacting with a
:rocket-ship:on a post is not the same as understanding and appreciating the work. A great example of working in public is writing documents with details, sharing in a central place, and soliciting reviews from the team.There is broad understanding of the business context and goals. The concept of appreciation implies a favorable judgment of the completed work. Having the ability to gauge the impact of peers depends on a shared understanding. For example, if there are 5 goals for the quarter, and someone on the team accomplishes the first goal, the value is evident.
Work is balanced across the team. If the work is unbalanced, contributors with more impact will not appreciate the work of contributors with less impact. The true feeling will be of disdain. The contributors with less impact will also not appreciate the contributors with more impact, not fully. The true feeling will be resentment at not getting a better project. In order for everyone to appreciate each other, some balance is required.
The Golden Rule
When I first started thinking about appreciation, it was in the narrow context of individual recognition. However after thinking about it more, I realized the trifecta is required for a high performing team. Individual recognition without driving outcomes is disheartening. Driving outcomes without winning together is bittersweet failure. Winning together without individual recognition is unfulfilling. It really is a golden rule. Individual contributors and their work must be appreciated.