Empathy: The key to a successful software project
Developers should dig deep to understand their project's stakeholders.
Seating (source: Pixabay)
In recent years, most businesses have become aware of the disastrous consequences of “throwing requirements over the wall” to software developers.
Although the industry hasn’t come close to converging on a solution to this problem, there is at least some basic understanding that a software developer ought to be a whole lot more than just a code monkey—they need to be actively involved in project planning, too.
Learn faster. Dig deeper. See farther.
But is the current generation of programmers well prepared to handle a dual role as both a technical implementer and a business analyst? I’d argue that while some are, most are not. And so even though we have been given an opportunity to change things for the better, most of us are still wading around in mud.
To be fair, most programmers are far enough down the path to better customer service to know that in order to properly solve a problem, you need to understand it well. To do that, you need to spend some time exploring the surrounding context, and you need to have a decent understanding of the needs and motivations of the project’s stakeholders.
The problem we run into (and it’s basically the same blindspot that our business partners have) is that we tend to think of the person who signs our checks or conducts our performance reviews as our primary stakeholder. We shape our work around their expectations, seek to negotiate a balance between our own idea of what good work is and what will make that person happy, etc. And when we do this part well, we’re even rewarded for it!
This is empathy played out locally, and it’s better than no empathy at all. But it is not enough to safeguard the success of even relatively simple software projects. To get beyond this point, you need to look at the work you do in a much more holistic fashion. Rather than getting too philosophical, I’ll attempt to illustrate with a practical example.
Suppose that you’re a freelance software developer working for a mid-sized agency, and your current client is a business owner for a medical practice. The project you’re working on is a tool that will help their scheduling manager plan shifts for doctors and nurses.
Take a moment and think through who the most important stakeholder in this scenario is, and write it down. We’ll come back to it later.
The business owner asks you to implement a feature that will check the clinic’s shift schedule against their appointment book, to make sure that correct staffing levels are maintained at all times. You are provided with a brief outline of the task, and are encouraged to ask questions or make suggestions as needed before starting your work.
One way to look at this project to assume it will be success as long as all of the following conditions are met:
- The scheduling manager is happy with the feature you built for them
- The feature was built within a budget that the clinic’s owner will approve
- The budget is large enough to be worth the time investment for your agency
To make this happen, you’d need to understand and balance the needs of these three key stakeholders, and then you’d need to deliver on whatever promises you made to each of them. Easier said than done, but fairly clear cut, right?
Wrong. We’re only halfway down the value chain, and if we don’t go deeper, we can’t know whether our efforts will truly pay off.
One key insight that will get you closer to the heart of the problem is that the only way to make the scheduling manager’s job easier and also obtain a good business outcome is to consider the needs of the doctors and nurses. At a minimum, they’ll need to be clearly notified about any changes that are being made to their schedule—but a good system would most likely also provide some sort of direct way to communicate availability and approve or reject proposed changes.
So then, are the doctors and nurses the most important stakeholders? Nope! They’re certainly close to center of the action, but there’s one more group that is far more critical to serve well. Who is it?
Maybe the answer is obvious to you or maybe it isn’t. The most important stakeholders in this particular scenario are the patients! Although they sit five degrees of separation away from you, they are ultimately the ones that will determine whether your work was helpful, harmful, or neutral.
Recognizing this point, some useful questions arise:
- How will patients be informed if and when they’re reassigned to a different provider? Will they be given an opportunity to reschedule their appointment if they strongly prefer seeing the provider they had originally booked their appointment with?
- Will the scheduling tool work well enough to make sure gaps in coverage are filled reliably? Or will the patients end up with long wait times due to overbooked schedules that arise from under-staffing?
- Is this new feature likely to improve the quality of service for patients, or is it mainly a matter of increasing administrative efficiency? If the latter, then are there other tools that can be built which might address both goals at once?
Having fully unraveled this thread, you then would need to work your way back all the way to where you started from; convincing stakeholders at every level along the chain to consider the needs of those who sit upstream from them, while also trying to meet their own expectations. In doing this, you’d need to communicate in many different ways, because each of these stakeholders have little in common with each other.
Sounds hard, right? It is hard. But this is what empathy looks like at scale, and it’s something that separates the most successful software projects from the endless parade of solutions in search of problems.
You may be thinking that as an individual developer, your ability to navigate and influence such a complex chain of responsibilities is limited—and you may be right. But by simply thinking about these ideas and asking good questions, you can use the influence you do have to change your work for the better.
Editor’s note: Gregory Brown is working on a book about the non-code aspects of software development, called “Programming Beyond Practices.” Follow its progress here.