Does hierarchy really matter for communication in a small software team?

Question

I have worked as project manager in small company where I managed about 20 people. I used to casually talk to everyone and share ideas with developers and their team leads.

Recently, I joined a big firm where I see most projects follow a hierarchy strictly. If I want to reach out to the non-managerial employees (developers), I need to talk to their leads who are reporting to me now. Do you think it’s healthy to not skip levels in the hierarchy?

I have a 20 member team which limits me to discuss with only three of their leads. I personally think that skipping levels in such a small team won’t do any harm. By skipping levels, I mean discussing their technical problems, code related and other stuff that may be blocking their progress.

Answer 1

I personally think that skipping levels in such a small team won't do any harm.

First thing, a 20 person is not small. Secondly, it can totally do harm.

In most environments, the team leads are responsible for being aware of what the team is doing, keeping it coordinated and removing any impediments. One of the most common impediments to software teams is project managers coming by and making the individual team member report (again) why they're not done with XYZ rather than actually working to get XYZ done.

If your teams do SCRUM then attend the scrum and hear what the impediments are. You can ask short questions or have a quick post-scrum to understand better what the issues are. If your team uses email, you can certainly ask to be CC'd on discussions of problems. And you can absolutely volunteer to help remove impediments.

But if all the engineers see you doing is being yet another person asking them about their status (read: not helping to solve a problem) you become a problem to avoid rather than a resource to help.

Another problem I've seen is when project managers try to give instruction. "Hey, why don't you work on bug F?". The team lead has probably already given the engineer instructions about what to work on. Changing that is setting the engineer (and by extension, yourself) up for failure. Now the engineer needs to decide which of the two orders to follow. Some will try and do both, leading to failure. Some will just shut down and not do either, leading to failure. Some will follow the team lead, harming the relationship with you. Some will follow you, harming the relationship with the team lead, and possibly blowing up a well coordinated plan. And some will just call a meeting so that you and the lead can fight to the death (or otherwise resolve your differences).

So no, I don't think it's healthy in most environments for project managers to by-pass team leads, but it's not a matter of hierarchy. It's more a matter of coordination. If you leave the team lead out of the loop, they can't do their job and the individual engineers can't focus on doing their job efficiently.

Answer 2

Yes it matters. By skipping the leads that tells them that they are not trusted. You are a senior manager now, you need to stop being involved in the technical level of detail the lead and developers have.

This doesn't mean you can never talk to devs. But it does mean you have to be aware of how this conversation affects the way the lead is managing his team. If you don't like how he is doing it, the problem is between you and the lead and going directly to the devs is just going to cause problems and make whatever problem you have with the lead worse. Look at it from the perspective of the lead, how would you feel about being bypassed in the communication chain and then there being a problem that you were not aware of or the dev worked on what the PM told him to when you were expecting him to be working on something else?

The appropriate level of communication with devs at this point is really basically managment by wandering around. You wander through the office, they mention things to you and then you involve the lead in fixing whatever issues were brought up.

Answer 3

In a small company, there is normally direct communication with all employees; it is likely that you have had direct contact with the VP and most of finance as well as the development team. However, if you are working in a large company, the hierarchy will be much harder set. This will be down to accountability. It makes life more complicated for you, but in the hypothetical case where one of your developers creates a malicious backdoor in the software, the managers you are currently speaking to are the ones responsible for allowing this to slip through.

If you have broken the chain of command in this scenario, then responsibility would be not only on yourself and the developer, but also on the manager for not being aware. As is often the case in the workplace, he may well end up being the one who takes the hit for it. There are a number of other scenarios where "just a bug fix" requires knowledge from all parties; be it for budget, time or legal reasons.

I imagine the best response in these scenarios would be to 'copy in' the team managers; send an email to X telling him "I am visiting Y to discuss a bug fix for code snippet Z. You are welcome to attend, or alternately I will detail you on what was discussed during the next project meeting/in an email after the discussion". The responsibility is maintained in this case, and there is a paper trail so that all parties can be accountable.

Answer 4

Skipping levels in a software team like you describe could be a substantial advantage if done right.

At one of the soft skills trainings I've been told that for hierarchical organization to work reliably in a software related industry, it would better support information transfer over at least one level of management, so that manager routinely communicates directly to subordinates of their subordinates. This would ensure that important knowledge doesn't get stuck at particular level of management.

• ^{They also explained that such hopping over the levels is assumed only for communication - that is, if you're the boss, you still don't tell a subordinate of your subordinate what to do. Instead, you just learn how to more effectively manage your "direct reports", who in turn pass that further down the management ladder.}

An interesting, although maybe a bit extreme example of this approach has been outlined in an interview of Eric Schmidt to Harvard Business Review about his venture as CEO at Novell:

...you can’t just look at an org chart to find your most important employees. The key people here are our most creative engineers - they’re the smart people, the ones who control our future - and they can be very well hidden in the organization. They’re not necessarily at the top of any hierarchy.

I used a kind of algorithm to locate these people. A few days after I started, I was on the company shuttle from San Jose to Provo, where our engineering staff is centered, and I was sitting knee-to-knee with two engineers embroiled in a fascinating, heated argument. They were obviously two extremely bright people. I asked them to give me the names of the smartest people they knew in the company. They gave me a list, and over the next week I set up half-hour meetings with all of those other smart people, and I asked each of them to give me the names of the ten smartest people they knew. Because the smart people in an organization tend to know one another, I eventually found out who they were—about 100 in all.

I met and talked with each of them. It helped that, as an engineer myself, I understood their intellectual and technological needs and what their concerns were. I listened intently while they told me about their experiences and their frustrations...

---

_{Most of above has been "extracted" from this answer where it has been posted as loosely related addendum.}

Answer 5

I have a 20 member team which limits me to discuss with only three of their leads. I personally think that skipping levels in such a small team won’t do any harm.

A 20 member team is not small at all. A small team is probably 5 people. More likely 3 people. But a 20 person team requires management & structure.

And unfortunately any attempt you would make to discuss specifics outside of the established structure that exists will really hurt you in the long run. It undermines the authority of your direct reports. And it will encourage your developers to simply come to you when any issue arises which would drive you crazy.

If you do want to have direct contact, it might be best to organize some kind of structure where you, the project leads & developers could hash things out as a group. That way the table is basically open to discussion. But since the project leads are there, you can turn to then to help reign things in.

Answer 6

Armies are as strictly hierarchical as any organizations can get, and yet generals talk to privates, sergeants and junior officers all time. It's just too easy in a strictly hierarchical organization to live in bubble, insulated by overzealous aides who do their level best to keep bad news from getting to you.

As a manager, you want to get to what's actually going on. From the mouth of your lead developers as well as their subordinates. I think you want be perceived as a no-nonsense, manager with a direct, hands-on approach. I suggest that you keep an open door policy where anyone who wants to talk to you can do so. You want be perceived as accessible as well. The hands-on approach and the accessibility keeps everyone honest and damps the temptation to feed you what you want to hear.

Of course, while you are discussing technical issues with the staff, you must be mindful of respecting the leads' official authority. If, after discussing issues with the staff, you believe that some changes in some technical approach are either necessary or helpful, make a point of consulting the leads. Final decisions gets routed through the leads with the leads making the announcement to their subordinates. Only those final decisions that affect everyone are announced by you personally. Again, because you want to preserve their authority and the way to do it is to act in respect for their authority. You don't want to be seen as bypassing those who report directly to you. Otherwise, every issue will be immediately escalated from the bottom to you, and this is an outcome that you don't want.

Answer 7

Will it do any harm in getting the job done? No, the opposite. Most organizations are realizing the benefits of transparency and collaboration and are moving from the old command-and-control structures to open structures. Even the US Army is pushing down the path of decentralization, delegating decisions down to the appropriate level, and being transparent in decisionmaking.

Will it do harm to you and others in your company? Probably. If they insist on "chain of command," then they are likely to explicitly or implicitly punish those who don't do that. I worked for a large chemical company that was very "chain of command" and have strictly avoided environments like that since. It has nothing to do with size - I've worked for larger enterprises where you're welcome to go talk to people, managers have either no offices and sit with the staff or an open door policy, etc. and I've seen 100 person shops where a manager "guards their people" jealously (of course, at a startup of 10 it's hard to do).

Try suggesting alternate methods of obtaining the goals of the limited communication of the chain of command. For example, when managing my last set of engineering teams, I didn't worry about people talking to my devs because a) we all kept firmly to a work intake process and backlog prioritization, so their tasks weren't getting set back because people were coming and getting work in as "favors," and b) they knew they were empowered to redirect people to me or to the person on support rotation if it was not the right thing for them to be talking about at that time. But the product manager going and talking to them about a story they're working on? Sure, that can only improve the outcome.

Of course if it is duplication of effort ("I want status, but should have come to the standup") then they'd get told to attend that instead. And they'd tend to talk to the leads anyway, as the leads generally had more of a picture of what was going on, and would only seek out individual devs when they knew that person specifically was hip deep in the thing they were concerned about.

Answer 8

It helps to think of what the purpose of a manager is: to manage and organize Resources of which employees are one kind. Are you able to effectively allocate your resources (including your personnel) by talking directly to the team without impairing the ability of the team managers to organize their resources? Or would it be more effective just to deal with the team managers directly? To answer this, you need to know what your resources are.