It's the Empathy, Stupid! | Konstantin Diener (EN)

In this talk, Konstantin discusses the importance of empathy in communication within organizations, especially how technical teams interact with management. He highlights common scenarios where developers face resistance from decision-makers when advocating for necessary resources or Agile practices. Konstantin emphasizes the need for developers to adapt their communication style to align with management's focus on costs and revenue, rather than relying solely on technical jargon. He shares anecdotes illustrating the disconnect in understanding between roles and the necessity of framing arguments about technical needs in terms that resonate with business leaders. By adopting a perspective that prioritizes the goals of management, developers can foster better cooperation and drive organizational success.

[music] >> Good morning, everyone. Or like we say it here in Germany, Mahlzeit. Welcome to my talk about It's the Empathy, Stupid. Um I'm going to talk about how we should interact in companies, how we should talk to our management, our decision-makers, our leadership. And um there will be small bits of AI in this presentation, but but not that much. It's one of the a few presentations

on this conference that is um not covering AI topics. I think you have been attending the uh the third day in a row now. If you have questions, scan this QR code, and you can post questions, and hopefully there will be time left in the in the end, so I can answer a few of them. My name is Konstantin. I'm CTO and co-founder of a company located

in Darmstadt in in the Rhine-Main area. Um we are focusing on building digital products that create value for our customers. And I will talk about things like value and um revenue and concepts like this uh throughout my talk. Who in the audience is a developer? Okay. Are there people in a different individual contributor role, tester, designer? A few of you. And is somebody here that is in

a leadership position, leadership role? Okay, a few of you. Fantastic. I brought some example situations to guide you through that um topic. Um and I think many or most of you uh know at least one of these situations. We won't be getting a license for XYZ. We are talking to management. They are not willing to pay the license for blah. Maybe it's the fanciest, coolest, newest AI

tool and you have to use free plans or this um educational plans uh {quote} {unquote} uh and uh are not allowed to use the real adult licenses. something from the Agile world, an example. I had this discussion over and over again with management teams um on one side and Agile Agile missionaries on the other side. It's important to have the whole team in the sprint review and

management always said, "No, that's not efficient enough." Maybe that's If you work for a product company, you can replace sales with any other stakeholder rule role, but maybe you know something like that. In your team, you do product work. You [snorts] discover new features. You think about uh things customers might love very hard, but in the end there is a guy from sales uh having a great

idea and the ideas from sales always win. And another topic that seems to be to become easier these days using AI tooling, but it was a constant battle together with decision or with decision makers about hey, we are using these and that libraries and they are outdated. There are vulnerabilities. We have to fix that. Oh, no, that there's no time for that. Please implement features. Who of

you heard at least one of these situations once in his career? Okay. You can relate to that. That's wonderful. And the interesting I question is how did you react in these kind of situations? And I'm guilty as charged. Me personally, I did react like that. But it's that obvious. It's very important to have all the people from the team in the sprint review. That's very, very important.

You do it like that in Agile and Agile is good. We have to have a retrospective every 2 weeks. That's not optional. We do it like that in Agile and it's very good. as I said before, I'm guilty as charged. I acted like that over and over again, telling customers why it is necessary to do product discovery work, why it is necessary to hold have the whole

team in the in the sprint review. We are paying that bunch of money for having seven people in the review. That's not efficient. And over and over I was telling them, we do it like that. That's the right way. Why don't you get it? And how did we end up here? And it's a situation that reminds me talking to my mother-in-law. She's a very nice person, don't

get me wrong, but she lives in the Czech Republic and Czech is the only language she is able to speak fluently. And I'm on a maybe A1, maybe A2 grade in understanding that language. But from time to time she uses vocabulary I don't know. I don't get what she's saying. And what is her reaction if I say "Didn't get it?" She repeats the same sentence louder and

slower. But it makes any difference. Doesn't make any difference because I don't know these words. So she repeats again louder and slower the same message instead of using different vocabulary, something I might know. She uses the same vocabulary and repeats it over and over again getting And that's the same principle we applied years and years over years talking to our management. Why don't you get it? It's

absolutely a sprint review because the Scrum Guide says it like that. Okay, we repeat it over and over again. but is it's this sender-receiver problem. We use the language the receiver doesn't understand. by simply uh spreading the the the same message, they didn't get it because they didn't know the language we are um using. And leadership here is uh a classical entrepreneurial leadership person that can be

your product owner, for example. Hey, we have to refactor these and that aspects in the codebase. Why? Just take time. We don't have time. We have to implement features. I don't get it. Why? We have to clean up our codebase. I don't get it. We have repeated the same and the same message over and over And one interesting aspect, and I every time I post this uh

comic on a slide, I have to smile a bit, is that we dramatically overestimate or uh what or under estimate um overestimate what others know about our discipline. That are two, I think, uh geologists discussing um chemical um things, and I don't know any of the the things they're mentioning because things that are completely completely clear to all of us developers I just must understand it like

that. I had discussions with my colleagues over But the customer must understand that. They must know that. That the implication of doing XYZ must be No, they are no developers. They won't get it that the implication is this and that. But we They don't get it. 2 years ago we had um, a customer and after a year working together she said, "A Wi-Fi and VLAN is the

same, right?" Mhm. That's right. But she was always she always loved working with us because she said, "You're the first agency that um, doesn't make me feel dumb. That I have to understand all these terms of sprints and releases and increments and backlogs. Never heard that before. I'm a lawyer." Um, you are the first agency that doesn't make me feel dumb, but some colleagues um, thought it's

pretty obvious what a sprint is about or a backlog is about. That's just how software is built these days. And the challenge for the senior leaders on top in the company that there are teams in the company. Development teams, marketing teams, sales teams, whatever. And every department, every has its own lingo. Marketeers speak a different lingo than developers do, than sales peoples people do, than HR is

doing, and so on and so on. And there's a middle layer between them their own language, their own lingo as well. And the interesting thing is we always the people on top of the company must understand all that lingoes of marketing, HR, sales, development, and But that's not possible because um, divide and conquer, they maybe they won't get it. And maybe they don't understand what you are

telling them because they don't have no clue about your domain yet quote quote. many people in management they are not willing to understand what you are doing. Your whiny developers asking for tools and budgets and another sprint to implement that obvious thing of software and And the end of this it leads to managers that don't get anything of the things happening in the company that are only

steering a company by using Excel sheets and PowerPoints and and so on and so on. They are not willing to understand how a car is built actually how a machine is built how that software is built because graduated a business school and are used guide the company through Excel sheets and PowerPoint presentations. In 2000 I think in 2008 during the financial crisis I heard a radio show

about a book publication The Puritan Gift to the American Society written by two brothers Kenneth and William Hopper and the book focuses on describing um the American economy has over decades over centuries um been built on the mindset of the people that were settlers in the US. Something like leadership is a role not a job." for example. And there were American presidents in the past that were

farmers in their day work and were also presidents. And still in the '50s, 1950s, it was pretty pretty normal for an American manager to get their hands dirty to understand what all the people in the company are doing on an regular basis, repair a machine or something like that, what the what the company is focusing on. The In Japanese in the total Toyota production system, they called

things like that gemba. Go see down to the production place, understand the processes where the the work is happening. And these both two people described that the beginning of the end of the success of especially American um economy started with these business schools and people that just learned managing, but learned nothing beside managing, just steering by Excel sheets and PowerPoint. And I Years ago, I was a

consultant um in banks and in investment firms, and I saw that in real life. People having their glass cubicles and just steering They weren't um wandering around uh in in the They were just in their glass cubicles and steering the company from their glass cubicles. People, if they want something, it was like visiting the Pope. They have to get an appointment there and present their slides, and

then maybe they get what they want to have. That means maybe the people on top level of your company aren't uh are not interested in learning what software development is, what marketing details is. They are not going to learn your language. How did you react? Ha. Stupid idiots. The strategy is crap. I talked to Scrummers, this product owners, and so on from big corporates. Every time their

management, senior management made an announcement, they replied in a bunch of hate. Uh these dumb dumb heads. They don't get anything, blah blah blah. And always this how can we um destroy their ideas? How can we destroy the strategy? How can we um uh some kind of um uh blockade establish a blockade on that. And does that feel good? Acting like that? Interacting with like that in

the company? Yes, there are people loving that. Yeah, ha ha. It's struggling around and we we we gave them another bunch. Fantastic for their crap strategy. But in the end, I think you're sitting here, most of you are not interested in having these battles every day and showing management that that they are And if you want to change it, you have to first change yourself, and the

most important thing is to change how you communicate with within your organization because we have to learn the language of the levels in the upper management, senior management, and not wait for them to learn our language. And I was when I was a young consultant in an investment firm, I worked together with a customer, a team lead at that investment firm, and he impressed me. A very

a very impressive person, and he said, "I've always been successful when I help my bosses succeed." Not this attitude of, "Hey, he's my boss. He has to help me succeed." Just wondering about what are their goals and targets? How can I help them um be successful? And that's the central question, what motivates these people or the the person I'm talking to, and how can I help them

to be successful? And that will be make my life better as well. And last year we had at our Scrum Tische Darmstadt, we had um Silke from the Cologne region, and she was talking about how to how to connect Agile to non-Agile people. She meant especially senior management. And the interesting thing, the advantage was that she had been board member for many years. she said she was

pretty overwhelmed when when she joined the board, every board meeting was just about costs, revenue, maybe acquisitions, but most of the times cost and revenue. Nothing different. No product discovery, no marketing strategy, no um fixing broken dependencies. And Rich Mironov, um a thought leader from the US that recently moved to Europe, he said at last or I think at last year's um Product Hunt conference, business people

don't understand sentences that lack a currency symbol. If you tell them, "If we do do the this and that, we will increase our our conversion by 12%." But that means costs as well. We have to implement that stuff. Yeah. Not interested. "We can increase our monthly revenue by 50,000 euros." Oh, that sounds interesting because there is a currency symbol involved. senior management people are just that simple.

Revenue, cost, profit. And that's their argue about that, but in the end it's their job. And there's a aside from Jason Who of you knows Jason Fried from 37 Signals, Basecamp dudes, and so on? He has very strong opinions. I like most of them, but not all of them. And he once said, "The P in my P&L, profit and loss, stands for freedom. Only if we make

profit, we have the chance to do the things we like to do it. Therefore, we need profit." He wrote a longer blog post about their model of how they create software, how they avoid working with investors and are modern term for that is bootstrapped um their business. And in the end, it boils down to five business goals why companies invest money. The first is they want to

increase revenues. Here is it Here it is again. The second is decrease cost. The third is increasing new business and market share. The The fourth one is increasing revenue from existing customers. That's something like customer lifetime value And the fifth one is increasing shareholder value. And it's simple like that. Senior management people only think in one in these five categories. How can we increase revenue? How can

we decrease cost? How can we increase new business? How can we uh increase customer lifetime value and something like that? Or how can we increase shareholder value? That's one lesson and the the next lesson is and I listened to a podcast uh and it was mind-blowing that people in our software teams all peoples in organization tell stories. But the stories we tell in organization depends on our

role. It's people in software teams tell stories they which span I think days to weeks. In middle management or your product creating a road map, something like Weeks to months. And senior management thinks in quarters to years. That means if you tell them stories in your period of time, that's much too fine-grained for them to understand. Because they they always think in Maybe they are listed uh

at a stock exchange. That means quarterly reporting and something like that. There's a German video by Markus Andrezak, um a guy from from the product scene describing this phenomenon um about how uh the stories differ on different levels in the organization. That means to convince your leadership, and that is the main reason why you're here in this talk, you must argue within their horizon, not days to

weeks. We have to implement XYZ in that sprint to blah blah blah. They are not interested in sprints. That's not the horizon they are thinking in. And you must use their language. I will start with the simplest possible In the early 2000, I had my first professional job in software engineering, and we used a tool that I think it its name was IBM Studio for Rational Application

Development or An Eclipse-based tool. Who of you knows It took 5 minutes to start. 5 minutes. We had desktop PCs, no laptops. They were too expensive. We had desktop PCs, and we had to switch off them in the evening and restart them in the morning when we start work. And every morning we waited 5 to 10 minutes because these machines didn't have memory. So, we told our

CEO, "We need more very small firm." And we told him, "Hey, we need more memory. These computers are very slow. The development environment takes 5 to 10 minutes to start." And what did he hear? Costs. Costs. RAM costs. Costs. And we repeated that message over and over again, and nothing happened. Our development lead had uh motivational speeches like, "When I started software engineering, we used the text

editor, dude." Yeah, fantastic. But, we don't use the text editor, we use IBM Studio for Rational Application Development, and it just to start. And then we we changed our approach and just calculated, "Okay, we have very cost-sensitive customers. We have to be very productive. And these 5 to 10 minutes every day means that you lose every month up to 4,000 euros, which you have to pay us

as developers, but can't charge the customers for." 3 days later, all of the machines had had double of of memory. Because that was a story in their language. Not just, "Oh, we are wanting developers. We need more RAM in our It's that slow." Um We said, "Okay, you lose 40 4,000 euro every week. And these RAM costs maybe 4,000 euros once. That seems to be a good

idea." We argued missing revenue missed revenue, costs, And that's the same applies for things like licenses. I'm sitting around and waiting uh for my machine, for my agent, for my whatever, until um I have new tokens in my AI model. The same applies. Just calculate how much time elapses and how much costs um pile up until you're waiting or things that can't be done because of missing

licenses or something like that. The second one, you're familiar with that as well. Only a small part of the team is allowed to take part in the sprint reviews. >> [sighs] >> Costs. The whole team in the review. First approach, first guess. If the whole team participates, €600 per meeting. Six people, 1 hour, maybe 100 euros per hour. Two emissaries participate. Very efficient. Means two people, 1

hour, 100 euros, 200 Wonderful. Does it work like that? How will the be the rest of the team be informed about what you discussed in the meeting? Oh, they can read the protocol. Mhm. Okay, let's say these two emissaries go back to the team and then inform them about what has been discussed in this meeting. Means and six maybe uh 45 minutes, 100 euros. Means in the

end 650 euros just for informing them. And what does always happen in this "Hey, we had a meeting with our stakeholders and that are the results. We try to inform you." What does always happen? The same if I talk to a neighbor or something like that, come back home, and my wife asks me, "And what about their elder daughter? Is she back from from the US?" I

didn't ask. You have to ask something like that. That's interesting. So, that means what happens if the team has questions about the things discussed in this And then it ends up with um it's not that efficient. We need another two more uh times half an hour, and that what Oh, that's in German. Still in German. What seemed to be a very efficient idea is not an efficient

idea. But, that's formulated in a language business people understand. Okay, every meeting if everybody participates costs you €600. If we send two emissaries, what seems to be more efficient, is uh €750. Features from sales always win. My example I used uh also used through my product discovery talks is of a a ride-sharing app where you can uh want to travel from maybe from um from Darmstadt to

Cologne to visit Jaxon. You don't want to use the um the train. So, um you can just open a ride-sharing app like BlaBlaCar or And they did product discovery, and um their goal is in Q3 we aim to acquire 50% new customers, and they mapped opportunities or problems their customers currently have to make the experience better and and foster customers to um help the ride-sharing app to

reach their goal. Pick up and drop off are quite problematic, and I will focus on the middle um three part. Deutsche Bahn is too expensive and maybe I didn't know that ride sharing is cheaper and so on and did customer interviews, collected data and so on and in the end um they had the idea uh the product team had uh has the idea we should implement this

you save X euros using ride sharing feature and that will increase our conversion by 50%. And that's this that lacks a currency symbol topic Because at the same time sales comes around the corner. Hey, we talked to business customers. Display ads in our app are fantastic idea. We can make, I think, at least 30 bucks 30,000 bucks a month using display ads. Hm. Revenue. Management is interested.

More revenue. 30,000 bucks. Cool idea. And on one hand display ads 30,000 bucks a month and from your team you don't know it yet. You just said we'll increase our But you were very convinced that's the right right idea because you did product discovery techniques, your product owner did customer interviews, you participated in that customer interviews, you mapped, you blah blah But in the end it's that

yelling game again. We are so convinced that's right and sales is wrong. Start playing their game. What's the anticipated growth of our customer base implementing that new feature? What are the cost per trip? What's our fee? We think from our results from product discovery that we'll have an uh additional 20,000 rides a month with 25 euros each ride and we get a fee of 12 That's right

that's not right. I wanted to write 12%. Uh 12% fee means 60,000 euros. Bam. Now it's a different game because it's not just we are we we very proud of our results and we think that's the right way and sales is just wrong. No, sales says 30,000 and you say 60,000 additional revenue a month. That's interesting in for business people. And I think some of you in

the audience are skeptical now. Constantine, where do you get all that numbers from resulting in these 60,000 euros? Are you a magician? No. It's the same game sales does as well. We do swag, scientific wild-ass guesses. Who of you has seen um Star Trek IV: The Voyage Home? Oh, very few of you. There's a scene and Mr. Spock is tasked with calculating how they can travel back

in time using a Klingon uh spaceship and he said he's not able to calculate it. He has to guess it, a Vulcan. That always is logic and just calculates. He has to guess it. And the captain Captain Kirk says more convinced of Spock guessing than other people calculating. That are scientific uh wild-ass guesses as well. Spock does it as well. And is doing it like that. There

is no customer that says, "Okay, implement that. Here is the letter of intent. I'll give you my money, 30,000." They're doing the same stuff, scientific wild-ass guesses. Okay, got it. But, there is this challenge. We're not allowed to update these libraries. We must update the dependencies. It's important. Don't you get it? apply the same rules then because at this point, it's just costs somebody up. People from

development say, "Costs, costs. We have to do that and that." But, the interesting thing is if we try to attach a number to this aspect as well as we did with the ride-sharing app, 30,000, 60,000, the game changes as well. How much vulnerabilities are in the actual code base? What do we anticipate? It's a scientific wild wild-ass guess again. What do we anticipate is the harm in

euro if this vulnerability is used, exploited by an an attacker? And how's the likelihood? Is that very likely, unlikely? And you can calculate um what the problem might be if you don't update the libraries. And that's a completely different story telling management. If we don't update these libraries, we risk penalties of up to 2 million euros. But, there's your enemy again, sales. Libraries. Probability. Doesn't matter. We

have a fantastic idea of display ads and we updated our calculation. It's 2 million euros a year. psychological bias you could use to win this race. And that's called loss aversion. If I give people two opportunities, one means to win and one means not to lose something, mankind will always choose the option that means avoiding to lose something. That means if sales say, "We can earn another

2 million using display ads, another 2 million a year." Additional profit, I can win something. And you tell management you will lose 2 million euros if you don't fix that Loss aversion is kicking in. We could lose something. Yeah, they told us something about how to win. No, no, no, we don't want to lose money. they don't want to lose money and the second thing is that

can lead to jail for decision makers if there are breach data breaches of personal data or something like that. assume that some of you are very skeptic now. Constantine, that's interesting. Nice right. Interesting. Nice information before having lunch. But all the things you mentioned are definitely above my pay grade. I'm a developer. I'm an engineer. I don't make any calculations like that. I I think you should

become comfortable with thinking in terms like that because times are tough out there. And CFOs have actual sheets like that. That are costs per month for teams. And then CFOs or controllers start asking questions like this team of Constantine doesn't add value or can it be laid off? In German there's this uh from a famous exhibition of Joseph Beuys this is das Kunst oder kann das weg.

Stiftet das Wert oder kann das weg? That's the question. And when this question arises, it's too late. That in the future, you should have a plan how you can communicate the value of your role, of your team, to avoid all these discussions. And in the age of AI and here's a bit of AI again also in my talk. I think the the message spread across all the

talks on this conference is coding becomes less less important, less expensive, and less while creating value for the company is the new interesting thing. That means thinking in value. What does that mean? Should we implement that that came from sales? Is that really a good idea. Thinking in value, communicating value losses, and so on, will be maybe not a core competence, but a very valuable competence for

you as engineers and problem solvers in the in the in in the future. many of the speakers have provided you with something you can start on Monday. Slides, I have something similar here. Last year I read the fantastic book Impact First Product Teams from Matt LeMay. And um he has a very powerful idea that he said the goals your team has should be no more than one

mathematical operation and one Y be away from your organizational goals. Not this cascading or Who has OKRs in the company? Who has cascading OKRs? Christina Wodtke and Matt LeMay say OKRs doesn't make any sense because when you end up in the team, there's most of the times no connection anymore to the company goal. That means your OKR is one hop away from your company goal and one

mathematical operation. And the the thing, the task you can start on Monday is thinking about what value does my team provide? Um and how does it correlate to what our company wants to achieve? And if you need support thinking about that question, I'll offer you um a free session of 1 hour of uh value assessment. We can discuss things I showed you in the presentation on a

real real example, something like getting licenses, and but we have real trouble with our decision makers, and I want to discuss that with you. How can I articulate that in their language? You have an actual issue convincing a management. We can discuss something like that. Or how can I find out what's the value of my team? And how many hops is that away from our company goals?

Here's the QR code. If you scan that, fill in your data, and I'll contact you if you're interested in having that conversation. I think the registration form is in German, but um doesn't matter. If you're interested, put in your data might have heard, I'm able to speak a little bit of English. And I I want to finish my presentation leaving you with a cheat sheet. Leaders and

are almost exclusively interested in revenue and costs. Find out what's important for your leader. Your argumentation must always base on profit growth or cost savings. Tell stories with in their horizon, not "Ah, we have to implement in that sprint." Blah, blah, blah. The next quarter will be important to have Mhm. Use SWAG. It doesn't mean hoodies and something like that. Scientific wild-ass Because everybody else, like sales

and marketing, is doing it like that either. And always think if you try to lose tend to lose the race, think about loss People will always choose the option that reverses losses. That was the cheat sheet. I hope you heard something interesting during my talk. I think we have a minute at least a minute for answering questions. Thanks for listening. Um the QR code in the upper

right side leads to my LinkedIn profile. I'm happy to get a bunch of new LinkedIn friends from the audience. And I'll have a look into the questions. >> [applause] >> There are no questions in Slido. Either everything is clear or nothing is clear. Ah, yes. There is a question. What if the swag est is off? It's It's It's always a guess. Sales is a guess, but you

compare guesses with guesses. And in the end it will be off. But I think that's one of the most most prominent reasons why software developers don't want to do something like that because it's not accurate. And sales nothing is accurate. Thanks for listening. Have a great conference day. >> Mhm.