I’ve had the privilege (or curse, depending on your predilection) of working in a software governance role for the last several years. What started as a simple API design advisory job has scaled into something that is equal parts technical acumen, developer empathy, business strategy, process psychology, and cultural anthropology. In growing, I’ve had to learn some new things.
One of those things is the power within systems, and how it is wielded. I’ve seen top-down, “do as your told”, initiatives flounder, despite the impressive titles of those declaring the mandate. This is because applying linear thinking in blunt ways to dynamic systems often fails.
But it doesn’t have to be that way. If you have a technical leadership position within your organization, you have more at your disposal than ‘my way or the highway’. Success in a non-linear system requires an appreciation of different governance power: soft power and hard power.
SOFT POWER
Soft power is a political concept developed by Harvard University’s Joseph Nye. Nye defined soft power as the ability to achieve objectives through appeal and attraction, rather than force or coercion. He clarified that it is in opposition to “command power”, or a nation “ordering others to do what it wants.”
Soft power applies to change agents within a company who may have the responsibility of achieving technology initiative outcomes, but lack the authority over all the participants. They cannot command people to comply. Instead, they have to rely on a different set of actions: diplomacy, strategic communication, assistance, negotiation, and community building. These actions share an inclusive vision for the future that others embrace without being told.
Creating standards or processes with a soft power approach may be as simple as stating a new expectation for teams to aspire to in a public forum. Or it might be a mutual agreement between parties on how to move forward on a particular issue.
Soft power excels when the situation is new and/or evolving rapidly. During this phase of an initiative, it is beneficial to adapt to new information while experience is gathered. Needs, some of which could not have been anticipated ahead of time, can be rapidly responded to. In cases where governance does not know what the final outcome should be, where flexibility and experimentation are most important, soft power should be the preferred approach until a desirable tenable solution is discovered.
Hard Power
Hard power is the ability to command (or restrict) a person or group to a specific set of behaviors. Usually, it describes the recognized authority for one individual (or organization) to direct another. But hard power can also be described as the set of allowances that a software system exposes.
Lawrence Lessig, in his books Code and Other Laws of Cyberspace (1999), and Code v2 (2006) proposed that software regulates behavior the same way laws do, albeit within the confines of a program. Software commands (or restricts) the user’s actions in a way that coercive, soft power methods do not.
Soft power may be a suggestion to do something a particular way via a persuasive argument. Hard power, as delivered via software tooling, is the encoded set of things a user is allowed to do. There is less malleability to a specific context. But the outcomes are stable and predictable. Also, because it is delivered via software, hard power can scale more efficiently than soft power.
A change to hard power, however, means changing code. Hard power’s capability to react and adapt is only as fast as a team’s deployment cycle. That cycle may include creation of a backlog item, gathering of stories, prioritization in a sprint, coding, functional testing, integration testing, user-acceptance testing, and final deployment. For stable, mature environments that don’t change often, that round-tripping may be an acceptible trade off for hard-power’s benefits.
Update: 2019-09-03
Related is the field of Choice Architecture. Choice architecture is the creation of desired outcomes through purposeful interface design.
Two Recent Examples
Two recent work examples illustrate how I employ soft and hard power to support developers delivering business value.
In one case, we were tasked with creating a collaboration process on a newly launched technology platform. It was so new, in fact, that what success looked like was tbd. With so many things like developer maturity, throughput, expectations, etc., yet to be determined, we needed to have the flexibility to experiment and change over time. Few things warranted dedicated tooling, or a ‘hard’ power approach, in this situation. Ignore the delivery lag; nothing kills developer moral like telling them to throw out what they just proudly delivered because “the situation is fluid”.
In the second situation, we recognized an opportunity to express hard power through our lifecycle tooling. The process flow was mature, with clear parameters and desired outcomes. However, we had an immediate problem that stalled a team. In that case, we defined a soft power agreement (“we will proceed with things in this way, and manually track what comes through during this intermediate phase”) until the hard power updated could be applied. It allowed us to solve issues today while we waited for backlog priority could align.
Conclusion
Being a change agent managing a software process across thousands of developers is no simple task. Moving from a simple linear system to a complex ecosystem requires a different set of approaches. I came from a development background; “applying power” talk still makes me uncomfortable. But, in order to be effective in my role, it is essential understand the nuance and how it can be applied.
This framework for how I classify approaches has been helpful to me, and hopefully it will be helpful for you, too.
