Field Notes: The Social Programming Interface
No, it’s not Facebook hacks I’m talking about. The "social programming interface" refers to what you must do to get a very big office buzzing excitedly with 40 or 80 developers organized into many agile teams, working on multiple sprints to crank out multiple applications at high velocity. Meanwhile, the “glass house” guys in the back rooms are contentedly sipping their coffee, because they know that their back-end enterprise services are safe and that there’s a well-managed API layer that protects them from the foment and revolution in the frontend teams.
I’ve seen this now in many customer offices, in many countries, on multiple continents. The social engineering process that leads to this state is something that most companies should confront and work through.
In my previous Field Notes post, I discussed ways API champions and visionaries can learn from their first forays into the world of APIs, and cultivate metrics that can illuminate that first project. The efforts that led there are usually relatively modest and constrained. Teams can leverage the insight derived from the first step in their digital transformation to further improve their API roadmap, discuss the tangible benefits, and think more clearly about the next steps in their API program.
Creating roadmap alignment
The API visionary must start to think through who will be affected, what their hot buttons are, and what cultural, process, attitudinal, or other changes are necessary among the players, and must come up with a plan to get those changes into play. This launch of the social transformation may not be easy; in fact, it might be risky. This is where the challenges can go beyond the merely technical, requiring some organizational savvy and emotional quotient to overcome.
This phase will probably involve educating colleagues about the benefits and logistical dynamics of API programs, so as to create alignment around the roadmap and action plan, and it will almost certainly entail “management upward” to ensure the benefits are clearly understood, in the language of discussion used at executive levels of the organization. It also may require placating concerns about vendors, partners, budget, and architecture, and probably some amount of project planning. Sometimes, it will require a lot of planning, starting from a high-level technical analysis is likely required, to provide a logical and methodical series of sequential releases with each phase meeting the right threshold of risk mitigation, cost efficiencies, and business payback.
To accomplish this, the visionary must find some technical or domain partners who know the backend well enough to help with this survey and mapping, have credibility with engineering cost estimations, and can deliver a risk assessment and work plan. Maybe some business owners have to be dragged in as well, to vouch for what is possible.
Even with all this, getting approval and organizational alignment around this path may most of all require diplomacy, marketing, and salesmanship. Who in the organization will be amenable to hearing about this, and who won't, and what are the hot buttons in each of these camps? Who has the most to gain from finally getting a handle on some intractable back-end services?
Where it starts to get really interesting is when it gets into reassurances about political viability, career longevity, and preservation of relevance. And, by the way, it may also entail driving some cultural changes within the organization. In SOA-driven engineering cultures, APIs are often implemented on a one-off basis at the request of a client team.
Culturally, this is the equivalent of tribal representatives meeting each other in a forest and trading obsidian for salt, and in these engineering organizations peer status, performance reviews—and ultimately even compensation—have evolved to be dependent upon an engineer getting to meet as many other teams as possible, to gain a “mover and shaker” reputation.
In contrast, the basic structure of an API program roadmap means that teams may be developing APIs based on a more broadly rationalized set of requirements, and may be developing those for “anonymous” programmers without having met them. Individual engineers can adapt their career management strategies accordingly, but the API visionary may at first meet entrenched resistance from those worried about losing political capital, accrued status, and a known means of career advancement. Another change commonly necessary stems from the fact that REST APIs typically require less documentation than SOA or other style protocols, so teams may need to shed long-held habits of writing long documentation for each API.
Altruism in digital transformation
For the visionaries themselves, all of this might present a degree of career risk. What if the campaign goes nowhere? What if it erodes credibility? What it the project or program is approved, but for whatever reason is derailed during execution? Who wants to go up against entrenched IT resistance, bureaucracy, and political swordsmanship?
Yet it’s important to realize that there are also important potential career benefits. There’s the chance to be seen as forward thinking, the chance to deliver real business benefit, the chance to be seen in action by higher levels of management. That said, most of the champions we see in this social pattern seem motivated mostly by a sort of altruism. Rather than seeing the definition and alignment around an API program as the vehicle for their next raise, these people most often sincerely see them simply as the best moves for their organizations’ digital transformations.
In an upcoming post we’ll explore project coordination and delivery cycles, and managing outsourcers, as types of social engineering associated with API programs.