Defending People

Stand Up

Thank you to everyone who participated in previous week’s discussion here . This is a longer post on the same topic. Enjoy!

Defending People

To defend your team's (or individuals on those teams) performance, you need to know how they are doing on an ongoing basis, how they are doing? There are three questions you need to be able to answer definitively for every team member. Are they getting their stuff done on time and with high quality, a.k.a functional competency? Can they do that without burning bridges with the rest of their team and the organization, a.k.a; cultural competency? Will they be able to elevate and evolve their capabilities as your organization evolves, a.k.a; growth competency? Keep a living document that tracks the progress of every employee against the three dimensions I mentioned above. A document like that is often called an Individual Development Plan, and there are lots of templates available online that you can repurpose for your needs. Bottomline is you have to be sure the people on your team are moving the company in the right direction because, at some point, someone will question your team's competency. You need to be prepared to answer it authoritatively. A provocative question that I sometimes ask my leaders when they are unsure of an individual's performance is; If you can hire somebody else in their place instantly, no questions asked, would you do it? A software development engineer costs about 500k USD annually, with all benefits included. You need to make sure you can justify the cost.

I encourage managers to reflect on their team's performance every month. I run a monthly talent review where all the managers in my organization get together and collectively reflect and refine our opinion of the engineering team's performance. I use a set of prompts to guide the conversation. Who is doing really well and might be ready for a promotion soon? And, Who is not doing well and needs help? The answer to the first question will showcase how well individuals are growing in a team, a.k.a, growth competency, and the answer to the second question is obviously to talk about the poor performers. The only time a 'No One' is acceptable as an answer is if the team is a newly formed (<6 months old) team, otherwise, it indicates that the manager is not paying attention to the performance of her team. Left unattended, mediocrity will almost always slip into the miasma of non-performance.

I encourage all the managers in the meeting to dig into each other's team's performance collectively. The goal is not to create strife but instead set a high bar for talent by collectively focusing on and nurturing talent. To make sure the managers are focusing on breaking the right boulders, I start every talent review with a public service announcement that goes something like this-

"The primary goal of this meeting is to elevate the talent bar for our teams continuously. We will be discussing very sensitive topics about the individuals on our team. Please remember that these are real people with dreams, aspirations, families, and emotions. So please be respectful and helpful. We are here to help our people. Lastly, everything we discuss here should not be shared outside. Gossipping about our people is a fireable offense. However, managers should take the feedback they gather here about their teams and share it with their teams without naming the individuals who gave the feedback." 

If you continuously benchmark your team against the other teams in the organization and have up-to-date individual development plans, then you will have all the evidence you need to justify your team's performance. 

Critical comments about your team are often off-the-cuff comments. A seemingly non-threatening dig at someone on your team. A gentle jab. "I hope Bob figures out how to speed up." "I wonder when Bob will figure out how to work with this team better?". If you hear this in meetings or one on one conversations, do not brush it off. If you ignore it, the fire will become bigger. Don't get defensive, but ask probing questions like, "Oh, can you tell me more?" If you have an IDP (individual development plan) for Bob on file, you will know all the projects he is working on, how he is doing against his goals and how his team feels about him. If Bob is actually having issues, then let the feedback giver know that you know what is going on and are actively coaching Bob. Otherwise, you should dig in for more information. Try to fish for tangible instances of poor performance and how to gather further feedback from multiple people. If the person comes up with real examples, it might indicate the start of Bob's glide down into poor performance. In that case, thank the other person for the feedback and commit to talking more to Bob and coaching him as necessary. 

If the provocateur cannot provide any real examples or come up with others who could back up his feedback, then the critic is either gossiping or lying. In those cases, you have to tell the detractor that you disagree with his assertion firmly, and if he needs further clarification, go to your boss or HR, but not discuss it with other people. After that, you should talk to your HR representative about the interaction, including letting them know what you think of Bob's performance. This is when provocateurs typically back off. After all, the standard office provocateur doesn't actually want to help anyone. Gossip is enough to keep them going.

You can use the same technique with your boss if he questions Bob's performance. In addition to doing everything in the previous section, I also offer to share Bob's development plan with him as further proof. Most bosses are satisfied with that, and they move on. However, there will be rare moments when your manager disagrees with you and really does think that Bob has a performance problem. Maybe he has a personal grudge against Bob? Maybe he wants to lay him off under the guise of a performance problem? If you truly believe Bob is an asset, you should stand behind it. You have to tell your boss that you can't disagree and commit. There are only two outcomes. Your boss, impressed by your conviction, decides that you are right and moves on, or he decides to go over you and fire Bob anyway. If your boss does the latter, you need to move on from the company. The first outcome is the more common one, so don't be afraid to push back. 

And for the very first time, two personal anecdotes! P.S - I have modified some personal details about the people I talk about in the anecdotes to preserve anonymity. 

Personal Anecdote - 1

A long time ago, in a company far, far away, or maybe not too far away, I was a mid-level executive in a large-sized technology company that was quickly expanding in a different location. I was responsible for building up that site from scratch. Essentially, a lot of hiring.

One of the interesting things about my role there was that I was a single-threaded owner. I.e., I managed both product and engineering functions, so I was responsible for hiring product and engineering leaders. In those early days of hiring, I hired a product leader whom I would put in my top 10 list of product managers I have worked with in my career. They are in the top 10 not because of raw product management skills but because they brought above-average product management skills and top-notch people skills. They were popular with every team and every engineer they worked with, including the most curmudgeonly engineers on my team. Their popularity extended beyond the boundaries of my team, and most people in the company had an easy time working with them, well, almost everyone.

One engineering leader had some sort of beef with this product manager. I never actually found out what their issue was, but whatever it was was strong enough to push that engineering leader to complain about my star hire to me and others, mostly me.

They peppered me with vague narratives about how my star hire was messing everything up themselves, their team, and through their actions, painting their leader (yours truly) in a negative light. 

I initially ignored it (big mistake), but then the narrative started picking up steam, and soon others in the company, including my direct manager, started asking questions about this employee's competency. So I decided to confront the provocateur directly. 

I got on a call with this engineering leader and started digging into their reasons behind painting this seemingly competent product manager in a negative light. All I managed to get from them was weak platitudes about the product manager having a 'bad attitude,' and when I pressed for more details, I didn't get anything substantial. I was now mostly convinced that there was nothing wrong with this product manager.

I then reached out to all the people (including going all the way to the C-Suite) the product manager worked with on a regular basis and asked them for feedback. They all said mostly positive or a bit of constructive criticism. I was now fully convinced that there was nothing wrong with this product manager.

I wrote up my observations, including making it clear that I am standing behind this product manager and their competency, and I sent it all to HR and my manager, and the engineering leader. After a lengthy discussion with HR and my manager, they all reached the same conclusion I landed on. The provocateur got their hand slapped, and the product manager still works for the same company.

Personal Anecdote - 2

A long time ago, in a company far, far away, or maybe not too far away, I was an engineering leader in a mid-sized technology company. Shortly after I got hired, I decided to bring onboard a very senior engineer from my network as a Principal Engineer. This way, I could focus on up-leveling the managers, and the talent management processes, shoring up the product development roadmap, and ensuring the organization structure scales with the company. And the Principal Engineer could focus on up-leveling the engineering skills of the engineers in the company, solidifying the technical design review process, and mentor the engineers with their careers. I had no intention of hiring another Principal Engineer, so my goal was to give this person a lot of scope and autonomy. 

I have very rarely met extremely smart individuals who are not quirky in a noticeable way. This Principal Engineer (PE) was no different. He was logic driven all the way and had very little patience with people who argued on the basis of anything else besides logic. When he lost his patience, he was in people's faces and would quickly make them uncomfortable. However, he also cared about the emotional well-being of the engineers in the company and spent quite a bit of time helping them navigate career, work, and sometimes even personal challenges. As a result, I got an equal number of complaints and praises about him from the company. But the one thing I was sure about was that he truly cared about the success of the company and the people in it, so I provided cover for him whenever pockets of the company raised their pitchforks at him.

One of the things he deeply cared about was diversity inside the engineering team. Software engineering is still a male (specifically white and asian men) dominated industry, and my team was no different. One way to increase diversity in organizations is to remove bias from the hiring process, and this PE wanted to change the hiring process to be more inclusive. In his proposal, he outlined many changes, including one that almost cratered his career at the company. In his proposal, he posited that a non-diverse interviewing panel would keep hiring non-diverse individuals, so he proposed changing all future interviewing panels to require a person of color, a woman, and a member of the LGBTQ community. When the engineering leadership team (me and my direct reports) and HR leadership reviewed the proposal, it felt right. Taking a stronger stance (requiring diversity in the interviewing panels) would move us in the right direction, so we greenlit the changes. None of us realized that we were holding a neutron bomb that was about to go off spectacularly with the principal engineer catching most of the blast with his face.

The PE got the engineering team together casually every week to exchange ideas, discuss issues coming in the way of productivity and how to solve them, etc. He casually shared his proposal with the broader engineering organization in that forum. Everything was going fine until he got to the part about requiring a woman, a POC, and a member of the LGBTQ community in all interviewing panels. The backlash was severe and swift. 

The first issue that the group raised was that the diversity requirements were not discussed with the people (women, black, and LGBTQ folks) who are now required to be part of ALL interview panels. There were only a handful of women, a couple of black and LGBTQ folks in the company. This meant that they would be part of ALL the interviewing that would happen in the company for the foreseeable future. That is a major time commitment (on top of the regular project work they were assigned), and this was the first time they heard about it.

The second, bigger issue they raised was tokenism. The few diverse folks in the engineering organization rightfully pointed out that making the hiring panels diverse was largely a symbolic, meaningless gesture that won't change much in terms of diversity in the engineering organization but instead overburden the tiny group of diverse individuals in the team. They wanted to see changes at the top of the recruiting funnel. They wanted us to source candidates from much more diverse channels. They wanted us to hire from historically black colleges. They wanted us to hire more from coding schools which typically have more diversity than a traditional engineering school. In short, they were furious. The PE was thoroughly embarrassed and ended the meeting by saying, 'If I speak more, I will make this worse, so I am ending this meeting. Sorry.' 

I heard all of this second-hand as I missed that meeting due to a conflict. I jumped on a call with the principal engineer to get the full details. His usual confident, imposing demeanor was gone. He had his fingers interlaced tightly before him and anxiously rubbed his palms against each other. He was avoiding eye contact with the camera and instead was nervously gazing away. He explained what happened in quick bursts of anxious energy. Interspersed throughout his distressed narration were numerous lamentations of, "I fucked up." 

I told him that, yes, he did mess up. I told him that his only mistake was not getting feedback about his proposal from a diverse group of engineers earlier in the project. I also told him he wasn't a racist, probably answering a question he was asking himself in his overheated head. I reassured and reminded him that his intentions were noble. I also pointed out to him that the leadership and HR team had greenlit those changes and were equally responsible for the misstep. Lastly, I told him that I got his back.

But sadly, it didn't help. He was spiraling down into a deep pit of self-doubt and despair. I knew he would be deeply unproductive if he went back to work. I told him to take a couple of weeks off to recover from the blow to his psyche. He immediately accepted. But before he logged off for two weeks, I told him to write up an apology and post it in the engineering slack channel where the entire organization congregated, which he did. I also told him to personally reach out to the people who called out his flaws and apologized. Which he also did. 

Then I personally reached out to the folks who raised concerns about the proposed hiring plan and individually apologized to them. We spent quite a bit of time discussing the personal intent of the principal engineer who designed the plan. A few of their initial reactions were to label the principal engineer a closeted racist, which I knew was completely off base. Some of them wanted this principal engineer fired immediately. Some of them wanted me fired because I was defending him. I walked them through the entire episode in detail, including how it started with the principal engineer passionately arguing for building a diverse engineering team and its benefits. I reminded them about the instances where he personally helped with a project or helped them out with work-related conflicts. Lastly, I also personally vouched for him. I repeated this exercise with multiple employees (including the CEO) for many weeks until people's minds started to change. It was a grueling mental exercise, but I knew that if I don't defend him, nobody will. In the end, everybody agreed that the principal engineer's intentions were good, but the execution was flawed.

The people on your team are your most valuable asset. It is your job as a manager to take care of them through the good times and the bad. Especially the bad.

If you all have additional thoughts, drop them in the comments!