Top-Down vs. Bottom-Up

When you have a position as a manager, you have power over a lot of people’s everyday life and you are accountable for their actions as well. So there’s a lot of responsibility on your shoulders to get things done and at the same time keeping your employees happy.

Making changes

All of this blog post really comes down to changing something. Usually this is a process change, sometimes including infrastructure or organizational changes. Doing this in the software development field is sometimes interesting, because you are the manager of intelligent, introverted and, with QA in particular, risk-averse personalities. Because of this particular set of traits, your changes will be met with scrutiny, discussion and sometimes suspicion and there will be few changes you make which will be unanimously well received by your employees.

Since you are very, very interested in keeping your employees happy and invested in the company, you want to ensure they are as empowered as possible. So you will include them in as many decisions as possible, let them make their own decisions and merely make minor corrections yourself along the way. You want to be a consultant for your team, someone setting the overall direction and letting your employees do their best within the confines of this direction.

Sometimes you even have to introduce changes which affect people outside of your own organization, which is a subject I intend to touch in another blog post, but this one is particularly focused on changes you make in your own organization.

We’ve already established that you want to make changes. You now have a choice to make: Do you want to make this change as top-down, using your power as a manager to get it through and cut through discussions or do you want to bring it up to a discussion, taking in opinions from your employees and possibly waiving the change?

Top-down

Using the Top-down method you gain speed. It is simply faster to get it done if there is a non-ambiguous goal which everyone just follows. Ironically, I find that the bigger the change is, the more people are affected by a change, the more you need to use a top-down approach to get traction on a change. Having 50 people organically adapt to a new process is just not going to work, so you have to do a management decision and inform people of the change. Don’t linger about a decision if you won’t reconsider it; you have to take responsibility for it, it is on your shoulders, you made the decision, it is your job.

Making change this way requires you to take full responsibility for the change and any outcome. If it fails, there is no way around pointing all 10 fingers your way, but if you are a manager of a department of some size, I assume you are already good with that.

You might face a problem internally with your employees if it is a change which is perceived badly by some of them. This is especially the case if you want to do something which will touch the “culture” of a company, where some who have been there long identify with this culture. In such a situation I usually think of this “You can’t fix a problem with the same resources which made the problem”. I don’t mean you need to fire everyone and start from scratch, but resources are anything from tools to people to processes, so if old-timers tell your change won’t work, you need to ask them some hard questions about why that change is any less bad than what they did to end in the mess.

Since you are taking on full responsibility for top-down decisions, you can’t make many mistakes with them. It really does have to be a good change you are implementing; otherwise you will be losing your employees’ faith in your ability as a manager, which will result in attrition or reduced productivity. The “goodness” of the change does not have to be immediately apparent, it might even cause a bit of stir and dissatisfaction in the beginning, but you should be able to see the positive effects after a few months.

Finally, making a top-down decision has 2 other effects. First, you set yourself up as a strong leader. Leading back to the self-confidence post, sometimes a department really needs a firm hand to get it running as a unit. The downside is that you might be perceived as a power-fascist, so use it wisely.

Bottom-up

Implementing changes bottom-up is a slower process, but also one where you don’t have as much friction. At least not much friction between yourself and your employees, but you might end up in a different set of problems where the team internally gets into discussions and grinds teeth. This only tends to happen in a dysfunctional group, so if you have interpersonal issue you must solve those before you allow yourself to implement bottom-up changes.

There are also situations where you don’t have a 100% clear picture of what the end goal is, in which case you will get much better results by empowering your employees to find the solution. There’s no need for you to give the impression that you are an all-knowing deity, when clearly they have a much better understanding of the “real” work, so you just give a direction for the change you want and let it play itself out.

Another bottom-up scenario is where you don’t have direct power over the people you need to get it done. In this scenario you need to play your cards through all the channels you have available, including your management peers, your employees, public mail lists and personal relationships with other discipline members. This is really where your ability to influence indirectly will be tested and there is no recipe for how to do that.

Using this approach is more about making evolutionary changes. It is smaller steps where you don’t know the exact outcome, but also one where you don’t risk as much of your personal standing.

Real world

In Unity R&D everything is very bottom-up. When I joined QA I needed to turn some things around fast and I did that top-down to get traction and it is only recently in the past 4-5 months that I have released this approach as I have seen the teams and their leads take on their own plans and fates. I did have a long talk with my leads about this exact problem of walking the line between top-down and bottom-up and my message was clear: Don’t be afraid of making the necessary top-down decisions when you have to. It is part of the people management job and something you must be able to do when you see the need.

Some of the changes I did top-down include the structuring of our test cases, the process we use for handling bugs and the organization I wanted to implement. I did not want to put those up for debate and I wanted them implemented fast. A LOT of other changes we did in Unity QA has been bottom-up and it is the preferred way to do them, more so as the team has become confident and able to execute efficiently.

My goal as a manager is to make as few decisions as necessary, leaving them up to the people who actually execute them. But I reserve my right to correct flaws and set them straight, top-down.