Christian Mccarrick:
[0:00] Good afternoon and welcome to the show.

Eric Elliott:
[0:04] I’m excited to be here.

Christian Mccarrick:
[0:06] Yeah you know I’m super excited to talk to you on the show to we have you know lots of different kinds of people and I’m really interested in your background
especially since the new company that I’m at right now I’ll Ciro is a complete kind of JavaScript and no shop so happy Taco Shop but obviously the,
the topic of our conversations is heard about leadership so we’re going to go on to that but,
you know I wanted to thank you for coming on and like I do with all my guests a little bit if you can just give me a little bit of a brief background like how do you know what was the path that you chose then or didn’t shows and it got you where you are today.

Eric Elliott:
[0:44] Sure so my background is actually spent a lot of time doing
leadership early in my career because I started out as a consultant while I took a programming job and did that initially and then I moved into Consulting for the next almost decade,
my career and in that time I was basically telling people my client I would tell them,
put me in charge of your engineering department and I will deliver bottom bottom line kpi measurable results or you don’t pay me and that’s how I got clients are Leon and initially it started out with small.
Little start-up sending this little startups started doing well and then got acquired by larger and larger companies and it worked up into Fortune 500 companies.

[1:32] And from there I took a little bit of a break and then I started working at a place called Zumba Fitness which is.
An exercise company that’s actually a tech company and I led front end engineering there and then I hopped over to,
10 page and.
And I was on a team of three swords in early developer on band page and we we got up to 30 million monthly active users and I help the architect in.
And run that app and though it wasn’t in the leadership position they’re my next gig was in a leadership role.
Leaving the tech team at Town Square.
Tout is currently still being used by about 80 million monthly active users and a lot of broadcasting and media companies like CBS NBC
BBC Wall Street Journal and a bunch of others.

[2:28] So I led the front end engineering team there and then I joined I joined Adobe,
as one of the early hires on their Creative Cloud
infrastructure which was of the projects that helps them move from the box software sales model to subscription software so I helped architect-designed architected,
and builds the Creative Cloud stuff a particularly I worked a lot on the on the.
The web home page that you get to when you go to Creative Cloud. Calm I did the initial versions of that and I also worked on the messaging back end.
So the messaging services and so on on that and I’ve done a couple of other.
Leadership roles got up into VP of engineering,
for a blockchain company and they’re I built a really great a small team really really great team and we built it the most amazing engineering culture I have ever seen,
on that particular team so I’m excited to talk about like.
Culture and how to how to make how to create a small team culture that can grow into a larger team culture and and really Inspire the Developers.

Christian Mccarrick:
[3:49] Yeah awesome and that’s certainly a Hot Topic when you talk about scaling and scaling scaling culture always comes along with that right how do you,
how do you maintain that culture was you go from that small handful of people to 1050 hundred two hundred and above so I just ran the challenges today.

Eric Elliott:
[4:07] Exactly in early in my career I saw tool ocelot more of those culture struggles and trying to as a consultant there was already an established culture so my job was to come in and transform this
the culture that was already there and that’s a really really hard job another person I know who did that really well was.
The engineering leader at PayPal Bill Scott.
Right he went in there and transform their engineering culture they had a culture that was like stuck in the late 90s
and he went in there and help transform that so that reminded me of like my early experiences as a consultant where you go in there and there’s always already this big established
process in big established like these are the way that we think about engineering here and you have to kind of reprogram those,
those things done in these large organizations that’s really hard to do so I really respect people who can go in into an existing team and turn the culture around and and
transform it and make it better when it’s already kind of spoiled and rotten but I also got this experience of building it from the ground up
completely fresh and new in end exciting in and so I’ve seen both both ends of that Spectrum it’s really an interesting interesting challenge.

Christian Mccarrick:
[5:30] Now it is and I think you mentioned the two aspects you know kind of a green field pipe company,
which has its own challenges but it is not a benefit they’re too and I think probably one of the more common areas for some of my listeners from an Engineering Management standpoint on Master going to be,
starting fresh in a new company you’re going to be stepping into something right so there’s going to be something they’re already but it was good bad,
indifferent,
it’s certainly probably the more experienced through my hat is stepping into something and Shepherd Nia Long from that point versus being able to start something from you.

Eric Elliott:
[6:06] Yeah yeah it was interesting to get see both sides that so I’m excited to talk about either way.

Christian Mccarrick:
[6:14] Yeah yeah some of the things are the same right but summer I think the scaling things certain they’re the same just a little bit about what you walk into when you walk in the door is certainly different.

Eric Elliott:
[6:26] Yeah in an existing company where there’s already a really big strong culture you’re still scanning but you’re scanning with resistance so it’s something in there something this big.
Big conglomerate Force pushing back on you while you’re trying to build so it’s a really interesting interesting Dynamic and there’s a lot more politics and and yeah.

Christian Mccarrick:
[6:48] Definitely a good quote from someone I know always says you know whenever you can talk about no politics and everything whenever you have more than two people in a room there’s going to be some level of politics whether it’s you know your intentions.

Eric Elliott:
[7:01] Exactly exactly you don’t want to you don’t want to get into that tangle but there’s always there’s always people who have
they have an agenda whether they whether they like it or not whether they admit it or not there’s some kind of agenda there they’re either doing something that’s working for them
or they’re deeply in Grant they got some deeply ingrained habits that need to be broken in order to make the transition successful and so,
there’s always going to be this like this process where it’s not just about you go in and lay down some rules and then everybody just magically starts of angles rules right,
that’s not that’s not how it works what you really need to do is he need to go in there and set up examples for them and and
and build habits and that takes time.

Christian Mccarrick:
[7:50] Yes certainly certainly and you know we’ll dive into that too I think some of the specific things are on how do we do that it companies both neither new or existing,
here in a couple minutes so I you’ve been you can also get it back leadership roles icy rolls.
And you what what are what are some of the things either personal experiences from you,
or coming into companies and semen from the outside what do you who do you think some of the top mistakes managers are new managers make as they get to get into the roll.

Eric Elliott:
[8:23] Sit at home and just how many mistakes
so the interesting thing is like a lot of the problems that we encounter on engineering organizations can be avoided they’re up a lot of them are avoidable
I’m almost all of it really are avoidable problems and you just have to know what to look out for so if you are a lot of
a lot of engineering leaders step up from being Engineers to get promoted into a leadership position because there maybe they’re great engineers.
And dirt what a lot of people that makes those promotions don’t seem to realize that those those engineering skills that got that makes them great Engineers don’t necessarily make them great leaders of Engineers you know but.

[9:07] If you remember what were the things that the managers you liked did right right and carry that with you into your engineering leadership position that really helps a lot
for instance somebody who’s been through been through situations where they’re being unfairly judged because maybe they’re senior developer sin and they’re being judged more as an individual contributor
in a good well-functioning organization there’s no such thing as an individual contributor engineer it doesn’t exist,
what really happens is you get the system of collaboration where there’s people who
to know more about the domain or they know more about the technical aspects of things and what ends up happening is everybody else on the team starts to lean on those people.
And those people are spending their time mentoring the other people and teaching them how to do things if you’re doing things right in the worst-case scenario what happens is people just dump all the stuff they don’t know how to do on that person.

Christian Mccarrick:
[10:14] Yeah.

Eric Elliott:
[10:16] And then that person becomes like the roadblock for everything because there’s a really good book on this topic is called.
Call the Phoenix project right and there’s this guy Brent and Brent knows everything about the system and everybody wants Brent’s time right.
So this is the opposite of what you need to be what you need to be doing is empowering Brent to teach the other people how to do their thing
so spreading that knowledge across the organization rather than bottlenecking everything that needs to happen to that one person with the knowledge,
rights and dumb one of the big mistakes that a lot of people make is.
Is they try to judge those really highly skilled developers on the basis of what tickets are they closing that were assigned to them.
And that’s a problem because they’re not closing their own tickets they’re teaching everybody else how to do their jobs.

[11:16] So what are the things that this is one of the biggest mistakes I’ve ever seen an engineering organization is as they’ll they’ll assign a bunch of menial tasks to some senior-level developer and say do this do this do this,
right in the nuts in unit 2 level developers helping people accomplish their much more important much higher value tasks
before they get to their medium tasks so they never close their that it might be days before they close their menial tasks ticket in your as an engineering manager you might be tempted to be like popping open the the issue tracking system in saying.
This looks like a pretty easy bug fix it’s been sitting here for days what you been doing dude.

[11:58] And the answer is hoping your entire team function.
I’m up there on the factory floor keeping it clean making sure that everything’s moving along smoothly,
and you’re judging me based on whether or not a fix some menial bug in in 10 minutes right so the biggest problems is trying to value.
Developers as individual contributors the whole idea like individual contributors on a development team just needs to go away because there’s really no such thing.

Christian Mccarrick:
[12:29] No one no one can ever exist in a vacuum and then a software-based filter aging it’s built.

Eric Elliott:
[12:35] Exactly especially in a development team so one of the big problems one of the huge backups we see on a development team that’s working pretty well,
is that will have things like code review processes right no code reviews a really important process because every hour spent in code review say is about 33 hours and maintenance.
And what can happen is that the code of these get assigned to the people with the most technical knowledge on the topic and those people tend to be also be.
Tend to also be the people that know a lot about some other topic and they they get all these Coterie these get heat on top of the same person.

[13:16] I know this person is trying to push through the code reviews and they’re not getting to the top the the the stuff that was assigned to them.
So one of the one of the problems is when we start to
develop this organization using processes like design review inspect reviewed code review these are all good processes that you want to implement because if you do
you can reduce production bug density by like 90% and sometimes up to like 97% just implementing those processes,
right but then those processes delete the whole concept of individual contributor nobody’s individually contributing anymore you’re collaborating.
Right so doesn’t make sense to try to measure the effectiveness of an individual developer based on the tickets assigned to that individual developer
doesn’t make any sense because it doesn’t lock doesn’t track with reality of what work is actually flowing through the organization.

Christian Mccarrick:
[14:14] Now that makes a lot of sense I definitely see that and then and then even the backlog of FDR’s NPR time you like starts starts to to grow to from hours to days to sometimes.
A week before they even you cannot even close at the yards and everyone scrambles a y and I think it has a lot to do with.
University of knowledge and knowledge transfer and sharing and what you say and what is the unit of optimizing your organization for optimizing for number of bugs tickets in Lenoir ticket someone’s closing.
Or should you also include in their in their timing while this is a very valuable aspect of this person’s job we’re going to actually value them to this versus how number of jeer tickets.

Eric Elliott:
[14:55] Yeah exactly so I mean I think one of the biggest mistakes is just thinking about people in terms of individual contribution in the first place right as soon as you start to track metrics like how many tickets zip code,
you may have heard the phrase what gets measured gets managed right but there’s a second part to that.

[15:18] Even if it’s harmful to the purpose of the organization to do so.
And this is one of those things where it’s harmful to the purpose of the organization to track.
An individual developers close tickets and to Value them based on that.
So the right way to approach reviewing whether or not a developer is as effective is to ask the rest of the team,
is this developer helpful are they making it an effective contribution to the organization and if they’ve been spending their time mentoring and helping people close their tickets and
and and being helpful to the organization you’re going to get that from those conversations right this isn’t something
this isn’t something where we can just magically plug it into an issue tracker and and magically like come up with a number that says this developers this valuable to the organization
this developers this no don’t try to Value them in isolation
right you should definitely be measuring like the velocity of your production but not on an individual contributor basis instead measure the aggregate
inch and watch how the aggregate score changes over time as you get more efficient and better at pushing out feature.

Christian Mccarrick:
[16:34] Absolutely and you’re this interesting statistics they’ve they’ve done a special thing for basketball and have a lot of stats
is the number of players who are the multipliers right there not the top scorers are not the top rebounders but whenever this person is on a team,
the entire team stats go up you know that particular person doesn’t contribute to the top-line stats.

Eric Elliott:
[16:55] Exactly they’re the ones nailing the assists all the time right and left their they’re making the past right before the dunk.

Christian Mccarrick:
[17:02] Yep yeah that I got a lot of questions about,
and you have a thing for number for relations both small and large and we’re talkin about ICU and managers and other things what do you see,
a little bit of the differences in organizations for,
you know you people chocolate. But I see then you have the concept of the check we do you have a team lead you have an engineering manager and what’s the best structure.

Eric Elliott:
[17:32] Yeah so.
A tech lead tends to be somebody who takes charge of a given a given product or projects from a technical,
perspective meaning that’s well while other people have a voice on technical choices this person tends to lead some of the early architecture in terms of.
Like,
how are we going to break this problem down into smaller pieces and then solve those smaller problems so they might take
they might take a more of an architectural lead on the team they also might do things like like help set policies on
what is the what is the code style going to be like in and what are are,
what are our engineering practices for this particular team that might be valuable that then might make a contribution,
so WWE the people that are kind of like kind of.
Setting the example for the rest of the team and maybe laying down some of the big foundation pieces as well in terms of like the connectivity of how all the various compositional elements of the application come together to form the whole.

[18:49] So they might make decisions like.
Are we going to use a micro architecture approach microservices architecture approach or are we going to are we going to try to save a little time and energy and build it as like,
an all connected monolithic sing at first
and then break it down into microservices is needed stuff like that are our decisions is that these people will tend to make and it depends on the size of the team right so the larger the team is the more likely it is that there’s going to be an architect to,
or even like on a very large team there might be a Chief Architect as well who who guides architecture for
the the basically how all of the products of the organization fit together and and interact with each other and connect,
and so it can split out to where a tech lead is is.

[19:50] Take me to go from anywhere from like a mentor on a small team to like helping other people,
figure out what they’re doing an end be productive with the app.
All the way up to now they’re also doing architecture and design things like that technical design things and giving a lot of feedback to the
like for example a tech lead might sit in on on some of the design discussions in and really give the technical feedback about.

[20:21] About.
Here are the technical implications of this feature design and so for example if you’re building a social network a tech lead might sit in and sit and talk about the the impact on
indifference graph structures that you’re enabling in the user interface and what are the performance of vacations of those grass structures and and things like that so it really depends
on the size of the team and as the team’s grow that the rolls 10 split out a little bit more where I saw it on a very small team check Lee County does everything that’s
it’s kind of a bit needs a strong technical understanding and Leadership voice.

Christian Mccarrick:
[21:03] You’re one of the things you mentioned earlier in the show a little bit about the importance of culture in an engineering team the importance of.
On the challenges to of leaders trying to nurture that type of culture,
about importance of a leader in helping to define the culture of an organization and when to use the word culture.
I know I’m not every time I talk about your ping pong or happy hours without Servicing.

Eric Elliott:
[21:36] Another man.

Christian Mccarrick:
[21:37] Yeah I think you know culture and values sometimes being in your world and put it in your mind what defines culture for you it is as it relates to a company and then in your organization.

Eric Elliott:
[21:48] So cultures really that the tone of interactions on your team a guides.
This people are starting point where they’re all on the same page about the things that they value the things that you’re trying to accomplish together as a team and I’m not talking about short-term goals I’m talking about
long-term aspirational this is our character that we’re trying to build right and.
There’s a right way and a wrong way to do culture there’s you can apply a whole bunch of processes and create a bureaucracy that’s a form of culture.
Right where at this is how we do things here we have this form formed 23A that you have to fill out before you can create a gif get Repository.

[22:36] So his process culture and then there’s just like,
the tone of this is how we interact and how we collaborate that these are the things that we value in terms of our interactions and what are the things that fits,
really sets the tone is early on
in the establishment of the culture you can show the employees that you value their contribution and you value them as human beings not just as employees right and I think.
Sets a tone that they can really reverberate in a really strong way and
you don’t do that by saying we value people and hanging that plaque on the wall all right it’s not a slogan
right it’s something that you just have to do so for example when you hire a new employee you don’t try to lowball them when they come on you don’t you know ask them what was the what was the salary you made at your last job
and then try to give them like 10% on top of that you pay them fair market rate whatever that market rate is even if it’s 100% more than their last job was.

[23:47] And this shows you that it shows them right away out of the gate we respect you as a human being and we want to treat you fairly and that’s in our our cultural DNA is an organization and.
That’s just the way we are here that’s the way we do things here we treat people right.
From the start and if you have a culture that doesn’t do that the tries to instead exploit people,
then what you do is you if you try to for example with the salary try to undercut and pay them as little as possible,
to maximize your budget right you’re shooting yourself in the foot because that person is going to feel undervalued the moment they figure out that’s not a fair salary and they might know it right from the start,
and they might it might set the wrong tone right from the beginning of the relationship where they’re feeling like well this company’s kind of cheating me but I really need this job right now so I’m going to take it anyway.
Right and that’s not the kind of relationship you want to establish at the beginning of an employee relationship.
So at culture is not about what we say our values our culture is about what we do.
Scultura something that we show and demonstrate not something that we like right down in a rule book and say read the cultural book.

[25:10] And it’s only by repeatedly showing in demonstrating what your values are that you build a real lasting culture.

Christian Mccarrick:
[25:17] Are some things you have to go online you know you can find the number of teams,
engineering teams they put together an engineering Manifesto,
are you can you just put things on a wall like inspirational posters and suddenly yeah you can know this is it this is our is our effort for our.
What things do you think one you think it is important and helpful to codify a little bit of your culture and then what are the things that you might want to put in there like treating people fairly if you want to sing.

Eric Elliott:
[25:54] Absolutely right it down
and put it in I like to create a git repository that’s all about our engineering culture and and what are the things we value and what are the some of the things that we do to reinforce that culture so for example Friday’s can be learning days free learning dates where people are not pressured
two to work on the the assignments they’ve been given in the issue tracker instead they can work on whatever it is they need to learn.
To get to the next stop or whatever they feel passionate passionate about in the in the in the Moment Like Google’s 20% time,
and that gives people permission to learn on the job.

[26:35] All right and that those are things that you can put in a git repo and say this is this is here but then,
writing it down is not enough you still have to when Friday rolls around you still have to say it’s Friday feel free to work on your learning work on your personal projects and,
and do the things that you need to do to learn in progress as a software developer and,
it’s not until you’ve done that repeatedly consistently again and again week-over-week over months and months even through the times when there’s a crunch time and Friday still runs
Friday rolls around and you say I know it’s crunch time but remember you’re learning but remember this is a free day for you you don’t have to,
Rush on these particular job and it’s only at that point that people really start to believe.

[27:28] Okay they they mean this when they say it this is really part of our culture right.
And you have to reinforce that even if it’s a freedom that you’re giving somebody you have to reinforce that freedom and remind them to take advantage of it like for instance,
if you offer if you offer vacation time unlimited vacation time it’s not enough to just say we offer unlimited vacation time,
but you should also figure out are they taking their vacation right and if they haven’t taken a vacation you know chimed in and remind them hey it’s been.
It’s been 18 months since your last vacation do you want to take some time this is this would be a good time for us if it’s or or ask them like is there something that you’re interested in going and doing and let them give them permission.
To leave the office and enjoy their freedom right and it’s only through reminding them that they have permission to do that,
then it stops being an instruction in a book and it starts being culture.

Christian Mccarrick:
[28:33] Absolutely what are the benefits and that you see of having a clear culture and values for an engineering organization weisenborn.

Eric Elliott:
[28:45] What’s important because if you don’t have all of that then people are going to pull the culture in different directions and so for example.
Somebody might really value top-down hierarchies and and instructions in strict rules whereas another managers more laid-back and and,
so number one anybody jumping between those teams would feel like this discongruent be like this mismatch right.
And and they’re not getting a sense of we have a culture here that needs to be respected instead you get like.
Thousands of little tiny mini cultures.
And that’s where you get really big politics problems because the different leaders were pulling the
pulling the organization in different directions have these agendas to protect their little mini culture and it becomes like little fiefdoms that go to battle.

Christian Mccarrick:
[29:48] Yes.

Eric Elliott:
[29:49] Especially as the organization grows and I’ve seen this happen large organizations in the Fortune 500 space and larger organizations if they
they develop all these little tiny pockets and people develop loyalties to particular leaders in the organization that and they’re all kind of competing they’re all pulling in opposite directions culturally.
And that Causes Chaos.

Christian Mccarrick:
[30:12] Gastly.

Eric Elliott:
[30:14] So it is important to as an engineering leader especially in the in the sea level of an organization like a VP of engineering something like that.
You really need to you really need to set the North Star and get everybody pushing in the same direction.

Christian Mccarrick:
[30:36] One of the things that I’ve I also think that’s important to an eight and I think you’ve mentioned this before is.
The Importance of Being able to also reduce the set of the cognitive load on on your engineers right so you know they don’t have to you know they don’t have to make micro decisions all day long if they know.
You know where or were they know clearly that this is our Northstar as you mention and I know that if I had to choose between a or b a certainly aligned a lot more Thorn or Star there for the decision is lot easier for them.

Eric Elliott:
[31:10] Yeah exactly and what are the things that that that has worked really really well in places like for example.

[31:17] Google’s famously has this don’t be evil Mantra right and in the early days of organization people would sit there and debate is this evil right,
and and that would be the deciding factor in whether or not they do that thing.
And I’m not really that really works like as as as much as we can debate whether or not Google is evil now.
It helps their engineering teams it helps their teams.
Make decisions and it gave them some kind of guideline and roadmap for like this is this is the direction our leader would take if our leader was faced with this particular problem,
so that’s also one of the things that is important with.
With building a culture and reinforcing the culture you can’t just put it in a book like I was like I said before you have to reinforce it over and over again it’s a repetition game right that’s how culture becomes culture it,
gets repeated and spread and and and it goes viral in the organization right yeah.
So as a leader it’s your job to make sure that everybody knows that this is these are the values that we follow and it’s not Justa and you have to repeat it all the time it’s not just something you can say and walk away set it and forget it.
Right it’s something that you have to continually rally the troops around right so as a leader we’re kind of like them.

[32:43] We’re kind of like the the support infrastructure for,
for the decision-making processes that are teams employ and those can be people decisions or technical decisions it doesn’t matter right but we build this Foundation of.
These are the things that we value this is the direction we want to be moving in so pick the things make the decisions that move us in that direction and that’s how you scale yourself right you basically,
that’s the best way to clone yourself is to teach people how to make the decisions that you would make in their position.

Christian Mccarrick:
[33:19] Which comes another point to it so it’s not only enough about giving them.
Information to be able to make a decision it’s all about giving him the authority the autonomy and empowering them to be actually go and make that decision in the metal part of your culture.

Eric Elliott:
[33:38] Yeah exactly.
Exactly so yeah that’s a really good point and in some organizations there are so freaking Apple.
Netflix is a famous example that they have a culture deck there’s another one of those are one of those teams right and and Netflix
what they do is they hire smart people,
and then they give them the authority to make good decisions and then they just get out of their way and let them make their just those decisions and I’ve done that same thing on all of the teams that I’ve LED since the beginning of my career and it’s always worked out well.
And I’ve seen teams that don’t do that that are more authoritarian that that have really weird policies about
how to ask for vacation time in and how to request time off and this is this is exactly the kind of policy that leads to people lying about their dead Aunt right six times she’s died six times this year.

[34:41] It’s because if you don’t trust your people to be autonomous with their their time and their decision-making process so I really believe in time Freedom number one right.
I believe that if you don’t give your employees time freedom and time flexibility it’s going to eventually lead to Mutiny or they’re going to leave your.
They’re going to leave your company for a greener pastures it’s just a matter of time before they find a better deal in Jump after 9 months on the job instead of instead of hanging you in with you for 9 years.
What are the things that leads to that is they need flexibility and a lot of companies.
Set up all these policies to protect themselves from people taking advantage of company time will that’s your hiring the wrong people if you think you have to do that.
Rights of the right people are the people who,
I get excited about the project and they want to solve these problems and they would be working on it for free if they didn’t have to feed their families and pay their mortgages just because it’s cool and exciting to two faces challenges with you.

[35:47] And if you’re not building the kind of team that would that would follow you deep into the woods of a new application design and and and put in time.
And and have your back,
then you’re hiring the wrong people if you’re hiring the kind of people that would try to sneak off into the different direction and get away from you so they don’t have to do any work you’re hiring the wrong people and if you accidentally hire some of those people fire them and move on right.

Christian Mccarrick:
[36:16] Yeah which is which is important so I think you know and you to bring it back to somebody said earlier to one of the things about scaling right so stealing culture scaling teens giving yourself how do you multiply yourself is really about
empowering these people so that you don’t become the bottleneck.

Eric Elliott:
[36:32] Exactly.

Christian Mccarrick:
[36:33] How do you say you coming to an organization what are ways to.
You write to change the culture to allow their unit it to make it a power like really I can make this decision what do you mean and I can still come back to YouTube how would you recommend going in and in fostering a culture of empower.

Eric Elliott:
[36:54] So you remind them so as if somebody that I trust to make the decision comes to me and asks me ask me what what should I do here.
And they have all the information they need to make the decision and they’re just asking for permission to do it I say what do you think we should do here.
And then I reinforce it I say what do you think you should we should do here you’re in the context of this thing you understand the problem and you’ve demonstrated you clearly know what you’re doing,
what would you do you give me advice what decision would you make.
And then eventually if you keep on doing that over and over again as they come back to you with more and more questions eventually they’ll figure it out and just make the decision.

Christian Mccarrick:
[37:38] Sure yeah and you know I think of you decide to do that right is if you’re giving up our organization you don’t don’t understand one for making a decision that you that you know you said that I should make.

Eric Elliott:
[37:51] Exactly and another thing is like give them freedom but also.
Don’t be punitive about mistakes to get made because there are going to be mistakes right there’s you’re going to make mistakes if you make all the decisions you’re going to make mistakes right.
Somebody somebody is making mistakes all the time right that’s is a million mistakes a day in a large organization is pretty common so.
And that’s okay right what what matters is our ability to correct those mistakes and deal with them in a responsible way once they happen and ends our ability to prevent. Same mistake from happening again.
And.
It doesn’t matter whose fault it is or her like you know what I mean like if it’s a good developer and they just happened to make it a big mistake one day,
now they’ve learned a valuable lesson and I would rather have that developer that’s already learned the lesson then fire him and get another developer who hasn’t yet.

Christian Mccarrick:
[38:53] Things you mention it earlier on your conversation you talked a little about.
Kind of the senior engineers and Dean coaching and mentoring and you had a recent tweet.
Who said great mentors are multipliers their most effective when you’re mentoring not building features and isolation.
Talk a little bit about it would explain that like how do a gamertag my scaling and culture driving like what is that how does that mean it has a help for.

Eric Elliott:
[39:25] So there’s three values when I look at an engineering organization there’s three values that I really want to see in the developers on the team I want to see the ability to solve problems I want to see some sharp skills
and I want to see mentorship like.
Mentorship is a skill that everybody needs you need to be able to accept mentorship and you need to be able to be a good Mentor when somebody comes to you with a question and a learning opportunity.
So mentorship is a great way to scale everything on an organization right gives people,
the knowledge sharing capability to spread the the valuable engineering knowledge not just engineering knowledge but also domain knowledge of your,
particular domain so that the business logic and and what’s important to the customers and things like that that all falls into a situation where,
you have these people who have a lot of that knowledge and some other people who have less of that knowledge and you need to build a transfer those those skills across,
write any need to be able to transfer their problem-solving abilities across the organization.
So it’s really diffusing normally there’s there’s kind of.

[40:43] There’s a power law distribution of skills and knowledge across your organization so a handful of people have the bulk of the Knowledge and Skills.
That’s the default that’s the default so a handful of people are going to be 10 times more effective,
at a lot of things in your engineering organization and what you want to do if you want to defuse that knowledge so that instead of ten times it’s now two times right,
or or a one and a half times right and you can do that by building a really great mentorship culture on your team’s where there’s time allotted for mentorship every week,
so your employees have the opportunity to pair up with mentors,
and learn something and there’s a dedicated time to that so like on their Fridays they could spend an hour working with the mentor,
and then an hour mentoring somebody else in the rest of their time building whatever they want to build.

[41:41] And that kind of leads to a situation where these skills get diffused across the entire team instead of,
aggregated under one person who’s now a few roadblocks right like every up the bottleneck that everything has to cramp through.
Now there’s a lot more people that can solve the same problems.
And that’s that makes those those people really great multipliers because they lift the productivity not just themselves but the entire team gets elevated right and psyche,
when you when you feed a great mentorship program on your team everybody on the team gets much much more effective including the mentors.

[42:24] Because they solidify their skills not only do they solidify their skills they solidify their communication skills.
Right and that makes them more effective developers and Leaders with better communication skills they get better at at disseminating ideas faster,
and they get this is a continual process where they they practice those skills
all the time and they get better and better over time and an interesting thing is like a junior developer can get into a team where there’s a really strong mentorship culture,
and they can be contributing at the level of senior developers far far far beyond their their experience within a few months.
Like six to nine months they can be like contributing as well as people who’ve been on the job for years like a first-year junior could be contributing at the level of the 3rd or 4th or 5th Year.
Developer and that happens within the span of a few months and that’s just like amazing to watch those transformation.
But it doesn’t happen if your team is all siloed and everybody’s just working on their problem and not communicating and not doing total views and not doing mentorship that stuff all stops dead in its tracks
and then you get a team that just doesn’t move it doesn’t progress it doesn’t get better over.

Christian Mccarrick:
[43:43] Yeah I think one of the one of my pet peeves to is is listening to someone say you know what I can do it quicker myself I don’t have time to do you know train person expires e.
And nothing gets me like cuz that is then that is a scaling anti pattern right there it’s like.

Eric Elliott:
[44:02] Exact exact.

Christian Mccarrick:
[44:05] 750 good analogy once were they were it’s like you’re running next to your you’re holding on your bicycle and you’re running next to it but you’re not take the time to stop and get on the damn thing because then you’ll be able to write sandwich in faster and longer.

Eric Elliott:
[44:20] Exactly exactly anytime you say I can do this faster myself you’re missing the opportunity to paralyze your ability to make progress.

Christian Mccarrick:
[44:30] Exactly that’s it.

Eric Elliott:
[44:31] So you’re making progress in cereal when you could be making progress in parallel.
And that’s ridiculous another thing about mentorship though is you can’t just stop at the junior developers write your senior developers also need mentorship but who’s going to Mentor the mentors.
So it’s a situation where if you want to build a good mentorship program you can’t just benefit only the junior is coming in early the mid-levels coming in.
You also need to benefit the people at the top of the engineering knowledge new organization and.
And it’s really hard to do that it’s much harder because then you have to go beyond the bounds of your employees your employee pool right and you have to reach out a special on small teams particularly,
you have to reach out beyond your organization,
and I couldn’t find that I was looking for I was looking for solutions that problem and I couldn’t find it so so we actually build a platform exactly for that it’s called Devin anywhere. IO.
Where you can you can sign up and will pair you with a mentor a senior-level mentor who can mentor the mentors,
who are who are who can mentor up to the.

[45:44] Chewy they can start mentoring senior developers Junior developers or or even like the leaders in the organization so.
And those kinds of mentorship relationships are super valuable because at some point.

[45:58] Your team is going to progress in progress up to the level of your most senior developers and then it’s going to hit like a ceiling.
Where it’s it’s impossible to get farther will not impossible but it’s much much slower going after after you hit that point and then.
If you want to lift that ceiling you have to go beyond.
You have to find somebody with the skills that can lift even more so at and mentorship is really critical like the the founders of
Google they didn’t build Google all by themselves I mean they did a lot of the work and I don’t want to discredit them for anything but they also had mentors,
write two came in and and and
talked these young founders of this little fledgling search engine through a lot of things about how do we build an organization and and how do we build an engineering culture and things like that and a name,
the sofa example one of their mentors brought in the idea of okrs into their organization in in Google,
I successfully used okrs for a really long time,
and they’ve done really well with it right so those are those are objectives and key results right and that’s been a phenomenal thing for for Google,
over over the last few decades right and then that’s something that I meant were brought into the the situation they didn’t,
I didn’t know about okrs before when they were just getting started.

[47:25] They were lucky to connect with a mentor the new about them right at the beginning right but yeah there’s a lot of things that that were fit.
Made the difference that really that really help the organization be better,
are things that mentors brought in the leader of HP how to Mentor the like Bill Gates had a mentor right still hasn’t been to a right,
all these people they they achieve these Great Heights but they don’t do it alone.

[47:57] They do it with with help from someone who knows more and.
I think that’s a problem in Engineering in particular because there’s so many autodidacts that they teach themselves.
Right engineering at and is so prevalent in the community and we tend to undervalue mentorship.
And it’s really one of the biggest biggest multipliers available and in terms of your productivity and your ability to progress friend since like I was I was self-taught.
Developer I started when I was a kid making little video games and I didn’t have a good Mentor teaching me all these programming capabilities I did like get all that from books and stuff but it took me.
It took me more than a decade to learn some of the some of the really core critical concepts of of application building like a particularly,
compositional patterns in things like that how to how to fit the pieces of an application together well it’s a decade to learn these things
and we teach them to mentees and their first few sessions right so it’s like this.
Magical amazing like shortcut to the Fast Lane right on getting up to speed and becoming a really great developer and you completely miss out on that if you don’t build a good mentorship culture on your team.

Christian Mccarrick:
[49:19] Yeah. It’s such an important thing and I think the the building that mentorship program to also enables you to.
Raco and higher same or Junior Engineers or straight from University allows you to.
Tubing you know help with the kind of the diversity Honore organizations by bringing people from maybe non-traditional backgrounds like codecademy is another thing so yeah it’s super helpful.

Eric Elliott:
[49:47] Yeah yeah and there’s just there’s some things you just can’t do without a mentorship culture like for instance.
If you have a if you have a good mentorship culture you can have you can’t hire a junior developer and trust them to work on on a critical product
Right Where I Was You wouldn’t want to put a junior developer on a mission critical product without a good mentorship culture because they can do more damage than good.
If there if they don’t have the proper guidance they can take in litter your codebase with time bombs that are that are going to cause real problems in production.
And so you can just can’t do that
you can’t you can’t put a junior developer on on mission-critical products without a good mentorship program you can but it’s not going to go well for.

Christian Mccarrick:
[50:34] No no.
Certainly not at all no one of the things to I want to I ask all my gas is,
aside from I think you mentioned a couple things already resources and I’ll make sure I try to put them in the show notes on simple leadership. IO,
any other resources you would recommend for managers your leaders when it’s books conferences blogs videos anything that stands out for you.

Eric Elliott:
[51:01] Shirts I think I mentioned the Phoenix project earlier that’s a great book that I think every engineering leader should read if you have it I know it’s cited a lot of people say hey check this book out for good reason if you haven’t read it yet definitely read it.
Other than that I think just just start today like building a mentorship program if you don’t have a good one at your organization.
And and build a mentorship culture and make sure that you’re practicing reviews so design review where you go over the the mock-ups and you make sure they make sense,
Speck reviews I do things I do rtd’s Witcher like read me to driven development for our technical
designs so we talking about like API designs and things like that we write them up and read me before we start implementing the code and then we review the read me before we start writing and I saved a lot of real.
And and tdd right test urban development is really really important and.

[52:08] Once you got all those things down you need to,
you need to learn how to compose software how to put together the application and in ways that that makes sense right
so topper composition is a is a topic that gets very little attention that should be like the foundation that everybody learns before they write like their fight V line of code,
and what I mean by that is things like function composition and object composition data structure composition
process composition you need to have a good Mastery of those things to be a master programmer you you can you can get things done without knowing these things well but.
But you’re not going to you’re not going to write the best code right you’re going to write too much code,
and it’s going to be overly complicated because you’re trying to put things together with duct tape and crazy glue when there should they should just be like stopping together like Lego blocks.
So I wrote a book I just finished a book recently called composing software that that you should read as as an engineering leader not only read it but also share it with your developers on your team and make sure that they know these things.
Because their critical skills that they get overlooked way to way too much.

Christian Mccarrick:
[53:24] Sure now great crate and I’ll make sure I put all these I don’t mention in our conversation today on our show notes if all the listeners out there definitely some great resources come check out some Blue Shield. IO,
for this a conversation and you can find links to those.

[54:08] Eric I greatly enjoyed our conversation this afternoon and continue it offline to at some point of future but thank you very much for your time.

Eric Elliott:
[54:17] Likewise no problem.