Episode 2 | The Growing Pains of Company Culture

Eiso: Hey everyone. This is Eiso and Jason, we're back again to talk about engineering leadership and all the interesting questions that stem from it. Before we kick it off and start talking about topics. How have the last couple of weeks been for you Jason?

Jason: Pretty good up here in Canada. As I mentioned to you in the pre-show, we got our first dose of the vaccine, so, you know, it feels good to see the light at the end of the tunnel in some ways. We also got a puppy. So we've been dealing with that, which is a lot like having a kid in some ways they get you up at night. I feel like I have another kid in the house that just eats a lot. A lot, a lot.

Eiso: I know the feeling. We have two golden retrievers here that were spaced a year apart. So I went through the puppy experience twice now having gone through the kid experience, but I guess it equally involves a lot of poop.

Jason: Yes it does.

Eiso: So maybe that's not a bad lead into the conversation starting point of today, which is "Culture: Marrying what we do and how we do it", as you so eloquently said on our last podcast.

I'd love to just start a little bit about asking you, what isn't company culture?

Jason: I don't think company culture is what has been predominantly defined by a lot of what actually gets in the common Zeitgeist attributed to culture for Silicon valley, which is the way the building looks or the furniture or those things. I think that that's kind of window dressing on a lot of the different things that go on in Silicon Valley, you know, talk about all of those things and yeah, maybe that should go into the culture bucket, but it would be the final five or 10%. But I also think that traditionally it's the easiest thing to point out and talk about, so it gets a lot of notoriety. But no one talks about your decision-making processes. No one talks about what happens when the site is down. No one talks about, you know, what's going to happen when a customer churns, how the entire company is gonna react. I mean, that's culture right there, those sorts of things.

Eiso: I had a co-founder at a previous company and he used to say "culture is what distinctly differentiates you from everybody else. And it's what makes you want to stay at a company.  And particularly, it also says who shouldn't join."  And so, talking about engineering cultures in different engineering organizations, do you have some kind of a bucketing or framework in the back of your mind from all the companies that you've seen, that you would kind of classify to different cultures?

Jason: I don't know if I have a framework, it would be loosely defined if I did. But given that your former co-founder uses a quote, I'll use one too, there's one from Maya Angelou, which I talk about generally speaking for leadership.  Everyone probably knows exactly which one I'm talking about, which is: "people will forget what you said, but they'll remember how you made them feel." And when you think about culture and you think about engineering or you think about anything, generally speaking, that's what you're actually referring to.

So, I look at  engineering product and company building similarly, which is one of the main differentiators, I think, for culture and how I would start to bucket them is maybe on the more conservative end of the spectrum or assertive end of the spectrum. And by that, what I'm actually talking about is speed. And it tends to be what you can do, how fast you do it, but then how safe you are at doing those things, because you can be incredibly fast and reckless. Or you can be incredibly conservative and safe, or you can be incredibly conservative and reckless too.

I think that, when I look at different engineering cultures, the first thing I actually look at is how many times a day are they releasing software? What are the processes for that? How do people think about bringing something to market? Do they need to analyze it and write 15 page PRDs and get 15 levels of sign off? Or can they experiment? You know, and again, spectrums, nothing is black and white, nothing is binary. You're looking at different percentages of varying degrees of any of those things. And I'm kind of looking at that, probably, to start.

Eiso: It's funny you mentioned this because right before this podcast I came off a call with one of my favorite engineering leaders who was at a high growth company where they're essentially doubling their engineers right now, almost every six months. And we were talking exactly about this. Like there's an amount of speed that you can get, but speed always comes with its trade-offs. In our business, at Athenian, we always  kind of say, you can move really fast, ship lots of features, but your quality is going to suffer. You can have amazing quality, but you're going to have to ship slower, and you're going to have to invest in areas that are not necessarily as customer facing, like new features, etc.  And I always like to joke a little bit. It's like CAP theorem and databases, you can only ever have two out of the three. I can have, you know, speed and quality, but that means I'm mainly shipping bug fixes. Right? I can have speed and features, but that means my quality is going to suffer.

You mentioned this in the context of culture, is there a right answer? For an organization or does it really vary at the stage that you're at and the time?

Jason: Well it will vary by stage and industry and sophistication of the organization of your infrastructure too. So a good example would be that if you're a two person company just forming and you're using GitHub and Heroku primarily, you can be a lot faster in that scenario, because GitHub and Heroku are taking care of a lot of the gnarly details.

Now, let's say you fast forward and you're 500 people and you've decided to roll around Xs, Ys, and Zs. Well, if you rolled your own Xs, Ys, and Zs, and you're not taking care of As, Bs and Cs along the way there. Well, you know, there's certain things that you're going to have to start figuring out.

So I don't think there's a right answer, but I do think that there tends to be a right mindset. In there, which is what we are optimizing for right now? And again, stage, size, scope, industry, blah, blah, blah. There's a whole bunch of different things that you need to take into consideration there. And if one of the things that you're optimizing for is “we will 100% just get features out the door for the next six months, because that is what's existential to the business”, just understand what you're trading off to the CAP theorem, understand what you're accruing in terms of debt or whatnot. And if everyone's on the same page and understands that, they can understand exactly what the next six months after that will look like too.

And then one last comment on this too, is, you don't have to live in any sort of end of the spectrum exclusively either. You could also, as you get larger, have an infrastructure group whose primary optimization life is safety, and you can have an application engineering group whose primary optimization life is speed. And you understand necessarily that inside that organization there'll be tension between those two groups and the point of those two groups at different ends of the spectrum is that they will probably get the best of both worlds once I’ve figured out that tension. Now, will they get it right away? No. Not in all likelihood. And there will probably be some sort of internal tooling team that will emerge from that as well, to try to appease both sides of this.

Eiso: So you mentioned tensions, and what you essentially call the different modes for different teams. I've often been calling it engineering contexts. Every team  has its current context and a current context can often just be defined by "what are they working on?". Is this team in firefighting mode, 80% of the time and 20% of the time in bug fixing, or is it like you said in priority of shipping new features, 60% of its time and 40% of its time on R&D or whatever long list of boats that we have.

But you're right, it creates tensions between different teams. Have you had any situations in your career where, where it was your job to solve those tensions, and to, to address them head on?

Jason: Interestingly, I think that it's almost always engineering's job to figure out the tensions, because the CEO, the product person and the salesperson, all three of them and the finance person, you put the finance person inside, then there's four. Almost all of them have a very, very, very different optimization. Finance keeps costs low, Sales gets revenue high, Product gets features out the door, CEO makes sure all the metrics are up and to the right, blah, blah, blah, all that sort of stuff. It's a combination of them. But for whatever reason, it all comes down to Engineering at that point, to balance those things.

There's a joke that I like to say, that the CEO should be the one who's prioritizing for the company, but ironically, it's the CTO who will probably push most of the prioritization because that's where it has to happen. The dirty little secret of the industry is that the CTO will, say, prioritize 10 times more than anyone else in the company, and it's because that's where the actual rubber meets the road. So yes, I would say that that's probably been one of my primary functions over the last 15 or so years. And how I think that you manage and alleviate a lot of that tension, is really just  it's what I will call old school, stupid human tricks, which is just make sure everybody is on the same page about the overall wellbeing of the company. And it's not about individual departments or individual XYZs. It's about the company.

And so one of the primary variables that I look at personally, if I were to join a company, or if I was taking over or joining an exec group and trying to make it healthier, is “do they operate in first team mode or second team mode?”. And what that means is how they treat the exec room. So, they walk into the exec room and think "I need to go to exec, to present what my team is doing”, their team being their function. I call that second team mode. They're treating the exec room as the second team. If they walk into the exec room and they're treating the exec room as the first team, and they happen to run a function, that's first team mode.  The healthiest exec groups and  companies operate in first team mode. Which is, everyone is their function second, and the company exec first. And in that case, It's a very easy conversation. What are the five things we need to get done this year? What are the priorities? Everyone's on the same page, here's the sub optimizations. Here's the things that likely don't get done, or here's like some worry I have. Everyone's on the same page. If they're operating in a second team function, basically, in my view, that's dangerous territory because  you're not aligned. You're out juicing your own metric. You don’t care exclusively about your organization and tension will come through. And, you know, if you think about the way that people communicate with each other, tension will come through in so many different ways.

Eiso: It's interesting you mention this, right? How do we take this, we have listeners who are, you know, an engineering manager of a five, six person team. And they're reporting to maybe their senior engineering manager or their director who in turn maybe is reporting to someone else to a VP of engineering. What can you do within your own world? No matter how large or small the scope is to get everybody in that first team mode?

Jason: This is where I recognize that many people outside of functions and departments can actually feel a little helpless because it's very difficult to fix brokenness at the very top. If you see it that way and it's manifesting. Now, what you hope is that there is an increasing level of competence in the chain that gets to you. So you can have this conversation. At some point, somebody is bearing a large amount of pain. But if you're, if you're in the middle of it , say you're a manager director inside an organization and you can clearly see that the company is operating in second team mode.

Some simple things that you can do is just make sure that your own department is operating in first team mode. And the easiest way to think about that is, if you're a director, are all the other directors on the same page? Are you operating yet as that? Directors and VPs and the VPs in the same mode, try to push it as much as possible because then there can be no finger pointing. If everyone's operating in that same way, there can be no finger pointing. And that's literally what you're actually just trying to stop. At some point, somebody in that group is going to have a project that's not doing well. For whatever reason, but if everyone's on the same page, then it's okay that one's not doing well right now because the prioritization is an X, Y, and Z over here, you know, you're on the same page, but if not, then big bomber Microsoft comes into play and everyone starts trying to save themselves and rank that person as a one. So they get tossed from the company.

Eiso: A lot of this stuff, when it comes down to it, it's almost like basic human common sense, right? Like I think this is, to me, this is the part that I always find so fascinating is that, you know, if we do the things that just make sense to us, like we address the elephants in the room, we're part of a team and we're, we're trying to optimize for what we're trying to get to as a company, we actually get really far. But as companies start growing and particularly start growing in size, or sometimes just aging in maturity, we mix in all of these implicit ways of managing, that somebody might've read in a book somewhere or, you know, have taught or have implicitly learned or explicitly learned from a previous boss who wasn't that great. Where does it go wrong? Because I'm pretty sure that if we get one hundred engineering leaders into a room, they're all going to agree with the common sense things that we're saying.

Where do we make those mistakes that take us from what's essentially a healthy culture, almost an organic culture, to the ones where we have so many complaints?

Jason: It's hard to universally say where things would go wrong, though, I agree 100% with your initial statement that it comes down to the basics or what we know them to be. At scale though, the simplest answer to this is that many people start to lose humanity to them. They become a name at the other end of an email or a faceless person in an org who you just happen to know the name of the type of deal.

My university experience was at a school named  Penn state, which was a land grant university in the middle of Pennsylvania. And it's large. The Freshman class was 55,000 people. I was a number. I couldn't possibly be a human to that administration. I was a number to that. So, you know, my humanity was essentially lost in that experience. Now, I had to make it my own way in that university. And I think that that's what happens. It's almost like a survivalist instinct that kind of kicks in and that's dangerous. I think that anytime someone's like, "surviving an organization", that's dangerous.

Also what happens is as leaders grow in their own career, and let's just assume that everyone's average. Like inside an organization, it averages out in that people are the average at their levels. And I don't believe that to be true, but that's a different story. Let's say that you're the average at that. You likely forget, at some point in your career, what it's like to be a line manager or director, or to not have the full context. I can't tell you how many execs I talk to on a regular basis and say, "how could that engineer not know that that was important. I said that on stage at all hands five weeks ago." Well, is that a them problem, or is that a you problem? You know, they forget what it's like to be on the other end of that, or the other side of the screen or other end of the telephone line.

Eiso: So you mentioned something which is, let's assume everyone's average and you say, I don't believe that. Go a little bit further into that.

Jason: You know, this has been formed over the last couple of years, as I've been watching the industry a lot more closely at the top end of the spectrum. And I believe that it's a lot like professional sports and I think that the pareto principle applies here very, very distinctly. Which is, if you could take any professional sports team, you'll find that there are one or two people on the team that are so far head and shoulders above everyone else. And they worked up and these are professional athletes. They are already investing in the world, but they're still so head and shoulders that you don't understand how they're even the same sort of sports type of athlete. We know them from soccer and all the others across the world.

I think it's more distinct though, to inside organizations, because sports have combined boundaries. You have a season, you've got a game, you don't have to worry about long lead decisions. They're not making money decisions, they are making in the moment decisions. It's very different, but it's similar from a constant conceptual standpoint. I believe that most people at the top end of the spectrum are actually below average. Because what happens is they are above average on one or two things. And below average on many. And what happens is the aggregate skillset that they have becomes below average, but they're propped up by the structure of the organization. And you see this most apparently in large, large organizations. The Microsofts and Googles and Apples of the world. Where, Jony Ive, as an example - I don't know him personally, but I'll use him as an example, - would be a legendary outlier who's just so far head and shoulders above on a couple of characteristics that, you know, his weaknesses were not as apparent, but he was able to elevate the organization. I believe that most organizations are propped up by several of those people. Then everyone else is on a below average side of the spectrum, on an aggregate.

It's very difficult to say that out loud sometimes because you would be basically telling the industry that, in all likelihood, they shouldn't be in their roles. But that's actually not true, because I don't think there are replacement players or replacement people that would be able to step in and do the same sort of function either.

I joke about Microsoft all the time. Most people in Microsoft at senior or below level are basically there because they've been there for 20, 25 years. They know the organization, they know the players, they survived the organization long enough. They actually know how to navigate it. They know the communication pathways, but they don't have product instincts and they don't really understand the market, but they understand Microsoft and there are no replacement people that can go in and understand Microsoft. So what does that actually mean? Well, I think that what it really means is "don't listen to 90% of the industry", including me. I should be a singular data point for anyone listening to this. Most of the feedback and advice that people give in the industry is not that great, you gotta amalgamate as much information as possible, and then figure out your context and how it applies to your context.

Eiso: To loop this back, what we were saying earlier is that most of what makes a healthy engineering culture, just a healthy company culture in general, on a basic human treating people as people, you know, do unto others as you like to do on to you, and care about how people feel more than than what you say. Do you think that because we live in an industry where we promote the outliers that have one or two amazing traits all the way into the top of our organization, and they end up driving so much of the culture and the rest, that it's those extreme outliers that almost push us towards not necessarily being that whole rounded, I don't even know how to say it, good, normal sense of people? What I mean is that you, I think you can see where I'm going for, right. Extreme athletes at the top of their sport might have incredible qualities in one field, but might be severely lacking in another.

Jason: I think that this is a fundamental misunderstanding of what it means to be a leader inside of an organization. So, let's use Michael Jordan as a good example here, because everyone watched that Netflix documentary last year during the pandemic in all likelihood, "The Last Dance". And people will famously cling to Michael Jordan as being just kind of a raging asshole. He strove for excellence. He demanded it, but he didn't know how to get other than just being that person or maybe that's what the culture dictated or maybe that's what the sport at the time dictated that he needed to do. But there's only 12 athletes on a basketball team. They're also paid millions of dollars and they're literally the best in the world at what they do. He doesn't need to actually inspire a bunch of them. He needs to get them to go from like a 10% output to a 12%, to a 15% output type of deal. And in fact, he can still, singularly, on a basketball team on the floor at a time, because there are only five players on your team on the floor at a time. He can singularly dictate the outcome. The difference between a sport and a company, at this point, is you no longer singularly dictate the output. You have to get that through others.

So it'd be more equivalent to being a coach. And there are very few coaches who are long-term successful at being the Michael Jordan style approach. They can have short-term success, but they can't have sustained long-term success. And then the ones that do usually come from an older school and have transitioned into the new school and somehow because of their credibility from that era have transitioned to this one. That's not what running a company is like.

I think running a company in a division, you would actually have to be a better communicator. You have to understand the psychology of the organization. You have to know how to inspire. You have to have more than one method too. You've got to be X to this group, or Y to this group or Z to this group. And you've got to understand that you have to go to the organization and get it. In Satya's case in Microsoft several hundred thousand people aligned and inspired. And yes, you're working through other people who were supposed to do that as well. But this is why it breaks down. So I think it's a difference in understanding of those sorts of things.

My fundamental belief is that people like Elon Musk, we put them up on a pedestal, but it's the wrong thing. Elon is not the technical brains behind a single thing that he's ever done. Never once in his career has he been the technical brains. If we understand what Elon is, which is a marketer, Elon is a marketer. And then if you look at SpaceX, who was the CTO of SpaceX, the founding CTO. Who was the founding CTO at Tesla, and understand how they operated, that would be a much better conversation for us to engage in.

Eiso: So, since you've met a lot of CTOs and VPs of engineering at the companies where the names are maybe not as visible to the rest of the world, what would you say makes them great leaders, the ones that really inspire you, that you look up to that you've learned from?

Jason: There are several universal things that I think  almost all the greats have, which is people want to be around them. Now that could differ in each of the contexts. Some people want to be around somebody because of their technical excellence. Some people want to be around others because they make them better. Some people want to get, you know, but being around that person, people wanting to be around that person is important. I think another thing that universally is true, is that they are indeed very good at their domain. Jeff Dean, good example over at Google, who happens to be world renowned for his machine learning and AI type of stuff of what he's done. Just happens to be, you know, an expert in that area.

And the reason why that's important is because you do have to have some expertise in the domain to have some of the trickier conversations. I don't mean like tricky and like, “aha, I'm right, you're wrong, let me trick you”, as like, “this is a tough problem, we got to sort this through together”. And you have to be able to have that, at depth. This goes counter to the industry trend, which is like, “you don't have to have any domain to be an engineering manager”. No, I absolutely think you need to have domain to be an engineering manager and in fact, to be the best in the organization, I think that you have to have deep expertise. You don't have to code anymore, as an example, but you do have to have deep expertise. It just so happens that that's almost like the adjuncts to power as both your core competencies at that point.

So I think that's true. Then I also do think that the best ones are excellent communicators. Multistyle excellent communicators. And the worst ones are the ones that have the short tempers and saying, "well, I already told you this". Like, if you think about those ends of the spectrum. Now, famous examples who counter that, again, you're going to find some exceptions and you're gonna say, well, Steve jobs was X Larry Ellison was Y or all that sort of stuff. Yes, but do you really want to emulate those folks? Because in many ways, outside of Steve jobs, they famously had massive failures too, along the way. Steve Jobs was fired from his company because he was such a notoriously hard person to work with. And in fact, if he didn't get the second opportunity, we would not be talking about Steve Jobs as this person. You understand what I'm trying to get to.

Eiso: I understand exactly what you're going for, yeah, but it brings upon something interesting, right? Is that how we, as leaders, and engineering leaders are taught, because we are, it's a profession where a lot of the things that you're talking about today are really oral history, right. There is no such thing as - in most companies or most organizations. - as, "Hey, this is how we are going to educate you and improve you as a leader." How can we even expect great leadership and great engineering culture to emerge when, till date we've almost just treated it as, you know, let's promote the person who asked to be a manager?

Jason: I don't have a good answer to this one, to be honest with you. Cause I think that It's kind of the same thing as in a lot of different industries too, which is maybe a day trader who gets promoted to run the floor, from being one of the active day traders, to running the department or division and, you know, do they get taught those things or do they have to intrinsically learn it? And I think that most industries actually have a person who is able to amalgamate and absorb all the ambient mess around them, to become that person. How can we change it? This is actually going to be difficult to change. Like probably one of the hardest things, almost, maybe nearly impossible to do.

And the reason why is that, if people were listening to this, like half VC industries listening to this right now, they would disagree with every single thing I say, because their incentive structure is actually different than mine. Mine is "I want my organization to be the healthiest version of the organization". They actually don't care about that. They care about "it's healthy as long as there's returns" and then, you know, it's slightly different than mine. We both want the same idea of an outcome but I want mine to sustain for 10 years and they only need it to last for five, as an example. I think because we can't largely even agree on what that would look like, it's going to be very difficult for us to change as an industry. I do believe that we need more people talking about it, writing stuff down and giving good examples of it. If I think about my executive career, what I was hoping to show is that there's a different way to have the same outputs and outcomes.

It might be a little bit harder because it's a less treaded path, but you could have those massive outcomes still just being a different type of a leader. And in fact, I think that has been proven with sports. I think you can show that different leadership styles can have the same outcomes, but again, we need more examples, I think, and more examples of people talking about it.

And also I think on a slightly different tangent, maybe to what you're asking is most of the publicity notoriety or accolades in the industry go to CEOs. And CEOs are a certain type of a leader, CTOs, VPs of Engineering and Engineering Managers, different types of leaders. And I think we need to showcase more CTOs, VPs of engineering and less CEOs for us in the engineering ranks to look up to.

Eiso: I mean to me, it drives me absolutely crazy that we even have to have this discussion. The fact that there are cultures out there where, like you said, leadership, even on an engineering level, is only dictated by "let's just get to the five-year outcome that venture capital requires, no matter what, no matter who we burned along the way or how we do so".

How much of this, and we touched upon this a little bit last time is our industry's incentive structure playing a role in this? And it's very funny that we keep coming back to, you know, where the money comes from,  on an engineering leadership podcast, but it does seem to be a topic worth exploring.

Jason: I think incentive structure is 90% of the industry. If you can actually understand the infrastructure you very, very, very deeply understand what's about to happen in the industry. Inside a company, inside the industry, inside a division, a department. I was having this discussion with a couple of people yesterday and they were talking about, they wanted to implement X, Y, and Z policy. And I talked about something I call the law of unintended consequences.

The law of unintended consequences dictates that this thing will go left right and pear shaped in any second possible way. And the reason why is because the incentive that people have now is this. And if you look at just that, just that incentive, it dictates that they're not going to be for the greater good, they're going to be about the personal good or the department good. And we've just incentivized them to think that way. Well, at the macro level, we have to understand that. So again, I'm highly skeptical any time of someone who has $15 billion in assets, under management, plus, you know, - I'm just picking a number out of the air, - deployed over thousands of companies, talks about "you always have to go big, you always have to go big, you always have to understand that you're always grinding and working 80 hour weeks". Well, that's because that's exactly your incentive structure. Like that's it, it aligns perfectly to your world view.

And so one of the things I talk about with CEOs of early stage startups all the time is that if you have a GP or somebody on your board telling you “no, this is exactly how it needs to work, I've been around the industry for this long”, all that sort of stuff. They've got 15 bets out there, and you're one of 15, but you're one of one of you. One of one in your company, your view of your company is 100% of your worldview.And you're one 15th of their worldview. So understand that the incentives are not aligned at all in any way, shape or form, and you have to get those things out there.

I do think we should talk about them a lot more in the open, but which is also, just to be really transparent, and blunt, which is why advice from VCs who have never run companies is usually typically very poor operational advice. It's very good metrics driven advice, but very poor operational advice. If you want to know how to build and run a company, you should only ever talk to other people who've built and run companies.

Eiso: I couldn't agree more with you, because the way that we're building our company at the moment is actually completely breaking that mold, and not going down the VC path. But if I want to take this really down to how we can help engineering leaders today who are finding themselves often in venture backed companies or high growth organizations that have these pressures.

What are some of the discussions they should be having with their CEO and their board about incentive structures internally? What are some of the things that we can do to make engineering more aligned?

Jason: I think this comes down to the exec team in general. And because that's where board meets company, it is usually the exec team. And so, I'm going to use my hands. I know this is a podcast, just picture bubbles above my head at the moment, kind of going off. But it usually starts with two things: Mission and Vision. And you have to have those things understood, well articulated, written down, long-term view. Mission and Vision become goals, become priorities, become tasks. And I believe that right there is a way to disambiguate incentive structures and get them out of the way and say, as long as we're aligned on this sort of structure, the mission, the vision, the goals, the priorities to the tasks, you largely can understand how to operate the company and navigate some of the other things.

Most organizations actually kind of skip around on those things. They'll say, “Hey, what is engineer X, Y, or Z working on today?”. They're talking about tasks, but you're not actually articulating what the goals are for some time bounded period. You're not saying like, "Hey, we want to increase revenue or decrease churn or X, Y, or Z in that timeframe".

So, I do believe you gotta figure out each one of those buckets. If you don't, you're only looking at one end of a racetrack to a degree, and you're not understanding the full course. Boards never talk about tasks, engineering teams talk about tasks. And boards don't typically even talk about priorities. That's something that gets broken down somewhere inside the company.

The exec team, I think, should really put that together, but where the engineering team specifically usually comes in, is at the prioritization level. There you're just saying, "Hey, we can't accomplish all those goals. So help us understand how to prioritize this because the goals become much larger broken down".

Eiso: I want to push you even a little bit more, because I know that we have, people are gonna be listening to this are like, yeah, I agree with you. But I'm a director of engineering in an org, and I have a  decent idea of what our Mission and Vision is. And I deal with all the challenges of it being, you know, vague, and I'm given goals that I know I cannot prioritize.

And how do I make my team, the part of the organization that I can control and maybe also the people I report to adopt a culture and practices that, that we build that healthy organization that we strive to build?

Jason: If we're honest with ourselves too, inside engineering organizations, is that we do seek out comfort over discomfort. Every human does seek out comfort over discomfort. So typically speaking, if your entire team is super comfortable, you're probably actually not operating at peak efficiency. I know there's going to be a whole bunch of people who are listening to this saying, well, he just kind of went off into executive land. No, this is psychologically true. Think about sports. Think about working out. Think about weightlifting. Think about running. Think about anything in life. You actually grow from discomfort.

If you're weightlifting, you actually need to tear down the muscles in a very small fashion for them to regrow back strong. And this is the same sort of thing inside organizations. Now, I'm not saying reckless. I'm not saying you're throwing all this massive weight around when you're weightlifting. No, it's a slow, methodical type of ramp up to the point where you get better. So instead, to engineering organizations I would say one thing: “if you're super comfortable, you're probably, you're not doing your job.” Just to be honest, you're probably underperforming for the organization or under achieving what is possible if you were to push just a little bit harder. And I don't mean push the people to work longer hours. I mean think about how to become more efficient. And there's lots of different ways in which we can specifically talk about it, but let's talk about two very, very concrete ones.

One is, honestly, you just say “no” to a whole bunch of things inside your team that you don't need to be doing.  Not like from the external organization, but too many safety switches, too many small things that are going on, too many loose processes. Instead of having one standup a day where five people are in it and they have a five minute conversation, everything's in slack and it takes three days to get to any one decision. When a one five minute meeting would have gotten all of that stuff out of the way. And again, it's comfortable to make it all async, and there's lots of reasons why you might want to say that, but one, five minute conversation solves three days worth of async churn. Another might be, just to be really honest with you, that you have inefficient processes or technical processes. Your builds take too long. You're not invested enough in that sort of stuff, or your tooling itself is subpar because you've not thought about that. Or you're maintaining a whole bunch of manual steps that if automated once would save you a whole bunch of time in the future.

Then the other side of that, when it's going up, I do think that pushing some more of the prioritization does help, like saying, "Hey, the goals we want to achieve, the way that I have these things ranked, these are the ones I'm able to achieve in this time period". Having that very, very well articulated conversation is really important. And most people can't actually have that conversation. They just say "we can't do all that". Because then they don't go through the work to say what they could achieve in that time period and hit that each time. And so I think, in a weird way, in a bottoms up sort of way, which I think is not the best way to operate, but it is the way in which most people do operate. You have to be able to articulate what you're able to achieve and then achieve it. And a couple of times you'll earn the right and the respect of the organization to have that conversation in more depth. It's inefficient, but it's what most people have at the moment.

Eiso: I like what you're saying. I think we did the same thing today that we did last time. We started pulling on a lot of threads that we can probably go much further in on. And, we're going to be continuing to talk. But if I try to take a little bit of stock of today, the main things that I see, and I actually fully wholeheartedly agree with, is that culture is how make people feel, depending on where we're at our environment, primarily the incentive structures that are such big drivers of these complex systems that we're in.

We find ourselves in places where we easily will get incentivized, not even sometimes by our own fault to not try to optimize for a healthy environment where we are at the edge of being comfortable. Not comfortable enough and where we're constantly striving for continuous improvement. But in many organizations, we're finding ourselves with a lack of  information, the inability to fully understand the complex system incentives that are pushing for outcomes without care of how they are achieved.  Which is leading to some of the cultures that I know you and I absolutely can't stand.

And that being said, there is still no way that we really know how to train and teach each other, besides the things that we're trying to do, and others are trying to do with books to really kind of say, "Hey, what's the path forward?". One of the things I'd love to touch upon more next time, and you kind of started with it now is we'll often have to fix it bottoms up. The things that we're talking about are really most effectively solved top down.  And I'd love to talk about that a little bit more next time, but on this note, let's end here today. Do you have anything that you want to say, as final words, Jason?

Jason: Going into that one next time is going to be fun, because there's an element of control that you can control conversation that we need to have there. And then also, if you do find yourself  in a spot later in life or in your career where you happen to. You have a responsibility to not let the same things that happened to you in your career happen to your organization. So what are you going to do about it?

‍