Should I take over stakeholder communication from direct reports?

Question

I started a new job 2 months ago as the manager of a small team. Two of the members of the team, let's call them Bob and John, are at the level of senior analysts with about 3 years of experience. They have established regular bi-weekly catch up meetings with the main stakeholders, who are themselves managers of other teams. All of the stakeholders have praised both Bob and John for their excellent work.

Bob has been doing a good job of keeping me in the loop, but he's not great at taking notes, clarifying what's the business need of the analysis, or pushing back against pointless requests (the type of questions that one can answer by thinking about the problem for a few minutes or use existing reports). As a result he gets saturated with ad-hoc work, and (1) he mixes what people asked him to do and sometimes needs to do re-work, and (2) this leaves him little time for strategically important projects.

John is not so great at keeping me in the loop, although he does seem to be doing a much better work at getting to the bottom of what his stakeholder need. Nevertheless, he has allowed his stakeholder to take over the decisions for questions that are loosely defined to be in the area of expertise of the analytics team (how should we AB test a new feature, how should we calculate a certain criteria, etc.).

Should I take over the communication with their stakeholders or are there better ways to deal with these problems?

Answer 1

Instead of taking over the communication, would it be possible to be part of the communication? If they are meeting in person, can you be a part of that meeting? Since you've only been in the position for a couple of months, you can have your stated role in the meetings to be observational only, being able to put faces to names of people you haven't met yet, and making sure that you understand what all is being asked of everyone there. It could be that after a couple of meetings, you're able to work with Bob and John directly on the things that you feel they need improving on, or it could be that you can see where the stakeholders are falling short. Either way, it gives you more options than just directly taking over the communication, but it also allows you the ability to directly take over the communication if that is what you end up thinking is necessary.

Just make sure that as you go into the first couple of meetings, you are established as just observing and developing your own understanding of what goes on and what is being asked. You don't want to undermine anyone's authority unless and/or until it becomes necessary. Any questions to you should probably be redirected to Bob/John or the stakeholders unless you are the only one capable of answering the question.

Answer 2

This depends a lot on what everyone's job descriptions are. Is it the job of Bob and John to interface with stakeholders, or is it their job to act on product requests for the company? In general, development teams (not only software development, but any kind of product design/development for any business) are in 3 stages: You have an "ideas man", a buffer person in the middle, and then an implementer at the end. The "ideas man"'s job is to come up with all the cool ideas that will make the product awesome, and then ask the implementation team to do it. It's the job of the implementer at the end to implement the ideas. It's the job of the person in the middle to make sure that those ideas come in at a reasonable pace with reasonable timelines and deadlines so the implementation people don't get bogged down with unnecessary scope creep or deadlines that are too tight.

Now, it sounds like your team may work differently, where there is no "buffer person" in the middle, and the people handling the requests are also interfacing directly with the people asking for features. Sometimes this works and is OK. Other times, it creates a huge headache. Mostly the headache is caused because the "ideas man" usually has some leverage over the implementers, in terms of evaluating their performance and (directly or indirectly) having hire/fire power over them, so the implementer can't actually ever say "no" to a demand or else they may be fired. This is why the buffer person is important, to separate their supposed performance from their employment record. It's also why the buffer person is usually management-level, so that project management doesn't have any hire/fire power over the buffer person.

That said, this is how things "normally" work. Your situation may be different. If things are working, things are getting done, and nobody is complaining, well "if it ain't broke, don't fix it".