Tag: systems thinking

Management and Systems Thinking

“Until managers take into account the systemic nature of their organizations, most of their efforts to improve their performance are doomed to failure.”

Dr. Russell Ackoff (thanks to Susanne Kaiser for the reference)

I came across this Twitter thread from Rein Henrichs, and I thought it had many good points about systems thinking and management.

It caused me to reflect a bit on my approach to systems thinking in the context of technical leadership.

One of the things that helped me the most as an engineering leader was developing a better understanding of systems thinking. When I (or others) use the analogy of “planting a garden” when setting up teams for success, this is what we mean. We are creating the system to enable groups and individuals to do their best work and then allow good behaviors (and results) to emerge. Of course, creating a system takes longer than pushing things down into the organization. Still, it produces more creativity and autonomy in the organization and makes it more resilient to change or challenges.

Managers who do not work with this understanding of systems think that management is purely about doing stuff: defining rules, policies, and procedures, assigning tasks, creating external incentives, and fixing problems. This “doing stuff” approach can produce good results in small teams or for a constrained about of time.

As Rein Henrichs also correctly points out, the act of building a system can be incomprehensible for others in the organization who are not directly involved (especially in other disciplines that are more transactional). This lack of understanding has often been my biggest challenge as a company’s senior engineering leader.

Building a system takes time. If you can get things to a good place where the system is starting to be self-perpetuating, the rest of the organization will see the improvements and become supporters.

Suppose the leadership team is impatient and doesn’t understand what you are trying to do. In that case, they will lean into the quick fixes listed above, namely re-organization or replacing individuals or trying to “drive accountability” through reductive top-down control mechanisms.

If that happens, you are stuck trying to mitigate the damage and build a longer-term plan to return to your original goals, but it is often a losing battle. The primary culture of the organization has re-asserted itself, and your chance to evolve it has mostly gone.

How do you avoid that fate?

Communicate! Make your plans clear in the hiring process, your initial days in the organization, and all along the process. Set realistic timelines for improvement and celebrate the successes along the way. When your peers are impatient, refocus them on the plan and the long-term gains you are working towards. Point to the achievements thus far and try to keep their “eyes on the prize.”

Will this always work?

No. It depends on the company’s situation and how much pressure there is on the leadership team. If the company is under stress, it might be better to refocus on shorter-term solutions that don’t actively detract from what you are trying to build.

My biggest successes in companies were getting the entire organization on board with the system I was working to build. Gaining support for a new systemic working is a culture change, and getting backing is contingent on the company wanting to change. If the company is on a “burning platform,” a situation where change is required for the company to grow or survive, you will find less resistance. A burning platform also provides the inspiration to persevere if the change is difficult.

My biggest failures trying to build systems were when I did not communicate my intentions clearly or did not get buy-in from the rest of the leadership team, or when I was not effective at communicating the improvements along the way.

Another challenge can be a change (losing a customer or a tough quarter) that puts pressure on the leadership team. In this case, you need to adapt quickly. Hopefully, the system you are putting in place encourages being nimble. You may need to pause the change to the system to focus on shorter-term tactical solutions. To minimize the disruption in the organization, be transparent about the need for the change, and set an expectation on how you will get reoriented towards your original vision afterward.

While there are many good books on systems thinking, the one I consistently recommend for engineering leaders is Management 3.0 by Jurgen Appelo. It isn’t just about systems thinking but weaves it into a broader book about management.

The p-word

I have never heard the word “politics” used in a positive light when describing a work situation. On the contrary, the words “corporate politics” evoke memories of cynical executives in ’90s movies quoting The Art of War to their reports while figuring out how to undermine their peers. One of the Merriam-Webster dictionary’s definitions of the word is “political activities characterized by artful and often dishonest practices.”

I propose that we reconsider the word “politics,” especially when used in a work context. The word, and the techniques ascribed to it, are inherently neither good nor bad. You can use politics for ill intent or good. Good intention aims for a win-win solution, whereas bad intent aims for a win-lose solution. Instead, let’s use this Merriam-Webster definition for the word “politics”: “the total complex of relations between people living in society.” For our purposes, let’s call the company we work in our society. A company is a society in that it can have a panoply of personal relationships, group dynamics, shared goals, and systems of governance.

If we can get over our initial reaction to being political, how can we use some of these techniques for win-win solutions to problems?

Thinking politically means thinking ahead (being strategic), understanding the motivations of the people you need to convince (having empathy), and understanding the interactions of the systems you are trying to influence (systems thinking). You are working to make something happen-something you cannot do on your own. You may be working to overcome resistance to a new idea in a conservative institution. You could be trying to persuade another group to help your team with a project that will be good for the company but might make that group miss their quarterly goals.

Thinking politically will help you gain support for your ideas, soften resistance to change, and focus people on the bigger picture. If you improve everyone’s situation, your peers will appreciate you, and you will find the way forward easier in the future. Conversely, done poorly, where you or your team move ahead at the expense of others, you will find it increasingly hard to gather support in the future.

Playing politics so everybody wins: A personal example

In the early days of the public cloud, I worked in a company that already had established data centers worldwide. Getting a new server racked meant requisitioning a server from the central IT organization, following all their guidelines around the machine’s configuration and which technologies could be used on it, and giving them access to maintain and manage it. The process to get a single server going with a public-facing interface could take months.

I was leading a new team trying to incubate a new product. We had adopted a Lean Startup approach, moving to get to market in under six months. As this was a brand-new area for the company, we couldn’t be sure how quickly the public would adopt the product, and we wanted the ability to add capacity quickly if needed or shut the project down if it wasn’t getting traction. The company’s lead time for servers was not going to work for us. So, we decided to leverage Amazon’s young AWS offering. I knew that this would be a controversial decision and might incur opposition from other teams, especially IT. I could have chosen to “ask forgiveness, not permission” and hope that my small team could fly under the radar long enough to launch, but that was very risky. Our actions could be interpreted as a deliberate avoidance of company security and budget policies, which could prevent us from launching if we were found out.

I spoke to my peers in other teams to understand their prior experience working with the centralized IT team. I learned that if I approached the IT team directly for permission to use the public cloud, I would get an immediate “no.” That would put me in a position of having to get their decision overruled, which would take a lot of time and energy. I decided to go a different route.

I put together a presentation on our plan for our product. I included our quick path to market to mitigate risk for the company, our plan to leverage the public cloud (to scale quickly and manage cost-effectively), and how we would address any corporate security concerns. The goal of the presentation was to build trust that my team was thinking about the business and not just playing with new technology, and to show that we had answers to the issues I expected other groups to raise. I portrayed our product plan as an innovative experiment in new product development; a low-risk approach to moving faster as a company. I wanted to get some protection for my team at a level that would short-circuit other teams worried about this new way of doing things.

After working with my boss to ensure I had their unequivocal support, we got time on my SVP’s calendar to discuss the plan. I prepared for any argument against the plan, but I also left room for input from the SVP to help them feel invested so they would help protect the project. We left the meeting with approval for our approach and moved forward quickly enough to launch the product within our six-month window.

The product was more successful and grew more quickly than we had planned. Our public cloud adoption made it far easier for us to scale as the number of our customers did. Our success also increased our visibility within the company, however. The teams invested in managing and growing our worldwide data center infrastructure now started to see us as a threat. I began to have many increasingly tense meetings with them to discuss moving into the corporate infrastructure. I could have used my product’s success to force the other team to back off, but that would have created even more enmity, setting up our teams for friction forever.

Instead of using my team’s success as a wedge to ignore the IT team’s demands, I worked with them to understand why we had to make the decision we had. I also identified what they could do to make switching to the internal infrastructure an easy decision for us and for other teams

considering following in our footsteps. I committed my team to switching to the company’s infrastructure as soon as it could support us.

Reading through that experience, you can see several political maneuvers I used to get my team the space we needed to ship our product.

  • Talking to my peers to understand what their experiences and anticipate challenges. Consulting my peers on the problem got them enlisted as allies. If I were successful, they would have a better chance of success themselves in the future. (systems thinking/having empathy)
  • Building a strategy to prevent the central IT organization from stopping my team’s plan. (being strategic)
  • Enlisting my manager meant I had an ally in my effort to convince other senior managers, someone who understood the SVP’s motivations and concerns. (having empathy)
  • Preparing my argument to the SVP not just to convince but also to engage. Making the executive not just an approver of the plan but a participant with a stake in its success. (being strategic/systems thinking/having empathy)

If I had stopped at this point or pressed my new advantage over the IT team, that would have been the type of corporate politics that people despise. I would have created a win-lose situation (and some very angry co-workers who would have justifiably felt I’d wronged them).

Instead, I took the following steps to help the group I felt I had to work around and improve the situation for everyone at the company:

  • I used the lessons we learned from AWS to help the centralized IT team understand groups like ours with less predictable or forecastable needs. (having empathy/systems thinking)
  • I committed to them that if they could support our needs (with our help), we would switch to the “official” infrastructure. (having empathy/being strategic)

Making sure we helped the IT team was more work for my team, but it was better for them and the company at large. It made the solution a win-win.

An outside observer, especially a jaded one, could look at each of my actions in a very different light. That observer would say that I schemed to isolate the IT team, skirted appropriate behavior, and cheated by going over their heads. If I hadn’t then gone back to help lift the IT team, I might agree.

One might say that the best thing to do would have been to work with the centralized IT team to convince them that they should allow and support my plan. I would agree with that sentiment if it were possible to gain the IT team’s support and ship my product on schedule. However, the experience of my peers told me otherwise. Those who have worked at large corporations with siloed functions working against different goals understand how intractable those other groups can be.

Don’t be a player of the p-word

When faced with a challenge at work, try to understand the motivations of the people you work with and the systems they operate within. From there, build a strategy to achieve your goal. If you can achieve your goal while helping others move towards theirs in the long term, you will be an innovator and a team player within the society that is your company. On the other hand, if you achieve your goal at the expense of others, you will be nothing more than a player of the unspeakable p-word.

Thanks to Laura Blackwell, Hannah Davis, and Mandy Mowers for editing help.