0

Our company's entire product team was let go (a few months ago) because of differences with key executives (on how the product should evolve). This team had product discipline and thought independently.

The executives quickly assembled an entirely new product team with players that were not recommended by the interview panel. The new team has been moved down the organization structure, presumably to clip their wings. The new team is keen on impressing the executives and they have made it clear that the team should toe the line.

I am having to work with one of the new team members. This new member

  • doesn't listen to what I am saying and hears what He wants to hear. What He wants to hear is mostly based on his negative assumptions about existing processes and products. During a product orientation session, I was demoing a neat feature of our product (one that has received several accolades from our clients). The new member started snickering for a few seconds and attributed the feature to unrelated product issues.
  • acts like all existing team members don't care about the product and He is the only one that truly cares about it. On one occasion, an executive reported a typo in the about page of the product (a low priority bug) and He disrupted the entire engineering team because He had promised a "momentary" fix to the executive.

These are my questions:

  1. When He makes such negative assumptions, how do I firmly (but professionally) call it out? Besides calling it out, is there something else I can do to suppress this behavior in him?
  2. Under pressure (from people like this new guy that has the ear of the top management) I tend to take shortcuts to deliver "momentary" fixes (that this guy is more than happy to promise). I take my work seriously and care about it (it is more than a 9 to 5 for me). I understand that these shortcuts are detrimental to the product in the long run. How can I stay true to my values and not give in (If I take more time, He might report to the higher-ups that I am not as committed to a quick solution as He is)?
  3. Are there solutions (to deal with this guy) that I am not thinking of?
  4. If you have come across such characters, are there other issues I should expect?
6
  • What is your role in the organisation and team, and what development methodology are you using? The answer will depend a lot on whether you're an entry level developer or the CTO. Jul 11 at 15:31
  • 1
    Also: "an executive reported a typo in the about page of the product (a low priority bug)". Who determined it was a low priority bug? If the product team says it is high priority, it is high priority. Jul 11 at 15:31
  • @Philip Kendall, I am a senior engineer. We use Kanban.
    – Ram
    Jul 11 at 18:07
  • 2
    The executive team didn't like the way things were going and replaced the product team with a hand-picked team over the remaining team's recommendations. To me it looks like there is a mandate for change and a belief that the team has underperformed. Do you really think you'll make any headway in changing the behavior?
    – pft221
    Jul 12 at 2:14
  • 1
    With the way things were going I also had a hunch that there is a "mandate for change". Thanks for putting the finger on it. I was hoping there would be strategies to influence the behavior.
    – Ram
    Jul 12 at 15:06
2

When He makes such negative assumptions, how do I firmly (but professionally) call it out? Besides calling it out, is there something else I can do to suppress this behavior in him?

Directly address the behavior as it happens. If he snickers in a meeting again, say "Why are you here if you're not going to take this meeting seriously?" Same with being dismissive or other disruptive behavior. Call it out immediately and make him explain his behavior.

How can I stay true to my values and not give in (If I take more time, He might report to the higher-ups that I am not as committed to a quick solution as He is)?

Make sure your doing Continuous Integration so you can show the executives that each change goes through a battery of test and once it passes is available on a development server. This process should be automated, so executives can see an automatic quick turnaround.

Once you have CI/CD in place, as a team (including the new team member), need to decide on coding and test coverage standards, and the entire time needs to enforce it. Let the new team member advocate for quick turnaround, and you can advocate for higher test coverage and more code standards. He'll likely be more receptive since he gets a say in the process.

Are there solutions (to deal with this guy) that I am not thinking of?

It sounds like he likes to make snide comments about people's work. Calling out these comments and putting him on the spot may fix it. If it doesn't, you and any other team members who feel targeted need to speak with him as a group. Give specific examples of bad behavior, and say "This behavior needs to stop or we won't be able to work effectively with you as a team."

You can try freezing him out and making his work life miserable, but 1) it's also difficult on you to blatantly ignore people 2) he'll probably run to management.

I would start looking for a new job as it sounds like you'll likely get in management cross-hairs for this

If you have come across such characters, are there other issues I should expect?

Yes, I refused to work with him after he lied to me. I made sure everyone knew about it and got transferred. I was also prepared to quit if I had to continue working with him.

2
  • 1
    It is important to also note that your choices are backed by direct interactions with the customers, and if you can pull it off smoothly, you might want to indicate that the customers buy our product, and are ignored at the company's peril.
    – Edwin Buck
    Jul 11 at 23:03
  • 2
    IMHO saying (and calling that out in a meeting) "Why are you here if you're not going to take this meeting seriously?" isn't addressing the behavior. It's addressing symptom of the behavior and I also feel that it is passive aggressive. IMHO The OP should only deal with technical issues in public and behavioral issues in private one on ones
    – Peter M
    Jul 12 at 11:31
2

Here is the important question: Is this person your boss/manager?

If not, why is upper management going to him to ask for bug fixes or issues? These requests should be going through your manager and/or scrum leader, who triages requests, creates tickets, prioritizes, and assigns them. You should never have a case where one developer promises something to be done "momentarily", and another developer has to pick up that task immediately; either the person who makes the promise should do the work, or the work should not be promised "momentarily".

So, the first thing to do is to get your manager to be a manager. Inform your manager that you are not comfortable with the way that this person is handling task allocation, and his irresponsible promises to management causes an impact on your work, as you often have to drop your own tasks to pick up the slack from his irresponsible promises. Tell your manager that you should have someone on the team whose responsibility it is to take requests and prioritize them in a way that makes sense, and strongly imply that this person should be the manager himself (because it should).

As for the issue that this person thinks nobody else cares about the product, inform this person that there is a backlog of work to do, and things get prioritized. Everyone is working on their own assigned tasks that need to get done, and because everyone doesn't drop everything immediately when management throws a hissy fit over a typo, that doesn't mean nobody cares; it means people are busy working on other things, and management's hissy fit will be resolved in time when someone can do it. In the meantime, if this person has extra time after his tasks are done to take on management's urgent issues, then he should do it. If he wants to raise the issue after the fact, then he can do that; you should have sprint retrospective meetings which would be a good time to raise those issues with the whole team, or he can raise the issues with the team leader directly via email or private meeting if he prefers to do that. The point is, ad-hoc yelling at everyone on the team whenever and wherever is not a good way to go about airing frustrations.

As for the snickering during the product orientation, just let it go. He's new to the team and he doesn't have context on the product. Eventually he will learn. That, or, perhaps he has a better way of doing this feature, which will perhaps be really good; if he thinks his idea is really good, suggest that he pitches it to project management and maybe they'll listen to him and make the product better. As developers, you are not empowered to make product direction decisions on your own, but if his idea is really good then the people who do have that power will take his idea and change the product in the way he suggests. But in the meantime, just let it go; he's new to the team and he'll deal with it.

2
  • He is not my boss. We both report to different managers. You bring up an important point. Typically is it the product manager or engineering manager (my boss) that assigns issues? In this case, this guy is the product manager of the said product.
    – Ram
    Jul 13 at 12:46
  • If he is the project manager then he has the ability to make promises to management. However, you should inform him that every time management throws a hissy fit, that doesn't make it a priority 1 issue, and it's part of his responsibility to make reasonable promises to management in line with what the developers can deliver. As for the rest of my answer, a lot of the content changes in light of this person being the PM, so take the rest of my answer with a grain of salt; I wrote it under the assumption that he was a fellow developer, not a PM.
    – Ertai87
    Jul 13 at 14:45
1

Letting an entire team go is a massive red flag. Product people don't just disagree with management for the sake of it. Also standing up to management is usually a sign of a principled team. Poor performers usually become yes men and keep their heads down. Also why hire this team if they didn't share a common vision for the product. This all stinks. From your tone it sounds like you had respect for the departing team little respect for the incoming one. I would evaluate how much you really want to try to make your current workplace better. It might be better to keep your head down while looking for another role. When dealing with people like this always remember that workplaces can be darwinian in that everyone has a survival mechanism. The more incompetent they are at real work the better they are at politics. See if you can reach and make peace with them. Indirectly tell them what you want and ask them what they want. If they see you as beneath them subtly warn them about how you can make their lives difficult. Just being professional may not work with people that aren't being professional back

You must log in to answer this question.

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