I have had the pleasure of sitting in on several event storming sessions, where an organization is brainstorming the design of the next generation of their APIs, ensuring that every idea and resource is literally put on the wall and represented as a sticky note. I have also had the opposite of pleasure of sitting in on many shit storming sessions where an organization is doing everything but properly planning the present or future of their API infrastructure. Revealing to me what I consider to be a fairly common approach to designing, defining, or just pushing tone deaf, out of sync, and unreliable APIs into production—adding to the technical debts that already exist across some large enterprise organizations.
Shit storming within an organization is where everyone is running around with their hair on fire on a regular basis. So often, it is seen as normal, and most people don’t think anything of it. It is an environment where most ideas are suppressed, and people do not share what they are thinking, acting in passive aggressive ways, or just waiting until the right moment and acting out with actual aggression. It is an environment where most people just keep their heads down and try to do the best they can with what they have, and a small handful of people get to dictate where things are headed without much feedback from other stakeholders.
While this approach to delivering API infrastructure may be common, it doesn’t have to be considered normal. Some people thrive in these environments, because they are able to adapt and stay afloat amidst the chaos. In my experience these situations arise over time as part of regular waves of dysfunction, bad decision making, and re-enforced by leadership that doesn’t not reward honest feedback from their teams. Resulting in APIs that get developed in isolation, absent of nutrient delivering feedback loops, and the essential building blocks that help ensure APIs make a positive impact. Setting the stage for a less than desirable experience across the desktop, web, mobile, and device applications that are built on top of these APIs—leaving a bad taste in the mouth of developers and end-users who engage with what comes out of an organization.
If you have been to one too many shit storming API sessions you might want to look for employment somewhere else—take my word, this is not how things are done everywhere. If you are passionate about staying where you are at, then start digging in your heals and pushing for more structured conversations around how APIs get designed, developed, and delivered. If you are determined to make change regardless of the historical patterns in place I commend you, and I’m here to support you. Let me know how I can help you develop your API strategy toolbox, and challenge some of these legacy practices, or lack of practices within your organization. Who knows, maybe you have the power to make change and calm the storm, and begin to reverse the cycle of the storming sessions within your organization—shifting how API resources are defined and delivered, and setting a new tone for how business gets done across teams.
