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.