How to handle product owner overrule technical team lead?

Question

My team builds a notification system and we have designed an integration flow and how to use our system. Earlier this week, we found an issue in our product where it sometimes sent multiple emails instead of one. We have got less than 10 reported cases last week.

We found the root cause and agreed to fix it next week. Yesterday morning, I got an email from the PO that she asked engineers in my team to change the system such that it uses a different mechanism to send the notifications. (I was not aware of this mechanism, which is another issue I will discuss with my team.)

Looking from her perspective, I understand that she wants to mitigate customer impact. However, this hack changes the integration flow between various systems and I have problem with this approach.

1. I would like engineers to fix issues properly instead of finding a workaround. I am new to my company but I have learned that people get used to workaround and I want to stop that
2. This hack creates an impression that we have fixed the issue when we have not. The behavior might be different when we properly fix the issue and I do not want to explain why it changes again.

I am frustrated and will talk to her this afternoon. I wanted to tell her two things. First, it is not OK to overrule what agreed upon - if she disagrees with me we can talk. Second, I wanted to stop a workaround solution and focus on fixing problems the right way.

How should I approach this meeting and discuss the implications of her actions?

Answer 1

TL;DR: You are new to the company, so I would be treading carefully. You want to lead the team to excellence in the long term, but you might not want to immediately pick a fight with your PO.

In general, I think you are right to object. Your PO overruled a technical solution you agreed on, which is out of place for a PO. At the same time you need to make sure that you have a good working relationship with your PO and do not pick a fight you cannot win.

What I would do in your situation:

1. Be ready to let this specific instance go. It is annoying, but you can always do a better implementation later. The world will not end, if the team is using a sub-optimal solution once.

2. Check with my managers and peers, what are the written and unwritten rules in this case. If you were to challenge your PO on this, would you have the backing of your manager and your manager's manager?

3. Discuss in general terms with your PO, how you each see each others responsibilities and have a working agreement. In my experience with POs they are usually very happy to leave TL business to the TL when they can trust them, to get the job done. POs don't want to micro-manage developers, POs want to spent quality time with Power Point Slides and be in long meetings with other POs.

Don't risk the trust and goodwill of your PO in the first disagreement. Collaborate with your POs in the framework of what is normal in your team and then work on gradual improvements from there.

Answer 2

You have a sense of ownership of the work you do. That's a good thing.

But you don't actually own the product. Explain your concerns to your manager. If they follow your guidance and recommendations, that's great. If they don't then you need to find a way to either live with it or you need to move on to another company.

You can only take responsibility for those things that are within the scope of your responsibility. You can only change those things that are within your authority to change. If your manager rebuffs you, there isn't anything you can do about it.

Answer 3

The first thing would be, if there is an established process, just email them back and say 'This isn't the process we've agreed to, you would need to raise this with...'.

Failing that, if the PO still insists then I'd take one or both of these approaches:

If you're doing scrum, then talk to the Scrum Master

The Scrum Master's job is protect the developers from the Product Owner's demands, and make sure that the processes are being followed.

What you're describing does sound like, if indeed you're doing scrum, the PO is overstepping, and the SM needs to do their job and put them back in line.

Clarify with your manager about what the chain of command/what the expectations of you and others in your team are

Let's say you talk to the SM and they're unwilling to push back, or you're told to do what the PO is asking anyway.

Or, let's say that you don't have a scrum master.

What I would do is talk to your direct manager - and have a frank conversation about what is expected of you.

What I have found in most jobs - is that within the company's org chart you will have a formal manager - but they're typically pretty hands off, approving your paysheets etc, and the person who is actually managing you is someone else (typically also under your manager) with the job title of 'tech lead' or 'senior developer'.

So what I would be doing is sitting down and having a frank conversation with your manager about 'What is expected of me? Is it my job to just do what the PO says? Is it my job to do what the tech lead says? Is it my job to weigh in with my own professional expertise and do what I think is right?'

You can basically tell you manager what you've got here, and ask them to clarify.

Nail your manager down on that, and get it in writing.

If you manager says 'Your job is to do with PO says' - then that's conclusive, and it's no longer your problem if things go wrong as you say. On the other hand if your manager says that you should be doing what the tech lead says, or using your own judgement, then you can just push back against the PO and ignore their requests.

If the manager has clarified that it is the SM's job to push back against the PO, and the SM isn't doing that, I would refer that to your manager - telling them 'Look the SM isn't doing their job, and that's making my job difficult'.

Answer 4

It sounds like you're using Scrum methodology. If so, send the PO back to the Scrum Guide, and ask them to show you exactly where it says that the PO can tell the development team how and when to do something. She should be concerned only with outcomes (i.e, only one email being sent). How that outcome is reached is for the development team to decide. It's issues like this that correct implementation of Scrum explicitly wants to avoid.

Answer 5

Concerns about short term emergency fixes are certainly valid, it’s human nature and happens pretty much in every industry.

It happens because emergencies happen, and you DO need to do the short term fix. The solution to this problem isn’t to declare that you won’t do emergency fixes, it’s a culture of committing to quality and cleaning up after such exceptions.

The emergency shouldn’t be considered resolved until the correct fix has been determined and implemented.

Now some emergencies aren’t emergencies at all, and letting non-emergencies derail your process is problem. But that is why you need buy-in for any process management, people need to understand what the process is and how things get prioritized and done. Otherwise you just spend a lot of time and money, without accomplishing anything.

Answer 6

My thought on the root cause here is that the PO doesn't trust that the solutions that worked out between the two of you are the best for the customer or the business. And the lack of trust works both ways - since you have no reason to trust that the PO will include you in decision making, obviously recent actions have shown that the PO will go around you and negotiate separately with the team.

That's a big deal, and not a great way to start off at a new position.

My process would be:

Find a time to have a private meeting with the PO. In that meeting:

• Ask and listen to why she agreed to 1 thing with you and then went around you. Let's start by assuming she's not evil. How is the customer best served by this?

• Have reasons why workarounds and this one in specific have a really negative effect. I suspect we all know they are necessary sometimes, so pick which battle you want to fight here. Dig in on this one and learn why the secret API would be so bad. It's harder to fight with nebulous information like "workarounds make a pile of technical debt that can have unintended consequences and create big work in the long term maintenance" - there's nothing definitive there. And if you're not in business next year, then the long term maintenance doesn't matter. But if you dig in on this one and find out "the secret API being proposed in this case has these unintended consequences... that's why we shouldn't use it" - and also "if we cause these consequences, and then undo the work later, then we induce several sets of adjustments for customers, and I worry they will loose faith in the product" - then you are giving a real business related reason. But you can't fight this fight with non-specifics. Another good specific is "it takes 1 day to use the secret API, it takes 3 days to do it right, and with our release process, the time to getting to the customer is on date X either way" - then you have another good solid reason to do it right the first time.

• Get her engaged in a proposal for doing this different (in a way that includes you) next time. I rarely find that ultimatums work - in a way it's like coaching - a solution that she, herself, proposes that meets your approval is more likely to work than something you dictate. That may mean adjusting in ways that are not optimal - but you give some to get some. I'd rather, for example, be texted or called at an inconvenient time to be able to give my input, rather than have a process that is painless but never used.

• I also rarely find it useful to try to set up a scheme where people don't talk to each other - generally if my Product Manager wants to talk to my engineers - I'm happy to have it, as long as I get input on what they cook up. For some engineers this is extremely empowering (for others extremely annoying) and so I coach my own team as necessary to be good code custodians and not let the PO go too crazy. The ones who like talking to product managers may be development managers some day. ;)

Have a talk with the engineers - I know you said this was a separate issue...

• But it's not. Easily half the problem here is that your team didn't say "Code Project needs to approve this" - if they deferred to you as an approving authority, the PO wouldn't have been able to change the strategy. Your authority comes from what the team grants you as their boss.
• I wouldn't probe a lot for "why" on this, but there does need to be a conversation on your expectations for how/when you should be included. It's great that they want to do urgent things for the customer and the product - but it's also important to do what's right for the code base. Engage them in the research for the conversation with the PO - get them thinking and explaining the down sides of the option. If there are none - then let's not fight this particular battle, let's just fix the process for next time.
• Again, be open to a process that gives the team some autonomy but that allows you the ability to sanity check the plan and have input before it becomes a done deal.

Hold everyone accountable in writing.

This is a new process - it's worth writing down. Once you've gotten agreement on both the PO side and the team side - send one mail to everyone. The tone should be analytical with no judgements and have very clear statements on who does what and in particular, what is necessary for an engineering commitment to be considered final.

You may have different processes and conditions for different timing - for example, this may be only the process for urgent bugs. New features may have a much slower cadence - so you may need to also say "this is for bugs of severity X, which require an SLA of Y".

I'd suggest including a "this is effective immediately" clause or a "open for comments until DATE at which time it becomes effective" - so everyone is very clear that this is how we're doing stuff now.

Check in/wrap up

Let some time pass and ideally another 1 or 2 of these types of situations happen. If the process is working - finalize it in a wiki or other commonly accessed team resource (email is a good way to loose stuff).

If it's not working - get folks together and fix it.

If it's not working because one person is a persistent problem - it may be time for more coercive/direct action (like escalating to a supervisor) - but I think we're a long way from that.

Answer 7

The short answer is: you're developing the product that the Product Owner asks for. Because when rubber hits the road, the product owner gets to decide what's in the product.

Don't get me wrong - you definitely have a vested interest in developing a maintainable product without oodles of technical debt. And you definitely shouldn't just blindly say "Yep, will do!" to anything they say.

Instead, you need to bridge the gap to figure out what the PO's after, and explain the pros/cons of each option under consideration (and possibly propose alternatives). And if the PO understands the Cons of a particular approach and chooses it anyway - then it's your job to proceed along that choice.

Additional Note About Technical Debt

You put a comment of:

From my experience, adding technical debt hurts productivity and quality in the long run

There's a reason they call it technical debt. Debt itself isn't bad. Businesses take debt all the time to spur growth. What's bad is debt that isn't repaid, debt that just builds and builds.

In other words, there's absolutely nothing wrong with this course of action:

"Okay, so we'll switch over to Method Y as an interim fix. We'll add an item to the followup sprint to switch back to Method X and patch the issue - and then add a second item in the third sprint to clean up the artifacts caused by Method Y."

Yeah, you technically have more work than if you just patched the issue to begin with. But it has a different cost (time to get the issue fixed for the customer). Is that cost worth the additional time that the debt causes? Quite possibly.

Short story - assuming technical debt itself isn't bad, as long as you have a plan to pay for it.