Conway's Law and Order

In the 1960's a computer programmer named Melvin Conway described a phenomenon he saw in the technology industry. What came to be known as Conway's Law states that

organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. Melvin Conway, "How Do Committees Invent?," 1967

To put this another way, and in a way that helps us think about our own work, we can say that the software we use is a reflection of the communication structures of the teams who built that software. This was originally meant as an empirical observation, not something to try to achieve or even avoid, necessarily. The observed trend is that the design of software is limited by ways in which teams work together or don't.

I like to expand on this and make a more general, but related, statement. I believe that product design is limited by the ways in which the designers view the world. This is true for software and hardware, and in products outside the bounds of technology altogether. Most of the things we use were designed by people at one time or another, and their vision of the world and their imagination of what the world could be impacted the thing we're now holding. Everything from a spatula to a laptop. Our perspective of the world gives us the foundation on which we make everything else.

That all sounds like a lot of vague new age bullshit. I know.

Let me make that a little more specific and you'll see why I'm angry this week.

The more things change, the more they stay the same

The Support tools we use every day - from help desks to knowledge bases, from note taking apps to snippet automations - were designed by people who had some view of the world. Their perspective and imagination of what Support teams could do and be (and what they could not do or be) impacted the tools they built. We work with software day in and day out that reflects back to us what another company thinks we can and cannot do as part of our work. We are looking into another person's vision of who we are every time we log in to these systems.

Over the past ten years or so, I've talked to a lot of Support Professionals about the tools they use. When I first got into this field, I didn't know what other teams were doing and I was endlessly curious. I learned that Support teams in the tech industry have been unhappy with their tools for a long time. We've also spent a lot of our time (often many unpaid hours) building our own tools or trying to fix the ones we bought in as many clever ways as possible.

Ten years ago there were not as many options for Support tools for small businesses as there are today. There were a couple of big products that small teams couldn't afford and there were a handful of mid-level products that more-or-less met the needs of an early stage startup. The startups that existed at the time often built a lot of tools in-house, even though that was far outside their primary business. Gradually, more tools came on the market and the ones that came about in the late 2010's started picking up some steam. By 2020, seeing small businesses use custom-built help desks seemed like a massive red flag to a lot of people. But somehow, people were still as frustrated with their tools as they'd been a few years before.

I've come to believe the reason many people are unhappy with the tools they use is because the tools weren't built for them or the work they do.

What would you say you do here?

A few weeks ago, I wrote up my thoughts on how Support is misunderstood. I think it's important enough to revisit some of those points here.

Many people think of support work as communication work. They imagine that there is a body of knowledge inside a company and a group of angry customers outside the company, and Support is there to give the inside knowledge to the people outside. The Support Agent is a transferrer of existing information. The people who think this also often think that support work is difficult, but they think it's difficult because (a) dealing with people who are angry is stressful and (b) understanding what people are trying to ask is difficult.

In this imagined world, it's fairly easy to see why so many people think that an AI chat bot can do the work of most of the Support team - if not all of the Support team, in some cases. When you see the role as that of information carrier, there are going to be better options than paying a person to sit at a desk all day.

But we don't live in that imaginary world. We live in a world where information does not exist within the company. In our world, Support teams have to discover information about the product they're supporting. They often have to teach people inside the company about the things they've learned. They have to write the documentation that customers will look for, and keep it updated as the product changes, despite the fact that they're often unaware of changes being made to the product.

We live in a world where Support Professionals need to have industry-spanning knowledge of their domain. Support teams need to know the context in which their company's products will be used by people. And they need to know what to do when things don't go as planned in that non-imaginary world.

Dress for the job you want

The problem is that many of the building designing and building the tools we use don't share our perspective of our world. Many of them have not been on this side of the veil and don't know how to translate our view of the world into their product. I've spent a lot of time talking to Support Professionals about their tools, and while most of them are frustrated with them, they can't explain exactly why. There are a lot of small things they complain about that add up over the course of days and weeks and months and years. "It takes too many clicks to send a response!" is a common one. Or "I have to keep too many tabs open!" But if you solve for those individual problems, people are still dissatisfied.

Years ago, I was responsible for transitioning a Support organization off of our brittle, in-house, bespoke help desk software onto an industry standard help desk product. We started with a small group of people, maybe five altogether, testing and configuring the new tool. A week earlier when using our in-house app, we could fly through the queue with ease, focusing on our work and resolving issues one after another. Trying out the new product, we found ourselves staring at a cascade of widgets and text fields that seemed to create busy work with every ticket. We had pages of options, tags, fields, and automations, but none of them addressed the team's needs or allowed them to work with other internal teams as easily as our own internal tool had.

One person told me, "It feels like all of these features were built for my boss." That felt like it was getting at something deeper. Multiple sets of drop-down menus, CSAT approval buttons, and timers in the sidebar all felt like ways for managers to track the work of Support team members. None of the features felt like they were built to help the Support Professionals research their issues, document what they found, or communicate that information to anyone other than the customer who opened the ticket.

Let's raise the bar

The industry standard tool was built by someone who thought the primary work of Support was to send existing information back to the customer. The rest of the product felt like it was there to track the work of the team. To the Support team, it felt like they were limited in what they were expected to do and then constantly judged on how they did it. And it wasn't unique to the help desk we were moving to. We had the same experience in all of the off-the-shelf products we looked at.

That was about ten years ago and technology has changed a lot over that time. Our tools have gotten better in some ways - they're faster, more reliable, and more accessible. But they haven't gotten meaningfully better in a way that matters to the Support Professionals using those tools. They still reflect an image of Support that is outdated at best, and belittling at worst.

We can do better. All of us.

We should expect our managers and our leadership teams to understand the full scope of Support's work. We should expect them to appreciate, respect, and value the full scope of our work. But we should also expect that from the teams building our tools. We spend most of our working hours staring at these applications that show us, in one way or another, who they think we are and what they think we can or cannot do. We should demand respect from them, too.