The Wisdom Wall
20 quotable lessons, heuristics and mental models. Every one is playable at the moment it was said. No fortune cookies allowed.
“When I'm going and having these conversations with leaders, and this is, I think the standard conversation most people have is it starts with leadership. If we're moving too slow, it always does. We've always believed that we've been more clear. We've created more clarity. We have aligned people better than we have.…”
“Dropbox hit a home run basically out of the gate. And there was kind of an expectation that that's how you built products. And like people came from different places and very different experiences, but pretty deep in the culture was this idea that you build it. And then, you know, Coin a phrase, they come and, and that…”
“I think the canonical example of this is Google, by the way. I mean, I think that Sort of in industry. Now we've kind of learned you hire people out of Google and they show up and they don't know how to operate because they've been such a determined high functioning thing where all of the tools were in place and they…”
“one of the things that people ask me is you look like you've worked with a bunch of great people. Like, do you just like bring them with you to every organization? And, and the answer is, of course not. Like every organization is different and partially I need the people who grew up in this organization to translate it…”
“Actually, one of the, the early stereotypes about engineering managers in our industry is as the shit umbrella, you know, just gonna keep people from being distracted by all the crazy. And what that is, is those teams end up just drifting off. You know, you talk about like coordination and alignment and shared values…”
“You know, I really have come to believe that high quality management is one of the keys if you're going to scale your organizations. And so the degree to which I invest in that versus invest in architectural principles or code reviews or other things has grown.”
“I think that we see over and over again, technical solutions proposed around the idea of, I don't want to talk to my coworkers. I think microservices is like the canonical example of this, but we see it in all different ways.”
“I think that one of the things we've realized is that there are actually multiple paths to success and multiple high quality ways to run a team. And that also that some companies Path to success doesn't actually run through a high quality engineering.”
“One of the easiest hacks for creating strong identity as a team is to put the team in a combative situation.”
“particularly when the, when the industry is on an upswing, there is something similar to managing volunteers and managing engineers, even though you're paying the engineers a lot of money to do it.”
“Fundamentally, the rule of thumb I use here is your team is your unit of concurrency. And so the number of work streams you want to be solving at the same time is how many teams you need. And so the more things you're trying to do at the same time, the more teams you need, but each of those teams has to interact with…”
“We say the abstraction layer has gotten better, but in many ways we are using more sophisticated tools. They have not gotten simpler. They have merely gotten higher level and more productive, but they're not simpler to use.”
“So your unit of measurement for health is at the team level versus the individual level, especially as you scale.”
“12 people is sort of the upward limit of where most people can manage effectively. You know, six to 12 with eight kind of being the sweet spot is just kind of how much most people can sort of juggle the amount of context you need for each individual in order to be an effective manager. So 12 is kind of your upward…”
“One of the things that's really different about software engineering than other types of engineering is the fungibility. Problems can take two days or they can take two years. And the fundamental difference is the excitement and clarity you have around the solution.”
“there's sort of this interesting window where you get about six months and then it's your fault. I mean, that's my standard deal with anyone senior is you get about six months and then it's your fault. And that's just as true when you're Coming in and it is easier to change some things when you're not, when you're not…”
“And so in your public communications, people are looking to see if you adopted their language, their ideas, that sort of stuff, because that's how you build trust. You know, you actually were listening, you trusted, you updated your ideas, you incorporated the information I gave you.”
“And I actually do think that a certain amount of detachment is actually pretty critical as you become a senior leader and the people who don't learn that Detachment are the ones who either fry or, or end up trying to micromanage a system that's too complex for them to understand.”
“the more junior somebody is, the more it is your responsibility to make it work for them. And the more senior they are, the more it is their responsibility to figure out how to adapt and to identify that they are in the wrong place.”
“I think the most common failure I see is people failing to teach Their engineering teams or their product and engineering teams, how to think about the business they are in.”