Host:
[0:04] Good afternoon James welcome to the show.

Guest:
[0:07] Hey thanks for having me.

Host:
[0:08] Yeah absolutely so James I wanted to start off a little bit and some of our listeners are always interested in learning a little bit of background of who my guests are on the show.
So if you could not go through a whole list of a CD but just to the highlights of your background.
A little bit of the kind of education and how you can get up into the job right now and Amazon.

Guest:
[0:30] Sure I’m so.
I graduated from the University of Arizona native Tucson in Tucson Arizona graduated from the of a with a degree in computer engineering which is kind of a cross between software engineering and electrical engineering mixed.
And minors in computer science and math so I always knew I wanted to go into software but I wanted to know a little more about the hardware primarily just to help my programming.
I entered the workforce and went into IBM,
worked on some pretty low-level device driver code for enterprise-level dis storage did that for about 6 years and then made the jump to Amazon.

[1:15] Join Amazon in Seattle I’m coming up on eight years in Amazon I’ve worked in Amazon web services I worked in retail and fulfillment and specifically fulfillment software.
I joined Amazon as an industry higher but was promoted to senior developer and have been a senior developer for several years.

Host:
[1:36] Great great interesting going from Sunny Arizona to Seattle that must have been a little bit of a shift.

Guest:
[1:42] Yeah believe it or not having been raised in Tucson it is actually possible to be sick of the Sun so so far so good rain is still magical to me crank up in the desert so.

Host:
[1:55] Yeah yeah she’s looking at our window the office is here and I’m based in San Francisco and it’s her every three years or so it rains in June and it’s actually kind of a rainy day here in the bay.

[2:08] So interesting in your team now would it what kind of team we are on now and how large is it team.

Guest:
[2:13] Yes I work in the Fulfillment software area,
my team has grown since I joined it I joined and it was your kind of standard two Pizza team which consists of five to eight to ten Developers,
or so plus manager and program managers however it’s the vision of the team has grown and so we’re now an organization of multiple teams,
and I served in a mentoring role to several two Pizza teams.
Ends and then I generally will focus specifically with one team that’s may be working on a very high mpact or high-risk area where I.
And part of the team and and a developer on the team,
but with mentoring of other teams and trying to make sure that they’re kind of heard everybody in the same direction at a high.

Host:
[3:07] Sure and when you talk about mentoring at your your standpoint that’s predominantly as we talked about mentoring on the coding and architecture that you can a team and project pay stuff.

Guest:
[3:20] Yeah there’s kind of the so Amazon has two piece of teams and so your team has a very strong ownership you own one or more services top to bottom,
so you generally function a little more like a startup where is people wear many different hats and although,
you’re my primary role is as a software developer I’m trying to think of things from the product standpoint I’m trying to think from the management standpoint so bit,
and everyone tries to be able to think from the different roles so that we can push on each other and make sure that we’re all,
holding each other accountable and also operating in Saline as possible but in terms of mentoring I’m generally mentoring software developers helping them with their career path with individual growth and,
and meeting hopefully reading a lot by example with my own,
codeine or code reviews and then I also Mentor teams and terms with of design so they’ll come to me with,
star all checkpoint with them at some regular interval understand their designs give feedback and try to help shape the direction that they’re going.

Host:
[4:28] Okay and is this more of a set of a formal Arrangement that is happened or did you just have to step into this mentorship role.

Guest:
[4:36] It kind of happened organically so so essentially and this is how I always suggest.
Ideally mentoring star X’s you know everybody has strengths and weaknesses and so there are certain things that you do very very well,
and they’re things that I do very very well and people just start asking how do I do that so it turned into kind of a mentoring relationship of how do I do that and.
And trying to help them to grow themselves and just share my strengths essentially with others,
and then I found myself repeating the same things over and over and over again and so then it started becoming that’s where my blog came from.
What is just a way to scale and now I can just refer them to different blog and trees and which saves me time.
Then you know having all of these different teams as organization grew and having all these different teams,
I saw things going in kind of Despair directions and I wanted to,
preserve the two Pizza team culture of teams are are autonomous and they can set their own Direction but I also wanted to be able to check in with them and so,
the mechanism I found it worked for that was these checkpoints so I formally set those up.
I need a very clear to the team I set some ground rules that you know they own their software they own the path forward I’m there to help in any way that I can and.

[6:08] You know hopefully my experience is something that they do find valuable and helpful but I also find the time valuable because I get to learn about what they’re doing learn about Technologies they’re using that maybe I haven’t you so it’s I tried to keep it very much,
a two-way conversation as opposed to being any kind of gatekeeper role that would slow people down.

Host:
[6:29] Sure and you know where the questions I have is well and is of a sea company scale and grow.
A different people step into univariate needed leadership roles what is the how do you differentiate between should of the manager of the teams and what you’re doing is this mentoring technical leadership role.

Guest:
[6:49] So for me the managers,
are really focused on the business especially product management program managers their their focus very much on,
the business so what are the business problems they’re trying to be solved really trying to gain a deep understanding of,
customer in their needs and then communicating that back to the development teams some my rule is.
Is different so it Amazon everybody tries to be customer obsessed.
So we tried very hard to understand our customers everybody does however developers I guess.
The where it’s separated is managers are very concerned with the business problems and then on the development side,
developers are coming up with the Technical Solutions to solve these bananas problems and a big part of what I do and what my role has grown into is.
Is not only coming up with a solution to their problem today but trying to come up with a solution that’s that’s.
Extensible enough and I slay it’s extracted enough so that as new needs a new asks come in we can.
We can add to our solution and away that where it stays maintainable and it still makes sense.

Host:
[8:16] Invention said of customer-focused and customer Obsession I believe that that’s one of the Amazon principles is it on.

Guest:
[8:23] Yeah absolutely it’s the first one.

Host:
[8:25] First one so tell me a little bit because we can talk about your blog post how to set techno direction from your team which is which is actually how I found you to be on this on the show you mention the Amazon leadership principles.
Hey give me a little bit of an overview button to say going to detail everyone but I know you mentioned two of them that are important in this technical Direction in your in your blog post.

Guest:
[8:49] Sure so yeah Amazon has these leadership principles and one thing I say in my blog entry that really holds true for me is,
yeah I’ve been I’ve heard from others and I’ve also been at companies where their corporate values or principles that really are just.
Kind of these very kind of platitudes that are maybe put on a poster and stuck on a wall somewhere and.
Nobody really looks at them and they don’t necessarily make a big difference in your daily activity at work and.
The thing that really strikes me about the Amazon leadership principles is that we live and breathe them everyday,
the we literally use the phrases you know customer Obsession and bias fraction and earn trust and we we use them in Daily conversation they just,
are interwoven throughout every team at Amazon and that’s actually,
very important because Amazon to highly decentralized company so in order to have some semblance of,
organization among the chaos there needs to be some common thread between them and the leadership principles really are that,
and they really coming from I believe they come from the behavior of.
Jeff Bezos himself and kind of some examples they said and then overtime have grown into a way to,
scale this this behavior in the stock process.

Host:
[10:18] Sure you have and I think that’s an end and I agree with that concept of whether it’s your leadership principles or some teams or companies have met efestos and it’s just something really to help drive that that culture in and you really feel that that.
Those leadership principles really helped Drive the culture there and Amazon.

Guest:
[10:35] Definitely I think they’re critical.
They’re critical to making sure that you know things like customer Obsession things where we’re yes we may look at what competitors are doing but we obsessed over customers end.
Problems that they have now and even solutions that they don’t even know they need right we’re just trying to advicate one thing that said,
frequently is,
that in the most important person in the customer is the one person who’s not in the conference room as you’re there discussing Solutions and so everyone needs to do their best to try to advocate for that person who can’t be there directly.
So that’s an I think again that comes straight from Jeff himself and and we work backwards from the customer and try to do the right thing for them I also think is.
Does an online company as as a company where it’s.

[11:34] You know I think with the internet today with security concerns with privacy concerns with with those kind of things you know really trying to put yourself in the shoes of the customer and do the right thing for the customer.
One thing I love about being here as it creates the right incentive your you’re really incentivize to truly do the right.
Or do your best to do the right thing in so that’s very rewarding.

Host:
[12:00] And you know the title of again your blog post to how to set the technical direction to your team.

[12:07] I’ll send you know it I think it’s also important to set that the trucks are not that technical direction should also stem from set of the company goals and Direction know how does that information flow with you and how do you translate that.
Business Direction into your team’s technical Direction.

Guest:
[12:25] Yeah so again that comes back to kind of the roles managers play versus developers so the business direction is something that.
That management really owns they own they want to make progress in a particular business they see an opportunity or they see a way to expand,
in a particular Market segment for example and they bring the problem and they bring in the also they kind of do the so in this blog post I talked about having a long-term Direction and then a short-term.

[13:00] Deliverable and then you need to have both and you need to have that balance and from a business standpoint management needs to provide that they need to provide here’s the direction we want to go.
It for this business but here’s a short-term way that we can see that we can accomplish that maybe here Step 1.
And then on the technical side for developers I traded.
Take both of those inputs and then turn that into a technical Direction which to me is a solution and the long-term it includes a long-term architecture.
You can see will be able to meet kind of those long-term needs and ideally be flexible in the right places,
I’m so it’s always a tough balance trying to not create the solution that,
trying to solve everybody’s problems right you have to keep it constrained but something that is directional and seems to align with the business direction as well and then.
But then provide that short-term solution to the business step one that they gave you.

Host:
[14:11] Correct and I like how you do both for your short-term and long-term goals section that you have is talking about tying in that that.
Business and why you’re doing it and then the business wins as well as that the technical wins for doing it doing I think so often especially in in Silicon Valley.
People sometimes tend to do technology for technology sake without necessarily tie not back into any of the business need or the customer Improvement.

[14:38] Technology will actually enable.

Guest:
[14:40] Yeah I know and I have to say you know we can be guilty guilty of that as well,
it is very very important to to tie it back to the business need there is an argument of you know I’ve seen talks from Google before where they’ve talked about having things that were,
business failures but but technical wins that were used elsewhere later,
and that’s a nice fall back but ideally you succeed in the business as well and not everybody has the same cushion that Google or Amazon especially,
startup.

Host:
[15:17] That’s right there’s not enough to the runway to be able to take those losses and build them into something else.
Know what are the things in your go-to you mention that I liked you reference to the mapping of the code base and you know how you does how you thought that was a very interesting thing to look at your tire architecture what you describe that from it.

Guest:
[15:36] Sure so so Simon Brown is somebody I will follow and he is written and given talks extensively about your architecture is code and visualizing architecture as.
Maps of your code beso.

[15:54] You know the Hallmark of an architect is that you can draw rectangles cylinders and arrows although a picture’s worth a thousand words.
It’s not very useful if many people look at the picture and they all come back with different a different thousand words right so it’s.
A pictures can be valuable but.
It’s also incredibly hard to draw one picture that effectively communicate CR architecture too many people and especially as your organization grows you really need that Clarity so so.
Simon Brown’s concept is nice because it just admits that you can’t put this all in one picture people will not be able to really,
Queen all the information you’re trying to convey so he views it kind of like Google Maps where you,
depending on your level of zoom in and out you’ll see different levels of abstraction or detail.
And so I love that concept and I use that in my architecture diagrams to try to simplify so you started this high-level where you just show the system as one block and you give context,
score of the key actors and dependencies on the system then you zoom in and zoom in and zoom in and you can communicate different things so,
so I really like that concept another Concepts that I haven’t blogged about yet.
Did that in turn away in Amazon but haven’t put it externally one thing in Block diagrams is near the arrows represent relationships but I frequently see a lot of diagrams with arrows and the arrows aren’t really labeled.

[17:36] And so it can be confusing what the exact relationship is and and one trick that seems so simple when you when you say it.
But the trick is to label the arrows so what I like to do is I think of the the blocks are components as nouns.
End in the arrows are the connectors right and so they should be like a verb or an action and I actually will create diagrams where you can read.
If you follow the arrows you should be able to read some kind of logical sentence in,
and that’s been very helpful for me because again it makes it so that everybody or most everybody is taking the same key conclusions away from your picture.

Host:
[18:28] And you do mention about that communication and.

[18:34] Communication I feel whether it’s in management weatherton mentorship whether it’s in the setting Direction Four teams having a Common Language a common scent of syntax and vocabulary as well as.
Have you tell me how how do you help on a communication level.
Drive that that level of direction is it written like you’re talking about in his block diagrams is it is it codified in in Wiki’s or do you have gift talk so tell me a little bit how the medication flashli happens.

Guest:
[19:05] Sure it’s generally a mix of a of a few of those things so I will write documents.
As a developer I prefer documents that are.
That are in a place that are very easy for people to access internally we have Wiki’s and systems like that that are fairly easy for people to access so I like using that as my medium and.

[19:30] All create documents that are essentially that architectural Vision that kind of long-term vision and then there’s a document that’s the short-term detailed this is exactly what we’re going to do and,
in that,
long-term Vision document for example I do include these different views of the system like the map of the system and then try to put.
I tried to put key overarching design points the thing that strictly about the long-term vision is that your design points need to be things that are relatively stable over time so what are the,
what are the big for example what are the major components of your system what are the big roles that they have in the system,
that’s what I’m trying to establish in the long-term Direction so.
Those kind of key tenants or design points I try to put those in that document that I try to follow him up with these different views where I present the picture and then I put some bullet points under it that,
honestly when it comes down to is they should essentially be if you were reading the diagram and reading those the labels on the edges my bullet points generally tend to just be those because your picture should communicate those key.
Relationships and key Concepts and key interactions so,
I just reiterate them in bullet points I’m a walk through kind of a high-level use case to,
again the whole point is to try to establish what are the key components of the system and how are they going to interact to provide the solution.

[21:08] And so I’ll write that document I don’t like to write that in.
And isolated siloed kind of environment so there’s usually working sessions where I’m working with maybe key developers & management as well,
and we’re having working sessions where we’re discussing through and then the document is kind of a artifact of that we’ve all,
talking kind of agreed on this this solution and then after that then I’ll share it with the larger group.
And I generally will call meeting with the larger group and kind of walk through the documents and,
answer anyone’s questions and add their questions to the document I always have a section for open questions and answered questions or fa q’s and try to.

[21:54] Make sure that the picture makes sense to everyone on the team and that there aren’t any major outstanding questions.

Host:
[22:03] Sure and you do mention that.
Amazon teams are fairly autonomous how do you deal with really cross have any cross teamtalk dependencies and how does that communication happen as it as it relates to preserve any technical kind of interfaces.

Guest:
[22:20] Yeah that’s it it’s actually a it’s interesting because as a decentralized company.
It’s a conscious decision that there will be a trade-off.
Where in order for teams to be autonomous coordination cost between teams are surprisingly expensive.
And not in a way that’s easy to see initially and easy to measure and so sometimes it is the right decision if a team has some component that.
That has been in production for a while it’s table it’s common it’s exactly what you need absolutely take it use it that team will be very happy that they have other users,
as well however it is common to also get some duplication happening where team decides you know I don’t need,
that. I just need this little thing to get moving and your team’s directions kind of different from mine so I’m not sure that I can,
that rely on your team to to change your software a little bit to fit what I need so,
so I might just build it myself and in order to move so that’s a conscious trade-off that’s made that does happen that can be a little,
shocking refrigerating to engineer Sue first come in to Amazon and but again it’s that,
that coordination cost is very expensive however sometimes you need cross-cutting or sometimes it just makes sense to collaborate with other teams and actually that.
That long-term Vision has been extremely helpful for me to to.

[23:56] Establish where that commonality is because if you show that to a team they may not.
Like they may not see alignment in your first step in what you’re doing but that long-term view I’ve I’ve actually very successfully use that before too.
Other teams bought in.
Saying oh I like the direction you’re going it actually aligns quite a bit with ours maybe if we tweak it a little bit then then we’ll be fully aligned and we can collaborate on this so so that long-term vision,
has been very effective for doing that.

Host:
[24:32] Good and you know.
From switching from your long-term section you had in your blog post over the short-term at one of the things you have in there is your impact forces effort Matrix and I think a lot of people are familiar with that.
Very squadrons high-impact high-effort low-impact lower Ferdinand and go and so on how do you decide then with the managers about what’s working you know how do you get.
Movement to momentum you know on those high impact low effort items.

Guest:
[25:04] Sure I’m it comes in different ways.
Again there’s that bias fraction leadership principle sometimes there’s just a little bit of it just do it,
is a senior developer sometimes I’m if I’m trying to organize a larger effort,
and I’m not on a specific team sometimes that is what I end up doing if I see an opportunity for something that seems like low-hanging fruit,
I think a valid criticism of this is yes that makes sense but it’s not always easy to understand what is higher for low effort and what is high impact especially the impact right.
In understanding what that is and so is senior developer sometimes I will do what we call a spike.
And I’ll try to create a quick prototype essentially trying to test the hypothesis that we believe this is high impact,
so let me do a Spike let’s test it in a in a simple way with maybe a very small set of users and try to understand.
Whether this is worth going after whether it’s really as small as we think it is or whether it does have any impact we think it does.
Before investing heavily into it so so having an individual is just motivated to do that in allowing them to do that spike is very valid for Gathering more data.

Host:
[26:25] Did you guys have the autonomy in your teams and the authority to do these small proof of Concepts that might impact maybe half of a percent of users what not actually put them in the production.

Guest:
[26:34] Yes I mean you have to take the appropriate so there are you know we definitely have a be testing kind of infrastructure that allows you to,
put these in and turn them on for a certain percentages of users so that’s incredibly useful that for limiting any kind of blast radius we do have a culture,
man it is very SWAT teams but all the infrastructure is in place for you to have very high,
QA like automated testing and quality to minimize any impact of just breaking,
regular functionality by making these changes it goes it depends on the team it depends on what they’re road map is I’ve found you know the,
The Talented managers are the ones who can effectively balance the two I go at their team go off and try to spike of something.
I’m putting General Amazon as a company is very tolerant of experiments and in Failure as long as you learn from it.

Host:
[27:35] And it doesn’t take the entire site down.

[27:40] Failure within reason.

Guest:
[27:41] Yeah.

Host:
[27:44] What are the things to you that you talk about that I think I I see all the time too is this concept of analysis paralysis right where as a leader.
I often times over I’ve experienced overtime my career you get teams and they’ll argue or argue discuss heavily various framework or Direction and at the end of the day.
They could have gone either passed and I probably would have had almost no difference in the outcome right now how do how do you.
I deal with certain as it as a as a kind of leader on your team’s getting people over that analysis paralysis and actually getting to make a decision with wood tools you have for helping your teams do that.

Guest:
[28:24] Sure a couple things so the long-term that is the one thing I hope that I don’t know that I got through very effectively in this blog entry is that.
The long-term vision is the main focus of it is directional so don’t get stuck on it it’s something that,
you can rat hole on it and you can go forever and ever and spend on it and I try to time box that effort and say okay long term are we directionally A-line do we kind of all understand where we’re going just trying to draw the,
big lines between certain components this will do this and it won’t do with this other component does because,
x-rated just defining those things,
but then quickly moving on to okay what are we actually going to deliver what’s the short-term so so the long-term vision is.
Very easy to get into that analysis paralysis face because it’s just too murky you can’t solve all the problems for the next 5 years now it’s not worth it,
for the short-term the other place I see analysis paralysis is where.
Where there are unknowns and risk where nobody can agree because we just don’t know and.
And one of the most effective directors I’ve worked under with he was so great about just saying.

[29:51] Was just try it.
That spirit is what I’d like to do to try to break that you you have,
rough solution this is what we think we’re going to do this I think we can put these existing funds together in this way to solve this process,
but they’re you identify kind of these big unknown areas and ends rather than debating endlessly on something that.

[30:21] No one will really know the answer to until you do it I prefer prototyping and I mean prototyping in the true sense not something you hack together and then put into and then somebody,
there is in production and then it becomes your production product but but.
Read to me a true prototype is where you have a it’s a scientific experiment is where you have a hypothesis you build the bare minimal thing to test a hypothesis and then and then.
Try it and then probably throw it away so hopefully throw it throw it away if it’s literally thrown together.
So there’s two levels of that right so your short-term.
MVP your business deliverable that might be testing a business hypothesis but you need to build that with quality.
Because you’ll just you’ll tamper with the results if you have bugs.
That’s the best way I like to cut it you won’t be able to get a good data on whether your hypothesis was right if it’s full of bugs and maybe the user is not.
Not hooking on to it because it just doesn’t work right and so that needs to be just fine yeah so that part needs quality,
however the hypothesis I mean is more of a technical concern like we think this dependency we think that this service that this other team has can do what we need,
let’s write a quick set of integration tests and simulate what are what we’re going to do with it and make sure that’s true so that’s more what I mean by prototyping is just.

[32:00] Betting your dependency age betting at certain Concepts in making sure that they work.

Host:
[32:06] I think that analysis paralysis goes from.
Down to the junior individual contributor in all the way up to corporate boards and whatnot I just reading an article this week that talked about.
What they found that the most effective CEOs do or the ones that actually not always make the right decisions but makes her the quickest decisions so that failing fast and doing the experiments to ultimately get to the right decision overtime rapper get there quicker than some of the competition.

Guest:
[32:35] Yeah absolutely in one thing I read that I loved was about.
About planes and how they course correct that they’re playing is I don’t remember the exact percentage but it’s something like a plan is off course 95% of the time but they’re constantly horse correcting right and,
as long as they’re checking frequently enough then they simulate a straight line line to the destination.

Host:
[33:02] That’s right over the large distance.

Guest:
[33:04] Exactly.

Host:
[33:05] And it going back again to your culture that the anonymous and that the two piece of teams at AutoZone.
Do you think that those leadership principles in the sense of autonomy really helps to almost Force good leadership and force people to become more effective leaders for those teams.

Guest:
[33:25] I think it does I mean so again there’s trade-offs but I think one thing that really helps is you have a lot less risk of,
diffusion of responsibility I mean one of the leadership principles is ownership that we have very strong ownership and,
an internal error software it’s it’s no public knowledge that we use a service-oriented architecture in Amazon and,
each team owns one or more services top to bottom so if you’re a Two Petes team,
you do the design ubuildit you write the test your automated testing you deployed production you and you do on call Peter support for it I mean you fully own it,
and that ownership really is very powerful in.
That because diffusion of responsibility is is where things can really go sideways,
but when you when everyone on the team feels very strong ownership then you’re going to have passionate discussions about where you wear,
it should go and how you should move in and then on top of that being the small size of the team forces you to be kind of Scrappy and and utilize your resources efficiently as possible.

Host:
[34:38] Now when you talk about some of those spirited discussions is there do your teams have sort of a final Arbiter whether it’s technical direction or you know.
Which feature something to add at one time is that serve the manager or is that a group discussion and how does that work.

Guest:
[34:55] I’m well.
Hopefully nobody has to really step in and say okay we’re forcing sometimes your manager needs to act as a facilitator and and say okay we’re going to draw the line,
it depends on the experience level of the team that that’s mostly Junior developers than the manager that the managers at Amazon are expected to be very technical and so.
So the manager can step in an active that on the teams who have a senior developer than ideally the senior developers help with those kind of making those decisions no.
So again this comes back to leadership principles there’s there’s actually one that’s called have backbone and disagreeing commit and Jeff Bezos.
Every year right space,
very well written letters to the shareholders in this last year he actually talks about disagree and commit and gives an example of him doing that but it’s a it’s not a passive thing it’s actually,
you know you argue for your point you argue.
And don’t just give in before because it’s uncomfortable or because you want to achieve some kind of social cohesion in your group like you argue respectfully but forcefully for your position.
But once a decision is made then you actively commit to it and he even gives an example of of actually saying I’m disagreeing and committing.

[36:26] Fundus ends and that’s very powerful because it does it does push you to have these.
Difficult conversations and but then ultimately be aligned as a team.
One trick that I’ve used or one tip that I have used a lot is when we get stuck on maybe we have two options and the team just cannot seem to let you know.
Cannot seem to move forward on that I like to try as much as possible to take the,
personal like my idea versus your idea out of the equation and all,
go to the Whiteboard and will say okay what are our options and will list out the options and then we’ll do a pros-and-cons exercise but the idea is to have everyone brainstorm the pros and cons for every option,
to try to remove that personal feeling of this is my idea yet,
and sometimes that’s enough and then one emerges the is the clear,
winner and another cases I think it’s Steve McConnell and Coke complete his kids this great line where he says he says if you have two good options.
Just pick one.

Host:
[37:42] Having to agree that it gets out of that again that that Perales is you have also is reading a.
Interesting article about the concept of having two different meetings when you’re really going through decision process and you separate.
The actual decision meeting from what you’re talking about or just heard of that pros and cons and that Discovery process and you you physically make them separate so that you don’t have to have that.

[38:08] Concept of having to make that decision that particular day and you’re focused really on as you mention.
Getting all the information out and then one feels I think a little bit more free if they feel like I owe this is just information or not making a decision and I have to lean one way or the other yet.

Guest:
[38:23] Yeah that makes sense.

Host:
[38:25] So when the other things too I want to get two here towards the end.
I think to be any effective leader senior Engineering Management leadership time management is I think crucial piece of of being successful at that.
I think you’ve also written in your in your blog a little bit about your your to-do list you have a tip for for handling your to-do list on a daily basis just tell me a little of the hell that has helped you to manage.
Both the mentorship you do this blog posting you do and you know the teams in the in the work you do on the teams of selves.

Guest:
[39:00] Yeah sure I guess when it comes down to is IMA slave to efficiency it’s one way that I like to put it I.
I just want to be as efficient as possible and part of that is one,
background note that I give generally is that,
my wife and I met very young Weird 19 and in college I was married shortly after college and we start having kids very quickly after that and so I didn’t have kind of the it now it’s very common for,
new developers to have a period of several years where they’re single and they can just put as much time as possible into work,
and I had a very strong desire to meet up spend time with my family and be a good husband and father so,
it force me to limit my work hours which then forced me to be as efficient as possible this to-do list that I blog about,
it doesn’t sound like much but the principles behind it are that I recognize there I can only have a certain number of things on that list,
at a time that I have a pretty hard limit of four maybe five but it generally three to four things on that list there in priority order.
And I maintain it everyday so,
it’s something that I’m I’m always revisiting am I working on the most important things in my working on the most important things and do I have too many things on my plate and if any of those things are true something has to give and I have to.

[40:36] Cut I have to reprioritize maybe talk with my manager maybe delegate if possible,
the other piece of that to-do list as I record my accomplishments for each day and they can be they can seem little but there’s,
the actually a huge psychological benefit to tracking even the small wins every day and in in my blog post I talked about how it can be used it performance review time as well as kind of a nice log of what you did.
But the keys for me are just ruthless predation and and treating your time as a very very important resource.

Host:
[41:18] And one of the things that you do mention in there is.

[41:21] Giving that sort of list of accomplishments especially the end of year review time to your boss and have to say it a listen as out there anything you can do to make your boss’s life easier at the annual performance review time is worth.

[41:34] Coming from.
Stop sides that fansite I will I will you know it’s almost like Christmas time of someone gives me some dwell formatted documents of things are throughout the year you know it’s almost subconsciously increases that.
That review slightly.

Guest:
[41:53] And along the same lines when I maintain my own to-do list I’m maintaining my own schedule essentially of what I do which is very empowering for me personally.
It also off loads work for my manager where it’s not that I’m coming to them saying what should I do what should I do I’m communicating to them,
this is my current priority and here’s what I’m doing and I’m always open to feedback and open to them coming in and helping me INRI prioritizing but I control my schedule ideal,
braids and that actually helps management because they they don’t have to handle me the whole time.

Host:
[42:32] Correct and that level of autonomy in control you have I think psychologically also is is helpful for you I probably makes you feel better about about your day today as well.

[42:43] So any one quick question about the you would you mix your serve personal to-do list and it worked it or less you have to or have you handle that.

Guest:
[42:52] Yeah I keep them separate definitely keep them separated I have a kind of a weekend to-do list.

Host:
[42:58] The honey do list.

Guest:
[42:59] Say exactly it really is really is not I’ll say I’m not as strict with the only three to four things roll either.

Host:
[43:07] Yes since you’re not the only one adding things to it.

[43:12] I might have to have an idea of a group podcast episode the future may be specifically with balancing that.
That live work balance especially with the engineers and and Engineering leaders who who do have families and I think that might warrant a whole other episode because there’s a lot of people.
That are.
Kind of maturing through the ranks and getting getting a little older and I think that would be worthwhile to hear people in Hell how will manage to do it and still be successful and sane.

Guest:
[43:43] Yeah that would be a great topic I always enjoy talking about that specially Amazon you know it it does have a bit of a reputation and and it’s,
it’s always refreshing for people when I when they see how much I’m able to get done and still have a very attractive.
Personal and social life as well.

Host:
[44:05] James any as a wrap up here any kind of last comments or thoughts that to to impart around the cert of the technical Direction and sending if your team.

Guest:
[44:15] Yeah I think.
There’s a few things so this post is kind of the culmination of trial and error in a number of ways and I have some pitfalls that I’ve definitely run into is.
You know you really need to have both.
And I’ve had situations where I just set the long-term vision and then everyone’s very excited about it but they don’t see a path there and then kind of spinning our Wheels because the maybe the other Engineers on the team,
just want to build that but that’s like a325 your project right so so both the short-term and long-term are really critical.
Being able to look at it from the business side as well and make sure that your.
Not building Ivory Towers I’ve definitely walk that line so you know and you’re not just building feel like you said technology for Technology’s sake,
but you’re also really working closely with the business and ultimately trying to solve the customer’s problem in the business problem as well I don’t know that the blog post stresses that but I would stress the system very very important.

Host:
[45:29] Great thank you for that so listeners we listening to James Hood the senior software engineer at Amazon and also a blogger.
Which I have a lot of respect for actually having that time that I should give back to the community outside of Amazon is well thank you for doing that and.

[45:49] Also any of the links we have LOL put James’s information is a Blog information links in a new social media has in the show notes that you can look at after the show how you can go visit them that simple leadership.
In this episode will be posted there as well as iTunes and you can see the.
Show notes that we have their James thank you very much again for being on the show this afternoon I really appreciate you taking the time to talk with me.

Guest:
[46:15] Thank you it was a lot of fun thanks for asking.