A steel sculpture at the IIT campus in Chicago, Illinois. It is industrial, yet human scale, almost like signposts indicating different directions.

The Power to Humanize Technology

In a prior essay, I asked how data systems could be humanized. A humanized system is clear in its intent, goals, and uses. It is transparent and trustworthy in how it collects, interprets, and uses data. It is equitable in its design and execution. And it has the potential to be used generatively.

I believe that we must understand power before we can take any other steps toward creating humanized data systems. While we may often conflate power with authority or control, it can also mean influence and agency. Unexamined power plays a decisive role in why our enterprise data systems* are often opaque, inequitable, not trusted, and extractive. Each of the elements of a humanized data system — transparency, trust, equity— are based in how power is experienced by all stakeholders, and how that power is used to shape the design and ongoing activities of the data system.

Power and Enterprise Data Systems

George Aye highlights the idea that “those with the least power are often closest to the problem.” This is certainly as true in technology systems as any other field of practice.

“The problem” can have different — sometimes conflicting — definitions depending on the perspective.

When we put this idea into practice, it’s important to be aware that “the problem” can have different — sometimes conflicting — definitions depending on the perspective taken. Failure to examine multiple views about “the problem” causes significant trouble in digital systems, from alienated users to low adoption to inaccurate data (real or perceived). In my experience the most productive start to technology conversations is asking for clarity in what, exactly, is “the problem,” who, exactly, has that problem, and what other problems are related to this one. I believe that this approach can be extended and aid the creation of equitable systems that are trusted and transparent.

How Systems are Chosen and Who Chooses Them

The single most obvious power dynamic in enterprise tech is who gets to decide what systems are chosen and what they are used for. Technologies are always chosen to solve a problem. Rarely is something objectively broken when a new technology is brought in. More often, “the problem” is a need or want: for better visibility into the work, for efficiency, for improved communications with clients or funders, for regulatory compliance, to keep up with a changing landscape, and any combination of these and many more.

A brushed steel wall, a round button, and a label that reads “Emergency Power.” I pressed the button but, alas, did not receive any emergency power that I am aware of.

A less obvious power dynamic is who gets to define “the problem” in the first place. Who gets to say this is a problem, and who gets to decide it needs to be addressed? Typically, whoever gets to claim something is a problem is also in a position to shape the solution. In small organizations and start-ups, it’s entirely possible that a single individual is responsible for executing on a given task and is therefore able to choose whatever software best serves the need. In larger and more established organizations, people further and further away from the day-to-day tasks tend to choose the tools. In no circumstance that I know of does the client or beneficiary of the organization get to choose the technology used to capture their data. Yet these are the people closest to a problem, too.

The entire technology solution is a reflection of the actual power dynamics and decision-making within an organization.

There are many other ways that power shows up in enterprise technology. The power to frame the narrative begins with the statement of the problem to be solved, and continues throughout the design, implementation, maintenance, and governance of the system. Power shapes answers to questions like:

• Who sets the rules and norms for how data is captured, interpreted, reported on, stored and analyzed? Who feels safe challenging, questioning, raising the need for changes or identifying errors? Who is impacted but left out of the conversation?
• How are people trained and supported in using their systems? Does everyone get appropriate resources or are some left out? Who decides what goes into the training and what is left out?
• How are solutions designed and implemented? Whose perspectives are included and for which parts of the process? Whose needs or problem statements are being prioritized? Is open dialogue and design encouraged or is the process more controlled? Is the process transparent?

Essentially, the entire technology solution is a reflection of the actual power dynamics and decision-making within an organization. Business decisions are made and processes are defined by the people who have the power to decide and define. These decisions and definitions are then implemented and enforced through technology.

Business decisions are made and processes are defined by the people who have the power to decide and define. These decisions and definitions are then implemented and enforced through technology.

In traditional technology implementations, it’s rare for technologists to consider the framing of a problem. When a problem is stated to a technologist, it is often the only thing we try to solve for. In fact, it is often the only thing we are allowed to solve for. The integration of design and DevOps thinking along with Agile and Lean methods helps technology teams be more aware of business process and user needs. These methods alone can’t overcome the fact that IT and development were given a problem whose solution is inherent in (and limited by) the framing. To chip away at this, it takes someone gently but relentlessly asking who all is this effort serving, and how do they see the problems, then negotiating the tradeoffs required to forge a holistic solution.

Different views of “the problem”

As a simple example of the ways different people at different levels of power are close to “the problem” as they define it, I want to tell you a short story that should be very familiar to anybody who works in a nonprofit setting. This is the story of what happens when you ask different stakeholders about their organization’s biggest data need.

The CEO / Executive Director says “I can’t get timely data that helps me understand our financial performance in the context of the services we’re providing. How much more money do we have to raise to serve double the people? I have no idea and it’s terrifying.”

The Director of Development states the problem as “I know how much we’ve raised so far and what our targets are, but it’s really hard to get reliable data from program. This makes it hard to raise more funds, cultivate better relationships with our large donors or even tell our story and get the word out.”

The story from an individual donor is “It’s hard to see what my gift is doing. It’s hard to manage my gift — the amount, the timeline, the frequency. Things should be simpler.”

An institutional donor has different concerns: “We can only fund certain types of activities and programs. We need insight into how our funding is impacting the beneficiaries, and we define that impact in certain ways that don’t fully line up with this organization’s program delivery.”

The COO has concerns often shared by the CFO. “Our auditors like to trace fund use all the way down to the program activity level. But program staff operate on a different cycle than fundraising, which different again from our accounting process. It can be a nightmare to keep track of.”

The Program Director says that the problem is: “We have so many different programs and we’re always under-resourced. I feel like we get grants that demand stuff we don’t already track and we have to scramble to figure it all out, then scramble to provide whatever information the funder wants.”

From the program staff perspective: “I’m stretched so thin. I spend at least half of my time keying data into different databases, but I still need to serve the people who rely on me. Some of this stuff I have to ask feels pretty invasive so I either don’t ask or I wait until I have a better relationship with the client. I usually wind up working overtime to get it all done.”

A client of the program has this to say: “It’s like I have to prove I’m a deserving person every time I walk in the door, and I have to repeat my information over and over again. I’m the same person with the same story and I know these organizations all talk to each other. It always leaves me kind of upset, and most of this information I have to give them doesn’t change anything they’re doing for me. ”

Even the vendor has a story to tell. A vendor is a stakeholder too, and has a surprising amount of power about what solutions can be considered and how data is framed, understood, and transformed into information.

The vendor’s story: “We have to provide high quality services to a large number of organizations while minimizing the risk of going out of business or allowing a data or privacy breech. We can only do that when the services we provide are relatively predictable, sustainable, and repeatable. We have to make decisions about what is going to be too expensive or failure-prone to implement, maintain, and support over time.”

We could tell the same story in an education setting, substituting students for clients and faculty for program staff. We could expand the story to include other stakeholders like the board who have a different set of needs and priorities altogether. While I’ve paraphrased these answers, all of them reflect real answers I’ve heard when exploring data systems solutions for organizations.

Yet most sales and solutions engineering focuses exclusively on the kinds of analytics preferred by executives, and rarely on any other consideration. It’s as if our entire discipline has forgotten that data must be input and used by large numbers of people before it can be transformed, analyzed, and consumed by executives, or is not terribly interested in how all that boring data entry stuff happens on the way to the shiny charts and graphs.

Power is concentrated around authority and money, and technology solutions are often sold and engineered accordingly.

It’s as if our entire discipline has forgotten that data must be input and used by large numbers of people before it can be transformed, analyzed, and consumed by executives, or is not terribly interested in how all that boring data entry stuff happens on the way to the shiny charts and graphs.

Power determines whose story is heard at all, and whose stories are left unwritten. Power determines whose needs, ease, and comfort are prioritized and whose are ignored. Go back through the different perspectives and roles above. As you read, ask yourself what you’ve seen in real life around power and these roles.

• Which of these characters has the most authority to decide on a solution’s direction?
• Who has the most influence? Are they the same person?
• Who most influences whether the new system is adopted or struggles to get traction?
• Who is managing the most risk — that is, who has the most legitimate need to control certain parts of the conversation?
• Which of these roles have you seen at the table when creating technology solutions? Which are usually or always missing?

Changing power dynamics in enterprise tech — challenges and suggestions

I don’t want to imply there are easy solutions. As the story illustrates, an equitable solution demands that a variety of legitimate needs and problems be considered and addressed. That can sometimes be technically challenging, costly, or cause a solution to collapse under the weight of unsustainable complexity. More often, however, it requires a level of role clarity and management capacity that can be challenging to achieve, particularly in chronically under-resourced social sector organizations. It can also just be challenging, period. Even if all conditions are perfect, there are legitimate and very difficult tradeoffs to be made in any solution where many different voices are heard. It’s simply easier to focus more narrowly on solutions that serve just one or two stakeholders, and it can sometimes be less expensive and more maintainable.

I believe that vendors hold a lot of power to shape these conversations. It is, after all, the technologist’s job — not the customer’s — to be the software expert. What vendors discuss with potential customers is a product of what they have to sell and what they think customers want to hear. What if vendors spent more time educating the decision-makers about how their software serves every type of stakeholder, including the organization’s clients? Decision-makers, of course, would have to be open to this — there are plenty who just want to buy something quickly and not engage in this kind of dialogue.

Enterprise software is infrastructure. The costs involved include initial purchase as well as ongoing maintenance and the occasional large and unexpected outlay. Just like owning a house, these must be planned and accommodated, or the infrastructure begins to degrade. Power dynamics often show up when someone with a lot of power expects or demands that those with less relative power manage the infrastructure without appropriate resources. Rarely is this malicious; more often, it’s the result of the natural disconnect between those closest to the problem of maintaining the infrastructure and those closest to the different problem of managing resources across multiple competing priorities. I have seen this with funders not adequately funding the ongoing costs of a critical data system. I have also seen organizations stop paying license fees, cutting themselves off from support and making it almost impossible (and extremely expensive) to extract data when moving to another system. Vendors — who have more power than line staff — can help set appropriate expectations with decision-makers about the resources required over time. Decision-makers, and particularly those who allocate resources, can establish safe channels for those with relatively less power to allow for better communication about resourcing needs.

The power that lawmakers and funders have to demand data about clients (or beneficiaries, students, or constituents) in the nonprofit, education, and public sectors is one gap that may seem impossible to close. I have to believe we can achieve equity even here, but also believe it may not be any time soon and will require a lot of effort. Organizations are being more thoughtful about how and when data is collected —asking only the minimum required information on intake, and gradually capturing certain data elements as the trust relationship grows over time. This allows clients to be more in control of disclosure and, ideally, to only disclose certain information when they feel safe enough to do so, rather than feeling as if they must disclose data because of their urgency to access services. Even when organizations are clear that services are not contingent upon disclosure, the client’s past experiences can lead them to believe this simply isn’t true. Clearly, it is critical to listen to the client’s voice as part of the design process in any task that involves capturing data from the client or using data to make decisions for, about, or with the client. My instinct is that there’s so much more we need to be doing. What has worked for you? What have you been a part of that made you feel as if your voice was truly heard and incorporated?

Conclusion

In much of my work, providing systems that reflect the stories of many different voices has proven to be a real, if incremental, improvement to the problems that all stakeholders face. This is why I consider myself a designer first and a technologist second — the outside-in, many-voices approach really does generate more value for all.

I am not sure that I believe it is the role of the technologist or designer to shift power, per se. At least not in the typical scope of a technology project. But I do believe it is our role to use our own power to elevate and amplify the voices that are at risk of getting left out. I believe it is our role to use our knowledge and influence to expand the ideas of what is possible and what is desirable when an enterprise system is being evaluated. It is our role to be aware of and reflect critically on the power we hold, since we are the ones creating the systems that enforce whatever rules we encode within them.

I don’t have any answers. I have two decades of observations and an increasingly urgent sense that the enterprise technologies are no longer limited in the old ways that made it harder for us to tackle these issues. So I will leave you with more questions, and encourage you to get in touch if you want to explore these issues further.

• Where have you used your power as a technologist to shape a solution that you’re proud of?
• Do you believe anything should be done to change the ways power is reflected in your workplace technology? If so, what? If not, why not?
• When you think about yourself as a consumer of government systems that you’re required to use, do you feel as if you own the data you provide or have any agency to affect change?
• Are you a decision-maker who chooses or influences technology solutions at your organization? Does it make sense to think about line staff and clients when choosing technology? Would you be willing to give your time and attention to a vendor who tried to engage you in this conversation?
• Are you a funder? What relative level of power do you see yourself having when technology considerations are being explored?
• What else must we change to ensure the power structures that are reflected in our enterprise technology systems are transparent, equitable, and trusted?

If you haven’t already, you may want to take a moment to read George Aye’s “Design Education’s Big Gap: Understanding the Role of Power.” Professor Aye is shaping some powerful conversations around the designer’s role in acknowledging and shifting power, and I owe him a tremendous debt of gratitude for shaping my own thinking on the subject.

Definitions: consumer v. enterprise technology

I recognize that many people are not acquainted with this distinction. Because the entire essay is all about enterprise technology, I wanted to offer a quick definition.

Consumer technology is stuff we, as individuals, choose to use in service of individual goals. The massive amounts of data captured while I’m using consumer products and all the ways that data is used without my knowledge (ahem Google and Facebook) is the subject of the large-scale social movements to improve privacy and transparency in “big data” technologies.

Enterprise technology was chosen by others in service of organizational goals and we often are required to use it. Many people who have to use one of these systems for work think of it simply as “the database.” Enterprise technologies are often “mission critical,” meaning that errors can cause a significant loss of money, time, or worse. Protection of data within and between these systems, and how the data stored in these systems can be used and shared, is the subject of laws and regulations. Many of these systems have a direct impact on the public (think about criminal justice algorithms, school assignment algorithms, and others) so we are seeing increasing and much-needed traction in social movements to demand transparency into the decisions that are made by software.