0

I have a team-wide performance problem on the team I inherited about a year ago. No matter their title, the senior+ engineers on my team perform at the level of a junior engineer (objectively, according to the company's leveling rubric):

  • They don't reach out to other partner teams for guidance in advance for work that involves changing things in other teams' purview, leading to a week, or sometimes several, of time spent undoing work on their PRs that wasn't kosher with the owning team (even if the correct solution was documented or when there have been several announcements that certain infra is thorny and that it's critical to reach out in advance).
  • They can't ask questions on their own. When I've pushed them to reach out to X team to see what they think, they won't tailor the question to the audience, dump whatever they're asking without context, and then get 0 responses until I provide them a question to copypaste which does get answers. Then I have to help drive the conversation once it starts up to provide additional context as it gets asked. I explain why I worded the question the way I did, but then this repeats anyway
  • They don't try to keep themselves in the loop and aware of what's going on outside of the bubble of our team. Even things that are widely messaged across the company might go unnoticed. It seems like the team tries to distance themselves from anything not immediately related to our work, which makes the above two worse
  • The two most senior engineers on the team which I would expect to help level up other engineers perform under the level some of their more junior peers, and don't push team members to do the right thing

I've been very upfront with my reports on what I expect of them, especially the two most senior engineers. I'm constantly messaging, widely across the team and individually, that they need to reach out to other teams in advance to align on solutions well before the PR stage. There's even an existing weekly review of the teams in our circle where anyone can bring questions, proposals, and plans for feedback, but my team doesn't take anything there unless I explicitly ask them to. When they do after I ask, the wider review group is always positive and thanks them for bringing their questions to the group. The teams that I point them to ask questions to outside of this meeting are also very helpful. And, of course, I've gone over the leveling rubric with my reports in our 1-1s and clearly pointed out to them that I expect them to be doing these things. All to no avail. What to do when an entire team isn't receptive to feedback?

I suspect this to be a widespread case of imposter syndrome. The teams we work with are all extremely talented. From my interactions with my reports, I get the impression they don't want to come off dumb or feel like they're not "real" enough to involve themselves in areas outside of my team, even though the other teams are welcoming. I also have an inkling of a suspicion that they avoid keeping me in the loop if they know I'll ask them to talk to another team. I'm stuck on how to address this. Things I've weighed:

  1. Become very process heavy. E.g. each engineer has a weekly checklist: "Did you modify external code?" "Did you talk to external teams?" "Did you get a response from external teams?" to shift it to where engineers have to actively lie in order to continue performing below level. I don't feel like this would be particularly effective since it's just further hand-holding that I'm constantly having to codify into as much bureaucracy as possible rather than addressing the culture issue
  2. Bring in a new hire that performs at the expected level to help be a role model for the team and can one of the existing two senior-most engineers (limited positions). Not sure how well this would work out given that firing someone might just cause engineer confidence to further dive off a cliff and remove motivation for bettering themselves, and I have retention concerns for bringing on a talented expert to be a babysitter.
  3. Can everyone or work with leadership to reorg so that the low-confidence engineers are spread into other teams that set a better example and can more effectively enforce a higher bar that their team is already operating at. It's been extremely effective for individual engineers from other teams that were moved elsewhere in the past, but given that this is for an entire team, and, selfishly, reflects poorly on me, I don't think this is practical

None of these seem particularly appealing to me. Are there any other options I have to bring my team out of its shell?

11
  • 2
    Why no disciplinary action? Seems you're empowering their behaviour
    – Kilisi
    May 21 at 6:20
  • I would imagine that downleveling them or other disciplinary action would just kill any drive they had to perform their job. May as well just fire them, which then affects the rest of the team's morale. I would have fired the two senior-most engineers already if the rest of the team was healthy.
    – Drudge
    May 21 at 6:25
  • 3
    Sounds like there needs to be quite a few demotions. May 21 at 8:39
  • 2
    Please answer the following questions - 1. How did this team come into being? 2. What was the team's performance under your predecessor? 3. What was the performance of the team members before they got in this team? 4. What kind of problems are they solving? Have you gotten someone at an Engineering Manager or Architect level to look at the scope of the problems? The point being, a team up against a brick wall will neither be productive nor motivated. 5. Becoming process heavy is not the right solution. Dig deeper, into the root causes of the problems and of the tech stack/codebase they have.
    – dakini
    May 21 at 9:49
  • 1
    Are you technical yourself? You said they make UI, are they the only frontend team? Is "frontend development" a well-regarded function within the company? I ask because many serverside engineers (dis)regard frontend as easy work. How good are the team at verbal and written communication in general? What is the quality of the documentation they produce? What is the quality of their overall codebase? Is it easy to read and well-commented? What is the quality of their code/work - are they many UI related bugs reported? I want to ascertain their technical and soft skills independent of each other
    – dakini
    May 22 at 16:00

3 Answers 3

13

I suspect this to be a widespread case of imposter syndrome.

I suspect you are wrong. There are multiple points in your list, that have nothing to do with impostor syndrome.

For example, not reaching out to other teams might be impostor syndrome, but if they do reach out, they completely fail basic communication when they don't build context and tailor their communication to the recipant. They don't think they lack the skill, they actually do lack the skill.

Another example is staying informed or in the loop. This requires zero skill or even perceived skill. Apprentices can already read mails and documentation. It is passive reading. You can be perfectly informed by just lurking and reading and nobody will ever know. If they don't do it, they don't think they lack skill, they do lack skill.

What to do when an entire team isn't receptive to feedback?

Quite frankly, at some point those teams were build by external force (a boss, a reorg of the organisation) and I wonder if maybe that team was the leftovers after they built good teams from the existing people.

That team is not seniors. If they are paid as seniors, they need to be set on some disciplinary path and either demoted or fired. The juniors might be savable by putting them in other teams under persons that actually act as seniors, so they can learn. Personally, I would not redistribute the "seniors". It won't improve their skills, it will just give them a good team to hide behind and get their paycheck for skills they actually don't have. You could offer them rotation to other teams and demotion to junior, but I doubt they would take it. Maybe they would be happier to take their senior title and start new at a company that doesn't need the skills they lack and that are fundamental at yours. Who knows, they might be really good in companies with 3-5 developers, where communication and work across teams is not needed. Preferably a company that builds everything from scratch and doesn't have to integrate with third parties.

But they don't fit in your company. Where communication skills are needed. And they don't have them. They don't think they don't have them, they actually don't. So take action accordingly. You might be surprised when you take that to your bosses (those who decided who is in which team), they might already know this.

7

This isn't a shell or imposter syndrome, it's plain incompetence.

Without discipline this team will never act professionally and it's unlikely that it is the whole team.

More likely the seniors are incompetent and the juniors are covering their own backs. This would be normal defense for juniors when their team is not performing.

I suggest you implement some disciplinary action on the seniors who should be setting a professional example and worry less about hurting their feelings or morale. This team has no morale right now to lose. It's just plodding through paycheque to paycheque getting constantly in trouble.

Some will wake up, some will fire themselves. Depends if they're being held back by inertia from above or not. They may all fire themselves, either way there is nothing to lose. Or the juniors might see a chance to finally do things properly and step up.

3
  • 3
    I'm with Kilisi. Imposter Syndrome is not an excuse to do a half arsed job. May 21 at 8:41
  • Disciplinary action as in write ups or demotions? Or did you have something else in mind?
    – Drudge
    May 21 at 11:34
  • 2
    Whichever. If you've already talked to them informally a few times it's a waste of effort continuing that road. Writeup is the softest option but affects the individual in time, demotion has an immediate effect on the whole team as it's a very clear heads up to everyone. So it's up to you how fast you want to bring things to a head. Either way you should be looking at hiring at least one replacement.
    – Kilisi
    May 21 at 12:26
2

So you are supposed to be a team leader (or manager) but the team have effectively taken control, shutting you out.

I think you are being too charitable in suggesting this is impostor syndrome; the opposite extreme would be to suggest this is insubordination syndrome, but as ever, the truth probably lies somewhere between the two.

The general impression given by your post is that you are taking a task-driven approach, and I'd suggest you take a more personnel-driven tack. You need to understand what is going on here on a personal level, rather than brow-beating them with more task objectives.

So you need to have informal one-to-one conversations with the staff, stressing that it is off-the-record, and you are in listening mode. This may not be easy; the feedback you get may be tricky to handle (e.g. they might say they were perfectly happy with the way things worked before you came along, and don't think your methods are appropriate) but at least you get to understand the gulf that has to be bridged, and hopefully gain some clues how to bridge it.

The other function of these chats would be to start building trust with the team; this will take a while, but gradually they may start opening up to you, see the merit in what you are saying, and accept your authority.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .