Latest / Beyond Leadership - Adopting a Coaching Mindset / #10 - How Did Two Engineering Teams Deliver an 18-Month Project in Just 10 Months?

Transcript

#10 - How Did Two Engineering Teams Deliver an 18-Month Project in Just 10 Months? · Beyond Leadership - Adopting a Coaching Mindset

0:00
Host: Michael Hoffman Guest: GUEST NAME
0:00
Hello Vans. Good evening. How are you doing?  Good. How are you doing? I'm good. How was your  
0:06
day? Pretty busy. Friday for me are mostly not  relaxing because that's where I organize like  
0:13
all my work for the next week. That's where  I discover all the things I forgot to do this  
0:18
week basically. [laughter] So you do a review  on Fridays to make sure that you start on the  
0:24
right foot on Mondays. Yeah, exactly. Well, that  sounds like a pretty good plan actually. It is.  
0:29
Yeah. Well, that's worked for me. [music]  Welcome to Beyond Leadership, adopting a  
0:39
coaching mindset. [music] In this series,  our conversations aren't about biography or  
0:44
polished advice. They're about how decisions are  made in the real world when the pressure is on.
0:50
We'll anchor on one situation where the path  wasn't obvious and explore what goes on in  
0:56
the mind of a leader when confronted with real  tradeoffs, [music] imperfect information, and  
1:02
the need to move anyway. [music] This podcast is  brought to you by Peer Plaza. [music] Human help  
1:15
instantly. Before we jump in, I want you to notice  something. Vans, who I'm going to call Vincent,  
1:25
casually mentions his Friday review process, but  that's one of those habits that looks small from  
1:31
the outside and turns out to be doing a lot of  heavy lifting. People often think productivity  
1:36
is about finding a better app or a better system  when sometimes it's simply creating a regular  
1:42
moment to stop, reflect, and make sure you're  not carrying last week's noise into next week.
1:59
Vans Shrobar is a software engineering  leader who has spent more than a decade  
2:03
at Rover where he has grown from developer  to senior engineering manager. [music] He  
2:08
has worked across large companies and startups  in several countries including France, Canada,  
2:13
England and Spain [music] where he lives now.  Recently he returned from parental leave after  
2:20
the birth of his son Noah and stepped into a  new senior role at the same time. Right then  
2:27
he was given responsibility for a project  that had to move almost twice as fast as  
2:33
originally planned and I want to understand  how he thought through that moment. Welcome  
2:40
Vansa. Thank you for having me today Michael.  Very good to see you. So let's set the scene  
2:48
for our listeners and why don't you tell  them what we're walking into right now.
2:54
Right. So you give a really good introduction  uh into this challenge. So I was moving into  
3:01
like a senior management role to give a bit  more of context as I was stepping in this  
3:07
role that was just after my first pentative  leave and I have a lot like coming up front  
3:13
uh in the upcoming year. So my first inner  assumption was like okay let's take it easy the  
3:20
at the beginning of it this years like make sure  that you get into this new step in your life and  
3:26
you get some control around it and as I came back  from this leave I had a new manager in place like  
3:34
a new direct report in place that I didn't know  about and I had to on board and pretty much the  
3:40
first meeting with my manager I get into like  project that before my leave plan to do in 17  
3:47
or 18 months with one team and when I came in he  say like hey you have news about this project now  
3:53
we need to do it in 10 months if you've ever led  a major project you can probably feel Vincent's  
4:02
stomach drop right there what's interesting is  that the scope didn't change only the deadline  
4:07
changed leaders often discover that the hardest  part of a challenge isn't the [music] work itself  
4:13
it's recalibrate celebrating your thinking  fast enough to match a completely new reality.
4:18
Wow. So, you had a new child, Noah, and all  of a sudden you're going from a project that  
4:26
was supposed to take between 17, 18, maybe  even more months now to 10 months. It was  
4:33
cut almost in half. Yeah. What did you  first think when you heard that? It's  
4:38
a great question. Well, remember your  boss might get to this, so [laughter]  
4:45
I had an open conversation about it and a  retrospective about it with him already.  
4:49
So I don't think he's going to be surprised about  any of that. But my first thought was like, "Wow,  
4:55
okay, let's go pretty much again all  I planned before getting back to work,  
5:00
which was making sure I take it easy, take the  new responsibility, onboard this new manager,  
5:06
continue working on road mapping the two of  the teams that I already had into in charge.
5:13
And in the same time, it was like new exciting  challenge. It was a great opportunity as well  
5:19
for me that to demonstrate that I was capable  to deliver high complexity project with include  
5:28
being able to think multiple teams under  my group as well as outside of my group  
5:34
in delivering this project and I like the  challenge. That's part of how I am. So it  
5:41
probably crossed my mind of pushing back, but I  was definitively optin for this challenge just  
5:48
because I see it as a great opportunity  for me. I hear this a lot from ambitious  
5:54
leaders. They see a difficult assignment  and immediately [music] start thinking about  
5:59
what they can learn from it, what it might  open up, and how it could help them grow.  
6:03
That's a strength, [music] but it can also  make it surprisingly easy to underestimate  
6:08
the personal cost of taking on one more  challenge at exactly the wrong moment in life.
6:16
And originally, this was supposed to be  done by one team. When did you realize  
6:21
that one team wasn't going to be able  to pull this off? Well, from day one,  
6:26
like basically the scope of the project was still  the same. Uh just the deadline changed. So first  
6:33
when they came with this deadline they was asking  what do we need to put in place to get into this  
6:38
deadline? Is it even feasible? So first step was  really planning phase which was okay what are the  
6:45
set of component that we need to uh to build to  do this project. How are the dependency in between  
6:51
those component? How we can cut this dependency  in between multiple team. how many team we need  
6:57
to put in like to make it optimal and not having  too much management synchronization between these  
7:03
teams that will remove the optimization of having  more people like the speed of having more people.
7:08
So my recommendation what I share with  my boss and with the VP of engineer was  
7:15
two team plus a couple of expert in given  area will make it feasible in 10 months.  
7:23
One thing that's easy to miss here is that  Vincent didn't respond to pressure with optimism.  
7:29
He responded with a plan. Instead of saying,  "We'll figure it out." He worked backward from  
7:34
the deadline and [music] identified the specific  resources and expertise required to [music] make  
7:40
the goal realistic. For me, that says mature  leader. So, you went with two teams. What would  
7:48
have made it difficult to have added a third team?  the dependency between the components. Basically,  
7:54
you need to build like in a given order a  set of component and adding another team  
7:59
like adding more ads into the project  will not have helped to speed it up.
8:04
It will just add complexity and thinking in  between those team because of the dependency  
8:09
on the component. This is one of those  counterintuitive leadership lessons. When a  
8:17
project falls behind, our instinct is often to  throw more people at it. But beyond a certain  
8:22
point, every additional person [music] creates  more coordination, more communication, and more  
8:27
opportunities for confusion. Sometimes adding  resources actually slows the whole thing down.  
8:36
When I think of Rover, and I think probably a  number of our listeners when they think of Rover,  
8:42
they think of dog care. They think of dog  walkers and pet supplies. And so where is  
8:49
all this complexity coming from? Can  you help us understand that? Well,  
8:54
for the base uh is like we have a set of services.
8:58
So uh depending of the services that you're  using like the booking flow it's like completely  
9:02
different and like just to give you like two  services that look similar but are like really  
9:07
different into the flow is like if you want a  petalk you need to select specific date which  
9:14
are non-consecutive and you want to repeat this  those booking over time you might want to change  
9:21
uh from time to time like what you plan and so  we need to able to track all those iteration  
9:28
On the other hand, you have the boarding which  are consecutive date really a lot simpler type  
9:34
of service to make it happen. And where the  complexity land it's everything that we add on  
9:41
top of it which is like we do acquire a lot of  companies that we integrate into our platform.
9:48
So we do have team that are really dedicated on  like making sure that those integration into our  
9:53
platform are seamless for us on the technical  point of view as well as for the user of the  
9:59
platform that we acquire. I think this is  a useful reminder that software companies  
10:04
rarely stay as simple as the product people see  on the surface. Every acquisition, every country,  
10:10
every regulation and every new payment method adds  another layer of complexity behind the scenes. The  
10:17
customer sees a button. The engineering team sees  hundreds of decisions that have to work together  
10:23
every single time. And there are different laws.  Even in the US, if you compare like different  
10:28
state, there are different laws, different  requirement for a marketplace to operate.
10:33
You can have one dog. You can add like an extra  dog which has not the same cost of the first  
10:37
dog. You can have like an add-on which is like  pick up or drop off. You can make a consolation.  
10:44
you can make a modification that's going to  change a price. So, we need to be able like  
10:48
to follow up on all of that. One of the things  I've learned from talking with leaders across  
10:53
industries is that complexity tends to arrive one  exception at a time. You expand into a new market,  
11:00
add a new customer segment, acquire a company,  comply with a new regulation, and before long,  
11:07
you're managing a system that's far more  complex than anyone originally imagined.  
11:12
And we wanted to have a partnership  uh with an external provider.
11:19
And one of the requirement was to be able  to provide a credit based payment which was  
11:26
completely different to what we used to do with  payment and add also a lot of complexity on how  
11:32
we're going to build this client because a credit  is something which is in Bible and depending of  
11:38
the add-on that you use depending if you want  to cancel depending if you have enough credit  
11:43
depending of the price of the sitter and  that's really the top of the iceberg. Yeah,  
11:49
it sounds really complex actually when I hear  you speak about it and I totally understand  
11:53
it. Working on a platform myself, there's so  many people don't realize how many variables  
11:59
there are that you need to solve and one  disrupts the other and one breaks the other.
12:05
So, what did the lack of history with your newly  hired manager change about how you approached your  
12:12
decision to work on this project? How did it  affect you having a newly hired manager? Yeah,  
12:20
you know the leadership role it's a lot if  not all about like trust and this trust is  
12:27
something that you build over time and you  continue nourishing over time and complexity  
12:34
on working in the really high stake project which  are really big business impact with someone that  
12:43
you'll know. So like by definition you don't  trust and putting that into the context that  
12:50
those first six months was the most critical  for the project because that's where like we  
12:54
tackle all the most complex component to  making sure that it was simply feasible.
13:01
I was on and off because of my paternity  leaves and my new role as a parent.  
13:08
I needed to make sure that this person had what it  need to continue operating without me being there.  
13:17
How did you cope with that? Well, I take the  conscious decision to be seen as the scope keeper,  
13:25
which I knew but probably did not internalize  enough at this time that it will be bad for the  
13:33
relationship that I will start building with his  manager because by scope keeper I mean that I took  
13:40
decision against what he said because I wanted  to limit as minimum the risk. So anything that  
13:49
the product was will I will ask or the designer  will ask I had like a binary decision is that a  
13:56
requirement or is like something nice to have and  even if like he like preaccept as a change saying  
14:03
like it's small enough I was pushing back and  like saying well we're going to document that and  
14:10
putting on the version after the launch I want  first to make sure that we can launch it even  
14:14
if it was a conscious decision It's well you know  that the lack of trust might and probably did let  
14:23
scar even if after the those critical 6 months  I put all my effort on rebuilding this trust.
14:31
Yeah, it was a complex decision. I would  probably do it slightly differently if I  
14:37
had to. In what way? I would not just do it  but express clearly and communicate clearly  
14:47
to him and the rest of the stakeholders that I  will take this role for this exceptional case  
14:52
because of the risk of this project the role of  being the scope keeper and I think by saying it  
14:58
that will limit the damage instead of just doing  it and say like yeah I'm do it and I will change  
15:07
that after make it clear to everyone that I'm  taking this role and this It's not the normal me,  
15:12
but it's like the me in this context  would have probably make it smoother. So,  
15:18
so being more explicit about the control  that you would take over the project itself  
15:23
so that people understood better why you  were in effect controlling the project.
15:34
I think every leader eventually encounters a  moment like this. You realize that being liked  
15:39
and being responsible for the outcome [music]  are not always the same thing. Vincent made a  
15:44
deliberate choice to protect the deadline  knowing it might cost him some goodwill in  
15:49
the [music] short term. Did you feel like you  were micromanaging? I did. I mean definitively  
15:58
when [music] he took decision and I revoked  those decision that was micromanaging like  
16:05
literally looking back on that how much of  that was due to stress [music] and much of  
16:14
it I'm sure due to lack of sleep you just had  a [music] child. Yeah. I'm going to turn this  
16:21
question into something that is not putting  me in the role that I'm finding excuses.
16:25
I mean this is definitively a contact like  sleep and everything but even with that I  
16:31
think what I a missed opportunity from me was  [music] to ask for help that simple now I'm  
16:40
a senior manager I should be super independent  in [music] this challenge instead of spreading  
16:48
this emotional and stressed decision uh to my  peers and my manager Now I see it now that I  
16:57
have a bit more experience like what make  you a great leader and especially a senior  
17:02
leader is like do not hesitate to get as many  support as you need like a team of leaders uh  
17:11
here in Barcelona [music] but that can help  you and support you. That wasn't the case  
17:16
before. So not that the culture was wrong  it's just that the resources was not there.
17:24
Looking back, what do you believe this  revealed about how you think about speed versus  
17:32
coordination? They go together. [laughter] Well,  hopefully coordination will help you limit the  
17:41
risk and on this specific project like that was a  key like the coordination. So from the beginning  
17:48
when like start planning the project like I start  uh planning specific date for checking on go no  
17:55
go we had like regular cross functional meeting  we put in place a rassi to making sure that we  
18:03
have one person for each section making the final  decision and avoiding well looking for this person  
18:10
if it was unclear. So this coordination was great  from the beginning. The speed was defined by this  
18:20
coordination I would say because like those self  deadline that we put on the road map was what was  
18:28
helping you and the quad keeper on like we have  the right speed to deliver in those 10 months.
18:35
I think one can think of speed as efficiency and  coordination as effectiveness [snorts] because  
18:44
you can have all the speed in the world  but if you're not effective then it's all  
18:48
for not. Do you feel like effectiveness was  prioritized so that you could gain the speed?  
18:56
I prioritize the effectiveness by pushing  back on anything that was not a requirement  
19:02
uh for the delivering of the of this like  first iteration of the project. So you  
19:08
push back on any new ideas that people wanted  to add to this project in your job as scope  
19:16
creep manager so to speak. Yeah. And did you  get a lot of push back on that? Oh yeah. Of  
19:25
course. Without a good framework on how to  propose change of scope which we don't have.
19:32
There is a lot of things that's still little and  that even for the team those engineers that they  
19:39
feel that it's going to be like really small  cost of implementing and have a great impact  
19:45
on the overall project in term of conversion. But  by experience I know that's like when you add up  
19:51
those uh small things or even sometimes just  one small things like it's not that small and  
19:56
that's like delay everything for more conversion  but if we don't deliver this more conversion is  
20:01
useless. So yeah, it was a few time me against  the world. Uh because like the product owner  
20:13
would say all the user experience designer  would say like yeah as a team that it's easy  
20:18
and the team say yes it's easy and I say yeah  but I don't first I don't think it's easy and  
20:22
secondly it's like just add up to a scope and it's  unnecessary and you don't trust your own team.
20:29
[laughter] Yeah. There's a leadership lesson  hidden in that distinction. People can tolerate  
20:35
a surprising amount of control when they  understand why it's [music] happening and  
20:39
how long it's going to last. Often the  problem isn't the decision itself. It's  
20:44
when the reasoning stays locked inside the  leader's head. I can imagine that this is not  
20:51
an uncommon conversation in software teams.  Yeah. No, you're completely right. Why do I  
20:57
suppose we haven't cracked that nut yet? [music]  Where is the communication going wrong? You know,  
21:02
it's like the conversation between sales  and marketing. Even with a good racy,  
21:08
I think there is a lack of accountability  because we ask and we want people to be really  
21:16
collaborative and that's super important  and that's key in software engineering.
21:21
It's like key in the culture here at Hover.  But this collaboration sometime delude the  
21:29
accountability. It's basically the team say so  is not one person the team because it's not one  
21:36
person saying it. It's like a bunch of people  like going to give their opinion and it's really  
21:42
hard to find like is that a real in-depth search  that they did to estimate that or is like a really  
21:50
superficial poker estimation. So, so you're  not dealing with a leader of the team. You're  
21:57
actually dealing with various people on the team  rather than the team lead. Yes and no. Because  
22:03
my direct speak is like to the team lead, but  that's get delude like my team lead is speaking  
22:11
with the team because they're collaborating with  them and it was the team to a clear opinion.
22:17
But that's where it's getting delude because like  now it's a team. Doesn't matter like at which  
22:21
level you take it. Uh I was personally speaking  with a team lead but this team lead first I didn't  
22:27
know him yet. Uh this manager I didn't know him  yet and at the end of the day was just speaking  
22:33
with a bunch of people none of them having  any responsibility of what they were saying.  
22:38
H it's interesting in a symphony orchestra you  have section leaders and you can think of them  
22:45
as team leads and the conductor would almost  never speak to the members of a section but  
22:53
only to the team lead because it just takes  too long. You have so little time to rehearse  
22:59
a piece of music. So if everybody were to  give their opinion, it would be cacophony.
23:05
And actually typically the conductor is speaking  with the concert master about things and the  
23:11
concert master might speak with the various  section leaders about certain things whether  
23:16
that could be Boeings or uh interpretation and it  would be nice to have that kind of coordination  
23:24
inside a software team. What do you think? It  is true. I think it's like a normal scenario.  
23:30
It is mostly true because you have a manager that  speak with lead project which is like me speaking  
23:39
to the engineering manager, the engineing manager  speaking to the project lead and the project  
23:45
leading with the rest of the team. One reason I  love this analogy is that leadership often looks  
23:51
similar when you're conducting an orchestra,  running a software team, or leading a business.
23:57
At some point, complexity becomes impossible  to manage person by person. You have to create  
24:02
trusted layers of communication where everything  slows to a crawl. I can imagine that you as a  
24:10
leader want to be democratic and listen to the  opinions and help people feel heard and at the  
24:19
same time there's a limit to what you can do.  Do you feel that perhaps sometimes you listen  
24:27
too much to your teams? Ever since first I  never wanted to be democratic. [laughter] Uh  
24:39
democracy is like every voice weigh the same. Uh  that's not true at all in company organization.  
24:46
that's where this trust is really important  because I will hurt someone that I trust. I'm  
24:53
not going to hurt that much like someone  that I distrust and that's based on our  
24:59
relationship, our experience working  together, our way of working as well.
25:03
Uh as well as like there is some expert in some  area that I'm going to like wait and value more  
25:09
their opinion that someone really junior. So  it's not democratic. [laughter] No. Uh do I uh  
25:19
hear too much about the team? I don't think  so. I don't think there are like a wrong or  
25:26
bad answer to that. It's really depend of like  what's the project about and what we try to do  
25:31
and like to give you another example like now  in this AI era we are transforming the way that  
25:37
we that we're working and everybody have like  a different opinion and I hear their opinion.  
25:43
I look for some opinion but I have myself like  a given time windows to do that and I need to  
25:51
take a decision at which direction we're  going because I think what's important is  
25:55
like making some progress and you can make some  progress the wrong direction but if you don't do  
26:01
anything you're never going to realize that what  you're doing is going to the wrong direction.
26:05
So no I always time like those feedback and  I don't think I take too much time hearing  
26:11
their opinion. So you were able to do this  project and a project that might have taken  
26:17
nearly two years and you did that in 10. Did  you finish the project? Is it done? Yeah,  
26:24
I was going to say that we finished the project.  It was two months in advance that give us the  
26:30
opportunity to do in-depth internal testing.  The launch has been really successful. No.  
26:37
Are you saying that you did this project in  8 months instead of 10 months and then you  
26:41
had two months to test it? That's right.  So help me understand how you can go from  
26:49
an estimated nearly 2 years to 8 months and  then have the liberty to test it for 2 months.
26:57
So do you think that it was poorly scoped from the  beginning? resource resources was different. First  
27:07
we had an extra team and probably most importantly  we had some specific expert in those critical area  
27:17
which was payment and finance where we needed  to unblock like this currency divisible payment  
27:25
uh into credit based payment. Yeah, [clears  throat] that sounds very complex right there.  
27:31
So, have you been able to take the learning from  how you organized this and apply it to the next  
27:40
projects? Because it sounds like you innovated  the way you're working. Well, I documented in fact  
27:48
uh and that's a presentation that I'm going to do  internally in the company. Uh I think the question  
27:55
in this document that I try to answer is like if  tomorrow we had to do the same kind of big project  
28:02
like in term of the time that we need to do it  complex and unsure about the physibility. what  
28:10
went good and what we should do differently and  part of the success is like there is a lot of key  
28:16
eric people that been putting 100% in which is  a normal case scenario would not be the case so  
28:24
those key specialist I'm sorry it is the normal  case or it's not the normal case where you no  
28:28
it's not the normal case those specialists are  like many things to take care about in their day  
28:34
to normal dayto-day like they're working  on multiple projects they're unblocking  
28:37
like multiple things but what's what we call  staff or senior staff engineer at the company.
28:43
In this case, it was like 100% dedicated on like  solving those specific blockers. I know that this  
28:50
was pretty dramatic for you during that time. Was  there a moment when you thought maybe I can't do  
28:58
this? Not really. The project was as planned  on the cost of how people was perceiving me.  
29:06
But hey, on the VP and leadership level, people I  was really happy because everything was on track.  
29:12
And at the end of the day, they didn't notice  that you were on parental leave. They didn't  
29:17
notice that you were severely lacking sleep. You  brought the project to the table before it was  
29:26
due and everybody was happy. So most of this  experience is really happening. Everybody up  
29:34
was happy. [laughter] Everybody [clears throat]  else was happy or everybody up everybody on the  
29:42
top level of the hierarchy was happy. people on  the other side, people that I manage directly  
29:47
was really unhappy about me because of my level  of involvement, my level of micromanagement, my  
29:54
level of being way too directive for uh what they  would like as well as my peers in other department  
30:03
because I was pushing back on their idea, PM's  idea about like how to make better conversion.
30:08
I was pushing back on UX making that's  going to be a better UX user experience.  
30:13
So to my level down like people was really  unhappy about me. So you were as we say in  
30:20
America a tough ass. You were very tough on  the team and have they forgiven you for that?  
30:28
Well as I mentioned like had 6 months like to  make this on the rail and making sure that he  
30:34
will stay on rail and deliver on time. At the six  month mark, I shift gears and explain why I was  
30:43
being that tough with them and that micromanaging  and I build new tools also like to uh making sure  
30:51
that I rebuild this trust. So survey, clear car  direction, focus on them, making sure that they  
30:59
have all what they need like to continue this  project with my support without my intake.
31:05
So yeah, that worked with my direct report. The  damage with my peers on the other department still  
31:12
need some reboot. Ever wish you could just talk to  someone who's been where you are? Not a chatbot,  
31:22
not chatbt or Gemini. A real human who gets it.  That's Peer Plaza. Human help [music] instantly.  
31:32
Whether you need a career coach, a leadership  mentor, or someone to help you navigate a tough  
31:38
transition, Peer Plaza connects you with  vetted professionals ready to help right  
31:44
now. Browse profiles, watch intro videos,  and book a session just like that. Visit  
31:52
pierplaza. com because the best advice still  comes from real people. Is it more about the  
32:03
way you said no rather than saying no? What? Yeah,  it is a way uh is how I communicated definitively.
32:12
And as I mentioned earlier, it's always  because I have not been vulnerable to them  
32:18
on [clears throat] explaining why I was doing  that. I was just doing it. [clears throat] Uh  
32:24
no explanation. Just saying no. [clears throat] No  document that we're doing that later. Of course,  
32:32
like explaining that we cannot put at the  deadline, but I could have explained like,  
32:38
okay, I'm going to put myself on this role, so  don't be surprised that I'm you might think that  
32:43
I'm a big blocker to not say other world.  So to come back to your original question,  
32:49
what I'm doing now with them to do is like I  put myself on their shoes. I see that there  
32:54
mostly with because like the most of  the damage was done with the designer.
32:59
The main problem is that as we do have technical  vision, we do as engineer execute this vision.  
33:06
They have UX and UI vision but we still are  as engineers that implement this vision. They  
33:14
are not. And so when we as engineering or me  personally block them into improving this,  
33:21
it's basically telling them like yeah well  you know all your beautiful vision and all  
33:26
beautiful work that you did well we may be  going to do that later if we have time which  
33:32
create a lot of frustration about like uh  what they're doing. So what I'm doing now,  
33:37
we get back into like all the project that  we did on the left here. See where the gap  
33:42
into what they wanted to do and what we did.  Document that, build the road map and assign  
33:48
like 10 or 20% of the engineering time on  working on those on this specific road map.
33:55
The advantage of that as well is like the tendency  that we have in the past was to in each project  
34:04
which come from product is like to try to add  multiple axis to it and by axis I mean like  
34:11
design coming and they want to implement their  vision in this product. product has a business  
34:15
uh vision for this implementation and we do  have a technical vision that we want also  
34:19
to implement and depending of the complexity of  those three axis does make any project at risk.  
34:26
So by having a specific road  map for uh the technical vision,  
34:29
having a specific road map for the product uh  vision and having a specific road map with the  
34:35
design vision like we separate the complexity  in like three different line instead of merging  
34:41
everything together and make like the  overall project way more complicated.  
34:46
doesn't mean that in any product vision there  are no need of like any design vision but we can  
34:52
limit the complexity of this specific axis if the  goal of the project is like a business outcome.
34:59
I'm curious still about the part where you're  telling people no and as you said earlier it  
35:07
was simply no without too much explanation.  What went on your head? You must have known  
35:12
that was creating tension with them. But at  the same time, was it the urgency? Was it the  
35:21
frustration? What was it that prevented you from  saying, "Hey, let's talk about this and let me  
35:28
help you understand why this is a no." Yeah, it  was mostly time constraint. Uh, so it felt like  
35:37
you didn't have the time to sit down with them.  And at the same time, perhaps I'm just going  
35:43
to give you a another version of this that we  can think about. Had you spent the 15 minutes,  
35:51
20 minutes sitting down with them, that might have  alleviated some tension between the two of you,  
35:58
had a better relationship, and then been able  to work better on the project as you continued.
36:06
What do you think about that today?  
36:11
I mean we of course sit like 10 15 minute to  discuss some of those idea of improvement that  
36:16
they wanted to put in place but that those talk  was those conversation was really unstructured.  
36:22
So they are they were really unproductive and  mostly based on emotional reaction each part  
36:31
defending their ideas. Yeah. me defending the  scope, them defending that it's better for the  
36:39
user experience and the team saying like it's  not enough we haven't discussed that. So how  
36:44
do you have a structured conversation like that  moving forward? Yeah. Again moving forward and  
36:53
by having now like a framework about like uh  complexity of those three different axis in  
36:58
a given project we can categorize any of those  project uh and decide if we want to improve UX  
37:04
or if we want to document it uh up front instead  of like in the middle of the development phase  
37:10
uh deciding like hey we're going to add this new  thing p okay but I'm not going to let you get away  
37:16
with that because what I'm wondering is there  is a discussion you know these things happen.
37:24
How do you structure a discussion like that  so that you both walk away with some kind of  
37:30
satisfaction instead of he just doesn't understand  or she just doesn't understand by understanding  
37:38
the other point of view having more empathy about  why we even need a conversation at the first place  
37:46
because if we have the need of the conversation is  because I mean understanding of like the objective  
37:51
of each other and By explaining my objective  doesn't mean that further understanding can  
37:58
they even want to understand it. So I need to  be the person like putting me in their shoes and  
38:05
trying to understand their point of view on like  okay why the big hurge about like these specific  
38:11
features and the specific things that you want  to add into the table how we can mitigate the  
38:18
risk of adding it versus the need that you  have on your own perspective on adding it.
38:23
So it's really about like making sure that you  have this ability to not be only centered of your  
38:29
own objective but like see different perspective  and different objective that might be in the  
38:35
same project. It sounds a bit like what Steven  CVY says in the seven habits. Listen first to  
38:43
understand then to be understood. And what I hear  you saying is having empathy for the other side.  
38:52
And that requires that you listen to them and not  just listen enough to give back your opinion, but  
39:00
actually listen and be curious to know more and  more. They feel heard. They feel empathy coming  
39:09
from you. And that probably takes away a mountain  of stress and consternation from the conversation.  
39:19
Moving forward, how would you implement that  in the next conversations that you have?
39:29
Tough question. Does it require both parts to do  that or can one person model that for the other?  
39:41
Oh, we need both part to do it. But like the  tough part is like how you drive the conversation.  
39:47
the or influence the conversation that the other  one like open to like also getting like different  
39:54
perspective because it's not just about like yeah  sure I do understand you and you're right on your  
40:00
own perspective and so we're going that way it's  like we need to both of us being able like to  
40:05
well both of the three of whatever the number of  people like to uh get all those perspective and  
40:10
understand them I lead by example I would say  and I would say Don't explain your perspective  
40:19
but ask question that will make them get to  your perspective that will be my strategy.
40:25
Mhm. Uh but did you think about that? How do you  think that will add risk uh to this project? Do  
40:31
you think it will add risk to this project? What  if they say no? I don't think it's going to add  
40:36
any risk to this project. What do you do then?  But I will dig into that like it is small enough  
40:44
but what if it's not small enough? Did you see  the perspective that building that mean that we  
40:50
need to build it like all the other platform? Oh  no I didn't see this perspective. Maybe we should  
40:56
dig into that before taking any decision. So what  I hear you saying is that having that type of a  
41:02
conversation where you're focused on listening to  the other person can make this less transactional  
41:09
and more about solving the problem at hand  without all the emotion getting in the way.
41:15
Yeah. And again lead by example meaning  yourself when you ask those question like  
41:21
you need to deeply internalize them like no I  don't think it add risk maybe it doesn't and  
41:26
maybe I'm wrong like let's work together like  on is it really adding risk and let's see like  
41:32
all the different perspective that will make us  decide if it add risk or not and it does require  
41:38
you to be open to the possibility even though  you're quite sure this is going to add too much  
41:44
risk Mhm. You too have to open up yourself to  the idea that well, he might have a point here,  
41:51
so I need to listen in. And I'm supposing that if  you listen in and ask more and more questions and  
42:01
you both arrive at the same conclusion,  then you're both happy campers, right?
42:07
Yeah. So, and you can share both stronger.  [laughter] That's also possible. I like this  
42:18
idea because it's easy to ask other people to be  open-minded. It's much harder to demonstrate it  
42:24
yourself. In leadership, people tend to follow  what you model far more than what you tell them  
42:30
to do. Van, this has been a great conversation.  Thank you so much. I wish you all the best with  
42:37
your son, Noah, and I look forward to seeing  you soon. Thank you. a wonderful weekend. Okay,  
42:44
you too. Bye. Bye-bye now. Thanks to my guest and  to all of our loyal listeners. Subscribe today so  
42:55
you don't miss upcoming conversations.  And if you found this podcast valuable,  
43:01
please leave a review. It helps others discover  the show and keeps the dialogue growing.
43:06
For more information about  ScaleU and ScaleU retreats,  
43:10
go to scalewu. org. org where you can  find the full library of podcasts,  
43:16
blogs, and additional resources. Thanks  for listening. See you next time. [music]