In a recent edition of the Ctrl Alt Delete podcast, host Emma Gannon described her discovery of a Facebook group that helps individuals make small decisions. “Can’t decide between two shirts?” it asks. “Can’t choose pizza or spaghetti for dinner? Let this group make small decisions for you.”
In “the before times”, I would have no use for a group like this. However, in the pandemic times, there are simply some evenings where this sort of “outsourcing of the banal” seems attractive.
Decision fatigue, or when the mind becomes exhausted after a sustained period of decision making, often follows. Many became acutely aware of decision fatigue during the Covid-19 pandemic. Suddenly, even trivial activities like opening doors and touching elevator buttons were a puzzle. Not only had the number of decisions skyrocketed, but the heavier impact that those decisions carried (the possibility of illness or death) created outsized effects: stress, loss of energy, and lowered mental capacity.
The last several years have been stressful. When individuals weren’t navigating a pandemic, they were experiencing everything from political unrest to supply chain bottlenecks. And then there was a war.
Businesses dealing with API sprawl are also stressed. The unprecedented events have meant that software architects, already stretched thin, have experienced higher levels of decision fatigue. “Just tell me what to do” is a common request.
The Software Strategic Impact
It is understandable how individuals would desire to bypass the hurly-burly of defining first principles - those are yet more decisions! “If it is good enough for Stripe or Twilio”, the thinking goes, “it is good enough for us- we don’t have energy for that vision quest stuff; there’s too much to do!”.
However, my concern is what happens on Day-2 with this “made to order” approach to API standards. “Day-2” is a DevOps term. It relates to the challenges that arise not from changes to a specific application but the more significant abstract processes and operations. For API standards, Day-2 problems relate to how a set of design standards, architectural guidance, or run-books get disseminated, adopted, and improved upon over time. It is one thing to gather key leaders together to announce expectations for a newly established API program. It is another thing entirely to continue to drive engagement and improvement among stakeholders in month 6. Without creating the crucible to form first principles, this greater identity and shared purpose aren’t formed.
Further, without discussion, adopting standards developed elsewhere may lead to bloated and ill-fitting style guides. Every standard a developer must follow introduces a grain of cognitive friction. Sometimes, the price paid is worth the production-environment benefit. However, every organization is different, with its own experience, style maturity, expertise, market, and desired end goals.
Each requirement in a standards doc should be able to answer:
- What is the better API outcome created by this standard?
- What are we willing to sacrifice (stop doing) to make this standard possible?
- How will “better” manifest in our day-to-day activities, behaviors, and interactions?
- How will we know if the standard is working?
- Has anyone done this before?
- Are we inviting others to a better future or imposing a singular vision of a future onto others?
- What is the non-obvious implication of this standard?
- (Bonus) How will we automate the education and enforcement of this?
Without considering the above questions, adopting standards from a different context will (best case) result in unnecessary effort and (worst case) be ignored. The consulting practice I work for does a great job of incorporating this nuance through careful, considered conversations. Together, we arrive at a healthier place for all involved.
The Good News
John Cutler is a product management expert and frequent communicator. He also sees the stress among the change agents he works with. Through that work, he also shares some hope:
“In the last eight months, I have spent countless hours speaking with change agents. They reach out to me for product management advice, but these conversations inevitably seem to turn to the topic of how to nudge their organizations in new directions. During the pandemic these discussions have acquired a new sense of urgency.
“Their anxiety is palpable. They care for their teams but are overwhelmed by the challenges, and the opportunities, facing them. To be sure, the pandemic has been catastrophic on every level, but many of the change agents I have spoken to are finally receiving the support they need and bringing about the impact they have long wanted to see. Their work is paying off, at the most inopportune time. There is movement in the right direction.”
During these unprecedented times, we must recognize the inherent opportunity in the status quo fracturing. Introducing change now does not have to contend with bursting people’s “normal” bubble. Nothing is normal! The cheese has already been moved. Energy is available if someone dares to channel it. That is not to say that change, like defining a set of API standards for a sprawling and increasingly problematic ecosystem, is easy. However, it does mean people are more likely to accept something new.