The Paradox of Autonomy and Recognition - thoughts on trust and merit in software team culture

Who doesn’t want recognition for their hard work and contributions?

 Early in my career I wanted to believe that if you worked hard, and added value, that you would be rewarded. I wanted to believe in the utopian ideal that hard work, discipline, and contributions were the fuel that propelled you up the corporate ladder. And boy, was I wrong.You see I started my career as a shy, insecure, but smart, programmer. I worked hard (almost every weekend), I wrote code for fun when I wasn’t working on my work projects (still do actually), and I was loyal and dedicated to my company. 

My project should have been judged on merit.

 Once, for 6 months I worked on a project with 4 other people – and I felt like my contributions in terms of functionality and hours contributed were in the top of the group. So you can imagine my surprise that at our launch party, the GM of the group stood up and recognized “Josh, and the other team members for their hard work.” I stood there stunned, thinking WTF?! How was it that the GM was so out of touch with the team? Didn't our manager look at the checkins and the being resolved? How did Josh, who had probably contributed the second least amount to the project, end up as the being the only person singled out from the group? Not me, not the most senior person on the project, but the guy who seemed to spend a lot of time talking to my boss and the other people on the project.So many of us have been there though. We work tirelessly, doing our very best to get things done on time, but somehow we get passed over – in favor of someone else whom you honestly believe didn't contribute nearly as much as you had. What happened to meritocracy and being recognized for your work? 

Autonomy makes Meritocracy impossible

 Fast forward to now in the present day. I work with a team of 18 amazing technologists and it is my job to judge their performance. And only recently have I realized that in many ways it is near impossible to do so.There is no objective, quantifiable way that exists for me to be able to do this at scale without resorting to micromanagement – which is not something you even want to contemplate with a talented team. If this doesn't make sense to you, let me explain (note that some of these are measurable, but others are more subjective - but all are various ways people have suggested as metrics to judge performance):

• Hours. Ugh. I hate hour watchers. Writing code, at least for me, is like art, and when I am just not in the mood I can’t force myself to get things done. To use the measure of time as a productivity measure doesn't fairly represent the creativity and mentation required of a developer. Beyond that, it’s not really all that feasible to track hours in a highly virtual environment. I love that people on my team can work from home – or whatever environment where they do their best work (it is the reason we have “no meeting” days) – but how could I possibly track someone’s hours if they aren't in the office? Just like beans, counting hours sucks. Don’t do it.
• Lines of code. This measure it flawed for many reasons – from the mantra that “the best code is the lines you don’t write” to the simple anecdotal fact it once took me 3 days to write a single line of code, while another day I wrote over 10,000 lines of code (although admittedly part of that count included some substantial cut and paste). And of course, deleting code can be very productive too.
• Bug counts. Of course quality is important, but finding bugs in production belonging to developers that otherwise write great code is not rare. This metric is seriously flawed in a profound way -- it does not account for the fact your best developers often produce a moderate amount of serious bugs because they have been entrusted to design and implement the most complicated and critical pieces of an application/system. Penalizing your best players for having highly impacting bugs is tantamount to rewarding mediocrity.
• Features. Functionality is key of course, since when it comes to contributions the features that are built or added to the product should be directly tied to customer value. Of course judging on features can get complicated when multiple people contribute to one features. And of course, the details of the implementation can dramatically impact the efforts and hours involved. For example, recently there was a project to add login to an existing site. Implementing the feature using interstitial pages would have taken a few hours, however the design involved using lightboxes, which added some complexity around security that added days to the project to accommodate. It can be misleading even looking at functionality and features if you don’t dive into the technical details of the implementation and trade-offs.
• Maintainability. It is hard to measure and track something as subjective as writing solid, maintainable code – but anyone who has had to struggle with legacy spaghetti code will tell you that maintainability is worth the extra time it takes if it it’s something requiring long-term usage in production. Coders who spend the extra time to write highly-robust, maintainable code are often penalized for it, simply because their true contributions will not be realized until years later.
• Building skills and knowledge. And how do you measure the benefit of the time invested learning a new technology enough to be highly effective in its use. Researching and choosing the proper tools that optimize your productivity. And the time spent making careful and deliberate strategic choices that ultimately make a project feasible and successful? Obviously these are critically important, but an outside perspective would note that it seems a lot more work could’ve been done in the same amount of time.
• Helping others. There are many programmers who are great but not for the work they do but in the way they enable others to be great. Just having these people on the team makes everyone else better. Mentoring and selfless assistance to others is critical to building and preserving a highly-productive and cohesive team, but can be an incredibly difficult to quantify an individual’s role in this despite the reality of the contribution.

And of course there are probably another 101 things you could look at to judge someone’s achievements – including the way they present themselves (having a good attitude for example), being very dependable, or a prime contributor of innovative ideas and solutions. However, very few of these are objective, concrete things you can total up and give a grade to – and it is incredibly difficult to do without diving into the minute details or micromanaging the project. 

So if there’s no reliable managerial measure of your contributions how do you get noticed?

 Really it all comes down to one thing: Trust.Trust is like a currency, when a manager gives their reports autonomy and independence they are trusting them to complete the assigned task, make wise and strategic decisions along the way while proactively communicating problems long before the become a problem. They are in fact investing their money in you, and when see the returns on that investment they, just like any lucky investor, are quite pleased. Trust, though, takes time, patience and consistency but if you can’t build a relationship with your manager all that means nothing. For someone to invest in you, you have to show you are in fact an investment.

• Does your boss trust you?
• Does your team and your peers trust you?
• Have you done a good job to earn their trust?
• How would your peers describe you to someone else?
• How influential are you within your organization?

As a manager, there have been times when I have been very fond of an employee, but then noticed that their peers didn't care for them or held negative impressions of their performance. In these cases, given the trust level I have with my entire team, the opinions of the collective can easily outweigh my personal preferences. Think of trust like a graph and each arc between the people you interact with as a weight – so when it comes to performance those weights really matter.

Projects, products, performance and companies aren't just judged on the output, but how they produce the output.

 In my project the one thing Jeff did differently was he didn't just do the work, but he made sure that the management – my boss and the GM – knew what our team was doing. In retrospect, he was the reason our project was recognized in an organization with so many people. At the time I resented Jeff, now many years later I realize that his contributions to our team wasn't just his code, but his communication and the way he did his job.As an aside though – I think that certain company cultures may reward this more the others. The problem with some people like Jeff that over time they can optimize on 'trust' and create a distorted view of their contributions – and this is what I mean when I say “office politics” – and this isn’t good either.One of my very smart friends told me a story about joining one big company and meeting tons of super-smart, highly functional and productive people who were all about creating trust with their superiors by being hyper-visible.

“They talked the most at meetings, they interrupted people, they sent extremely verbose emails at 3am detailing the minutia of a meeting that took place the previous day, they cc'd long lists of seemingly irrelevant but high-ranking people on their emails, etc. And their bosses loved them and they got the best reviews, etc. After meeting these individuals and being both amazed and disgusted by their shtick, it started to become clear to us that the whole culture self-selects to this type of person. It didn't take us long to understand why so much “work” happens, but so little gets done.”

So what can you do if you are a manager?

 As an employee, I want to be judged by my contributions, and have a team that is a meritocracy. I also want autonomy and the ability to own substantial things and not have someone looking over my shoulder.As a manager I want to give recognition and praise to the people who deserve it, and I don’t want to micromanage and spend my days being big brother.This implies an implicit contract:

I will give you autonomy and independence, but it is your responsibility to share status and information with me.

 For example, once a team member told me he had worked so hard and really gave it his best, however from my viewpoint his progress wasn't up to the same level of his teammates. When he was leaving the company he told me all these things he had done – and I asked him “Why didn't you share this with me before?” You see, I would have advised him to spend his time elsewhere on priorities that were more important to the business. He responded with “I thought you would know.” Don’t make that same mistake.It is also important that as a manager you recognize improvement. This means understanding a person’s strengths and weaknesses. If you observe someone’s performance and you see they make substantial improvements in one of their development areas then that is definitely worth recognizing. For example if you have an amazing engineer who is typically a poor communicator, but they step up and not just contribute their great coding prowess to a project but also keep other team members abreast of evolving risk factors – then those sorts of achievements are worth praise.Just make sure you take in all the factors of a person’s involvement in the organization. Take steps to ask good questions and solicit feedback from other members of the organization. And let each person know your expectations around communication and progress.

And what can YOU do now?

 And so my end conclusion in all of this is: if you want autonomy, and the ability to own and control your own domain and projects – it is your job to push information and build trust with your team members.In other words, you need to learn and do the following:

• Follow through. Do what you say and consistently deliver on your commitments.
• Proactively communicate when a task takes you longer than you thought, and why.
• Improve your communication skills. In order for others to hear you, sometimes you have to hone the way you deliver your message.
• Volunteer information and make an effort to explain vague or hard to understand ideas and concepts. Make an effort to share the details of your decisions and diversions. This is also important when you make mistakes – letting others know before they figure out on their own will show ownership of the situation and can prevent misunderstandings later.
• Be forthright and authentic with your feelings. Even when you may hold a contrary opinion communicate your thoughts (respectfully and with tact).
• Don’t talk behind the backs of others. It is very difficult to build trust if someone knows that you will say something negative about your boss, the company leadership, or another coworker.
• Be objective and neutral in difficult situations. Learn how to be calm under pressure and act as a diplomat resolving conflicts instead of causing them.
• Show consistency in your behavior. Not just in follow through but by eliminating any double standards that may exist.
• Learn to trust them. This is one of the hardest ones, but trust is a two-way street. Giving others the benefit of the doubt and learning how to work with them is essential to a strong mutual working relationship.

In turn hopefully you have a good manager that will be able to ask you good questions and take the time to understand your contributions. And if that is not your situation, then make sure you are sharing information with those around you; such as your peers, your boss, and other stakeholders.Good leadership is keeping everyone on the same page, and if you want independence, it is on you to make sure people know what you are contributing.--Do you have other suggestions? Thought of other ways to think about judging output or performance?If so, please leave them in the comments – I would love to hear some other points of view on this topic.Discuss this post on Hacker News.  [And thank you to the lovely Vanessa Johnston for the photo at the top of this post. And a big thank you to Bryce Howard, Jay Bartot, and Reza Hussein for reviewing earlier versions of this post.]