If you're interested in the story behind the business headlines, check out Big Technology Podcast, my weekly show that features in -depth interviews with CEOs, researchers, and reformers in business and technology.
Hi, I'm Alex Kantrowitz.
I'm a long -time journalist, CNBC contributor, and the host of the show.
I empty my rolodex every Wednesday to bring you awesome episodes, so go check out Big Technology Podcast.
It's available in all podcast apps.
We'd love to have you as listener.
I'm Tomer Cohen, LinkedIn's chief product officer.
In my new podcast, Building One, I interview some of the best product builders out there, people at the intersection of dreaming and building and learning.
Together you and I will learn from their experiences.
If you're just as curious as I am, follow Building One wherever you listen, and check out the conversation on LinkedIn.
Services while it's out on the ocean, these changes will make that happen much less.
And that's something people can understand.
They say, ah, greater connectivity means that the services will be more effective, that our users will complain to us less when they get into part.
Ah, now that's something that I can sell.
The engineers may need a bunch of help in understanding what those business contexts are.
And one of the things, unfortunately, that we tend to do, I was just talking to a big global charity about this, that other people who don't want to bother learning our language and who say, look, I just want my outlets.
Come and say, please do X, and tell me when X is done, and don't bother me.
And that's the worst thing you can do.
Much better to say, here's why I want X.
Here's how it's going to benefit the business.
Here's what it's going to mean to the bottom line.
It's going to reduce cost, increase revenue, something like that.
And how could you help me solve that problem?
Here's one way I know, but I'd love to hear another way.
Again, you're inviting that falsification.
You're being humble, as you were saying, and that's making sure that you are open to other solutions.
And you're getting a business description of the value of whatever the engineers tell you.
Hey, I'm Kwame Christian, and you are about to step into the world of Negotiate Anything, the number one negotiation podcast in the world where we teach you how to make difficult conversations easier while getting more of what you want in the process.
Each episode is packed with practical tips and strategies from the experts.
We delve into negotiation, conflict resolution and leadership skills that are crucial in both business and in life.
Whether you're closing a deal, managing a team or navigating personal relationships, Negotiate Anything provides you with the tools you need to succeed.
Our conversations are real, relatable and most importantly, rooted in practicality.
So if you're ready to transform your conversations and elevate your negotiation skills, join me on Negotiate Anything.
Subscribe and listen on Apple Podcasts, Spotify or wherever you love to listen.
Let's make every conversation a winning negotiation.
Hey, everyone, it's Kwame Christian, host of Negotiate Anything, asking you to please do not skip forward because this is not a commercial.
OK, I've got something for you.
So we want to hear from you, our incredible listeners, because your feedback is super helpful in making the show even better.
We've created a quick and fun form to get to know you.
And this is your chance to make the show even closer to what you love.
And here's the best part.
If you fill out the form before December 31st, 2024, you'll be entered into a raffle to win a signed copy of my book delivered straight to your door.
It only takes a few minutes and your input will help to shape the future of Negotiate Anything.
Find the form in the description of this episode and we'll announce the winner in January.
Who knows? It might be you.
Thanks for helping us to make the show even better and even more connected to you.
Good luck in the raffle.
Douglas, thanks for joining us today.
Nice to be here. How are you, sir?
I'm doing well. Thanks for coming on the show.
And for the listeners, that is the only time you will hear me say Douglas because Douglas prefers to go by squirrel.
So I will respect you on that.
So how about you get us started by telling us a little bit about yourself and what you do?
Well, I'm here in England in my six hundred year old house.
And although I talk this way, I'm actually English.
So to totally confuse people that these beautiful beams are underneath a thatched roof.
So great opportunity to be in an interesting place and to talk about interesting things, which is what I love to do, because I'm a tech person by training.
I've been writing code for forty five years.
But what I love to do is actually have conversations.
And I wrote an entire book about how you can have really effective conversations with technology people.
You were saying that you were having trouble before we got started with tech matters.
So I bet having that tech conversation might be one that you might find is difficult.
And I have a lot of techniques for doing that a lot more effectively and negotiating with us engineers who love ones and zeros and helping other people to get on with us in a much better way.
Incredible. And squirrel, I'm going to have to restrain myself because I owned a house that was one hundred years old.
And I remember how challenging that was.
So maybe afterward we could talk about six hundred years old.
That's incredible. But you are right.
I think difficult conversations are tough enough by themselves.
But then when you add a level of sophistication that comes with technology, it becomes even more difficult.
And I think maybe a good place for us to start is to just understand what makes these types of conversations so challenging for so many people.
Well, a problem typically is lack of common language.
So another place where I experience it is when I talk to people about my car.
So I have a beautiful electric car.
It does amazing things.
I don't know where the battery is.
I don't know how the steering wheel is connected to the wheels.
I know I can get in.
I can push a certain set of buttons and the car takes me places.
But I don't want to know anything more.
And a lot of us view our technology, our phones and our computers and our Zoom sessions and all these wonderful things that we have in just the same way.
We don't care how they work.
As engineers, we love how they work.
So we get very excited about that.
And what often happens, just like my mechanic might want to tell me a whole bunch of things about how my car works, I just care.
Can I drive it home or not?
Do I need to get a renter?
Or are you going to fix it for me?
Then I can drive it.
So us engineers, we like to give you more information, more context than you really need.
And you often feel intimidated by all the jargon, all the complexities.
And it sounds like a secret language, like a magic, you know, like you've gone to Hogwarts and you're suddenly trying to say, it's power almost or whatever it is.
They say with the magic wands.
And if we went to Hogwarts, you and me, we wouldn't get on so well.
Right. Because we don't speak that language.
So getting to a common language is one of the most powerful techniques.
That's brilliant. And you're absolutely right, because along with that intimidation that comes to you, when you are talking to somebody who has a higher level of sophistication in a specific topic, and they're using jargon that you don't understand, a lot of times, I think the majority of times, people
don't feel comfortable or psychologically safe to admit the simple fact that they don't know what in the world you're talking about.
And so in the professional world, we can develop the skill of pretending like we know and understand when we don't know and understand.
So you have two people that are talking at each other, but they're not really communicating.
So let me show you and your listeners interview or something.
I'm happy to send one of these to anybody who is watching us or listening to us.
It's an official certificate issued by me, numbered, signed and with a beautiful gold seal.
And it gives you permission to ask questions.
So you're entitled to ask questions of software developers, system admins, designers, QA staff and diverse other technologists, things like what are you doing?
Why are you doing that?
Can I see the results and when it will be done?
So, you know, I printed that because I had so many people saying, well, I can't ask the engineers that they tell me these complicated things.
I have to trust them.
No, you don't. You could have a conversation with them and it'll be a difficult conversation.
It might have some productive conflict in it, but you could get better results.
I love this. And I don't want to assume that people understand what productive conflict is because semantically, we might be able to understand what productivity means.
We understand what conflict means.
But those two together, I think it's so foreign to most people that they don't appreciate it.
So what does that mean to you?
Well, let me demonstrate nonproductive conflict.
You jerk because you just haven't listened to me.
And why didn't you look this up?
And you know that I'm really interested in productive conflict.
Why don't you know what that means?
Now, that's unproductive conflict, clearly, because I'm attacking you personally and I'm not listening to anything that's important to you.
But a productive conflict...
Now, believe me, I don't feel this way, so please don't feel bad.
I hate it when I attack the host and I feel bad.
But here's the point.
If I were to say something like, you know, I'm kind of feeling disappointed and my disappointment might be unjustified, but I want to tell you about it.
And the disappointment I have is that you didn't look up productive conflict.
And it sounds like you probably didn't even read my book.
And that makes me feel sad and unimportant.
And I wonder whether I might be wrong about that.
Is there something I'm missing or it's something that I could do differently?
Now, that might lead to some conflict for you.
Believe me, I don't feel that way, so please don't feel bad.
That wasn't real. But you can hear how I'm being both vulnerable and clear about what didn't work for me.
And I'm inviting you to tell me where I might have contributed to the problem.
Now, that might lead to a productive conflict where you say, yes, Squirrell, you didn't even send me your book.
Come on, if you don't send me any information, how am I supposed to read it?
And I would learn something.
I would say, oh, wait a minute.
I should send the book to people before they have me on their podcast.
Now, that's completely made up.
None of that is actually true.
I don't want people to feel like we're having that conflict.
But you could imagine having that with your engineering team where you're having trouble with your Zoom calls or you're trying to build some new amazing feature into your website.
And it's not done on time.
And you could tell people how you were feeling about it, why that made you feel that way, and invite them to help you understand how you might have contributed to the problem.
That's a totally different type of conversation.
And guess what? Engineers are very responsive to that.
Everybody is. But engineers particularly, because it's very clear.
There are so many things I love about this, because I think for me, a lot of this can be couched under humility.
And when I think about humility, yeah, we can look at it as a virtue.
But I like to think about humility in the form of accuracy.
I'm just willing to make accurate assessments.
Sometimes those are favorable to me.
Sometimes they're not favorable to me, but I'm going to try my best to be accurate.
And so I'm going to, in this situation, you stated your feelings accurately.
This is how I'm feeling.
But you were also generous in your interpretation.
This is how I'm feeling and why.
But I understand that I probably don't fully understand everything.
So you invited them in, hey, help me to understand what's happening.
So you have that collaborative nature in this.
And then lastly, you were curious, because you said, I don't understand at all.
That's humility. It is accurate to recognize that you do not have infinite knowledge.
And then that is just puts you in a position to have that productive conflict.
And I think when you look at it through that lens, you can recognize, oh, now I can see why so many of my conflicts were unproductive because we started off with accusations and conclusions and people were defensive from the start.
In your country, you're having an election I've heard.
And there are some people who don't necessarily agree with each other all the time.
And they have very unproductive conflict on purpose.
So it's this terrible example that we all see.
And these two folks, they go have a debate and they're always arguing for their position that nobody ever says, you know what?
That position on immigration, I think you might be right, actually.
I've now learned something new and I'd like to change my policy.
So they're more aligned with yours.
Could I join your party?
Right. That never happens.
We never see that. But that's what we want in business productive conflict.
We want to have an outcome where we actually understand better how we've contributed, what we might change, what we might do differently, how we might support our engineers better, give them better resources to change the scope of what we're asking them to do.
And they might also say, hey, wait a minute.
I have a better solution.
You're asking for A, but I can do B technically.
Wouldn't that be better?
That's the outcome we like to have.
But the only models we have are people shouting at each other and arguing about whether somebody's eating their pets.
So we haven't got great models for how to negotiate effectively.
And again, I'm going to have to demonstrate some restraint because I want to go down that rabbit hole too because the media, all they do is teach us just incredibly destructive ways to engage in conflict.
And just like as children, we play follow the leader, we do the same thing in our adult lives.
We look at the leaders of countries and organizations and we say, oh, that's what it takes to get to the top.
That's how I should be.
And we follow that lead.
And the thing is, when you have an interaction between two people who don't agree and they engage with each other respectfully and they are deferential, they're curious, they are appreciative and respectful, that doesn't sell.
Exactly. The algorithm does not promote said behavior.
And so we just don't see it.
So I'm really glad that you called that out.
And I know for the work that we do at the American Negotiation Institute, we work with a lot of tech companies.
And I see this internally in every company, the UX team, they can't communicate with the sales team, they can't communicate with the marketing team.
And all of this, there's conflict just because of the inability to communicate because what we recognize is we're speaking different languages.
And so let's say we are not engineers and we're talking to engineers.
What would you say are the things they need to keep in mind as they're having these conversations?
It's to help the other person to speak a business language.
And this is really quite foreign to them in the same way my discussion of engines with my mechanic is quite foreign.
So be sensitive to that, but invite them and don't let them off the hook to tell you about what the business value is.
So just to take one example, I was evaluating a team that builds software for ships.
So they're helping ships to have the right materials.
And if you get on a cruise ship, it's probably using their software to make sure that the supplies are right on the cruise ship.
And this company had a change they were making to really shift all their software.
And the engineers had great engineering reasons for doing it.
Really good, solid, excellent reasons, but hadn't explained it in any terms that the rest of the business could understand.
So the rest of the business said, okay, you're going to change the software from A to B.
How does that help me sell more of our products?
How does that help ships have the right materials on board?
And the engineers didn't have the skills to give that piece of information.
They had knowledge, but not the skills.
So the way to bridge that gap is to ask them questions and help them move slowly toward an explanation that is in business terms.
For example, one of the problems is that a ship has trouble connecting to the internet and to services while it's out on the ocean.
These changes will make that happen much less.
And that's something people can understand.
They say, oh, greater connectivity means that the services will be more effective, that our users will complain to us less when they get into port.
Ah, now that's something that I can sell.
The engineers may need a bunch of help in understanding what those business contexts are.
And one of the things unfortunate that we tend to do, I was just talking to a big global charity about this, that there are other people who don't want to bother learning our language and who say, look, I just want my outlets come and say, please do X and tell me when X is done and don't bother me.
And that's the worst thing you can do.
Much better to say, here's why I want X.
Here's how it's going to benefit the business.
Here's what it's going to mean to the bottom line.
It's going to reduce costs, increase revenue, something like that.
And how could you help me solve that problem?
Here's one way I know, but I'd love to hear another way.
Again, you're inviting that falsification.
You're being humble, as you were saying, and that's making sure that you are open to other solutions and you're getting a business description of the value of whatever the engineer is telling.
Hello, my friends. Before we get back to today's episode, I want to ask you a question.
Have you ever wondered how to elevate your team's negotiation game and how you can help the folks on your team have better, difficult conversations?
At the American Negotiation Institute, we offer transformative keynotes and workshops tailored to empower professionals with top tier negotiation and conflict resolution skills.
Whether it's a keynote for your next event or hands -on training for your team, we've got you covered.
Don't just negotiate.
Master the art with the American Negotiation Institute.
Click the link in the description to find out more.
Elevate, negotiate, and succeed.
Hey, you, I'm Andrew Seaman.
Do you want a new job or do you want to move forward in your career?
Well, you should listen to my weekly show called Get Hired with Andrew Seaman.
We talk about it all and it's waiting for you, yes, you, wherever you get your podcasts.
I'm Tomer Cohen, LinkedIn's chief product officer.
If you're just as curious as I am about the way things are built, the insight behind what it takes to create world -renowned products, then join me for my new podcast, Building One.
Together, we'll get to learn from leaders around the world, people with diverse backgrounds across multiple industries.
Each will share insights into their craft.
So listen and follow my new show, Building One, on Apple Podcasts or wherever you get your podcasts.
And check out the conversation on LinkedIn.
It's gonna be great.
Brilliant. And I think in addition to that, it starts with the mindset of shifting your assumptions too.
Because I think a lot of times we assume, all right, we're speaking the same language.
When the conversation is done, we are all on the same page.
That's not true. And you told me what you think about this.
It seems like maybe even articulating that at the beginning explicitly is going to be very valuable.
Can I tell you a fun story?
This is yet another of my clients.
I've worked with 300 around the world, so I have loads of stories.
But this one's really great.
It's a company that is really involved with language.
So they're providing services that are related to language and translation and all that kind of stuff.
And they wanted to support more languages.
So very naturally, they started talking about language expansion.
And I'm saying, we're going to expand our languages here.
We're going to have more languages there.
We're going to do more with languages.
And they had extensive discussions about this, but kept getting stuck.
They came to me and they said, squirrel, we just can't figure out.
Why is it that the engineers aren't building the language expansions we keep asking for?
The engineers kept saying, we're building it, but nobody seems to be using it.
What on earth is going on?
Well, I finally got somebody who understood this to sit down with both of them.
And it turned out that they were having tremendous arguments about what these words meant.
And they meant different things to different people.
And so naturally, when somebody talked about expanding the languages, they might think of something that users would see.
And the engineers were thinking of changes that were technical and software.
And so these things were quite different.
It turned out they really agreed.
And they were really keen to make exactly the same sorts of changes the words didn't mean the same thing to the different people in the group.
So exactly as you say, if you can get that right at the beginning, if you can agree on what important words mean, and be curious about it, and humble and think, you know, it might be that I'm misunderstanding you.
It might be that when you say language, you mean one thing, and I mean something else.
So let's make sure we get that clear.
So that's the sort of thing that you can do at the beginning to really solidify your communication so you don't get in trouble later.
What I love about all of these tips is that everything has been incredibly doable.
Haven't even talked about high levels negotiation skills and strategies.
And I think a lot of times we over complicate these solutions.
And it's the simple solutions that get us there.
And let's think about this.
If we are people who are having conversations in tech, we consider ourselves to some degree to be intellectual.
And sometimes we over intellectualize the problem and lead to unnecessary complicated solutions that don't work.
And if we just take the time to have these preambles and say, Hey, listen, we speak different languages, and then take the time to before responding or reacting to what somebody says, just saying, Hey, just before I respond, I want to make sure that we're in alignment.
When you say language, what does language mean to you?
And I think when it comes to a lot of these conversations, whether you're a negotiator or just a leader at work, having tough conversations, it requires the humility to ask what might seem on the surface to be a stupid question.
It's obvious to me.
Of course, everyone knows what this means.
Exactly. And some of the funniest, I say funny because I'm not in it.
Some of the challenging conversations come from the situation of the recognition that, Hey, what is obvious and common sense to me, is different from what is obvious and common sense to you.
So I don't even think I need to articulate the specificity behind this because you should get it.
Everybody knows it.
They're thinking the exact same thing about you.
And again, the communication just does not occur.
Well, let me give you another of those very practical techniques specific to working with engineers.
They can really help a lot of your listeners and viewers.
So what you can do is ask the engineers to show you their automated tests.
Now it may be that your engineers say, Oh, we don't have any automated tests.
We have a human being sit down and bang on the keys.
If they're doing that, stop them right away because they're about 30 years behind the latest technology and they're really not working as they should.
You should phone me and I can help you with that problem.
But assuming that they're up with a modern tech and they have some automated tests, then they can show you at least what those tests are supposed to do.
And those tests are verified.
It should be verified every time the software is changed.
So then you really know that what is in that software is what's being tested.
That's a way that you can be absolutely certain.
Just like I know that my car, if the airbags are needed, I run into something, the airbags will go off.
Why do I know that?
Because somebody crashed a bunch of copies of my car and they verified that, yes, the airbags actually popped open and saved the crash dummy from being destroyed.
So in the same way, your engineers are doing the same thing and you can ask them to show you in the code what it actually does.
And if it's illegible to you, that means they don't understand it either.
So they should make sure that at least the names of the tests are things like, when I open Zoom, I can hear the person on the other end.
That was a problem you and I had.
When I open Zoom, I can see the person on the other end.
And if you see tests that verify that, you can say, yeah, well, I can have some confidence that this works.
And that's a way of getting to the same language.
Because if they say, oh, yes, we're creating an audio system here, we don't have any video, because we don't have any video tests.
You say, hang on a second, we wanted video.
And I can tell you several occasions where people thought, we're building it with video, but then they only found out the engineers were building it with audio.
So this is a common type of problem.
And I bet your listeners have encountered this many times where somebody says, I'm doing it to solve this problem for you.
And they are not seeing that outcome.
And you can do that, you can check that by actually asking the engineers to read the code and show you the actual tests that they're running.
Oh, OK. This is great.
Because let me make a point that was not specifically articulated.
I want to see how this lands with you.
Because what we're seeing is, if we ask them to show us the testing, the automated test, then we can actually see what it is that they're working on with specificity and have a clearer conversation.
And now, this is the deeper point.
Tell me if I'm off on this.
Because what I'm thinking is that, for me as a chess nerd, I love to play chess.
And somebody would be, they just finished the Olympiad.
I was watching all the exciting matches.
India was just doing so well.
Always do, always do.
Yeah, and so if I talk to somebody and they say, oh, you like chess?
Oh, that's fine. That's great.
But if I talk to somebody and they say, well, what's your favorite opening?
And then I'm like, oh, you know.
No, well, of course, I just do the pawn to e4 statistically.
That's the strongest opening, move that knight to f3.
I just like the classics, right?
We're going to have another rabbit hole.
We'll debate that. We'll play some play.
Anyway, keep going.
And so, but I can recognize, it's kind of like game recognizes game.
I recognize that you have a level of sophistication in this that leads to higher levels of respect.
And so bringing it back to this scenario, most people who are maybe in sales or marketing or operations, when they're talking to engineers, they speak their own language.
But if you say, hey, can I see the automated testing?
Can you read the code to me?
Then the engineer is likely to say, oh, you know.
Okay. And it could lead to a deeper conversation and a little bit more respect.
What do you think about that?
So I think that's helpful, but I'd be cautious about it.
Because what it can sound like is if you just taught somebody to say, hey, how do you respond to the bird opening?
And then somebody can say, yeah, well, I don't think it's very sound.
I go e5. And then you continue, they might not actually know anything about chess.
And so if you get into a deeper conversation, they're really going to be lost.
And so what I'm not suggesting is that listeners go and take a coding course.
I mean, that would be fun.
Please do that. That's a great thing to do.
But probably you have another job to do.
And that's not your either avocation or your vocation.
So that's okay. But what you can do is ask for the piece that makes sense to you.
And so maybe a better chess analogy would be to say, I hear there are a lot of draws in chess and that's one of the problems.
You tell me more about how you avoid draws in your games without telling me the detailed chess notation and what you did.
You might say things like, I like to attack on the king side.
I like to defend very carefully and make sure all my squares were protected.
And you could have a reasonable conversation.
And those of our listeners who don't know anything about chess have understood that part.
Whereas bird opening and 1T4, that didn't mean anything to them.
So that's the kind of conversation I'm encouraging everybody to have.
Go and say, look, don't line me with science.
I don't need to read the lines of code.
But just tell me, do you have a test for this?
And can you show me the test?
What's it look like?
Okay, so the test name says, when I open Zoom, I get prompted to connect a microphone.
And when I speak into the microphone, the other person hears me.
Now tell me why that didn't work when we tried it this afternoon at three o 'clock.
And then you're having a much better conversation like in that chess example, where you can discuss it on a level that makes sense to the business while incorporating the appropriate technical information.
One thing listeners are going to hit when they try that is the engineers will say, you could never understand the code.
It's hopeless. It's too complicated.
You could never do it.
And you say, just show me the names.
Show me the names of the tests.
And if they're named test one, test two, test three, test four, you go make them change the names to something meaningful.
And they know how to do that.
If you can get to that point where they have meaningful information about what they're verifying, then you're on the road to a great business conversation that can help you really get a lot of profit out of your engineers.
This is incredibly helpful.
And for the listeners who are engineers, now, if you were coaching them on what they can do to make these conversations easier for the people who are not engineers, what would be the key piece of advice for them?
The first thing is talk to people who aren't engineers.
Get a lot of practice with that.
And you'd be surprised how many people who write software only talk to computers.
And one thing I'm constantly telling them is go have a beer with the people in marketing.
Go attend a sales conference.
Go along on a sales call.
Go sit. You know, there's one case where I sent a very crusty, very grumpy engineer who said, you know, don't bother me.
Just let me sit in the corner.
And I said, you're going to answer the phones.
You're going to be on customer service for today.
And he's grumbled and grunted and so on, but I sent him over there.
And guess what? Our customers were 10 -year -olds.
So we were servicing kids.
You can do this very easily now, but back then, it was hard to get a debit card for your kids so they could learn about saving.
Now you can do it at every bank, but we were quite innovative in doing it.
And so he was answering phone calls from crying children who were out of money and whose card wasn't working.
And guess what? He knew how to reach in the database and do sneaky, clever things so they could have some money.
And he came back. He said, my God, this kid was crying.
And then he got his hamburger at McDonald's, and he was happy.
And now I really understand why we're doing this.
So if you can get that level of understanding of your customers, even though it's painful, even though it's not the thing you might want to do, and you prefer to talk to the computer, man, you can be a much more effective engineer.
So you can encourage, if you're a non -technical person, you can encourage your engineers to do that.
My dog agrees. That's why she's barking.
And if you're an engineer, you can go seek out that kind of opportunity.
I guarantee customer service will be completely blown away by having you show up.
And they'd be very interested in showing you some of their problems.
Oh, this is so good because I'm thinking about this, not in the technical sense.
I'm thinking about this in the more nebulous cultural sense.
So I like to think about little C culture versus big C culture.
We have the ethnicity, we have nationality, that's big C culture, we can all see that.
But when you think about culture as just the way that we do things, you recognize there are going to be different cultures within organizations, within communities.
And really, this is almost like a study abroad program.
You're suggesting that the engineers go and immerse themselves in the culture of another department so they can actually speak that language.
Got it. Here's another story of sending engineers as ambassadors.
I write to send them on sales right along.
So a salesperson's going to call on somebody and send the engineer along.
So I did this with an engineer who wasn't as grumpy as the other one that I was describing to you.
But he was just kind of clueless.
He just didn't really understand.
The folks that we were selling to in this case, they were very grown up.
They're the kind of people who sit on trading desks.
And you might have seen pictures of these.
They have about 18 screens in front of them and they're throwing phones at each other and they're screaming buy, sell, buy, sell, that kind of thing.
So I sent him to the trading floor with a salesperson who was going to go sell to one of these people.
And he said, OK, that sounds fun.
I guess I'll go there.
And he said, I'm going to try it.
And he came back, and the first word his mouth were, now I really understand why these people do so much cocaine.
The thing he had appreciated, not to mention their completely frazzled existence and their perhaps interest in illegal drugs.
But what he had mastered was that it was very important that our application, which was on one tiny corner of one tiny screen, be really easy to use and very prominent.
And so he got very interested in user interface and making sure that things were visual and could compete with all the other inputs.
So although his comment was outrageous, he really got a deep understanding of customers that day.
And the more you can create that kind of business understanding very quickly by immersion, the faster you'll get and better you'll get profit out of the engineers.
Incredible. Squirrel, this has been a great interview and I can just think about even the clients that I've worked with over the past few years, you have answered so many of their questions and demystified so much of what it is that they go through every day.
So I appreciate this and I appreciate how practical all of this is.
And for those folks who say, listen, I want to learn more.
I want to get in touch.
What is the best way for them to get in contact?
Well, here's the first thing for them to do.
So I'd love to send them this certificate.
I really need it. I have a pack of them right here.
I'd love to put them in the post to you.
And it's a great way to start a conversation with an engineer.
Say, hey, I just got this certificate.
It means I can ask you some questions.
How about we talk about it?
You know, show me your tests.
So the best way to do that is to head on over to douglassquirrel .com.
You just have to remember how to spell Douglas and then squirrel and put .com at the end.
And I'm sure you'll put it in the show notes and things.
And there's my email, my Twitter, my phone number, my home address.
You come see me in my 600 -year -old house.
So everything's there.
And if you write me and say, hey, I heard you on the negotiation podcast and I'd love to get a copy of their certificate, I'll get it in the post to you.
So that's one. And then the other is that I run absolutely free a community of thousands of executives, tech and non -tech.
And I'm helping them to negotiate and collaborate in this way.
It's my way of giving back.
So it's completely free.
And that's called the squirrelsquadron .com.
So you go to squirrelsquadron .com.
And there you can sign up.
I do weekly events.
I do weekly emails.
There's a forum where you can ask questions and say, how could I handle this problem?
And there's loads of people around the world who participate and discuss these topics as we're speaking.
So I'd love to see any of your listeners in any of those places.
And all these things are free.
There's ways to pay me for stuff, but I'd much rather help them out immediately by certificates, free events, and just getting in touch.
Squirrel, thank you so much for joining us.
Really appreciate it.
Absolutely. Wait, wait, wait, wait, wait.
Now, before you sign off, I have something to tell you that I've never told you before.
Just kidding. I've told you before about it.
You should listen to it again.
I want you to know about Negotiate Anything Premium.
Imagine all of the things that you love about our traditional feed plus so much more.
I know you like our traditional feed because you're at the end of the episode.
And with Negotiate Anything Premium, you'll get more bonus content you've been asking for, more of the expert insights that you can't get anywhere else, and more exclusive behind -the -scenes access into every conversation.
Are you ready to get more of what you want out of your life, career, and every conversation?
With Negotiate Anything Premium, you'll have access to more high -level, custom -designed content and insights, giving you the tools you need to negotiate higher salaries, better deals, and better relationships in your life and career.
Once I had a listener share that Negotiate Anything helped her to negotiate a $53 ,000 raise.
Could this be you? What would that mean for your life?
I've seen first -hand the impact this model has had on my life and the lives of my corporate clients, and I am confident that it can do the same for you.
Are you ready to negotiate more of the best things in life?
Click the link in the show notes to learn more.
I'll catch you later.
