This post originally appeared on Tandem's blog.

Software is much more than 0s and 1s, bits and bytes. Building software is fundamentally a human activity. In fact, the term “computers” originally referred to the people who performed calculations and didn’t become associated with machines until the late 1940s. To build good software, you need to build it for humans: the users who will interact with it and the developers who will maintain it.

In 1967, computer scientist Melvin Conway described an organizational pattern in his paper How do Committees Invent? that was later called “Conway’s Law.” If you’re not familiar with Conway’s law, it states,

Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.

Put simply, teams build stuff that mirrors the way they communicate. A team that builds and maintains software will do so in a way that matches the way they communicate within their organization. To successfully modernize your legacy technical systems, you have to start by modernizing the human systems that support them.

Learning From Giants

When Satya Nadella took over as CEO of Microsoft in early 2014, he inherited a company that was on a trajectory towards irrelevance. Microsoft was a tech behemoth that had invested heavily in creating a customer base of Microsoft-allegiant IT organizations. Internally, Microsoft had organized itself similarly, with large, bureaucratic teams devoted to a single vertical, like the Windows operating system. And the company hadn’t been keeping pace with market trends. Nadella worked quickly to change that. He recognized that cultural change was one of the most important factors to driving innovation and market growth.

Nadella immediately reoriented the company vision around cloud, mobile, and service to end users rather than administrative departments. He also reorganized, completely eliminating the Windows division, and built teams around broader product offerings and technology trends. Nadella recognized the need to break silos and foster cross-division collaboration in order to transform Microsoft into the relevant, service-oriented, modern tech company it is again.

Why do I bring up Microsoft’s recent transformation? To show that no organization is too big to invest in shifting their human processes and roles in order to foster dramatic technological innovation. Even though your team is likely smaller than Microsoft’s, it’s no different. If you have legacy systems and are feeling pressure to innovate, the best place to start is with your team culture.

From Brittle to Resilient

A resilient system is one that continues to function even when something goes wrong; there’s no single point of failure. On a team, that means that one person’s “oops” won’t cause big delays or missed deliverables.

The most common cause of a brittle team is rigid, bureaucratic decision flows. If every question has to be “run up the ladder,” it’s really easy for one missed email or a little PTO to bring everything to a screeching halt. A resilient team is one in which there is a decision-making framework that allows most decisions to be made quickly and easily regardless of who is present. This requires trust and clearly defined roles and responsibilities.

Resilient teams lead to resilient software. Quick decision-making is important in agile software development. We need to build, test, and iterate in order to find weak spots and shore them up. Without the test and iteration steps, we may ship code that fails – and fails big – without ever knowing it.

My team will help you create this type of decision-making framework if you don’t already have one. We start all of our projects with a conversation about “who to go to” and identify the subject matter experts and approvers for all of the domain areas we’ll be integrating with. And we revisit those decision responsibilities throughout the project to make sure we’re getting decisions as efficiently as possible and ensure we can continuously ship software.

From Monolithic to Distributed

Monolithic systems are those in which disparate functional components are interwoven and interdependent. They are resistant to change and require top-down directives to do so. A monolithic organization is one in which small changes require massive logistics overhead to coordinate the work between various departments. In an environment like that, building custom software is going to feel like trying to turn around the Titanic.

To move from a monolithic organization to a distributed organization (metaphorically, not necessarily physically), you want to find ways to decrease coupling within your departments and sub-groups. Rather than organize by skill sets (IT, marketing, finance), you may want to align your teams by business goals (either products or market sectors). This ensures that parts of your business can shift and change in response to changing audience needs and all the necessary skill sets to do so are present. You are investing in your organization’s ability to stay nimble.

The United States Military Entrance Processing Command (USMEPCOM) is a complex entity of specialized teams that each owns part of the enlistment qualification process. My previous company partnered with USMEPCOM to reorganize their delivery team structure so subject matter experts from each department were represented. The Rapid Delivery Team (RDT) is vertically and horizontally integrated to reduce coordination and communication overhead from working with multiple bureaucratic support functions. We were able to accelerate development and replace their nearly 30-year old system with a cloud-based solution that integrated more than 25 applications into one interface.

From Silos to Sharing

Information silos hold back innovation, because information is trapped within an insular system. That info is not being shared and communicated with people who may find new ways to use it. Information silos can also lead to brittle systems like we talked about above, since a silo is often also a single point of failure.

Teams where each person knows only what they’re working on and nothing about what anyone else is doing are often stagnant. Just like Nadella did at Microsoft, it’s important to break down communication barriers and foster cross-functional collaboration to drive internal innovation. Creating cross-functional teams aligned around business goals is one way to achieve this. You can also invest in tools that allow for self-service information gathering, such as intranets and dashboards.

Information drives innovation. In my experience, clients who remove silos and share information are more successful creating change and sustained growth. When working with one energy company, we learned that the entire process to notify customers before a potential power outage lived in only one person’s head. We built a notification dashboard that reduced the previous, hard-to-understand process from 37 steps to 10 as the first step toward a long-term vision of simplifying and modernizing this process. Once everyone on the team had visibility into the information that drives customer notification decisions, suggestions for further improvements started pouring in. Together, we created a long-term roadmap that includes new ideas from team members, like integrating geographic information and meteorology data from weather stations.

Conclusion

Back in the 60s, Conway probably had no idea how fundamental his observation would be to successful agile software development. In my projects, we don’t start modernization projects at the technology layer; we start at the human layer. We know that lasting success is dependent on your team being able to continue to grow and change with your system. Let’s work together to make sure your processes and software reflect the innovative type of organization you want to be.