What alignment isn’t
Alignment isn’t the same as agreement, or cooperation, although it can include those elements. It’s not unity or unanimity.
When we talk about “business alignment”, sometimes we get sloppy and use it to signify agreeing to the goals of the people in power, or a superficial arrangement of shared interests.
What alignment is
Alignment is the active choice to make your vector match something else. Vector includes both direction and movement. The moment of being aligned is a snapshot of a dynamic state.
If we take a moment to think of alignment as movement, it changes how we understand what we’re lining up to.
Alignment in software is considering the state and direction of our teams, our dependencies, and most of all, our consumers. Where are we now, and where are we going, and how can we do that together?
Software has always been about aligning the computer, the code, and the consumer. Sometimes that means thousands of developers across dozens of divisions to make an operating system, and sometimes it means one hobbyist building something for herself, but in order to make something that really works, you have to understand what you want it to do.
How we got to today
Much of early software came from command-and-control environments. Admiral Grace Hopper was not a title distributed by a bridge club. In the military creche that software was born to, it made sense that the purpose and outputs of software would be clearly defined before anything was created. As software expanded in capabilities, from decryption and trajectory calculation to communication, multi-directional inputs showed up. Software had to not only execute commands, but respond to context.
Commercial software experienced the same moment, from a time when companies were in control of what software was used for, to a time when software was useful to communicate back to the company. No longer was software something that was distributed. It became something that was uploaded.
In large software projects, a single developer or project manager doesn’t have the power to shift the entire mass very far — software projects, like anything else, have inertia related to both their mass and velocity. If the iconoclast gets too far from alignment, the organization either rejects them or convinces them to re-align.
The rise of open source and the abundance of cloud computing has allowed for very small teams to make a much larger impact than we would have assumed possible for most of software history. With enough time and infrastructure, ConcernedApe (Eric Barone) coded an indie game that took the world by storm1. It is common to think of software features as being created by triads or small teams.
Even indie developers and moonshot teams need to find alignment with their systems of distribution and their users. The first thing that startup advisors try to get through to founders is the absolute necessity of understanding product-market fit — what are you making, who is it for, why do they care?
Hacking and growth mindset
Once it was possible for ordinary human users to change software, we did. We used artillery physics to bomb hapless worms into radioactive rubble2. We attempted to assert control of what our printers could talk to and do. Early hacking was almost always an attempt to get software to align better with what the user wanted.
Knowing what your software is doing is a surprisingly difficult problem in computer science. Almost all our stacks are complex, and few of us understand every layer of them. One snippy letter from Ada Lovelace to Charles Babbage begs him not to alter things in a way that seems to improve them, because it throws off her calculations. The first debugging argument!
Complexity
When we started splitting our programming into server and client, data and operations, front and back end layers, we multiplied the complexity of getting everything to work together. Alignment is harnessing all the constituencies of the socio-technical system and getting them pointed in the same direction.
When Amazon promoted the idea of the 2-pizza team, they also talked about how every team would communicate with other parts of the organization with APIs. The entire organization was aligned on using APIs to communicate anything that needed to pass between team or service boundaries. In that case, it was an implicit contract, since everyone was working for the same organization.
If software has eaten the world, it has eaten humanity too–and we are symbiotic with software. When we say socio-technical system, it isn’t just the global software/humanity gestalt, but the systems within the greater system. The smaller the system, the easier it is to align. It’s easier to go on vacation alone than with anyone. It’s usually easier to go with just your partner than your extended family. Each time you add nodes to the family-vacation system, you increase the difficulty of decision-making and alignment.
Software makers knew that adding nodes added complexity, but it’s inescapable complexity. It meant that alignment had to be both stronger and less prescriptive. It’s the difference between personally planning a vacation where all participants agree to all activities, and booking a cruise, where “get on the cruise ship” is the main alignment, and activities can be more independent. We’re all on the cruise ship, going to the same places.
However, building the kind of trust that enables this strong alignment and weak direction is not easy to do from a command-and-control mindset.
Alignment goals
It is hard to do alignment if you don’t understand the goal.
It is tempting to make alignment itself the goal. But that’s how you get echo chambers and groupthink. The goal you’re aligning to needs to be broad enough that everyone can see their place in it and narrow enough that they can tell what isn’t part of the goal. When you get something that well-defined, you can hold up every action and choice to it and tell whether it will help or hinder the goal.
Alignment to an overall goal helps groups within a company and keeps them from veering off into their own weird things. Alignment with customer needs and desires keeps a company from ignoring its own long-term interests. Especially in software, it’s easy for us to get hypnotized by the potential of new and shiny things and forget that our assignment is to help users get things done. Alignment and frequent course corrections helps us keep in touch with the people who want to be our users.
Conclusion
Alignment is a moment in time, and it is never finished. You will have to keep working on it over and over again, for as long as you’re trying to do a project. This may feel like an exhausting task to add to all the complexity of building something, but if you don’t have alignment, then what you are making means nothing.
Progressive Delivery wants your team to build the right thing, for the right people, at the right time. In order to do that, you will just have to keep aligning, over and over again, like driving a car, like telling a spouse you love them, like going for that jog. Alignment is doing the actions that fit with our values and desired outcomes.
Progressive Delivery 