Communicate to build trust and avoid meddling and micromanagement

To me there are two ways in which insufficient leadership can cause frustration for product teams. The first is by not providing direction in the form of goals, strategy, or vision. The second is by meddling in the day to day of the team. Having covered the former in my last article I want to give advice on the latter today.

Unfairly or not, the tendency to micromanage and meddle is caused by a lack of trust. This shows in the tendency to try and control the team. Frequent feature requests, direct contact by leadership to the team members to micromanage their day to day work, and a high concern with story points, velocity, burn down charts, etc. are typical in this instance.  While dealing with missing direction is pretty straightforward, taking on extra responsibility, building trust is more difficult. It takes time to do so.

If you took the advice from the last article to heart, the good thing is you already have a head start. Taking on extra responsibility already helps build trust by showing that you are trying to do the right thing. Overall though, the most important aspect of building trust is communication. 


The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 


Communication is the key to building trust

Micromanaging what the team is working on is a signal that leadership doesn’t trust the team to work on the right things. Leaders believe – sometimes rightfully so – that they know the business better than the team. Thus, they think that they have a better idea of what needs to be done. 

You therefore need to demonstrate that you have a solid grasp of the business to build trust. The best way to to do that is by being transparent about what the team is working on, what decisions you are making, and how you made them. Try to avoid surprises and keep a channel open where you share any change of plans early on. The goal is for leadership to know what is going on at all times. At the same time you want to familiarize them with your way of thinking and making decisions.

To accomplish this, the amount of information you are sharing should feel like too much. You are probably going to feel like you are being a nuisance – and you might be. Don’t worry, though, people will let you know when it is too much. Then, you can always scale back. In building trust, it’s far worse to share too little than too much. 

You need a communication system

In order to effectively share information you need to structure your communication using a deliberate system. Not enough people think about how they want to do this. I have shared my default system in the article on stakeholder management. Go ahead and read it. I will only highlight a few things here, the most important being that you actually make a deliberate plan about what you communicate in which setting to whom. 

For building trust the most important elements of the system are 1-1 meetings with VIPs. Following the theme of rather communicating too much than too little, I would rather set up one too many of these individual meetings and cancel when they are no longer needed instead of scheduling one too little. 

Then there is the product update, with specific, smallish groups of stakeholders (e.g. all sales people for a B2B product) that is also crucial to building trust with an influential group of stakeholders. For me, this is normally a monthly meeting to share information and discuss the specific needs of a distinct group of stakeholders. 

Shielding the team is a double edged sword

I have been in situations where managers meddled in the day to day of engineers, constantly requesting status updates or asking them for specific tasks. This forces the engineers to multitask and this doesn´t work. One of the main ways to have an efficient development team is to just leave them alone and let them do their work.

While it is good for engineers to have direct contact with management (eg. to better understand business context), it can’t be so much that they no longer get stuff done. It’s a delicate balance to strike.

If it gets out of hand, funneling all requests through a defined channel (e.g. Jira Board or dedicated Slack Channel) or through a defined person (e.g. product owner or manager) can be the way to go. Although I am not a big fan of patronizing the team by telling them who they can and cannot take requests from, there are situations where it is necessary. To achieve this you need to do two things.

First, you need to agree within the team that this is the way to go and that all requests will be funneled through, for example, the product owner. Encourage them to redirect all requests to that one person when contacted. Sometimes, the engineers are intimidated and won’t push back. That’s why you need to do one more thing. 

You need to get public buy-in for the approach from those stakeholders that are meddling. I often use the review or the aforementioned product update for this. As long as you explain what the consequences of the interruptions for the team are – there is usually no disagreement here – and are able to convey that the truly urgent requests will still be served, you shouldn’t receive much pushback. 

Involve leadership when it makes sense

It can make sense to involve leadership in certain workshops or team activities. This way they feel heard, are actually able to contribute (hopefully), and see what is going on. This builds trust. 

This is particularly helpful in a company where management has frequent feature requests. They do this because they are worried that the scarce resources of the team are spent on the wrong things. 

They believe their understanding of the business is better, enabling them to make better decisions. This is often true! Many agile coaches, for example, are too much focused on product delivery and don’t have sufficient knowledge of customers, markets, or the competition.

The way to gain trust and consequently more empowerment for the team, is to involve the leaders in the process. This way they a) see how the team works and influence how the scarce resources are spent and b) satisfy their ego in shaping the product. 

A good way to involve stakeholders is to have them take part in brainstorming sessions. It doesn’t matter if this is part of an official process (e.g. the ideation part in continuous discovery) or simply whenever the team has an ad-hoc session to discuss solutions. 

This way, the stakeholders can add their features to the list of solutions. Over time, most teams will show that they aren’t completely clueless and stakeholders will gradually want to be less involved. 

Conclusion

Product development is hard. Leadership is hard. Both cause frustration. In dealing with management that is constantly meddling in the day to day, remember that leadership could have a good reason to do so, they lack trust. The way to overcome this is abundant communication and judicious involvement. Once leadership feels sufficiently informed and understands your reasoning, they will back off. 

Trust me, they have enough to do as is. The less they have to worry about individual teams the better.