Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Never Tell Me the Odds: Navigating Organization...

Never Tell Me the Odds: Navigating Organizational Politics

Note: Due to my speaking style, these slides are not as useful without the talk itself. Look for a final version of the video here (or find it in the 2023 day two livestream) https://www.youtube.com/@DevOpsDaysChicago

Where there are people, there are politics. Despite negative views many engineers have of office politics, they play an important role in our organizations. Politics is how we, as groups of people, make decisions. If we want to influence decision-making in our organizations, then we need to understand organizational politics.

When we talk about devops, we talk about building a culture where we collaborate across boundaries in our organizations. To get to this point, we often need to change the way that our organizations make decisions across these silos. It’s not just culture that we need to impact! The ever-increasing complexity of the software systems that we build and maintain require an increasing amount of joint activity and better tools for collaborative decision-making in our organizations.

In this talk, I’ll discuss:

How to identify political structures and learn how decisions get made in your organization
Common political structures in technical organizations
Tools for healthy collective decision-making

Josh Zimmerman

August 10, 2023
Tweet

More Decks by Josh Zimmerman

Other Decks in Technology

Transcript

  1. EPISODE IV NEVER TELL ME THE ODDS: EFFECTIVELY NAVIGATING ORGANIZATIONAL

    POLITICS It is the last talk before lunch. Some guy just got on stage to talk about politics and now he’s doing a cheesy Star Wars style intro crawl. Yikes. I guess we’re going to just have to hang tight and hope he doesn’t talk so long that he eats into lunch. @[email protected]
  2. Agenda • Terminology • Identifying political bodies in your organization

    • Common political structures you may find • Tips and tools for improving collective decision-making. @[email protected]
  3. This is even easier if you have a corporate archivist

    on staff or have hired librarians to help with knowledge management… @[email protected]
  4. I mean, unless you expected to find the weird vestiges

    of social interactions of all of the people at your organization. @[email protected]
  5. To be fair, asymmetrical power is only awful if you

    think people should collaborate on their problems instead of pushing their problems of on other people. @[email protected]
  6. If your skip level doesn’t know who you are, it’s

    harder for them to advocate for you when your manager doesn’t have enough power. @[email protected]
  7. If I had a nickel for every manager in a

    hierarchy tried to create a flat team structure underneath them, but didn’t join it themselves, I wouldn’t need the clout from speak at tech conferences. @[email protected]
  8. If you’re not used to flat orgs. You’re going to

    need time to acclimate and change how you do things. @[email protected]
  9. If you’re going to accept your fate, the least you

    can do is help make sure the next person struggles less than you did. @[email protected]
  10. Sure, maybe you specifically are dealing with a goose. But

    in that case, it’s probably a problem for your security team. @[email protected]
  11. For the men in the room: This means when you

    were shitty and made a woman be the secretary for your committee that you still needed to be taking notes. @[email protected]
  12. If you have the power to do so, I highly

    recommend declining meetings without agendas and letting whoever scheduled them know why you did it. @[email protected]
  13. If you’re encroaching on the time limit for a topic,

    the chair needs to consider whether that topic needs to be discussed outside the current meeting and act accordingly. @[email protected]
  14. There are so many resources out there that you really

    don’t have excuses for not doing your research. @[email protected]
  15. Ways that you are wrong @[email protected] • Your opinion is

    right for your team’s context but doesn’t make sense for other teams. • You happen to be missing context that another team has. • Your solution is good but it’s too expensive. • Your solution is good but it requires more people to maintain it than you have on your team. • Your solution is good but it pushes too much work on another team. • Your solution is good but will take more time to implement than your team has to give it. • Your idea is good in theory, but hasn’t been verified to actually work while someone else has something that works already. • Your solution is good but requires everyone on your team to learn a new language. • Your solution is good for your team, but bad for your customers.
  16. Ways that you are wrong part 2 • You are

    the only person who can possibly implement your solution. • Your idea would work but domain knowledge around the subject says that common practice is to do something different. • Your solution would work, but you said the phrase, “we can just secure it later”. • You never consulted domain experts who were important to involve, even if just to verify that you are correct. • Your solution works, but you need to do something manual across all of your applications. • You decided to use a tool that you already use and there is a better tool out there. • You used Route53 as a database. • You decided to use a new tool when a tool that you currently have could work. • You decided to use a tool that you already use in a way that is unsupported by the maintainers and it could be easily deprecated. • Your solution creates many tickets that are going to get immediately backlogged and become tech debt. • You never consulted anyone your decision impacts. @[email protected]
  17. You already (hopefully) do this for code, but practices around

    experimenting and creating short feedback loops should apply to other decisions too. @[email protected]
  18. Just because your team is the best team to make

    the decision doesn’t mean that other teams shouldn’t have input. @[email protected]
  19. Successful delegation @[email protected] 1. They can’t make a decision for

    a problem they don’t understand. Don’t make them do research. 2. Don’t make them research possible solutions. 3. If someone tells me that you rejected their decision after you did this, I will find you and stand behind you at your workstation glaring at you until you get uncomfortable.
  20. I will never understand why some people think it’s okay

    to expect people to work with those who would deny them their basic humanity. @[email protected]
  21. Turns out your underrepresented people want to do the work

    they were hired to do and not spend their time at work worried about their safety. @[email protected]