The cover image for this post is by 77hn
For those who don’t know, the following is our “why”:
Realising the digital potential of our clients through bespoke software solutions and leveraging podcasting to get their message directly to their customers, via our bespoke production and mastering processes.
By sharing deep compassion for you and your customers, we ensure that we have a deeper understanding of your problems, and can create innovative solutions to them which fit the problem in the best possible way.
This is only possible through compassion for you, your needs, and your customers.
It is only when your problems are shared with someone who is truly compassionate that they can help you to find the solution. This is what a friend does when you confide in them, what a medical professional does when you seek treatment, and what we do when you connect with us.
It isn’t just what we do though, it’s both how and why we do it: we want to spread compassion via our working practises.
In the development space, there’s a name for this: DevEx. DevEx is described as:
DevEx is the creation of a relationship between Developer and Customer Experience teams within an organisation to better align feature development practices to the experience of the customer.
As we’ll see, the only way to achieve full DevEx is to hae compassion for the users of our software.
Why Talk About Our Why?
Simon Sinek, in a lot of his presentations, training sessions, and books talks about establishing a “why”:
People don’t buy what you do, they buy why you do it.
One of the best examples of this is the iPod.
In “Start With Why” Sinek talks about how there were other, arguably better MP3 and digital music players on the market when the iPod was first released. Apple knew this, so when it came to marketing the iPod, they didn’t focus on what it did (play digital music in a convenient form factor) or how it did it (by focusing on the technical specifications of the iPod); instead, they focused on why people should buy one: they created a mystique around the iPod by making it a desirable device, and by prompting people to show them off with the “what’s on your iPod” ad campaign.
As such, we want to separate ourselves from the other bespoke software houses and podcast production companies out there by sharing our why, how it came to be, and why it’s important to us.
Plenty of companies spend a lot of effort telling you how great they are, and there’s nothing wrong with that. But the question of “why” is a fundamental part of our philosophy and something that we have spent a lot of time contemplating; without confidence in a supplier’s why you can’t have full confidence in the quality of their output.
Our why can be summed up with one word:
We are great believers in the power of compassion to bring teams together, to enable truly agile delivery of great quality products and services, and to boost customer confidence in our client’s products. Without compassion, none of these things are possible.
What Is Compassion?
Compassion is when you combine empathy or sympathy with a desire to relieve the suffering of another person. In the world of software development, this essentially means a customer who is struggling to achieve a certain goal or complete a task, or to help someone who is looking for a solution to a problem.
…our jobs as developers, whether we realise it or not - whether we like it or not - is to manufacture the tools that the people need in order to do things. And that requires us to understand where the user is coming from, what they want to do, the why behind what they want to do, and the (metaphorical, emotional, or physical) pain they might be feeling.
The above quote is taken from an episode of The .NET Core Podcast which is specifically about compassion for the users of the software we create. We would definitely recommend listening to this podcast episode, as it is very detailed about why compassion is so important for developers. We consulted with the podcast host to help them understand the topic, and produce the episode.
How Are We Promoting Compassion?
We are working to bring greater levels of compassion into the software development workplace, and have found that the majority of development teams tend to be lacking in compassion for their users, each other, and the companies they work for.
We recently worked with The .NET Core Podcast to create the above referenced episode about the lack of compassion in development teams, how having compassion for your users will always lead to better software which is more attuned it’s your user’s needs, what compassion is, and how to foster it in a development team.
…if you have that little contempt for your users, then it is going to come out in your everyday language, not just when you’re exchanging "banter", being silly, and talking about what you do. But you’re also going to react like that when the users report something that’s actually wrong with your software. And if a user knows that you’re going to scream and shout at them when they contact you, they’ll stop contacting you.
This leads to either users dropping your software from their toolkit (which is extremely bad if you’re a software vendor because they’ll stop paying) or user-created hacks to get around issues - sometimes this leads to Shadow IT, which is a big problem in its own right.
Treating people without compassion means that you are telling them you understand their problems better than they do; and when you do that you are immediately discounting their thoughts, feelings, and opinions.
Treating people with compassion is both listening to their point of view, and internalising it. Putting yourself in their place allows you to see their problems from their point of view; and seeing their problems from their point of view allows you greater clarity as to what the solution should be rather than what you think it is.
This is the entire point of User Centred Design and why both Agile and Scrum have such short feedback loops: we want the user to interact with the things we create as often as possible so that we can see what we got right, but also what we misunderstood. And by diving deeply into those misunderstandings we get a greater appreciation for the problem and gain the compassion required to solve those problems in a way which fits the user’s needs.
We promote compassion by consulting on podcast episodes like the above-mentioned Empathy, Sympathy, and Compassion episode of The .NET Core Podcast; but also through our day-to-day work and interactions with clients. It is important to us that we deeply understand the problems that you, our clients, face and that we offer solutions to those problems, rather than attempting to shoe-horn a pre-packaged solution to every problem.
This is one of the many reasons why we have a very public client code of conduct where we lay out what we expect from clients but also what our clients can expect from us when we work together.
Seek first to understand, then to be understood
Understanding a problem requires us to have the compassion required to see the problem from someone else’s point of view. By focusing on understanding, we can see which potential solutions won’t work before settling on the one which will work. Only then can we turn our thoughts to ensuring that we are understood when explaining the proposed solution, and this can only be achieved with compassion:
compassion is focusing on how to communicate my thoughts and opinions in a manner that you understand
In doing so, I deeply care about the words, examples, metaphors, and details that I am using to explain my point of view and my understanding of your problem.
An the only way to apply DevEx to our working practises is to approach all of our communications - with the users, customers, and our colleagues - with compassion. Working together in a compassionate way will allow us to create solutions which are better suited to the actual problem that they are facing.
Get in touch, using the contact form below, to see how we can use our why to solve your problems today, on time and under budget: