How to defend yourself without sounding defensive or aggressive

Question

I'm a senior developer on a project. Because I'm the most senior, I was given the role of an informal dev lead to control and guide the dev team when needed. Apart from that we are doing scrum.

The Product Owner - who's the only person responsible for backlog selection and prioritisation - now told me that I'm burning the dev team down.

The problem is I have 0 impact on what we are working on. Actually, we (meaning the whole team) have already had several discussions with him about him assigning too many points per sprint. I do occasionally point to possible problems with the designed solutions during the review and I do, when needed, point to the need to test when the code that is demoed has not tested - this type of things. But good coding practices is something we agreed to follow at the beginning of the project and I leave it for him to decide what to do with the situation.

What do you do in such situations? I'm not ok with him directing such accusations towards me. He already accused me of something else in the past, which resulted in a not very pleasant discussion with my boss, although I don't think I had done anything wrong.

I could among others:

• contact my boss directly, tell them about the accusations and why I don't agree with them and that I find it worrying to receive such "feedback" to preempt the colleague escalating that to my boss

• tell the colleague verbally or in writing that I don't accept such accusations

• write to the colleague with my boss in cc quoting the accusations and stessing that it's his and only his role to prioritize the backlog

• shut up and pretend I didn't hear it

I work in a culture in which escalations happen a lot.

Answer 1

How about setting aside the idea of "defense" and "accuse" for a moment. This could work out great for you.

First, do you think that someone is burning the team down? Is that happening? Would you like it to stop? If so, and especially if you think it's him, this is fantastic. He has come to you and said "the team is burning down." Great! You are on the same page! You both agree there's a problem!

Second, he has come to you to talk about what to do about it. This is also great! Never mind who is or isn't burning them down, what are the options the two of you would both support and agree to that will stop them burning down?

Maybe he thinks his role is to throw possible work at you and your role is to say no to some of it and defend the team. Maybe he thinks you're over-engineering or over-testing and need to accept less of it; you can probably calmly talk about how teams get super randomized by bugs that show up when they think they are done, and planning effort for things becomes very difficult in that environment.

Whatever it is he thinks you're doing that is burning the team, he may be wrong about what you're doing or whether it's good or bad. So what? He has started a dialog and offered to discuss what it might take to keep the team unburned. That's great. Continue that dialog. What are the two of you going to change to help protect the team?

(As for trying to rebut the accusations, defend yourself to this colleague or your boss, or other actions listed in your question, I suggest doing none of those. What matters is fixing your current situation. If you work together with this person, you may be able to change what he is doing and thus protect your team. That is very important. You may be able to get more people, or otherwise make the changes that your team needs. And showing yourself to be someone who can make meaningful change even with people who are unprofessional and throw around accusations? Don't think that goes un-noticed.)

Answer 2

Well that's unfortunate. Let's break this down.

You the tech lead do not get to say what are you working on. The way you influence that is that you take in the spec and draft a sensible way to go about it. Managers want feature Z before feature X, which is a totally ridiculous thing to do architecturally? Instead of hard turn down, come up with the ways to do it: make a tech demo or mockup separate from the rest of the project or quote them two months worth of tech debt down the line spent on refactoring. You are not a marketing professional and, quite possibly, not even an expert in the project subject area. You are a tech expert. If the owner starts arguing with you about tech things or how long features should be taking, there's not much to be done, really. No trust in people you hire => no good work could be done. Micromanaging owners are terrible and they might as well just keep hurting themselves, don't waste time on it.

But very, very importantly - don't cross the line from your side, either: ridiculous as management requests might be, push back on them in a cooperative way, offering solutions instead of critique.

Worst case scenario here is owner driving the project to the ground with creeping tech debt and overworking the team, not much to be done here. IMO, if you say "this will take 2 weeks" and the owner straight away says "you must do it in one or else" one should consider quitting. Maybe there is someone else who can finish it within a week who's not you - but if your expectations for the work don't match with your employer's, it's a long downwards spiral with no real benefit to either. I've seen people who'd hire team after team only to come to the conclusion "huh those programmers suck, charging way too high and quoting ridiculous deadlines for simple features", and there's just no real reconciling with those.

Answer 3

The push / pushback dynamic between product owners ("the business") and development is not a new one, and agile techniques were in part an attempt to defuse it and turn it into something more productive. I agree with some of the other answers that you should keep the dialogue going with the Product Owner. You should clearly and politely state that they set priority, not tasks. In a crude way, the somewhat unprofessional comment about "burning the team" indicates you are successfully pushing back, such that the team see a dilemma of choosing who to please. Of course when talking to the product owner they are going to complain about the other guy (you).

In addition, it's clear that the product owner wants to go faster. Maybe there's a good reason for that? Maybe there's even things about the system that slow delivery down ... like not have good automated test coverage? Maybe you only get one decent release out every two months?

It's better if you sort it out with the product owner directly. If you have not talked to them one-to-one, face-to-face (or video), you should do so. It's not unreasonable to ask for backup from your own manager, though, especially once direct discussion has been tried. I would definitely not do it by email and cc. Reach out to your manager and explain the situation. Suggest the product owner needs to understand the boundaries better. Then after listening to feedback from your manager, if they agree with your analysis and will back you up, setup a face to face or video meeting with the product owner, yourself, and your manager. Reiterate that "burning the team down" is not fixed by "burning the product down".

Secondly, and in the same meeting, present your concrete plan for making the development go faster. This will have the usual "to go fast, go well" dynamic, but it foregrounds that goal of faster higher quality delivery, rather than something that can come across as esoteric technical concerns or nice-to-haves.

Answer 4

Document everything, and communicate more

You said you believe he's "assigning too many points per sprint." Have a face-to-face conversation with him and tell him exactly that. You can say that you believe that you've been "set up to fail" by over-committing to work that you don't believe you'll be able to get done, and that you're skipping out on the agreed-upon code-standards like testing for the sake of meeting deadlines.

Perhaps your developers should start choosing how much they commit to, and choose how much they believe they can get done in a time period, rather than having someone from the outside assign how much they think the dev-team can do in a sprint, have the developers self-assign, or pick however many stories they think they can get done within the sprint. You know how many points you completed last sprint, and the sprint before that, and your team has a velocity of points that you regularly complete on average. There's no point committing/assigning more points than the average number of points you've completed in the past in a sprint.

Make sure your boss is informed of delays

If something takes longer than expected, tell your boss, and the Product Owner. Provide the backstory and all the relevant details. Tell what was different, and tell him how you're handling it. More details doesn't hurt, no matter how small or boring those details are, he should know everything that's happening and anything causing a slow-down. It's important that nobody is surprised when something doesn't go as expected, everyone should already know well beforehand.

The "burning down the team" comment sounds too vague and general, ask for clarity

I personally would ask for clarifying specific details of who, what, when, where, why, and how did I burn down the team; how much has the team burned out because of those actions, and to quantify the benefits of an alternative method? Anything that sounds too vague needs to be clarified, and if something is inaccurate, point it out with the evidence you've documented.

Correct any distortions of the truth by adding the context

If you think someone exaggerated, edited what you did or said, removed parts of a story (not the scrum kind), or took something out of proportion or context, I would respond to those distortions immediately, and include the background story and context. There's always a history behind everything, so explain the history, the story, and any bumps along the road.