May 7, 2024 • 17 mins
In this episode, we speak with Vladimir Baranov, an expert in coaching founders and technology executives. We explore the critical importance of cultivating human interactions within the tech industry. Vladimir shares insights on how the neglect of interpersonal relationships and effective communication can jeopardize company success, particularly during pivotal growth phases. He emphasizes the need for technology leaders to develop their human interfaces to foster more cohesive and resilient teams.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Welcome to Tectastic, where we navigate theintersection of technology and business,
uncovering innovations that redefine our world.
Glad you're fair enough.
Welcome to its techtastic.
It is lovely to have you here.
Thank you so much, for having me here.
So one of the reasons I was really excited toget you on this is I am going through right now
(00:25):
with my company, the thing that coach peopleon.
And you've had a lot of experience.
Coach, you'd start a founders.
You've run a bunch of your own companies, andyou currently offer a service co founders.
Right?
Yes.
I do.
Founders and technology executives.
Yeah.
So I'm I'm curious about that and technologyexecutive What is it about the, technology
executive that relates to the founder thatneeds that same level coaching?
(00:48):
Oh, absolutely.
Side in the market is that we, as technologistsor founders in technology industry, very much
focus on the product in client interactions,trying to reach that product market fit.
And sometimes we are not paying attention tothe relationships between ourselves and our
teammates or between ourselves and executivesor between executives and the company.
(01:12):
And there is a great risk that over time, ifgoals outcome relationships are not in line
with the company, they can bring the companydown at the worst possible moment.
And if we start talking about those issuesbeforehand, it's almost like setting up those
metrics or analytics before you start launchingthe website.
You will have a pulse of how you companyactually feels on Insight, and that will enable
(01:37):
you to monitor it as a company grows and goesto that product market fit eventually and
generate those great revenues for you.
So that's where I I see the parallels.
It's the founders venturing into the businessit's growing, but the connections may be not
still investigated and debugged, or technologyleaders are not yet aware that those interfaces
(01:59):
as they are right now focusing very much onindividual contribution from the technical
perspective, but they're not yet know how todevelop their human interfaces.
To influence others and to achieve what they'relooking for.
So I love that, the focus on the humaninterface's piece, and you remind me of a topic
that's come up a lot in my past.
I've been in technology long enough that I canremember being the computer guy in a company.
(02:22):
Right?
And a lot of people that are in very seniorrole in large companies today, that's how their
career started.
They were the computer guy.
And when the company said, hey.
We're gonna being a technology company at somepoint in the past.
They hired people, and they said, hey.
Computer guy managed the technical people now.
That was how you train to be a manager.
Right?
And then that just continued up until you'resitting in, like, the c suite going, I know
(02:46):
what I'm doing, but you don't you really don'tyou haven't been trained on being a human
manager, a human leader.
It it's like front end development versus backend development.
You're very competent in the technology side ofjob.
Right.
But the front end part, you had no training onyou have no experience in.
Absolutely.
And it's been a real trash I think of thetechnology industry is that we look for the
(03:08):
best software engineer and we say, you're goingto be the team lead.
And then we say, you've been team lead.
Now you're gonna be a manager.
You're gonna be a director or the VP, andyou're gonna keep going up that way for the
people that are interested in it.
Right?
But, again, no training, no expectations ofwhat that means.
You you fumble your way through it.
If lucky, you get a chance to try again.
And it starts on a technology company, like, wewe start in a small room at folding table
(03:33):
working on the same project together.
We have easy human interaction.
But, like, with COVID, a lot of us started ourtechnology companies remote.
I don't see my team.
Right?
When am I gonna see them?
And then no standing me anything.
I don't wanna get in the way of their flow.
Right?
I want their hands on their keyboard.
I want them focused, and I want them create Sothat human piece, we almost run away from it.
How do we get it back?
(03:54):
How do we how do we make that connection?
The way, you phrased that and the way I believeother technology companies are working is we're
always trying to optimize, which we always tryto build something more and more and more
efficient.
But we always do it within the domain of ourknowledge.
We know how to write code, so we believe if wewant to write more code and more and product,
(04:17):
we just need to write more code.
And sometimes it could be true, but in the end,we're running code, which will then be used by
other humans.
And we have mental models of other humans, howthey will use that code, but it's not
necessarily the truth.
And realigning those mental models with ourusers takes a lot of time.
And as you mentioned before, product marketfeed is part of it to understand how your user
(04:41):
thinks.
Now if one developer has a user mental modeland another developer has a user mental model,
chances are those models are not same.
And both of them are running at a hundred milesper hour developing code for their own models.
By the time they commit the code, By the time atoken gets checked and by the time it goes to
production, the user will experience differentinterfaces in your application because a
(05:04):
different developer wrote it.
Now you can always apply layers of changes tomake sure that people are having the same
theme, but the idea, the underlying kind oflike harming engine understanding of the
product by the developers will not always beperfect.
And thus, there is a really good, exercise toonce a week, twice a week, once a month,
(05:26):
whatever the cadence is appropriate for theteam to align first on how they understand the
user, and then eventually to how theyunderstand each other.
Because there's opportunity for meshing andcommunicating with each other in a way that
does not require words, which develops overtime, or specific kind of communication.
But if you do not talk to each other, you donot get that model training data necessary for
(05:51):
you to define that interface between each otherthat enables you to accelerate.
What I'm bringing up here is that it's anotherto you to make things more efficient, make
things, go faster, make things less buggy atthe very end.
You you touch a a very important part ofefficiency that I think gets overlooked a lot.
And that is the effort and activity.
It's not what you're shooting for.
(06:12):
It's the outcome of that activity that youwant.
And a lot of wasted efforts spinning theirwheels doing 2 different things that are
crossed with each other is not efficient.
So taking a little bit of time to align andmake sure you're you're driving towards the
same thing is far more efficient.
It's like the a bunch of people rolling in aboat.
If one person's rowing backwards and everybodyelse is rowing forward as a less efficient
motion than if everybody was rowing the samedirection.
(06:34):
Right?
And we run into that a lot.
That's actually, surprisingly, what we'retalking about is what my company tries to solve
after the fact.
Awesome.
Right?
You you've created the technical debt.
You you've created these place where there'sbeen a disconnect between the desire and the
outcome state.
We help you solve that.
So the thing that's really interesting to meabout that, when you're talking about it with a
human interface piece and that that model pieceis that organizational structure has such a big
(06:58):
impact on people.
Right?
And I I always think of the game of telephoningplayed as a kid.
You've got the customer screaming about aproblem.
Now the problem is the customer doesn'tactually know the problem they want solved.
They know the pain they feel from it.
They know how it impacts them, but they don'treally know the problem.
And then you've got a product leader.
Maybe it's CEO, right, but you've got theperson who's got the vision for how we're going
(07:19):
to solve that.
They believe they've got a better picture.
So you've already gone through one game oftelephone.
Like, one party passed to another.
And now that's gonna get passed to the productmanager or whoever.
Right?
It's gonna get passed and passed and passed.
And it gets to the finally, to the people thatimplement it in code.
Who are playing a telephone with the computeritself.
Right?
They're trying to tell the computer.
This is what I want you to do in an imprecisething itself in the programming language.
(07:43):
And so the the natural outcome of this game oftelephone is you've got a bad translation.
You're always going to be off the mark, whichmeans we have to iterate It means that code has
to be thought of as ephemeral, and we all haveto converge towards an a shared understanding
of what good looks like.
But we won't start there because we all startedfrom different spot in that game of telephone.
(08:05):
Yeah.
That's a fantastic analogy.
And, one of the things to bring up that is nothappening and is not most of us are not taught
to do is actually ask a lot of stupidquestions.
Or powerful Christian, depending on how youlook at them, to clarify what the other person
is sharing.
If you have an act without a sin, you get toUTP communication, which is not necessarily
(08:27):
always understood that they received, you needto bring it to TCP in a way that every
direction between the layers that you have justdescribed, at least have a high level
verification that the person listening hasreceived it.
And maybe there's a feedback loop to theoriginal party, maybe not the same with, that
allows you to clarify the information you havereceived.
And on top of that, perhaps maybe there is away to design incentive structure where the
(08:50):
pain of the customer can be felt by all theparties who are in a chain.
And that's the hardest part is when people talkabout OKRs and KPIs and drive from that is they
misalign that, and they build theirorganization.
I I talked about this this particular topic atlength.
And so I'm sorry if anybody's gonna be boredwith me saying it again, but, like, You have to
build teams to be durable, but the goals thatthey have aren't.
(09:11):
If you build a team and say your job is toensure that the product get better and better
and better.
That's a terrible goal because we might not doproduct recommendations in the future.
Maybe it's gonna have an AI interface to besomething else ever.
Right?
I don't want to incentivize a technology choiceand a current state of being into perpetuity.
However, if I said, I want you to Always makesure that the customer is getting better and
(09:33):
better, things that they'd be interested inbuying, and we're gonna know that because
they're buying more of them.
Yeah.
That that that stays true.
I I do want that as an e Hammer company, let'ssay.
Right?
And the second part, like, they're buying moreof them tells me that's a good signal.
But we don't do that.
We say that the conversion number needs to gofrom 5 to 6 and 5 to 6 percent, and you need to
(09:54):
do better and better product recommendationsbased on this case AI.
Yeah.
And probably write more lines of code.
The more lines of code you write, the better.
The more hours you spend on the computer, thebetter.
I'm always amazed, though, that how fast thatgame of telephone falls apart, and people don't
ask the clarifying questions.
And I'll give you my favorite way to test thisin an organization because I've done this
(10:15):
multiple times, and I wanna see if you thinkit's nuts or not.
But I will get into a team, and though somebodywill say, okay.
It'll be done on that date.
Please to find done for me.
And I and I want everybody else to heareverybody else's definition.
Oh, actually, like, you'd need to do thatanonymous and then they compare, because
otherwise, they start copying.
It's back to the same model of the result and,of what work we're actually doing.
(10:37):
People forget the outcomes A lot of peopleprobably don't even know what other people are
working on.
Yeah.
It's so complex if you, if you, like, if youlook at any sizable organization, even just
eight people working on something.
It is hard to keep tabs on what everybody elseis working on.
Oh, absolutely.
And I agree.
That's a challenge.
Like, you have your own contact people haveothers, but that's where the need of the leader
(10:59):
comes in, which who's actually aggregating allthat into a wholesome picture a project
manager, be a part time, leader, it's theirresponsibility to do that.
Cause you have 8 individual contributors forKenneth code.
You're bound to run into the issues where thereis no coordination.
Like, you have to define in a router or aninterface, which brings all the results
together and gives people meaning to their workand also tiny beats of information of what
(11:24):
everybody else is working on so they can buildtheir own model and how they relate to the rest
of the project.
So when you say that I think of, like, theagile manifesto and what was intended by it.
The the intensives, the positive humanintensives.
The fellow part when it got codified into aseries of talking points by consultants.
Yes.
(11:45):
Well, that's how they got paid if nobody getspaid for a vision.
You know?
If only.
Right?
Yeah.
It it's an interesting problem.
And so, like, if if you were to give, thestartup community that's listened to this, a
couple things they need to look for to know ifthey've got a problem to start with, and, like,
maybe some tools they might leverage to solveit for themselves.
(12:05):
What advice would you give them?
Absolutely.
I will focus on the conversational piecebetween two parties and how to clarify
information that flows across the channel.
1, try not to solve the problem right away whensomebody comes to you with a question.
In technology world, we're so guilty aboutdoing it.
Why?
Because we're so good at it.
Problem, usually, we don't get the fullcontext.
(12:26):
Have some patience to have the and share asmany details as possible.
Next, ask questions.
Are there any more details?
It's a funny question.
It's a very straightforward question, but itgives you 25% more on average.
Number 3, summarize what you've just heard.
Don't feel stupid about doing that.
You're doing a basic step of making sure thatyou've heard exactly words in the way that they
(12:48):
have arrived.
So the other person hears them and understandswhat they have communicated to you.
And then ask what is the expected outcome as,you mentioned, what the outcome should be, and
how do they define successful Is that pressingthe button?
No.
The button just shows up on the screen orsomething like that.
So I would say that's sort of like, think ofyour communication with another person as that
(13:10):
way of getting information, which might have50% fidelity, like that JPEG of 50%, maybe
like, okay, like, 10% where it's hard to seethe details and you're adding more and more
clarity by asking those questions.
Like, our heads sometimes jump to conclusion,then we'll feel like we've got something, but
we're then risking the fact that we might nothave gotten it.
We pride in ourselves that we get things fromthe very beginning, but there's a high chance
(13:33):
that we might not.
Wow.
There's actually personal advice in theirongoing And I and I'm gonna give an example of
where I've already failed recently on thisexact topic.
So lifelong technologist love to jump to thesolution.
It's my It's the superpower that we all Hammer,as you described.
Right?
I got into an argument with a VC.
Oh, okay.
This is Alfred.
Can I I cannot Christian to this
(13:57):
over what tech debt is?
Now the reality is what I should have said inthat exact moment is this disagreement is
exactly the problem.
We all have a different definition for itbecause we don't see the whole elephant.
We're a bunch of blind people grasping at itand feeling the trunk or the tusks or the tail
and thinking we have full view of it.
That would have been a great way to describewhat we were doing.
(14:17):
It's not what I did.
It's like, well, hold on.
Like, That is also tech ed.
And that's tech ed.
That's tech ed.
Right?
Like, just wanted to do that.
Now, your point on repeating it back, is suchan important one that I know.
I'm I'm repeating it back to everybody elsebecause I know nobody heard it well enough.
We all think we need to understand what's inthe other person's head clearly.
(14:38):
We believe we do.
We'd make that assumption.
Erase that assumption.
You don't know.
Of into it.
Always assume you don't know and clarify.
What I heard you say was this.
That definition of done thing I've run it inevery team I've ever run into, and we spent
honestly an entire day on it where we would getto a precise definition of what done is.
(15:01):
Doesn't include testing.
Doesn't include you, you know, like, what aboutdocumentation?
Is that meant?
Well, yeah, it's done to tell us talk.
You're like, whatever.
Right?
You get into that debate, so you all agree.
But it took the debate and getting down to thenitty gritty to have a firm clear definition we
could all point back to and say, Hey.
I'm gonna be done on December 3rd.
And then to go, okay.
Well, then I'm gonna get the doc on December4th, and I'm gonna, you know, do this thing
(15:25):
over here with that.
As far as, like, definition of done, a newconversation see in a bit of regret.
The unfortunate thing about experience is thatit comes after you need it.
So
Yeah.
Every time.
And, well, the, the best part of that was thatturned into a great follow-up session with that
VC.
And we're that person's now gonna be an adviserto us.
Like, there's no downside to that.
Like, he wanted to have that argument, and Ilove being wrong wrong.
(15:48):
I honestly love it because I'm learningsomething if I'm wrong.
I have deeply held convictions.
I believe I'm right, but I'm often wrong.
We want to be wrong, but it doesn't feel rightwhen we're wrong at all.
Yes.
I wanna learn.
I wanna be wrong, but I'm not Yeah.
That's exactly right.
(16:08):
Well, Vladimir, we're almost out of time.
I wanna give you a chance to point peopletowards where they can find out more where
reach out to you and they can engage if theyneed your, your special knowledge and
experience.
Oh, absolutely.
Thank you for giving me that chance, Hammer.
If you would like to hear more.
And if you have topics on either humancommunication or human interactions in your
company as a technical executive or as afounder, please do reach out.
(16:32):
My website is human interfaces.co.
That's human interfaces.co.
As part of this podcast, I'm offering a freecomplimentary session, and you can just add
splash.
Textastic.
Oh, my god.
Excellent.
And that's a wrap for this episode ofTectastic.
(16:54):
Wanna thank you personally for joining us andwe'll see you next time.
Until then, keep exploring and stay curious.
Thank you for listening.
If you are new here and enjoyed the content,please subscribe.
It really helps us out.
And if you are a regular listener, thanks somuch for your continued support.
(17:14):
Overwhelmed by tech debt, discover Vala AI, thesolution to tech challenges with the simplicity
of a click.
No engineering background?
No problem.
Vala AI enables anyone to effortlessly tackletech issues, freeing up your time from tech
headaches.
Make tech debt vanish with Vala AI, where yourtech solutions are just a click away.
Welcome to Tectastic, where we navigate theintersection of technology and business,
uncovering innovations that redefine our world.
Glad you're fair enough.
Welcome to its techtastic.
It is lovely to have you here.
Thank you so much, for having me here.
So one of the reasons I was really excited toget you on this is I am going through right now
(00:25):
with my company, the thing that coach peopleon.
And you've had a lot of experience.
Coach, you'd start a founders.
You've run a bunch of your own companies, andyou currently offer a service co founders.
Right?
Yes.
I do.
Founders and technology executives.
Yeah.
So I'm I'm curious about that and technologyexecutive What is it about the, technology
executive that relates to the founder thatneeds that same level coaching?
(00:48):
Oh, absolutely.
Side in the market is that we, as technologistsor founders in technology industry, very much
focus on the product in client interactions,trying to reach that product market fit.
And sometimes we are not paying attention tothe relationships between ourselves and our
teammates or between ourselves and executivesor between executives and the company.
(01:12):
And there is a great risk that over time, ifgoals outcome relationships are not in line
with the company, they can bring the companydown at the worst possible moment.
And if we start talking about those issuesbeforehand, it's almost like setting up those
metrics or analytics before you start launchingthe website.
You will have a pulse of how you companyactually feels on Insight, and that will enable
(01:37):
you to monitor it as a company grows and goesto that product market fit eventually and
generate those great revenues for you.
So that's where I I see the parallels.
It's the founders venturing into the businessit's growing, but the connections may be not
still investigated and debugged, or technologyleaders are not yet aware that those interfaces
(01:59):
as they are right now focusing very much onindividual contribution from the technical
perspective, but they're not yet know how todevelop their human interfaces.
To influence others and to achieve what they'relooking for.
So I love that, the focus on the humaninterface's piece, and you remind me of a topic
that's come up a lot in my past.
I've been in technology long enough that I canremember being the computer guy in a company.
(02:22):
Right?
And a lot of people that are in very seniorrole in large companies today, that's how their
career started.
They were the computer guy.
And when the company said, hey.
We're gonna being a technology company at somepoint in the past.
They hired people, and they said, hey.
Computer guy managed the technical people now.
That was how you train to be a manager.
Right?
And then that just continued up until you'resitting in, like, the c suite going, I know
(02:46):
what I'm doing, but you don't you really don'tyou haven't been trained on being a human
manager, a human leader.
It it's like front end development versus backend development.
You're very competent in the technology side ofjob.
Right.
But the front end part, you had no training onyou have no experience in.
Absolutely.
And it's been a real trash I think of thetechnology industry is that we look for the
(03:08):
best software engineer and we say, you're goingto be the team lead.
And then we say, you've been team lead.
Now you're gonna be a manager.
You're gonna be a director or the VP, andyou're gonna keep going up that way for the
people that are interested in it.
Right?
But, again, no training, no expectations ofwhat that means.
You you fumble your way through it.
If lucky, you get a chance to try again.
And it starts on a technology company, like, wewe start in a small room at folding table
(03:33):
working on the same project together.
We have easy human interaction.
But, like, with COVID, a lot of us started ourtechnology companies remote.
I don't see my team.
Right?
When am I gonna see them?
And then no standing me anything.
I don't wanna get in the way of their flow.
Right?
I want their hands on their keyboard.
I want them focused, and I want them create Sothat human piece, we almost run away from it.
How do we get it back?
(03:54):
How do we how do we make that connection?
The way, you phrased that and the way I believeother technology companies are working is we're
always trying to optimize, which we always tryto build something more and more and more
efficient.
But we always do it within the domain of ourknowledge.
We know how to write code, so we believe if wewant to write more code and more and product,
(04:17):
we just need to write more code.
And sometimes it could be true, but in the end,we're running code, which will then be used by
other humans.
And we have mental models of other humans, howthey will use that code, but it's not
necessarily the truth.
And realigning those mental models with ourusers takes a lot of time.
And as you mentioned before, product marketfeed is part of it to understand how your user
(04:41):
thinks.
Now if one developer has a user mental modeland another developer has a user mental model,
chances are those models are not same.
And both of them are running at a hundred milesper hour developing code for their own models.
By the time they commit the code, By the time atoken gets checked and by the time it goes to
production, the user will experience differentinterfaces in your application because a
(05:04):
different developer wrote it.
Now you can always apply layers of changes tomake sure that people are having the same
theme, but the idea, the underlying kind oflike harming engine understanding of the
product by the developers will not always beperfect.
And thus, there is a really good, exercise toonce a week, twice a week, once a month,
(05:26):
whatever the cadence is appropriate for theteam to align first on how they understand the
user, and then eventually to how theyunderstand each other.
Because there's opportunity for meshing andcommunicating with each other in a way that
does not require words, which develops overtime, or specific kind of communication.
But if you do not talk to each other, you donot get that model training data necessary for
(05:51):
you to define that interface between each otherthat enables you to accelerate.
What I'm bringing up here is that it's anotherto you to make things more efficient, make
things, go faster, make things less buggy atthe very end.
You you touch a a very important part ofefficiency that I think gets overlooked a lot.
And that is the effort and activity.
It's not what you're shooting for.
(06:12):
It's the outcome of that activity that youwant.
And a lot of wasted efforts spinning theirwheels doing 2 different things that are
crossed with each other is not efficient.
So taking a little bit of time to align andmake sure you're you're driving towards the
same thing is far more efficient.
It's like the a bunch of people rolling in aboat.
If one person's rowing backwards and everybodyelse is rowing forward as a less efficient
motion than if everybody was rowing the samedirection.
(06:34):
Right?
And we run into that a lot.
That's actually, surprisingly, what we'retalking about is what my company tries to solve
after the fact.
Awesome.
Right?
You you've created the technical debt.
You you've created these place where there'sbeen a disconnect between the desire and the
outcome state.
We help you solve that.
So the thing that's really interesting to meabout that, when you're talking about it with a
human interface piece and that that model pieceis that organizational structure has such a big
(06:58):
impact on people.
Right?
And I I always think of the game of telephoningplayed as a kid.
You've got the customer screaming about aproblem.
Now the problem is the customer doesn'tactually know the problem they want solved.
They know the pain they feel from it.
They know how it impacts them, but they don'treally know the problem.
And then you've got a product leader.
Maybe it's CEO, right, but you've got theperson who's got the vision for how we're going
(07:19):
to solve that.
They believe they've got a better picture.
So you've already gone through one game oftelephone.
Like, one party passed to another.
And now that's gonna get passed to the productmanager or whoever.
Right?
It's gonna get passed and passed and passed.
And it gets to the finally, to the people thatimplement it in code.
Who are playing a telephone with the computeritself.
Right?
They're trying to tell the computer.
This is what I want you to do in an imprecisething itself in the programming language.
(07:43):
And so the the natural outcome of this game oftelephone is you've got a bad translation.
You're always going to be off the mark, whichmeans we have to iterate It means that code has
to be thought of as ephemeral, and we all haveto converge towards an a shared understanding
of what good looks like.
But we won't start there because we all startedfrom different spot in that game of telephone.
(08:05):
Yeah.
That's a fantastic analogy.
And, one of the things to bring up that is nothappening and is not most of us are not taught
to do is actually ask a lot of stupidquestions.
Or powerful Christian, depending on how youlook at them, to clarify what the other person
is sharing.
If you have an act without a sin, you get toUTP communication, which is not necessarily
(08:27):
always understood that they received, you needto bring it to TCP in a way that every
direction between the layers that you have justdescribed, at least have a high level
verification that the person listening hasreceived it.
And maybe there's a feedback loop to theoriginal party, maybe not the same with, that
allows you to clarify the information you havereceived.
And on top of that, perhaps maybe there is away to design incentive structure where the
(08:50):
pain of the customer can be felt by all theparties who are in a chain.
And that's the hardest part is when people talkabout OKRs and KPIs and drive from that is they
misalign that, and they build theirorganization.
I I talked about this this particular topic atlength.
And so I'm sorry if anybody's gonna be boredwith me saying it again, but, like, You have to
build teams to be durable, but the goals thatthey have aren't.
(09:11):
If you build a team and say your job is toensure that the product get better and better
and better.
That's a terrible goal because we might not doproduct recommendations in the future.
Maybe it's gonna have an AI interface to besomething else ever.
Right?
I don't want to incentivize a technology choiceand a current state of being into perpetuity.
However, if I said, I want you to Always makesure that the customer is getting better and
(09:33):
better, things that they'd be interested inbuying, and we're gonna know that because
they're buying more of them.
Yeah.
That that that stays true.
I I do want that as an e Hammer company, let'ssay.
Right?
And the second part, like, they're buying moreof them tells me that's a good signal.
But we don't do that.
We say that the conversion number needs to gofrom 5 to 6 and 5 to 6 percent, and you need to
(09:54):
do better and better product recommendationsbased on this case AI.
Yeah.
And probably write more lines of code.
The more lines of code you write, the better.
The more hours you spend on the computer, thebetter.
I'm always amazed, though, that how fast thatgame of telephone falls apart, and people don't
ask the clarifying questions.
And I'll give you my favorite way to test thisin an organization because I've done this
(10:15):
multiple times, and I wanna see if you thinkit's nuts or not.
But I will get into a team, and though somebodywill say, okay.
It'll be done on that date.
Please to find done for me.
And I and I want everybody else to heareverybody else's definition.
Oh, actually, like, you'd need to do thatanonymous and then they compare, because
otherwise, they start copying.
It's back to the same model of the result and,of what work we're actually doing.
(10:37):
People forget the outcomes A lot of peopleprobably don't even know what other people are
working on.
Yeah.
It's so complex if you, if you, like, if youlook at any sizable organization, even just
eight people working on something.
It is hard to keep tabs on what everybody elseis working on.
Oh, absolutely.
And I agree.
That's a challenge.
Like, you have your own contact people haveothers, but that's where the need of the leader
(10:59):
comes in, which who's actually aggregating allthat into a wholesome picture a project
manager, be a part time, leader, it's theirresponsibility to do that.
Cause you have 8 individual contributors forKenneth code.
You're bound to run into the issues where thereis no coordination.
Like, you have to define in a router or aninterface, which brings all the results
together and gives people meaning to their workand also tiny beats of information of what
(11:24):
everybody else is working on so they can buildtheir own model and how they relate to the rest
of the project.
So when you say that I think of, like, theagile manifesto and what was intended by it.
The the intensives, the positive humanintensives.
The fellow part when it got codified into aseries of talking points by consultants.
Yes.
(11:45):
Well, that's how they got paid if nobody getspaid for a vision.
You know?
If only.
Right?
Yeah.
It it's an interesting problem.
And so, like, if if you were to give, thestartup community that's listened to this, a
couple things they need to look for to know ifthey've got a problem to start with, and, like,
maybe some tools they might leverage to solveit for themselves.
(12:05):
What advice would you give them?
Absolutely.
I will focus on the conversational piecebetween two parties and how to clarify
information that flows across the channel.
1, try not to solve the problem right away whensomebody comes to you with a question.
In technology world, we're so guilty aboutdoing it.
Why?
Because we're so good at it.
Problem, usually, we don't get the fullcontext.
(12:26):
Have some patience to have the and share asmany details as possible.
Next, ask questions.
Are there any more details?
It's a funny question.
It's a very straightforward question, but itgives you 25% more on average.
Number 3, summarize what you've just heard.
Don't feel stupid about doing that.
You're doing a basic step of making sure thatyou've heard exactly words in the way that they
(12:48):
have arrived.
So the other person hears them and understandswhat they have communicated to you.
And then ask what is the expected outcome as,you mentioned, what the outcome should be, and
how do they define successful Is that pressingthe button?
No.
The button just shows up on the screen orsomething like that.
So I would say that's sort of like, think ofyour communication with another person as that
(13:10):
way of getting information, which might have50% fidelity, like that JPEG of 50%, maybe
like, okay, like, 10% where it's hard to seethe details and you're adding more and more
clarity by asking those questions.
Like, our heads sometimes jump to conclusion,then we'll feel like we've got something, but
we're then risking the fact that we might nothave gotten it.
We pride in ourselves that we get things fromthe very beginning, but there's a high chance
(13:33):
that we might not.
Wow.
There's actually personal advice in theirongoing And I and I'm gonna give an example of
where I've already failed recently on thisexact topic.
So lifelong technologist love to jump to thesolution.
It's my It's the superpower that we all Hammer,as you described.
Right?
I got into an argument with a VC.
Oh, okay.
This is Alfred.
Can I I cannot Christian to this
(13:57):
over what tech debt is?
Now the reality is what I should have said inthat exact moment is this disagreement is
exactly the problem.
We all have a different definition for itbecause we don't see the whole elephant.
We're a bunch of blind people grasping at itand feeling the trunk or the tusks or the tail
and thinking we have full view of it.
That would have been a great way to describewhat we were doing.
(14:17):
It's not what I did.
It's like, well, hold on.
Like, That is also tech ed.
And that's tech ed.
That's tech ed.
Right?
Like, just wanted to do that.
Now, your point on repeating it back, is suchan important one that I know.
I'm I'm repeating it back to everybody elsebecause I know nobody heard it well enough.
We all think we need to understand what's inthe other person's head clearly.
(14:38):
We believe we do.
We'd make that assumption.
Erase that assumption.
You don't know.
Of into it.
Always assume you don't know and clarify.
What I heard you say was this.
That definition of done thing I've run it inevery team I've ever run into, and we spent
honestly an entire day on it where we would getto a precise definition of what done is.
(15:01):
Doesn't include testing.
Doesn't include you, you know, like, what aboutdocumentation?
Is that meant?
Well, yeah, it's done to tell us talk.
You're like, whatever.
Right?
You get into that debate, so you all agree.
But it took the debate and getting down to thenitty gritty to have a firm clear definition we
could all point back to and say, Hey.
I'm gonna be done on December 3rd.
And then to go, okay.
Well, then I'm gonna get the doc on December4th, and I'm gonna, you know, do this thing
(15:25):
over here with that.
As far as, like, definition of done, a newconversation see in a bit of regret.
The unfortunate thing about experience is thatit comes after you need it.
So
Yeah.
Every time.
And, well, the, the best part of that was thatturned into a great follow-up session with that
VC.
And we're that person's now gonna be an adviserto us.
Like, there's no downside to that.
Like, he wanted to have that argument, and Ilove being wrong wrong.
(15:48):
I honestly love it because I'm learningsomething if I'm wrong.
I have deeply held convictions.
I believe I'm right, but I'm often wrong.
We want to be wrong, but it doesn't feel rightwhen we're wrong at all.
Yes.
I wanna learn.
I wanna be wrong, but I'm not Yeah.
That's exactly right.
(16:08):
Well, Vladimir, we're almost out of time.
I wanna give you a chance to point peopletowards where they can find out more where
reach out to you and they can engage if theyneed your, your special knowledge and
experience.
Oh, absolutely.
Thank you for giving me that chance, Hammer.
If you would like to hear more.
And if you have topics on either humancommunication or human interactions in your
company as a technical executive or as afounder, please do reach out.
(16:32):
My website is human interfaces.co.
That's human interfaces.co.
As part of this podcast, I'm offering a freecomplimentary session, and you can just add
splash.
Textastic.
Oh, my god.
Excellent.
And that's a wrap for this episode ofTectastic.
(16:54):
Wanna thank you personally for joining us andwe'll see you next time.
Until then, keep exploring and stay curious.
Thank you for listening.
If you are new here and enjoyed the content,please subscribe.
It really helps us out.
And if you are a regular listener, thanks somuch for your continued support.
(17:14):
Overwhelmed by tech debt, discover Vala AI, thesolution to tech challenges with the simplicity
of a click.
No engineering background?
No problem.
Vala AI enables anyone to effortlessly tackletech issues, freeing up your time from tech
headaches.
Make tech debt vanish with Vala AI, where yourtech solutions are just a click away.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Special Summer Offer: Exclusively on Apple Podcasts, try our Dateline Premium subscription completely free for one month! With Dateline Premium, you get every episode ad-free plus exclusive bonus content.