I got a surprising question during my workshop this week:
It seems that communication with the business is critical to make Event Sourcing right. What would you recommend to learn how to talk with the business?
And I have frozen for the moment. It sounded like a common question, but I had an issue responding promptly. A lot of thoughts started spinning around my head.
For me, it was more of a question of how to communicate with others. There’s no significant difference between the business and developers. We’re all humans.
So my first answer, after the moment of silence, was: Empathy.
And I got a blank stare and quickly realised that wasn’t a great answer. Not because it’s incorrect. Empathy is the key here. But how to teach that to others or give actionable advice for others to work on that?
Especially since we’re not taught about that during our studies, IT idols also rarely give a good example. We’re working in an industry where the running joke is: I didn’t want to be a developer to talk to humans.
Still, much of our work is related to communication: meetings, Slack discussions, emails, etc. I already wrote a dedicated article with tips on running meetings effectively. Even if we’re fully async, we write docs, commit messages. All of that is communication. Even code is a form of discussion with our colleagues of future us.
It’s clear that even if we don’t want to talk to humans, we need to do it, which won’t change whether we like that.
OK, then, how to communicate better? Here are a few suggestions:
Using terms like eventual consistency, scalability, and maintainability doesn’t say anything. Be precise and explain your assumptions using simple words. Even if you’re talking to technical people, you may be surprised that they may not know or understand terms differently. Then you may get annoyed, even if you’re the one that made a false assumption.
Let’s assume that you have a brilliant thought. You want to express that but cannot choose the right words. Eventually, you manage to do that, but it sounds much different to you when you say it. And it sounds even different for other people. Each of these steps is a translation process. Even if you speak the same language, the understanding may differ. And that works both ways. The person trying to answer you will go through the same process. So again, don’t assume. Are you not sure? Ask, and double-check.
People do not mean bad for you; people just want good for themselves. Humans are rather lazy; we are looking for easy and straightforward solutions for ourselves. We’re rarely so important that others will go to great lengths to hurt us. One may harm us if we stand in the way of their goals. It’s usually just a business. We need to select the hills we’d like to die on. Usually, they’re not worth it.
Especially towards yourself and your ideas; First, listen, then talk. Too often, we already know what to tell without listening to someone. We just wait to tell our line. Will you lose much by listening to someone else’s ideas? You don’t need to agree with them, but they can give you an intriguing perspective.
Be interested in others. Try to understand the domain you’re in. Don’t just solve coding sudoku. Talk with business, and accept that we should bring solutions, and they should bring problems. Or best don’t make the distinctions and categorisations. The business/IT split is obsolete. Now IT is business.
Assertive is not about saying no. It’s about clearly drawing boundaries and expressing them. Too often, I hear complaints that the business won’t let me use X or do Y. Most of that comes from a misunderstanding of why we’re here in the projects. We’re to solve business problems and deliver value using technology. If we are hired because of our tech skills, we need to make technical decisions. Yet, such decisions are not made in a vacuum. Time, budget and scope are also essential factors in making them. We cannot just make them based on purely technical assumptions. Still, we shouldn’t be making them and only take business assumptions. We should not be hiding from responsibility. We should have a trust agreement on the parts who are responsible for what and just make decisions in the areas that are purely in our area. Yes, that means that we can be made accountable for them. But that knowledge usually also increases the quality of making them.
We don’t need to have the same perspectives. Too often, I see people vigorously trying to persuade others to their point of view. Sometimes we can say that we respect other people’s opinions but go our own way. That’s fine as long as it’s not breaking’s other people work. Consensus is when we all win, and compromise is when we all lose the less. Agreeing to disagree is a compromise, and sometimes that’s good enough. We can always revisit our discussion later, wiser by the outcome of our decisions.
Is it all that simple?
Is this a good starting point?
I hope so.
The rest is up to you; a blog entry cannot teach you empathy.
Practice, practice, practice!
p.s. If you’re looking for a better starting point, check Dale Carnegie - How to Win Friends & Influence People. The title sounds cheesy, but it’s a great book with actionable advice. Also quick to read.
A bit harder, but great reads are Becoming Technical Leader and An Introduction to General Systems Thinking by Gerald M. Weinberg. The former will tell you how to advance reasonably in your career, the latter how to think critically, where to simplify and where to complicate your thinking.
p.s.2. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.