The danger of detached management

Obviously none of the following have I ever experienced personally, it’s more of a thought experience I suppose.

So let’s say you have a software feature team made up of a handful of focused and experienced professionals and perhaps a few juniors just for good measure. Let’s also imagine that this is true for both the engineers and the product managers and they together manage to implement a very fruitful culture where things to deliver and their priorities are always clear. Things also get delivered more or less on time and technical dept is also kept under control. Sounds great so far, right?

To color that picture a bit further let’s also imagine that this imaginary team has some process in place to improve their internal processes and discuss pressing issues. For example they might meet regularly for Kaizen meetings to keep things generally improving.

Now let’s say that said team also has a lead, but that lead is mostly involved in high level discussions, long term plans and in some cases aligning with other teams on said long term plans and their execution. She has her calendar full of meetings with stakeholders and upper management while she also takes part in the hiring process and of course some other personal tasks.

It’s obvious that she lifts a lot of weight off the teams back, practically enabling them to focus on the product and engineering tasks. I suppose this should still sound great, there’s hardly anything to boost team performance more than cutting out distractions. The problems start when she decides not to have one-on-one’s with her team members and that since she’s not part of the day-to-day work of the team attending standups or the Kaizen might be optional for her. This however can render her practically detached from her team.

These can effect the team in a few ways.

1. Hard to get help. Perhaps least importantly if and when there is a problem the team can not solve itself, it is harder to get the lead to weigh in or help because first she’s not used to weighing in on team issues and second she might lack some context which is not always easy to properly explain.
2. Awkward team activities. Team members may also feel somewhat awkward or even anxious around a detached lead as she may be seen as some sort of an outsider without sufficient amount of regular interaction. As consequence this may also poison team activities such as team events in some cases. This is more of a problem for introvert team members probably, but still worth mentioning.
3. Lack of trust. Lack of touch can also cause a lack of transparency and team members might start wondering what their lead is doing most of her time and whether she has enough insight into the teams’ work to be able to properly represent them in long term planning sessions with other managers.
4. Understanding team performance. For example let’s say the OKR says product X will be delivered by the end of the quarter but then some urgent request comes up that pushes the team to deliver product Y first. Or perhaps there’s also a dependency on team Z to deliver product X and they’re late. Either way at the end of the business quarter product X is not delivered, therefore a detached manager may think that the overall performance of our imaginary team is less than great. Technical improvements throughout the quarter might also easily go unnoticed of course.
5. Understanding individual performance. Team members might be judged on weird measures like being typically vocal or less vocal during selected meetings attended by the lead used for example. Imagine that being used as a deciding factor for your relative performance compared to the team average. This can of course further lead to team members getting unfair and unhelpful promotion feedback which will inevitably force valuable employees to seek their promotion in the form of a new position at a different company.
6. Creating legacy systems. Possibly the more important consequence of such unfair feedback is that people who don’t quit will typically adjust. When technical greatness is not appreciated, people will simply focus on product delivery and quality will naturally decline. This on the other hand is the perfect recipe for creating legacy systems that no one wants to touch anymore. When this happens, the lead will have her job failed as hard as possible, no matter how great a job she does doing her day-to-day job.

I imagine most of the above would apply to any delivery team, in or outside of IT, however with software feature teams there’s an extra risk: Whether the product delivered is of poor or great quality can be very hard to easy to tell. Yes, if the live system is broken every second day that’s a clear sign or in case the UI is not usable it’s easy to assume that the code is one big pile of crap. However the complexity of even the simplest software systems is still more complex than most other products in life and this means even software that does a decent job on the surface might be less than pleasant to work on as an engineer. (That’s what we typically call a legacy application.)

As I see it, a manager has two main choices to gain a better understanding of the overall quality of the product her team produces.

1. She can either make sure to be involved in development, check the code produced for key features, be part of standups and main design decisions religiously. This is absolutely doable, I’ve seen it done multiple times, but definitely takes a lot of time. Problem is that this might render her partially unavailable for important manager discussions and she might also easily become a blocker for the team when she’s less available.
2. She can also choose to invest instead into understanding how her team members work as a team, join in some of the design decisions and observe how things get handled. Plus she’d still need to make sure to have a personal connection with her team to get better insights of potential problems. If things don’t go as they should, she would still have option #1 to try but if everything is okay she’d have more time for other important tasks.

I guess being a manager is not easy and one of the toughest thing about it is that sometimes there’s very little difference between being great or bad at it.