• Bruce on Mastodon
• Bruce on Twitter
• warpedvisions.org

Allen: Welcome to It Shipped That Way, where we talk to product leaders about the lessons they’ve learned helping build great products and teams. I’m Allen Pike. Today’s interview is with Bruce Alderson. Bruce is a senior product manager at MailChimp and has previously held titles like engineering manager, CTO, and Head of Commerce Technology at companies ranging from scrappy startup to over 10,000 employees. Welcome, Bruce.

Bruce: Hey, Allen, how’s it going?

Allen: It’s going really well. I feel like this is decades in the making paths.

Bruce: It’s true. Yes, it’s true. I met you about 20 years ago, I think.

Allen: Yes, very close to that.

Bruce: Yeah. We had a nickname for you, and I will not repeat it on air. Sometimes, we still call you this nickname, and it’s no longer true.

Allen: So you’re making it seem very insulting. People would call me “the boy,” because I was the youngest employee by far. You’re making it seem like it was like a cruel workplace.

Bruce: It’s not a horrible nickname. It’s a diminutive word.

Allen: It was diminutive. It was not particularly respectful, but in your defense, I was, I think, a teenager at the time. So I was a boy, and I was going around with probably undue amounts of overconfidence, as young programmers often do.

Bruce: You did, but it was inspiring. There’s a story I still tell about you on a regular basis. You tested software for us on a regular basis, so we had a mobile product at the time. The mobile product had its own framework, and you used to walk around testing it, not looking at the software.

Allen: I did do that.

Bruce: You would show the engineer the software, you would tap on the screen, and you’d say, “Hey, it crashed,” and you would have no idea if it did. And you were just almost always right. It was fantastic, and it was one of those cases of engineering prematurely releasing software and stress testing it in a way that wasn’t obvious. So it’s been a very valuable resource for me.

Allen: I have fond memories of testing. Testing is obviously a longstanding entry point for a lot of folks into software engineering, and it’s not, in some ways, not as creative in the way it’s done in a lot of organizations as it used to be. It’s a little bit more prescriptive and a little bit less just give some kid time to try and break your thing, but I feel like I learned a lot doing that.

Bruce: Yeah, it’s actually quite a great teaching exercise to test software, understanding where it breaks and how it breaks. Very important things.

Allen: Highly recommended. So before we get into the topics, I did not have Allen’s exploits trying to break C++ mobile apps from years ago on the list. Before we get into the topics, we could give some folks some context and background on you. Are you up for trying to summarize the decades of engineering and product leadership background in a couple minutes?

Bruce: Sure, I’ll do my best. Actually, just gave a talk on this at work. It was one of our paths to product management, and because I didn’t start in product management, it’s interesting to a lot of folks. I’ll start way back. I started programming when I was six years old on an APIC computer. Something about programming was interesting to me at the time. It made my little brain explode, and even today, when I think about it, it’s fantastic. I went on from there. I programmed all the way through high school. Kind of in the later years of high school, you stop, because you have other things to do. But then, I went to university to learn how to program. Of course, not being very well off, not being in the right area, I ended up going to community college, and I didn’t bother finishing. My first co-op position, I took, and I worked. And it was a support position, and from that support position, I started coding. Starting coding, I ended up learning from a bunch of incredible engineers at the time, and I moved into systems engineering. It was a huge amount of fun, systems talking to each other, but I couldn’t talk to normal people about it. This was always one of my challenges with the work I did. My partner would come in and hear me on a phone call, and she would be like, “I don’t know who you are. What is this stuff you’re talking about?”

Allen: And these were low level hardware systems you were writing stuff for?

Bruce: Yeah, one of my first projects was a Pascal compiler for a Motorola 6800 CPU on a trained black box. So the lowest level lowest level stuff we could work on. But it was fantastic making this little machine that could take code and turn it into machine code and run it, and it’s still running today, which is baffling. From there, I went on, and as happens with engineers, you get older, you have experiences, you start to raise your view over time. And so, as a low level engineer, you’re looking at the details as much as you can, and over time, you kind of raise your view up a bit. And I became a component designer, a systems designer, which I don’t know if we have that title very often anymore. And systems architect was where I ended up there. I loved it all the way through. That was first 10 or 15 years or so, and that’s actually where I met my mentor, John, which you just happen to know as well. And I went on from there to be architect and CTO at another company, and it’s where I started getting interested in other parts of the business. Because just thinking about software design really misses out on why you’re doing it, and so often, you’ll architect or design something that isn’t as meaningful as it could be if you knew what the business case was or who the people were that were using it. So I went on, I learned how to do visual design in there. I had my own agency for a while. From there, I was a second founder of a startup in Vancouver. That startup, we did e-commerce software, and so, I did all of our visual design or most of our visual design. I also did most of our architecture and staffing and the sorts of things you do as a CTO. I went on, from that, we sold that company to a small company called MailChimp, and then, we sold that company to a not quite so small company, Intuit. And in that, I had to make some decisions, and it’s interesting to take, when you wear all the hats, and you learn that you can only wear one of the hats and you have to pick one.

Allen: Well, this is the stereotype, a large organization specialization tends to be the preferred way of having impact, rather than having the same person design the website as be the CTO and do the architecture.

Bruce: It is so true, and in fact, I was pretty lucky to hit the ground at MailChimp. Because at the time I hit the ground, there were still people from 15 years ago working at the company. So I think the CTO at the time actually committed code occasionally. Not that everybody loved it when that happened, but there was enough knowledge that he was able to do so. And he had the passion that he really wanted to do it, and that was pretty special to see. So while I had to pick a hat, it was pretty easy for me to pick another hat. So I started out as an engineering manager, which, in that organization, was the sort of manager that doesn’t code anymore. And that was a tough switch for me to know the things that needed to be done but only be able to influence the people that were doing it. I did enjoy it. It wasn’t as if I didn’t enjoy it, but what I really wanted to dig into was that first thing I saw when I started in engineering, which was “Let’s make cool stuff.” And as an engineering manager, you’re not super responsible for the actual cool stuff. I had a realization that, in product, we do everything but the engineering. Meaning we get to figure out what could be done. And part of that is working with engineering, part of it’s working with design, part of it’s working with your business partners, but you get this ability to take all of that, distill it, and put it into something that is interesting and fits the timeframe and the budget. And turns out that’s as much fun as coding, in fact more, because you can have 30 people working with you, that are all way smarter than you. And it is just a fantastic thing to work with people that are like that.

Allen: Yeah, that’s one of my questions, and you kind of dug right into it, which is this multidisciplinary path that you have. And I think we share that streak of wanting to do lots of different things and being interested in the product and the business and the engineering and the design, which sometimes is slightly annoying to some of the other people on the team, which is like, “Let me do my design, why do you have to comment on this?” But one of the stereotypes is that large companies don’t always have rules for folks that have that breadth of interests, and it sounds like you’re sort of implying at least, or maybe explicitly saying, that product management maybe the path for you if having your fingers in multiple aspects of the product at once is something that appeals to your sensibilities.

Bruce: I haven’t seen all large organizations, but my gut sense is that there’s always a role somewhere that is multidisciplinary. The reason is is there’s always something in a product that needs that kind of wider view. It just happens, where I landed in MailChimp, Intuit, is in a set of teams that deals with platform and APIs and stuff that’s all very engineeringy. Meaning that I can both do product thinking, but also, I have to be able to understand engineering thinking. So it’s not like you discard all that. We have lots of roles that cross disciplines as well. You always need that person that knows where the stuff is, and those people tend to be able to do a little bit of engineering and a little bit of testing and sometimes a little bit of product. And as a manager, you need to know who those people are, because they’re the people that will move mountains when they need to be moved. And that, I think, is the most interesting thing about big organizations is there is this view that they’re just big machines, where every part is exactly the same. I haven’t worked at Apple or Google, but I can say from the other companies I’ve seen, there are definitely roles that are fit to the person and not the other way around. So yeah, I believe that, if you want to do it, you just need to find it in the organization you’re in or an org that does that better.

Allen: Yeah, product management is one of those interesting ones that’s very different from org to org as far as I’ve been able to tell. Some organizations have a very designery bent to their product management. Some have a very engineeringy bent to it. Some have a non-existent product management role, where it’s at least the groups I worked on, the group I worked in at Apple, there was no one with the formal title “product manager,” at least that I was ever interacting with or being aware of. I always got the sense it was kind of a little bit of bottom up design and the senior people on the team would advocate for stuff, and then, whoever is in leadership in effectively the engineering org chart and the VPs and stuff would then have some product input and product marketing for the whole company would have product input, but it wasn’t in any stretch by the imagination, the “modern approach” that a lot of companies increasingly do was this triad. I’m sure your team or MailChimp or Intuit tends to do this, the pair a product manager, a design lead, and a tech lead together. Is that something that you do either on your team or on the other teams there?

Bruce: Yeah, all the teams I’ve worked on, even back to startups, we’ve had kind of a triforce is what we always call it.

Allen: That is a better name. That is now the official name.

Bruce: It is now the official name for everybody. And the purpose of that, it isn’t always the same three concerns, but part of this is critical mass of meetings. Three people in a meeting can be very productive, and then, as you add folks, it becomes increasingly less productive. So in my current team, our triforce is actually a program manager and an engineering lead and a product lead. We don’t have any designers, because we’re mostly services and APIs and such. But on previous teams, we’ve had a designer involved in that, and sometimes, we will still include a program manager. And a program manager’s great for navigating the organization. You have seven teams that are relying on your work, they need to be updated, and you need to track dependencies and all that. It’s like banking, it’s boring, but very important to making things happen.

Allen: You say it’s boring, but maybe the program manager thinks it’s fascinating.

Bruce: I have yet to meet one that thinks so, but they’re all very good at what they do. They’re very excited about doing it. Sometimes, the value of doing boring things is still quite good for a person.

Allen: Honestly, the value of doing boring things is one of the things… I don’t know, I’m curious to what degree you agree with this, but one of the things that comes up when we’re talking about seniority and leadership about how people approach their work is that I find that senior people are able to have more impact and really, in some ways, almost by definition, are more senior, if they’re willing to just do a boring thing sometimes, even though it’s boring, and it’s like, “Yes, I don’t really want to do this thing either, but if we do it and then, it’s done and we do it promptly, then it’ll have this big positive impact. And yes, let’s not let your entire job become that boring thing, but sometimes you just do the thing and then it’s done.”

Bruce: Yeah, in the end, it’s about results. And often, if you do the math, just doing the work is cheaper than trying to abstract it or start a project to solve it permanently.

Allen: Now, we need to do an entire new architecture to deal with this, so I don’t have to edit a CSV file manually in Excel or something.

Bruce: I do love those solutions, and I like to see senior leaders actually fix things. Because they get a satisfaction from it, and the rest of the team knows that they’re willing to work hard as well. Those are pretty important. Program management, the work they do, it is intense, and they’re not thanked enough. And they get satisfaction from it working well, and it’s a very abstract way of thinking about your own performance, not about… As an engineer, often, your performance is, that your unit tests pass, or your PRs are approved, or the code is running in the wild, that is also quite satisfying. But for a program manager, it’s like this wider net of satisfaction, could be a year you wait to see how successful you are. Product is a little bit like this as well, though we tend to be cheerleaders for ourselves. We have launch announcements that come out very regularly, and we put out status updates. We like to get up in front of people and tell the story of everybody and celebrate your team. We’re narcissists, I think. It’s the kind of only base requirement,

Allen: When you post a job description for a hiring a new product manager, “Narcissist wanted.”

Bruce: Works for design as well.

Allen: You and I have talked actually about this, storytelling, context gathering, and that’s a loop of a lot of leadership roles, product management and others, where you gather context, you tell the story to others, maybe get feedback, gather more context, repeating as leadership skill. How would you describe how you apply that in your work? And how do you think about coaching others when you’re trying to help other people develop those sort of storytelling type skills?

Bruce: One my favorite lessons of starting at a company like MailChimp was the fact that, to teach a thing, you need to tell the story a dozen times. You have to get used to repeating yourself, and it’s not going to annoy people. There are enough things happening, attention is precious, and sometimes telling the story a few different ways is very important. As an engineer or when I was an engineer, that was a very frustrating kind of behavior. “I already told you this. I laid it out point by point. How do you not know everything that I know?” But you realize, over time, that getting people to that understanding is figuring out what they don’t know, hearing their reactions to the stories, and tailoring the stories for the groups and the individuals and then, repeating it as much as you can, as consistently as you can. And of course, the story evolves over time as well. So retelling the story is helpful to build into it what you’re learning. And so, part of getting into product for me was learning that that’s okay. It feels wrong initially, because you’re repeating yourself. But you realize that it’s the retention, it’s that end goal that you’re going after. And so, in all of my teams, we have story time, where we talk about fundamental principles. “Why do people do this thing? Why is it frustrating for them?” Just generally, and then, get down to what we think is valuable to the business in that.

Allen: I like that point about repetition. When I started scaling a team, I had that same mental model you described, “But I already told you that thing.” Course it was like four years ago, some document is buried in a Google Doc somewhere that no one even realized. My model went from, which I find it’s way more helpful to helping you repeat things, and I still I think I could get better at it. It went from thinking, “Have I taught this person this thing yet? Yes or no?” To assuming everybody has a most recently used cache of memory and as they interact with other facts or things about the world that the thing that I am encouraging everyone to pull in this common direction or “Here’s this value we have as a company” or “Here’s the fundamental goal of this product effort” will eventually fall off the bottom of the cache if I don’t repeat it or something, a habit I started to feel really silly when I started doing this, but now, it’s a core habit, is have docs, where the very, very top of the doc will be three or four bullet points of, or even two or one bullet points, of, “What are we even trying to do?” And it will just be right in your face, and you open the doc. And it’s like, “Why are we even having this meeting? What is it this launch even supposed to achieve? Why are we even building this feature?” Whatever it is. And that’s another form of that repetition. At first, it seems silly. “We all know why we’re building this, but in six months, will we all know?”

Bruce: And will the reason be the same in six months as well? And that’s something that is always true, because organizations change quickly. Our understanding changes. Retelling the story partly is about reinforcing what has changed in it. I have this feedback trick I like to use, so I tell stories, I repeat these things that are very important. I know I’m succeeding when I start to see those stories bleed into specifications, Jira tickets, and where you see clear explanations of why we’re doing things. And to me, it’s one of the most satisfying things when you have engineers, for example, teaching the fundamentals of what you’re building. And they’ll be reminding people, “Wait a minute, you can’t store this like that, because of this thing here. There are laws around this or there are standards.” And to see that repeated, it means you’ve succeeded. It doesn’t mean you stop repeating it at that point, but you know that, now, it’s being repeated by others. And so, it’ll live on, and it’s a little bit like an organism that way. If this knowledge isn’t being repeated, it’s not really alive, it’s not really part of the organization yet. It’s just something I’ve said, and once it escapes from my orbit and it becomes part of the rest of my teams, there’s a chance that that will live on organizationally over time. And some of that knowledge is very important when you’re trying to teach other teams how to use this thing that is very specific to your industry.

Allen: That habit of effectively teaching these stories and these why questions is one of the, if not the only way, that you can scale yourself as a leader. Otherwise, you end up just being this bottleneck process that eventually hits a hundred percent CPU of trying to double check everyone’s work and making sure that they actually are complying with the 10,000 things that are in your brain.

Bruce: It’s one of the most important tactics I have is finding in an organization, anytime I switch teams, two or three people that become your voice, and they may not even know it necessarily. But you mentor and you train them, and they start to just repeat the principles and the stories you talk about. And you trust those people to do those things. You don’t need to monitor what they do excessively, because they’re great at what they do. And that’s really, I think, any leader’s success is having that group of individuals that really takes those stories well and then, can retell them. It doesn’t have to be something you talk about much, but just even the act of mentoring somebody is enough to build up a connection like that.

Allen: Yeah, that’s something that happens in almost all organizations, but definitely, I see it happen a lot in quite successful large organizations is that you have this org chart and you could draw the org chart of, “Okay, well, this person is in charge of this, and this person is in charge of that,” whatever. But then, there’s also this total other org chart, which is the path of things like this, what you’ve just described. There’s certain individuals contributors often or maybe line managers that are having outsized impacts in certain areas, in ways that are not in a formal job description, and they’re helping other leaders in the organization have a bigger impact of what they’re trying to do. And that’s one of those ways that organizations are able to overcome the latent bureaucracy will let everything slow to a stop if you let it type problems. You’re able to communicate things in ways, other than putting it in the queue for the monthly company newsletter or something like that, that you’re using your connections and relationships that you built up, in order to do more. And sometimes that means that the person that you’re talking to, is the conversation you’re having with them strictly on their list of Q1 priorities? I don’t know, but it’s important for the impact that you’re trying to drive for this product or the company or whatever.

Bruce: Yeah, I love those disruptors, the ones that cross organization lines. I imagine, if you looked at their slack node graph that you would see a very distinct pattern for people that are good at crossing those boundaries and getting things to happen. Those are the special people in an org. I believe everybody has a lot to offer, but occasionally, things will get stuck in just the shape of the organization and that whole view of “Let’s get it done, let’s make it good,” will cross all of that. And I think that’s a good sign of an org, when it can happen. It is not the default, but it will happen, and it will make things better.

Allen: I’ve been told a couple times that, if you try to analyze who your strongest salespeople are in a org that has a sales team that, if you just index on which salespeople talk most frequently to engineers, then you’ll find the best salespeople often. Because they’re not just in this little silo. They’re like, “Okay, I’m going to go and find more information about these things and actually understand them.”

Bruce: Yeah, it means a lot to engineering to be heard and to be understood. Commonly, there’s a gap between engineering and product. Many product managers don’t come from an engineering background, and it does make it difficult to retell a story that’s coming from engineering. “We need to do this, because of this big engineering thing.” And to say it without embarrassing the engineers or mischaracterizing the problem or even the timelines involved, it means a lot for that to be accurate. There’s a lot of trust built in knowing how to do that. I don’t think every product manager needs to be like that, but learning to do that and then, taking the time to care and to talk to engineers is a huge deal. Same goes for design, QA, if you have it, support, making good connections, if you have analytics teams or comms teams, it really is about having good connections and good trust between those. It’s amazing what the people side of it can do.

Allen: Interesting that you say that, that not a lot of product managers are coming from engineering backgrounds, where that varies a lot, I think, from company to company. My understanding, talking to someone at Shopify, they were saying that a lot or maybe the majority of their product managers at one point had come from an engineering background. I was talking to somebody from Jane App, which is one of the largest startups here in Vancouver, and they have a lot of their product managers coming from support. Because they’re very support and people oriented group. And then, obviously, there’s some companies where design is the common path. On the teams that you’ve been working on, what is the typical source of the product manager, so to speak, when you’re trying to recruit people in, I guess?

Bruce: So we’re about half internal and half external, but I don’t know if these are real stats, but from my experience, it’s about half and half. I would say, internally, support and engineering are two big sources. Design is also occasionally a source. The people who do design tend to really love it, so they tend to cross over less often. Externally though, we find people are coming from sales or previous product orgs where they have MBAs, and I think an organization needs a number of people thinking kind of more about business strategy than about product strategy. But having them in the product org is helpful, because then, you have good thinking about metrics, good thinking about measurement of success. So as an engineer, my idea of metrics is kind of different than that of somebody thinking like an MBA, where I’m thinking, “How are these things performing? What are the latencies involved?” Very engineering centric, where somebody from the business side will be looking at, “Okay, what’s the engagement level? What are the cohorts and segments of these folks?” And it’s not that, as an engineer, I can’t think like that. It’s not my default. And so, having, for us, I like having the mixed org, because I have other people I can work with, that can ask really good questions around, “Okay, does this prove anything to the business or to our sales goals or any of these other things?” I have seen organizations though that are very anemic in the sense that they have one flavor mostly of their product people. And I think, for us, we’ve been lucky, because having been acquired, it changes kind of the nature of the org. So we’re kind of two orgs, and we will be for a number of years. And so, we have some of that MailChimp DNA that was primarily design driven, design and engineering, but so, a lot of our product managers were from engineering. And then, as we grow, we are hiring more people that have that business sense, and it’s a really good balance. It’s improved our org substantially.

Allen: Yeah, I guess there’s a bit of a stereotype among the engineer founder driven companies that thinks of it as maybe better to train engineers to think about business than it is to hire business people and try to get them to think about engineering. But I imagine, as you get to the scale of a company like Intuit, that has a lot of different lines of business, that are maybe fairly different from one another, in terms of technologies and things like that, that one thing they have in common is it’s all business.

Bruce: In the end, it is, especially as a publicly traded company. It changes the nature. You report on things differently. There’s more detail needed. You don’t shoot from the hip as much as you would from a founder-led startup. And it’s like both of the models are good in their own way. Founder-led startup can move very quickly, but they tend to focus less on specific sales goals. And then, an organization like Intuit has this incredible focus on business principles, and I don’t know, I love the contrast between the two. Because we do better work now in many areas because of it.

Allen: That’s interesting that you say that, because I think there’s a bit of a stereotype that bigger companies are worse at focusing, that you end up with more and more different competing interests and you have bureaucracy and politics and those things can be a distraction. So it’s interesting to hear you say, I don’t know if this is about Intuit or maybe it’s lucky that the group that you’re in, or maybe it’s just a bad stereotype, that these big companies end up unfocused and not able to rally all in a common direction. You get a whole bunch of different groups all kind of at odds.

Bruce: Yeah, it’s interesting. From what I know of other companies of similar sizes, there is a huge amount of focus on the business side, and it’s often very good. Perhaps as an engineer, that doesn’t seem like real focus. It’s like the no true Scotsman, that’s not focus unless it includes these things. Business focus is boring for an engineer generally. At least my experience as an engineer, I remember thinking about it, I’m like, “That’s just all nonsense. Why do I care about any of that?” But it turns out it’s very helpful for figuring out how you’re growing, who’s using your product, who to talk to, and having strong focus there. Businesses are not often successful without that business focus, and sometimes, they are successful. And then, they’re wildly not successful later, because they’ve missed out on building that strength on the business side.

Allen: Yeah, I guess you end up the mentality of someone with a product or a design or an engineering background may see lack of focus, where someone who has an MBA sees focus, where you look at a business that understands that their entire business is about ads. And the product people think that the entire business is about having a clean user experience, but it’s like, “Well, if we had only one of those things, which one could pay the bills?” It’s like, well, it’s the ads, and it’s like, it is your choice to work in a company that has ads. We all know that this company is fueled by ads, and we’re going to try and have more ads, because what kind of business this is. And an engineer or a designer or whatever might see that as a lack of focus, because in their mind, they come from a certain perspective, where the focus should be on minimalism or whatever it is that, in their view, is the thing that brought the product to success in the first place, which might even have been what brought it to success in the first place. But I think you’re exactly right on, where you have two different perspectives of one group just describing something as focused and the other describing it as unfocused. It’s like, “Oh no, we’re focused on the bottom line.”

Bruce: It’s the “everything is crap if I don’t like it” viewpoint, and we all fall to this. It’s easy to not appreciate the amount of work that goes into the other side of this, but you see it when you start to succeed. So if you can look further off in the distance and kind of track your progress, you can see, “Wait a minute, this stuff that I think is really boring or this stuff that doesn’t fit my engineering perspective, it all really matters to the business. It’s helped us pick features better.” I think one of the results of that is the software you end up with is not as clean and simple as the design aesthetic you might want it. And the reason for that is is that the world and business and life, none of those things is clean and simple. You look at Apple’s biggest improvements, and they’re not the fact that there’s less green carpet in applications, it’s that the very small features are well tuned to what they need to do. Apple loves to applaud these tiny improvements to their system. Often, when you hear it, if it’s a thing that’s been bothering you, like “Wow, that’s amazing, that’s exactly…”

Allen: “Multiple timers at the same time.”

Bruce: Yeah, “Now I can cook two things at once.”

Allen: I know. I’m excited for that one. I think I went through this same process a lot with how I related to the Amazon product. Many people I use and like many people with a design background, I was like, “These people are incompetent. How did they design such a bad page? There’s so much just ugly nonsense here and pieces of it that are rough edges, and this is objectively bad.” And then, the more people, that first, certainly the further I got in my career, but also the more people that worked at Amazon and the more I understood how they design things and they make decisions about what goes into the products, it’s like, “A lot of thought is going into this and a lot of work is going into this,” and there are certainly ways that it could be aesthetically nicer, but they’re deciding to do the things they’re deciding to do for very good business reasons, that result in things that they’re measuring. And nobody there is like, “Why don’t we try making it nice?”

Bruce: Amazon is a great example of that. I use a couple of their designs for projects that I work on as a contrast to how everybody else does it. So not even considering AWS, AWS is the product of hundreds of thousands of hours of talking to customers. All of the weird things in AWS are because somebody asked for them. It’s not because some engineer thought, “Hey, this would be cool.” They have a company that was using it, and it was important. So it gets added, and there’ll be a checkbox for it somewhere that doesn’t make any sense, but it’s solving a real problem, which is amazing. But even if you look at their store product, the way they store products and the way you actually put products into Amazon feels so 1997. It is janky and weird, but the result of it is such fantastic software. You have this huge catalog that crosses all of these manufacturers, not that it isn’t without problem, but that jankiness is capturing the real world need there in a really good way. Aesthetically, maybe it’s not great, but it functions. And in the end, that’s one of the important parts, and it’s profitable. Who argues with that?

Allen: Yeah, it’s interesting. Switching back a couple topics to something that I wanted to just dig a little deeper in and see if you have anything to share on this is you’ve talked a little bit about this path of you’d been one of the co-founders and CTO and designer at this commerce startup. Startup got acquired by MailChimp, which got acquired by Intuit. And so, you’ve been through this loop now a couple times of these acquisitions, like the fish eating the bigger fish eating the bigger fish chains. What have you learned about surviving and then thriving through those kind of acquisition scenarios, where there’s so much uncertainty and so many other people, I don’t know how your team fared, but often people do end up bouncing out or bouncing off of these changes?

Bruce: It is a tough problem to switch from a small org to a larger org. There’s a huge ego shift that I saw all of our teams struggle with. I was a CTO when I entered MailChimp, and I was a senior engineering manager when I landed. That’s a demotion, according to their org chart, of four or five. It’s not really a demotion, because you’re still managing the same scale of operations. But you don’t have that title. And I think ego is the first hard hurdle, the first difficult hurdle for people. Second is that you’re picking a subset of your job, and you can pick incorrectly. I picked engineering management, and it was good. Mentoring engineers is fun, and following their careers, there’s a lot of joy to be had in that. But I didn’t feel as effective as I could. I just pivoted, because it looked like it would be easy to do. But some of our other previous staff members, it didn’t fit them, and they couldn’t see a place where they would fit. They wanted to go back to that small and more intimate team. I loved doing things at a big scale though. So for me, it was just a matter of looking and figuring out where I should be. I did get a piece of advice on the way in. One of our leaders took me aside and said, “Hey, you should look at switching what you do every three to five years. You’ll get bored.” Especially now that I’m no longer young, I want to make sure that I’m engaged with the work that I do. So looking to switch either the area of focus or even the type of job that I spend most of my time with is a really good way to keep engaged with the business and the work and to keep growing. I think maybe we miss that in our first acquisition. Second acquisition was much easier. So going from 10 people to 1500 people, that’s multiple orders of magnitude. And so, we went from 1500 people to, I think, it’s about 15,000 people. So we really just added two layers of insulation above us. The difference to us individually was much smaller in comparison. Still, you’re navigating a much larger org, and there are things that are slower because of it. But overall, the impact wasn’t as large. Now, the cultural change was quite a lot, because there were expectations. We are this cool hip culture, which to most of us doesn’t mean a lot, because none of us are cool and hip.

Allen: But MailChimp had these goofy animations of the monkeys and stuff like that. It was particularly part of the, at least from the outside, it always kind of seemed like a company that didn’t take itself too seriously or at least took itself less seriously than Intuit seems to take itself.

Bruce: Actually, Intuit also is pretty cheeky. It’s a different being the accounting software kind of, you have the classic joke, you have an accountant in a room and an engineer and a designer and something funny falls out of that. It’s definitely MailChimp is the designer in that joke, and the accountant is Intuit. And it’s not as kitschy as MailChimp was, but that’s okay. It was actually getting in our way sometimes. So I love the culture that MailChimp had. I do feel lost for parts of it, but there are other parts of it that I think it was time for us to grow up. 20 year old company needs to, maybe we don’t need a room that’s covered in skateboards. That was our board room, because we didn’t have a board of directors.

Allen: Okay. I can see how that would be cute for the first decade, but eventually, be like, “Okay, I get it.”

Bruce: Yeah. And I think Dan wanted his skateboards back.

Allen: Sure. So that’s really what all drive the whole acquisition. I’ve been asking a little bit recently about folks’ thoughts on career paths, because there’s more career change happening for people in our industry right now than there has been in previous years. You mentioned, for you personally, that you ended up settling into product management as something more satisfying, partially because changing things up means leads to more learning, but partially because you found you personally were having more impact. Do you have an instinct on what kind of things might lead somebody who is moving on to the next stage and saying, “Okay, well, I’m not just going to be…?” Not just, but they’re moving out of an individual contributor role, they want to be in more of a leadership role from their engineering role, and weighing, “Okay, would engineering management or product management be a better path for me?” Do you have an instinct of what kind of folks might thrive more on the engineering management path and maybe might not product management as much? Or are you the wrong person to ask, because you’re the person who bounced in one direction?

Bruce: I don’t know if I’m the right person to ask, but I have observed a few people. So we have a mentorship program internally, and so, people have the opportunity to say, “Hey, I’m a senior engineer, and I’d like to try being an engineering manager,” or “I’d like to try to be a product manager.” And so, as opportunities arise, people are able to try it. It’s always interesting to see who succeeds and who struggles with those changes. I think a lot of it has to do with your comfort level with uncertainty. So engineering, we get very comfortable with knowing how everything works all the time. If I set this to one, it’s always going to do this, unless there’s like a plasma field or something comes from space. But you’re certain about so many things in engineering, and when you move over to engineering management, you’re dealing with people. And people are not as predictable. So you have to be okay with the social costs, personal costs, when dealing with a lot of people, because you’re helping people through the best and the worst of times. And it can be very fulfilling to do, but it can also be very draining for some individuals. And then, when you look at product, you also add onto that the uncertainty of where the business is going, what the goals are, what the metrics are, and that uncertainty you have to make peace with and say, “These are the principles we have to point us at this set of goals we have. We’re measuring it, so we’ll change it, but we don’t know it’s going to work.” It’s nothing like engineering, where you can say, “Yeah, it passed unit tests, I’ve debugged it, walked through, looked at all the data. We know it works.” With product, you don’t know it works until much later. You can measure it, and you have some positive feedback. But it’s these increasing levels of uncertainty. Your comfort level with that is very important when switching to it. You have to be okay with it. And then, there are other things you do in these jobs that you write a lot or you speak a lot and you have to get comfortable with that, and networking becomes very important. Arguably, it’s very important as an engineer in a large organization as well. But I think it becomes more important as you’re affecting more change, because you want to unblock more things and not be a blocker for other teams.

Allen: Yeah, I think that all the things you mentioned is being more comfortable and being more effective in the presence of uncertainty and ambiguity and having more demand on your networking and connection building skills. Those skills seem like, I guess, there’s definitely some of a difference in between the needs for them in product management versus engineering management versus a senior individual contributor. But as we were talking to Nick, who’s in this sort of staff plus role at Amazon and anyone else who we’ve talked to who’s in those senior IC roles, will tell you the same things is that, if you’re a senior engineer or certainly an intermediate engineer, you have certainty of there’s ones and zeros or whatever, but if you’re going to be a senior staff, principal architect, or whatever, you’re probably dealing with a whole bunch of different teams that have different priorities. And it’s unclear how to go about doing different things. And some of the things on the roadmap are not going to get done, and it’s not totally clear what the consequences of which things will or won’t and how to balance all these different things that are all in the air. And your schedule often ends up being at least half meetings with other people that aren’t even on your team. And like, “This isn’t programming.” It’s like, “No, you’re a leader now.”

Bruce: Well, it is programming, but you’re programming humans. And it’s a much messier experience.

Allen: An indirectly programming. So I guess my question of that is, do you have any principles or habits that you like to go to when you’re needing to work or make decisions in this sort of high ambiguity, high uncertainty, low information environments that you kind of end up needing to deal with in product leadership and leadership generally?

Bruce: Yeah, I was recently trying to write an essay about managing through chaos. There are certain points in organization timelines, where it gets very chaotic. You have some big release coming up or you have some big set of changes that you’re trying to coordinate between multiple teams. During those times of uncertainty, you can’t really see that far ahead, because things are changing so quickly. So you have to fall back to, first, principles. And I tell my team this all the time, and they hate it, because it doesn’t mean a lot to them, but I say, “Let’s focus on doing good work. We know where we’re aiming at, but we don’t know all the details. So as questions come up, let’s make choices that are good choices.” This is better for our customers, this is better for the data, this is better for the infrastructure or for performance. Have a list of really good reasons why we’re doing something. And then, if we need to stack, rank it against other work, we can say, “Okay, this work is better than this work,” and this is without having a direct business metric for it. Ideally, you would know everything, and everything would have a metric and you’d say, “Yeah, that’s affecting it more. Let’s do that.” But when things are more chaotic, you have fewer of those measures. Things are changing too often to really know if you’re hitting your targets. So focusing on, first, principles is a really good way of making sure good things get done. And generally, when good things get done, the results are that you have improvement overall, but it’s hard to do as an engineer, because certainty is your happy place.

Allen: Yes. It reminds me of the advice that often happens on a team sport, where if you’re having a hard time, some things are going wrong, the team isn’t performing, things aren’t clicking, is that they just go and have a practice of doing the most basic things, just shooting free throws over and over and over again or something really basic, basic, basic. “Okay, we’re just going to do skating drills,” and these are like NHL players who’ve done these skating drills 1 billion times. And “Is this is really adding anything incrementally?” It’s like, all probably actually yeah, because if you’re not sure what else to practice on, practicing on the fundamental things actually probably does align up well with the more complicated things that layer on top being better.

Bruce: Back to basics is always a good strategy when things aren’t going well. I coached the soccer team for 12 years. We did the exact same thing. So when you would have a few games that just everything falls apart, you’re like, “Okay, let’s do triangle drills, let’s run laps,” and all the simple things. And when I talk about it with my teams, I usually talk about knife skills. So we have cool down weeks, and so, I say, “Hey, focus on something that you’re uncomfortable with, something you’re not good at. Pick a small project to work in this time that makes things better, but also kind of pushes your skill further. So it could be a logging project or some advanced query thing, where people aren’t comfortable, but work on it in a safe space and get good at that thing.” Much like a chef would get good at using their knife and somebody with enough experience and enough knife skills can do pretty incredible work. And the same goes for software or soccer or hockey, if we have to talk about hockey.

Allen: I remember, 20 years ago, I was running some service on some VM, Linux VM, and I was getting frustrated and complaining to you about having to deal with something along the lines of the package management system or upgrading to a new version of something. And I was like, it was ops, it was before even we had the term DevOps. It was like DevOpsy kind of stuff. And I was complaining to you, “Oh, why am I having to do this stuff?” Or “I don’t understand this stuff. Let’s just not” or whatever. And you were very specific. You’re like, “This is a skill, it’s going to suck. And then, you’re just going to hit your head against it, and then, you’re going to understand it. And then, you’ll be like, “Oh, okay.” And then, for the rest of your career, then it’ll be fine.” And I was annoyed, but then, a week later, I was like, “Oh.” And then, for the rest of my career, I’m just like, “Oh yeah, I’m just going to administer this machine” or whatever. And that is an example of that, that you have all these little blinders around of things that you are super great at, and spending a little bit of time leveling those up can have huge, huge dividends.

Bruce: It really does. And DevOps is a good example, because it is not fun work for most engineers. It’s frustrating, it’s opaque, and if you haven’t dug into understanding how it works, it takes a long time. So that is one of the best core skills as an engineer is to keep your system running and to be able to prototype quickly, and all the stuff in that is kind of the boring stuff unless you happen to be a DevOps person, in which case it is your favorite part.

Allen: But the thing I found was not as much that it took a long time to understand that stuff, but that it was very unclear, at any given time, if I was about to understand it. It feels like, “Okay, well, now if I resolve this Python error, what if I resolved this Python error?” You always felt like you’re in the desert without a map, and then, suddenly, it’s like, “Okay, it works.” And then, you feel awesome, and then, next time, you resolve that problem much faster. But although that’s a lot of debugging, but I feel like, when you’re doing it for ops stuff, it feels slightly less like you’re, I don’t know, doing a creative act and a little bit more like you’re just mangling machine.

Bruce: There are more moving parts, it’s install an OS. There are hundreds of different services running and different things that could be wrong with it. And it’s often very simple. But finding the simple thing is about learning how to bisect problems and troubleshoot and just not care that much about how long it’s taking. You’re going to fix it, and just, if you keep cutting the problem in half, you’re either going to find you run into problems or you’ve identified the problem.

Allen: And of course you’re also practicing that habit, which is itself going to the really basic basic, that’s the running laps of engineering is systematically figuring out where the problem is coming from. As we come to the end of the episode, I’m curious if you have any favorite lessons learned or interesting mistakes that you’ve made or been part of, that you would be up for sharing.

Bruce: Might be faster to talk about the mistakes I haven’t made yet. Yeah, that’s actually a pretty tough question. There are lots of mistakes that we hit in software development, just generally. They’re all mistakes that are well known, well recorded, in our hubris and in the chaos. We hit them anyways. And it’s always entertaining. You’re like, “I knew that Brooks’ Law was a thing, and here we are. We’ve added six more people.” So I’ll talk about this. One of the recent projects I worked on a couple years ago, we were tasked to build a big thing. It was a really good idea. There were business pressures that made it look like a good idea for us. So we started along the road of doing so, and this was back when I was Head of Commerce. And so, we hired and we hired and we hired, I was probably in 20 or 30 interviews a week, and we scaled from five people up to about 125 people, I think, in the end. There was an acquisition that was part of that, that I wasn’t responsible for, but it was like it was all toil, it was all scaling. And you know that that means that certain things are going to be very slow. But we didn’t really think about the sequencing of, normally, when you add people, you add them more slowly than that, especially if it’s in a startup. In a startup, you add people based on your runway and your funding, and that doesn’t often require you to go from five to a hundred in the span of six months.

Allen: What org has ever survived that?

Bruce: I will say that our particular org did not survive that, and it wasn’t because of the thing we did. It was ill advised, it was painful for many of the people involved. It turns out the business case wasn’t as solid as we thought, and it’s normal to pivot in business. So that part, it feels, as the engineer in me hates to throw stuff away, the business person in me knew that it was the right decision to move on to different projects. That wasn’t the worst part of it, but we really failed in having the right people involved as well. So we actually hired a set of product managers that were all great product managers, but they never worked in this space before. And it turns out, we go back to stories that we were talking about earlier, unless your product people and your designers can talk about the stories with confidence, they can’t do their work with those things. And so, when it comes to cutting scope, if those stories aren’t part of your team’s DNA, cutting scope becomes, it’s like rolling the dice. It is a meaningless experience. What happens at the end is going to just be a random assortment of features that will not capture what people are really thinking. You don’t have the relationships with your customers to know. You don’t have the stories that you’ve been telling over and over for months. So I think my biggest mistake is trying to do something so quickly. I’m easily excited by a problem of “Let’s make this big thing,” and I’ll be like, “Okay, let’s go do it.” So we execute all of the pieces of it well, but then, the whole machine doesn’t necessarily work. It would’ve taken another six months or a year to get that machine to really focus on the real problems. And so, yeah, trying to over speed up development is almost always a bad idea. I’m sure, given enough practice, you could get good at it, but I don’t think I have enough cycles left to do that too many more times.

Allen: Yeah, and I think you hit on something that is, I think, one of those known things, but we, like the mythical mammoth, people will forget it is that product leadership, when the product is in new, which obviously, if you’re going from five to a hundred, you’re not doing something from scratch, but it’s obviously taking on a big new initiative. Product leadership requires one of understanding of the domain, like deep understanding of the domain that they’re designing for, or an existing product with metrics and virtuous cycle that they can then iterate on from an analytical approaches. And so, if you are building something totally new, you need the first category of people in a pretty substantial volume, to the point that a lot of startups end up with these things where you get advice like “Don’t hire a chief product officer until you’re under serious pain.” Have the founder of the thing be doing the product leadership as long as possible, because going in and hiring, unless you can get somebody who’s seen your product, that really understands that domain, which is rare, because every startup is in some other different domain, then having that be somebody with a lot of that experience making those decisions, until you get this real actual validation loop and traction and product market fit, then that’s when the MBAs can be more helpful at that stage.

Bruce: And of course, we always think if we got to do it again, but if I got to do it again, I would put together triads ahead of time. And I would let the triads hire or I’d let them work with a hiring partner instead. But figure out a lot of the product direction well before you try to do your main staffing. Part of that has to do with discovering what the stories are, who the customers are, what your segments and cohorts and everything are. Doing that ahead of time, having the understanding of what it is and if it’s even possible to build, that is probably a much better approach.

Allen: Sounds like a plan. Well, we’ll all do that next time. Thanks so much for your time, Bruce. It’s been awesome having you on the show. If people want to learn more about you and the work that you’re doing, where can they go on the internet to learn more about Bruce?

Bruce: Like many other people on this show, I am not on socials as much as I used to be, but I am on Mastodon at Bruce Alderson. I am on Twitter occasionally, Bruce.Alderson. And I have a website that I haven’t posted to in ages called warpedvisions.org, which I’ve been running for about 30 years now, though I’m now officially running it into the ground.

Allen: That’s now official. It has been now announced on the show.

Bruce: I’ve now announced it, so I must do so. No, I’m sure like a Phoenix, it will rise and become something again.

Allen: It has risen again many times, and I’m sure it will again, at least a couple more times.

Bruce: I’m sure it will. I’ve realized that what I have to say isn’t that new, and so, as I gain experience points, I realize that writing needs to be thought out a little bit more. So I’ve been taking my time.

Allen: You say what you have to say isn’t that new, but we’ve learned on this very podcast from you that telling the same story again in different ways can be really useful to the audience.

Bruce: Yes, but telling people how to write parsers at Pearl is probably not something that’s interesting anymore.

Allen: I’ll give you that. It Shipped That Way is brought to you by Steamclock Software. If you’re a growing business and your customers need a really nice mobile app, get in touch with Steamclock. That’s it for today. You can give us feedback or rate the show by going to ItShipped.FM or at ItShippedFM on Twitter. Until next time, keep shipping.