Before I get into this post, I want to credit one of the books responsible for shaping my experiences here. For anyone who is leading or wants to lead organizations, you simply must read the book Switch by brothers Dan and Chip Heath. While the book focuses on change, it is extremely relevant for all disciplines.

It is fairly common that when you rise to a lower or even mid-level leadership position, you start to get a little bit disenchanted with your organization. As an individual contributor, you frequently don’t have a wide enough view to really know all the problems within the company. And you assume that leaders are somehow uniquely capable of managing an organization, so your expectations are likely a bit high.

But then you get promoted, and you are suddenly privy to a whole swath of new knowledge. Your increased exposure means you now know exactly how the sausage is made. If you are observant, you become keenly aware of every dysfunction across the organization. If this is your first time dipping your toe into the management waters, you likely don’t have a ton of experience at other companies, so you might think your company is particularly incapable. But the reality is that every company has its share of issues. They might vary from organization to organization, but you will likely never work again for a company that doesn’t have a little bit of chaos behind closed doors.

So now that you are in management, you are in a position to change things for the better. Where do you start?

Our instincts actually hurt us here, especially in high tech. Our inner engineer looks at every situation as a problem that can be solved through some kind of system. How do you design a system? You start by understanding what problems need addressing. This means that you look at the existing system with a careful eye on what is not working. Any changes need to close the gaps.

As an example, maybe your company has some product quality issues. When you root cause individual bugs that come in, you might find that there are gaps in testing. Maybe someone observes that code reviews are not effective. Someone might suggest that use cases are not well understood. Management looks at all of these and puts together a Get Well plan that involves the various functional leads designing process improvements.

In cases like this, process improvements are almost always additive. The Get Well objective is not to design a system by scratch but rather to augment the existing system to account for the issues. If you ever wonder why large companies are so slow, this is part of the reason. What used to be a slick system designed for a well-functioning team is now a set of convoluted processes with additional checkpoints added for every time someone bastardized the previous process.

By the way, this is why the US tax code was approaching 74,000 pages by the end of 2012. Every time some clever tax lawyer found away around the process, another set of pages was added. Each of those additions creates more holes that need closing. And so it goes as the process grows from 10 to 100 to 74 thousand pages.

You want to know what the real kicker in all of this is? When the process changes are made, you might not be any better off for having done it.

The psychology behind making change is actually fairly powerful stuff. People are exceedingly more likely to commit to change when the ideas are their own than if they are handed down from someone else. So when we analyze a system from above (as is the case with most management audits), we end up making recommendations from outside the team.

The subtle point here is that you basically have to convince the team of two things: first, that they are somehow doing the wrong thing, and second, that someone not in their shoes knows better what they should be doing.

As engineers, we think that we can rely on logic and reasoning to make our points. We might produce a document or even a PowerPoint presentation that breaks everything down into digestible chunks. Then we communicate to everyone through a series of meetings or maybe an email notification. We might even go so far as to provide training for people on the new process.

But the issues related to change are rarely purely based on logic. And when we ignore the personal side to peoples’ jobs, we are belittling them and unknowingly shooting ourselves in the foot.

Rather than starting with an analysis to determine all the gaps, what if we looked across the organization to find out where things were working well? Even if our hypothetical quality problems are widespread, there are certainly those individuals or groups who are performing well. It might make sense to find out from them what they are doing differently that is promoting their excellent execution.

It could be that the code reviews are more effective there because people in that group tend to have a longer tenure and understand the code better. Maybe they have managers who are particularly effective at managing priorities and reinforcing the role of customer experience. Perhaps they are using some small tool that automates parts of test. Whatever the difference, it is worth understanding what this bright spot in the organization is.

The next step is to replicate this bright spot elsewhere. Rather than having management push the idea down into the organization, what if the team responsible communicates to their peers? It is not an outsider’s perspective but instead some tips and tricks from people within the system. This helps prevent organizational antibodies that form whenever a new idea is presented from the outside (a common symptom of Not Invented Here syndrome or NIH).

The dynamic that is created here is one that reinforces that which is good rather than punishes that which is bad. That in an of itself is enough to reframe the entire exercise. It makes the entire exchange less adversarial, and it has the nice side effect of promoting the good efforts of a team that is performing above and beyond.

I’ll close with suggesting that while my examples are all about teams, the same principles lend themselves to individuals. When you provide feedback to someone, are the ideas on how to improve yours or theirs? Being a leader isn’t about having all the right answers; it is about helping others to arrive at them all on their own.

[Today’s fun fact: In space, astronauts cannot cry. Because there is no gravity, so the tears can’t flow. I don’t care about the science – any astronaut who is also a Minnesota Vikings fan could muster up the tears.]