Empathy System Architecture

If you’re a software developer, there’s a skill that is becoming increasingly important to your work. Empathy. Understanding other people’s feelings and experiences helps us meet the needs of the people who will use what we create as well as writing code in a way so that it’s easier to maintain. That’s why “Act With Empathy” is our first core value at Corgibytes.

However, there’s a HUGE gap in understanding. This isn’t because software developers lack empathy — far from it and we should fiercely combat any idea that reinforces that stereotype. Instead, I think the problem is that most of the people who understand empathy deeply don’t know how to code, so they’re not able to make the connections that would make empathy concrete and applicable to their daily work.

Over the years, as I’ve spoken about empathy in software at conferences, I’ve been repeatedly asked some form of this question:

“I’m a back-end software engineer. I don’t interact with the customer. I don’t work on the user experience. So, where, exactly, does empathy show up in the work I do? How does empathy relate to things like databases and object-oriented languages?”

Lately, I’ve been diving deep into research to answer this question. The more I learn, the more I see that software and empathy have much more in common than we might think. Since I spent a decade in communications understanding empathy and a decade in software leading Corgibytes, maybe I can help be a translator between these two worlds.

Empathy as a Set of Interconnected Skills

First, we need to get clear on what empathy even is. Recent neuroscience is indicating that it’s not a feeling or character trait. Instead, it’s a set of different skills that can be developed and learned. Here’s the definition I find to be the most complete.

Empathy is a system of interconnected skills that are used to accurately and compassionately understand and help people.

For the past year, as part of the research for my upcoming book, Empathy-Driven Software Development, I’ve been hunting for exactly which skills are part of this system. As I began to piece together the puzzle from reading hundreds of research papers and books, I started to see that empathy has an underlying architecture similar to software, which I’m calling Empathy System Architecture.

With Empathy System Architecture, we can map out the fundamental skills required for empathy in the context of building software as a way to facilitate learning. Adults learn by associating new concepts to past experiences. By linking empathy to computing concepts you might be more familiar with, it might make integrating these new concepts easier.

1. Senses = Empathy Inputs
2. Perception = Empathy Processing
3. Communication = Empathy Outputs
4. Artifacts = Empathy Storage
5. Boundaries = Empathy Security
6. Relationships = Empathy Networks
7. Attunement = Empathy Synchronization
8. Perspectives = Empathy Schemas
9. Decisions = Empathy Algorithms
10. Ethics = Empathy Integrity Constraints
11. Compassion = Empathy Power Source
12. Prosocial Action = Empathy In Production

So, let’s dive in, shall we?

Senses are like Empathy Inputs

The human body is equipped with specialized neurons that enable us to interact with the world around us through senses. This sensory energy is then converted into electrical signals known as neural impulses that are sent to the brain to be interpreted. Sensing using our neurons has some similarity to how a computer might receive information from a keyboard, touchscreen, or mouse. The physical energy from the click is transformed into electrical signals that can be further processed.

As we develop empathy, we need to pay attention to sensory information. These signals can come from our external environment, such as what we see, touch, hear, smell, and taste. However, there’s also much more sensory information that our bodies process, such as what is going on internally, which scientists call interoception. Our brains are constantly monitoring levels of pain and fatigue, temperature, hunger, thirst, metabolism, breathing, heart rate, and even circadian rhythm.

Similar to how we learn to spot patterns while we code, learning to pay attention to sensory signals is an important skill for empathy.

Perception is like Empathy Processing

Similar to how the electronic circuitry in a computer executes a computer program, our brains use perception to select, organize, interpret, and cognitively experience sensory information. Perception is what enables us to assign meaning to the neural impulses we generate.

While comparing our brains to the Central Processing Unit of a computer can work as an abstracted and generalized metaphor, this metaphor starts to break down once we dive a bit deeper. So, when it comes to perception, it can be useful to extend the metaphor to include production code and not just the CPU.

For example, recent neuroscience research is showing that we instantiate emotions in a remarkably similar way to how we might instantiate a class at runtime (also known as duck typing.) When our bodies detect a sensory pattern, we’ll give it a name. For example, when I notice that my heart rate increases, my mouth is going dry and my breathing becomes more shallow, I’ll take those attributes and assign a name to them, such as nervous or excited, depending on the context.

Once we’ve named a concept, our brains will then call behaviors that have worked in the past, similar to how object-oriented languages use methods to determine the behavior of a class. When we think of perception as production code, we realize that we have the power to change our behavior in the moment. For example, I tend to talk faster and louder when I’m nervous. If this isn’t the behavior I want, I can override it similar to how we might throw an exception or use monkey patching.

The ability to adapt our behavior to our surroundings is an important part of empathy. It allows us to respond compassionately to what other people need.

Communication is like Empathy Output

Sharing what we perceive is an important part of developing empathy. When we communicate, we are transmitting information. What’s amazing is that the exact same communication model is the foundation for sending information between computers and between humans.

Shannon-Weaver model as presented in A Mathematical Model of Communication.

The Shannon-Weaver model of a general communication system was developed in the 1940’s by mathematician Claude Shannon when he was working at Bell Labs. A message begins at an information source, gets constructed with a transmitter, is sent via a channel, is interpreted by a receiver, and concludes its journey at a destination. At this point, the message gets processed at the destination and becomes part of a new message that is sent back to the original source, creating an ongoing loop that continually processes information.

Seeing this model for the first time in the context of writing software blew me away because it seemed so familiar. As it turns out, this is the exact same model that was used in many of my marketing and communication courses in college. Not something that was inspired by the original. Not a derivative model. It was this schematic. The exact same one that made the internet and all forms of digital communication possible. That’s because people like Warren Weaver and John Robertson Pierce took Shannon’s math and added context that was valuable to people who weren’t telecommunications specialists.

Now, this model has been criticized by some people in the social sciences, but I think in many ways that’s because it’s been generalized. If we dive deeper into the mathematical principles, we can explore how to construct a message so that it is clear and will likely be understood by a given audience. Using this model can also help us anticipate problems with how our message might be received.

For example, entropy, or the amount of statistical uncertainty, is a key principle of Shannon’s mathematical model. You may have come across this principle if you’ve done work in cybersecurity because high entropy is essential for generating cryptographic functions, such as ssh keys, that are difficult to break.

Entropy is related to another aspect of Shannon’s model — compression. Messages in a low-entropy (high certainty) system can more easily be compressed than ones in a high-entropy (low certainty) system. In daily communication, this means that we can predict the amount of entropy between ourselves and another person. The lower the entropy (higher certainty), the more linguistic shortcuts we can use.

Here’s how this might work in your day-to-day work. Let’s say that you’re collaborating with a teammate who has similar experience to you and you’ve been working on the same project together for several years. This experience gives you a high degree of confidence that your pairing partner would accurately interpret this alphabet-soup of a sentence. (Note: if you don’t know what this sentence means, don’t worry. You don’t need to.)

“We’re using ASP.NET MVC but don’t put the logic in the UI. That makes it easier for the marketing team to change the HTML and URLs for SEO. Plus, it’s easier for us to do TDD.”

The reason you can use these acronyms with confidence is because there is high certainty (low entropy), you can take advantage of compressing bigger concepts into letters without compromising the probability that your message will be understood.

Keeping this kind of probability in mind can help us construct better messages with people who we don’t know very well, too. For your colleague in the marketing department, you can probably guess that they wouldn’t know what most of the acronyms mean. So you might convey the same message in a different way.

“It’s tempting to want to put the logic right alongside the code that controls what you’ll see on the page. But there are some good reasons we should separate them. That will make it easier to make changes later, so we should be able to add new features faster. It’s also easier to test, so the risk of introducing a bug or crashing the app is lower. Plus, you’ll have lots more control of the links and our app would get better rankings on search engines.”

While this second paragraph is less efficient in terms of word count, it’s likely much clearer to the person you’re talking to who doesn’t code.

Artifacts are like Empathy Storage

As we sift through a codebase, we can find evidence of other people’s thinking. This is often key to being able to quickly build a mental model of what a system does. We can also reverse this thinking. While we’re coding, we can imagine people in the future and leave something for them to find.

In this way, codebases can become a type of time capsule. Just how an archaeologist or anthropologist might use artifacts and context to understand a past civilization, there are many opportunities in our daily development practices to leave artifacts of our intentions for another person to reconstruct.

When we sit down and think about the number of artifacts we create while we write software, it’s pretty staggering. With workshops I’ve run, there are always piles and piles of sticky notes, often to the surprise of the participants. Here are some categories and examples of artifacts to consider while you code. With each of these, a bit of empathy during their development can go a long way to reducing the frustration of someone who comes after you (which may even be your future self.)

• Language elements - functions, classes, methods, variables, subroutines, etc.
• File structure - READMEs, /docs/*md, directory and file names, directory hierarchy
• Version control - commits, pull/merge requests, change logs
• Automated tests - Unit tests, integration tests, acceptance tests, approval tests, scenarios and specifications (ex: Gherkin)
• Third-Party dependencies - APIs, Linters, databases, libraries, packages,
• DevOps - deployment tools, analysis tools, CI/CD tools, environment setup, orchestration, observability
• Generated Bi-Products - Logs, WAR files, output, reports, graphs
• Contextual documentation - wikis, code quality reports, product guides, knowledge bases, process guides, onboarding guides, exploratory test guidelines,
• Customer/User communication - product documentation, user guides, training, FAQs, marketing websites, social media, release notes, alt tags
• Project communication - backlog, issue tracking, story/epic tracking, burndown charts, budgets, timesheets, architecture decision records, departmental reports,
• Personal communication - social conversation, interpersonal conflict, negotiation, emotional support

It’s easy to slip into a complacency when creating some of these artifacts. You might even find yourself thinking “who’s even going to read this?” When that’s the case, pause and ask yourself who will read what you create.

For example, I used to think no one really used alt tags, so early in my career I’d kinda blow them off. Then my friend Taylor lost his vision in a car accident and he told me just how important alt tags were to him. That changed everything. Now, because I care about Taylor, I want to do what I can to make his experience with what I create as pleasant as possible. Identifying the human and empathizing with their experience can help us find the motivation to create more maintainable and accessible software.

Boundaries are like Empathy Security

Boundaries are absolutely critical to creating systems that are healthy and resilient. You don’t have to look far in the software world to see this. Many programming patterns are rooted in setting and managing boundaries between different system elements (encapsulation, strong cohesion, loose coupling, microservices, bounded contexts, automated testing, and SOLID principles are just the tip of the iceberg.) In general, healthy boundaries = healthy codebases.

The same can be said for people. Healthy boundaries = healthy relationships. However, many of us (myself included) have been conditioned to believe that operating from a place of empathy means always acquiescing to other people’s needs.

That’s not empathy. That’s being a doormat.

Compelling research on this comes from Adam Grant’s book, Give and Take. People who help others with no strings attached tend to be highly successful, but only if they maintain strong personal boundaries. His research shows that people who don’t “give their time and energy without regard for their own needs, and they pay a price for it. Selfless giving, in the absence of self-preservation instincts, easily becomes overwhelming.” Operating without personal boundaries actually hurts our capacity to empathize with others.

What do healthy boundaries look like? In her book Set Boundaries, Find Peace, Nedra Glover Tawwab provides three categories:

1. Porous - when we don’t clearly communicate what’s okay and what’s not okay, it can create an unhealthy closeness (enmeshment) that can drain our energy and lead to unhealthy relationship dynamics.
2. Rigid - if our boundaries are too inflexible, we can inadvertently push people away which prevents us from developing the trust required for a deep connection.
3. Healthy - boundaries that enable resilience “require an awareness of your emotional mental, and physical capacities, combined with clear communication.” You are able to give without giving too much, which often requires saying no with confidence.

To help us understand how to set and maintain healthy boundaries, we can turn to the world of cybersecurity. In 2015, Symantec published a whitepaper titled “The Cyber Resilience Blueprint: A New Perspective on Security” where they advocated that “organizations must change their security posture from a defensive stance focused on malware to a more realistic and resilient approach—a cyber resilient approach.” In other words, porous boundaries were bad, but this was a recognition that rigid boundaries could be equally bad. Symantec’s “Five Pillars” which describe healthy security policies also happen to mirror healthy boundary policies.

1. Prepare/Identify - First, we need to identify what we need to protect. This means having compassion for ourselves and being honest about the boundaries we need to uphold, even boundaries that we need to hold ourselves accountable for.
2. Protect - There are six types of boundaries that we need to monitor, according to Twwab: physical, sexual, intellectual, emotional, material, and time. The goal is to communicate boundaries in a way that is clear, direct, appropriate, and consistent.
3. Detect - People will bump up against your boundaries constantly. The ability to notice violations is important. Seldom do you establish a boundary just once. It’s an ongoing process.
4. Respond - When a violation occurs, it’s important to resolve the issue promptly to prevent boundaries from becoming porous. Behavioral regulation and consistency is key so that our actions serve our goals.
5. Recover - Self-care and reflection are an important part of the boundary setting process. It can be helpful to proactively develop healthy remediation and recovery strategies, such as therapy, exercise, or spending time in nature, that might help you heal when a boundary violation occurs.

Relationships are like Empathy Networks

There are many ways that we can connect computers to each other. The arrangement of nodes and their connections is just as relevant with people as it is with computers. In the field of telecommunications, we use the term network topology. When we’re analyzing social systems, it’s referred to as social network analysis. Whether you’re looking at people or computers, the goal is to map out relationship structure to understand how information flows through a system.

Using nodes and links, you can map out how both computers and people form relationships with each other. Image Source: Adobe Stock/kytalpa

For example, as an individual, it’s useful to observe how you relate to the people around you. Some of your relationships will be stronger than others because there has been more opportunity to build trust. For example, your relationship with a trusted long-term friend is stronger than that of the cashier at your coffee shop.

Looking at your personal network topology is helpful for your personal well-being as it can help you figure out where to spend your time and energy investing in relationships. There are some relationships you might want to strengthen (say, a new co-worker who is working on the same project as you) and which ones you may want to weaken (perhaps a person who is consistently disrespectful and doesn’t honor your boundaries.) It can also help you discover a community and build social capital that can help you reach your personal or professional goals.

From an organization perspective, interaction topology is important for productive teams, a concept that Matthew Skelton and Manuel Pais explore in their book Team Topologies. We can also see this in open-source projects on GitHub, where research has found that networks that placed a high emphasis on rich interactions and clustering were more productive and resilient than those with a hierarchical structure with only a few key maintainers. Finally, paying attention to your team’s communication architecture matters because, according to Conway’s Law, it will be mirrored in your system architecture, too.

Attunement is like Empathy Synchronization

In software, we have many different protocols that help us ensure that information is synchronized between different devices. For example, TCP/IP is largely what runs the internet. Messages are broken up into packets, sent across a network, and then reassembled on the other end. The emphasis of this protocol is accuracy. Did the packets, which may have each taken many different routes to arrive at its destination, eventually arrive in the correct order?

For human relationships, attunement is the mechanism that allows us to build trust through accurate understanding. At its core, attunement is about listening without judgement or defensiveness. When we attune, we are intentionally making an effort to synchronize our understanding with another person’s emotion and experience. We are doing our best to ensure the packets of information that another person is sending are being received correctly on our end.

Attunement is a choice. Do we turn towards the opportunity to understand or away from it? This choice happens in small day-to-day moments, bigger more significant moments, and also in times of conflict. In his book, The Science of Trust, relationship researcher John Gottman dives deep into the theory of attunement, which he developed with his graduate student Dan Yoshimoto. “The skills of attunement,” Gottman explains, “can make all the difference between a relationship’s strength versus its demise.”

Perspectives are like Empathy Schemas

In both software development and psychology, models and schemas are terms that we use to describe how we organize information and explain conceptual relationships. Our brains hold an extraordinary amount of data that we use to make sense of the world. As we navigate our experience, our internal database is constantly updating itself and reorganizing information to help us conceptualize reality. It’s as if we have a massive database inside our minds. It’s our perspective — a dataset of experiences that is unique from everyone else.

In psychology, schema theory was first developed by Jean Piaget in 1923 and is a foundation for popular therapeutic techniques of today, such as Cognitive Behavioral Therapy. Schemas are heuristics that we’ve built in our minds so that we can rapidly and intuitively assign meanings to things.

For example, how do you identify if something is a table or a desk? In many ways, their attributes are the same. They both are commonly rectangular, made of wood, are similar heights and have four legs. The differences might be subtle, but we learn to distinguish them through lived experience. In other words, we’ve built schemas around them.

Schemas aren’t just for tangible objects either. We form concepts to categorize abstract things, too. Colors, ideas, and emotions — all of these are schemas that are built on our internal mental models. So are concepts that we might want to change, such as stereotypes.

If we want to operate with empathy effectively, it’s important for us to find ways to enable other people’s perspectives to become compatible with our own. While this can be a challenge, there are tools that we use to build software that can help us. In particular, we can look at relational databases.

A relational database consists of different tables, each which are made up of rows and columns like a spreadsheet. The database is built by creating relationships between these tables, which makes the data relatively easy to retrieve and modify.

As developers, we can use tools such as Structured Query Language (SQL), Class Diagrams, and Entity-Relationship Models to help us wrap our brains around what’s going on. We can adapt these tools that we already use to help us map out our perspectives. Then, we can work on creating ways to easily interface with other people, similar to how we might build or consume an API.

While this might seem far fetched, consider that researchers and developers in the field of Natural Language Processing are already using these types of techniques to personalize the responses of computer systems in programs such as chatbots. You can also check out John Sawers, who talks about Emotional APIs.

Decisions are like Empathy Algorithms

As humans, we build our own algorithms and formulas to help us evaluate information and choose a course of action. In the book Algorithms to Live By: The Computer Science of Human Decisions, computer scientists Brian Christian and Tom Griffiths explore what they call “human algorithm design” which is about applying computer science principles in ways that help humans find better solutions for every day decisions.

This matters, they argue, because “Thinking algorithmically about the world, learning about the fundamental structures of the problems we face and about the properties of their solutions, can help us see how good we actually are and better understand the errors that we make.”

The decisions we as technologists make ultimately end up in the technology we build. This is especially prescient in the field of machine learning, where biased datasets are increasingly being used to determine who gets an interview for a job, who qualifies for a mortgage, who gets granted parole, which results come back for search terms, and what information gets shown on social media and online advertising. These seemingly small decisions have a big impact on an individual’s life, impacting their earning potential, civil rights, safety, health, and well-being.

Dr. Joy Buolamwini, founder of the Algorithmic Justice League defines this problem as “coded gaze” a term which she developed to describe “the algorithmic bias that can lead to exclusionary experiences or discriminatory practices.” According to Buolamwini, coded gaze is “a reflection of the priorities, preferences, and also sometimes prejudices of those who have the power to shape technology.”

Being aware of how we make decisions and consistently trying to make more compassionate choices is an important aspect of empathy.

Ethics are like Empathy Integrity Constraints

“The scientist, engineer or manager may well wash his hands but this will not free him from moral duties or social responsibilities — not only qua a human being and a citizen, but also as a professional. And this because, let us recall, they more than any other occupational group are responsible for the shape the world is in. You cannot manipulate the world as if it were a chunk of clay and at the same time disclaim all responsibility for what you do or refuse to do, particularly since your skills are needed to repair whatever damages you may have done or at least to forestall future such damages. In short the engineer and the manager, precisely because of the tremendous power they wield or contribute to building up, have a greater not a diminished moral and social responsibility. This being so, they had better face it.” - Mario Bunge, “Towards a Technoethics”, 1977

As technologists, it’s important to recognize that ethics is a critical part of the work we do. This means consistently considering the impact that our work will have and modifying our actions accordingly. The optimism bias is seductive, but we must think beyond whether or not something could be built and think also about whether or not it should be built. While it’s tempting to dismiss ethics as something that can be delegated to another department, as software developers, we cannot abdicate our responsibility, as the philosopher Mario Bunge points out in the quote above.

Again, we can look at how we work with data in software to help us explore ethics and empathy. In a relational database, a key aspect is what’s called an integrity constraint. These are rule sets which are put in place to make sure the data stays accurate, consistent, and reliable. In a similar way, ethics are rule sets we embed into our decision making processes to help us weigh whether our actions are moral, fair and just.

For example, the Ethics and Compliance Initiative recommends thinking about problems in through what they call the four “PLUS filters.”

• P = Policies - Is it consistent with my organization’s policies, procedures and guidelines?
• L = Legal - Is it acceptable under the applicable laws and regulations?
• U = Universal - Does it conform to the universal principles/values my organization has adopted?
• S = Self - Does it satisfy my personal definition of right, good and fair?

Then, while you are making decisions throughout your daily work, you go through the following seven steps:

1. Define the problem (consult PLUS filters)
2. Seek out relevant assistance, guidance, and support
3. Identify alternatives
4. Evaluate the alternatives (consult PLUS filters)
5. Make the decision
6. Implement the decision
7. Evaluate the decision (consult PLUS filters)

This is just one of many different ethical frameworks out there. Incorporating ethical considerations into our daily decision making is an essential aspect of coding with empathy.

Compassion is like an Empathy Power Source

Imagine you own a car. If you want to use it, you’ll need the right fuel. Otherwise, you won’t get very far. Such is the relationship between empathy and compassion. Empathy is like the car and compassion is like the fuel. Or, if we’re sticking with our computing metaphor, empathy is like the laptop and compassion is like the battery.

While there are many overlapping qualities of empathy and compassion, the distinctive quality of compassion is the active desire to relieve suffering. Research from the Center for Compassion and Altruism Research and Education (CCARE) at Stanford University describes compassion as having four key components:

1. Awareness - cognitively recognizing suffering
2. Affect - being emotionally moved by suffering
3. Intention - wanting suffering to cease
4. Motivation - a readiness to help relieve suffering

Compassion is cultivated and nurtured with sustained practice, which you can learn through programs such as Compassion Cultivation Training, which was developed through the researchers at Stanford’s CCARE. Specifically, this includes skills such as learning to slow down and pay attention (mindfulness), generating feelings of caring and warmth (loving-kindness meditation), and increasing compassion for yourself (self-compassion).

In this way, compassion becomes enduring and active. Compassion isn’t something that happens to you. Rather, by adopting a compassionate mindset and purposefully nurturing it, your capacity for compassion can increase over time.

Empathy that isn’t fueled by compassion can become taxing and toxic. Without compassion, attempts to understand and help people can backfire and often aren’t sustainable. For example, if we have compassion for everyone else, but forget ourselves, our poor boundary setting can lead to burnout. If someone is able to cognitively understand another person, but doesn’t care about how they feel, they’ll be more likely to manipulate them or inflict harm. On a group level, having compassion for some people but not for others can lead to tribalism where entire groups of people are disparaged or dehumanized, sometimes based on a single characteristic (race, ethnicity, nationality, gender, etc.)

When our compassion tanks are full, we have the energy to do the hard work of perspective-taking, attunement, boundary setting, communicating, and the other skills in Empathy System Architecture. Without compassion, we can expect an empathy breakdown.

Prosocial Action is like Empathy In Production

A software production environment is where the latest version of the code is made available for use. Infrastructure, servers, source code, databases, and more all work together to deliver software that, hopefully, works as it was intended. Software in production is software in action.

This is true for empathy, too. Empathy requires interaction. It doesn’t just live in our minds. This is similar to how we might write code on our local environment, but to make it useful, we need to deploy it to production. As the old proverb says, “The road to hell is paved with good intentions, while the road to heaven is paved with good works.” It is our action that matters, not our intent.

Eek! If this sounds scary, you’re not alone. Operating with empathy means that we’ll make mistakes. We’ll mess up. We’ll blunder and get things wrong. Empathy is a vulnerable process where we are consistently facing our own inadequacies. Learning to stick with it and work through the big challenges is part of the package.

This happens when we write code, too. Bugs crop up that we didn’t expect. A change to a dependency introduces a new security vulnerability into our system. We bang our heads against the keyboard trying to solve a tough problem. But we keep going. We learn. We patch things up as best we can and try to make things better.

Empathy isn’t about being perfect, but it is about orienting our actions so that we are more likely to help than harm. When empathy goes well, we can see higher trust, more joy, more creativity and innovation, and higher productivity — all because we’re able to work better together.

Empathy Training for Software Teams

Believe it or not, what you’ve read only scratches the surface of many of these ideas. Just like you can go incredibly deep on a single aspect of software system architecture, there’s a rich treasure trove of information about any aspect of empathy system architecture, too.

If you found this article interesting, be sure to sign up for updates about my book at empathyintech.com. We’re also hosting events and have an active Discord server to help make empathy training in the tech industry as accessible and inclusive as we can.

And finally, while empathy skills are absolutely a key part of what makes Corgibytes so good at software modernization and maintenance, we’ve determined that teaching these concepts to other teams is outside of our core competency. This means that you’ll be hearing a bit less about empathy from me on the Corgibytes blog, but…

…(drum roll)…that’s why we’ve launched Heartware — our sister company that will focus entirely on helping developers build these critical skills in the context of their daily work. While I’m still actively involved in Corgibytes, my main focus for the next phase of my career will be building this new business that helps turn “soft” skills into software skills.

Over the past decade, I’ve seen first hand how actively making empathy part of your daily development practice can have a profound positive impact. Empathy System Architecture helps take empathy out of the clouds and into the code. When we look at empathy as an integrated system rather than as a collection of isolated components, we can start to see how elements interact and decide where we want to focus our attention.