Decisive Moments Podcast (by Plato)

[00:00]

MUSTAFA KHAN:

Today’s all about how leaders, why should leaders create and have a robust management philosophy. So we’re super excited for that conversation.  David take it away.

DAVID MURRAY:

All right. Thank you, Mustafa. Hello everyone and hello Lawrence. Thank you for being with us.

LAWRENCE BRUHMULLER:

No worries. Happy to be here today.

DAVID MURRAY:

Awesome. So we’re going to dive in and actually I already see a bunch of questions. So far we have 11 questions asked so as folks are thinking about questions that you want to get answers to, or maybe follow ups to things that you hear Lawrence share, feel free to put them in the Q and A button in the bottom left. Click on that button, you’ll see a list of questions and you’re welcome to upvote other people’s questions. So I’d love to get started with just like the quick sort of high level like tell us about yourself, things that you might imagine, folks might want to know, and just kind of start from there.

LAWRENCE BRUHMULLER:

Yeah. So good morning, good afternoon, good evening everybody. It’s great to see people from all over the world. I am joining you all from usually sunny – but it’s a not so sunny – Oakland, California up in the hills. So I see we have a few of the people from Oakland joining.

So I am the CTO of Optimizely. I’ve been at Optimizely for about six months. And for about the past 10 years or so I’ve been in various engineering kind of head of overall engineering leadership roles. Before Optimizely, I was at We Work heading a major piece of their technology build out when that company was in a hyper-growth mode. Before then I was at a pure SaaS company called Clear Slide. And before that, I was actually in the security space for a while at Symantec where I came in through the acquisition of a company called Vontu. You can see all this on my LinkedIn anyway. But that’s kind of the Head of Engineering /CTO part of my career. And it’s all been in the Bay Area.

Actually I was originally born in Hawaii, but I grew up in San Diego. And then I went to college, Harvey Mudd in the LA area and then about a few years after college, I moved up to the Bay Area, and it’s been pretty much Bay Area ever since. And it’s actually up until recently it’s been pretty much downtown San Francisco ever since. So for those of you who are either from the city or spend a lot of time there, it’s just been basically me moving from various dots, you know, south of Market here, then a few blocks and up here, and then over here. I remember initially coming up and thinking that I would have to some point… when I first moved up there was like no tech in the city. It was like a bunch of bankers and some media and I was thinking eventually I’m going to have to start commuting down to the South Bay and I just kind of put it off for a while.  And thankfully the tech moved up and so it was pretty much been San Francisco the whole time. Of course, now we’re all just hanging out in our homes. So it’s quite, quite different.

That’s a little bit about me and I guess during the course this hour, you’ll probably learn how I think about software engineering and building teams, but that’s kind of the outside picture.

DAVID MURRAY:

Very cool. You know, it’s funny because I had the kind of the opposite, which was starting in Mountain View in the South Bay in the suburb area because it’s the heart of Silicon Valley. I’m like, Oh, it’s so pretty and there are trees and parking and blah, blah. And then seeing at least startup lands, you know, folks trickling up to the city in droves. And now it’s really only the really large companies that are still in the “valley” Valley. So I guess it ended up working out for you in terms of location.

LAWRENCE BRUHMULLER:

Yeah, at least in that chapter, and now we’re in this next chapter where we’ll see how it goes.

DAVID MURRAY:

What is location right? Deep philosophical question. Yeah. Very cool. Well, thank you for sharing that.

[03:40] How to Define Management Philosophy vs Set of Habits

DAVID MURRAY:

And we actually have the most upvoted question which is the best tee up ever which is , in  practice, how do you define a philosophy of management?  How you distinguish it from, say, just habits?

LAWRENCE BRUHMULLER:

Yeah, well I think about it as far as: what your core principles? Like the word philosophy is interesting one, but I also just replace it with like, what are my core tenants or principles for how I do my job. And my job happens to be ensuring leadership and management, so therefore it’s how do I do that?

And so that’s:  what are the principles that I could take from environment to environment that would be the underpinnings and everything else I’m doing? And even if I’m adapting things because this one’s a start up, this one’s a bigger company, this one’s all remote, this one’s an altogether different kind of technology, what would be the same?

And it’s got to be some kind of a fundamental principle, almost like these are my top three or four principles. If I was writing a manifesto, what would that be like?  And I think if you do that, you’ll find that those are going to be pretty fundamental beliefs about how things should be done. And not kind of more tactical habits like something like, I tend to have one-on-ones with people every week. That’s a habit. Maybe you’ve built that up and you think that’s really good. And you think that people who don’t do that often enough are making a mistake. That’s kind of there’s probably a reason below that, that makes you think that’s really important. So kind of trying to find the fundamental “whys” behind those habits would be the way I think to distinguish it.

DAVID MURRAY:

That’s interesting. So when I when I hear the word principal I’m immediately reminded of principles by Ray Dalio. I don’t know if you’ve if you’ve read it. But, you know, this idea of like setting these principles as kind of almost the most important thing when you’re going into anything work related in that if you’re clear and explicit about those principles, then you’ll find that the organization around you and the culture you’re setting underneath you will tend to adhere to those principles. Whereas if you aren’t explicit and you aren’t having that clear conversation with at least yourself to determine what those principles are, that kind of culture defines itself. And sometimes the things that get defined aren’t always as great as you would like.

LAWRENCE BRUHMULLER:

Yeah. Kind of like the culture just happens to you, so you should be more intentional around it. I don’t know. I think I started to think about this more after actually going through some more kind of job search energy cycles, where I realized I was being asked this and maybe you know if you rewind a few iterations of my career, I was kind of winging those answers.

And I had a feeling that maybe I was good at certain aspects of management. Some things I needed to get better and I’d be trying to articulate that in an interview and realized I was kind of making it up as I went along. Like hmmm, okay I really need to have my kind of top points in my head and convince myself that those are the right things and then you know this is going to be really easy to talk about it. So it kind of came up very tactically like “lets interview better” and then I realized it was actually much better when I joined that new company, and it was much better talking to my peers outside. And so, from there it became a clearly more useful thing, you know.

[06:50] Best Strategies for Sharing Philosophies with Team

DAVID MURRAY:

Sure, completely. So this is great. There’s so many more topics we actually already have 18 questions. So I want to dive through them.  Briefly before I do, I just wanted to acknowledge and thank our sponsors Lohika who are wonderful engineering services, built for a singular purpose, which is to help VPEs and CTO clients grow by scaling their engineering organizations through core services and people. So thank you Lohika for your gracious sponsorship.

So with that, moving on. What are the most effective ways to share your philosophy with your team and what strategies have worked best?

LAWRENCE BRUHMULLER:

Yeah, so I’ve ended up writing some of this stuff down for my own use. And depending on the culture of the team I’m working with, I feel like it needs to be delivered verbally or it can be delivered in a written form. So that’s why I feel like it’s okay to adapt. Some cultures are more like document-based cultures. We have a lot of Google Docs floating around, people comment and they, you know, spend a lot of time asynchronously before they get together and discuss something. And other cultures are more like “hey let’s get together”, let’s have live synchronous voice protocol” as I call it.

And really get into it.

And so I think depending on those [differences], is going to affect the best way to get your message across. But I think either way, as the leader, you need to have in your head, which means it’s probably written down somewhere, at least for you. What things are most important to you and what core principles are most important to you? So I always have something written down. And it’s in my personal Google Docs and it evolves over time. And it’s not really long you know, it’s a page and a half or something like that. It’s evolved over time but it’s kind of my personal reminder of what I stand for. And then, yeah, how I choose to put that out there is different.

Maybe one other difference is how much you would show up and be like, Hey, I’m here and here’s what I stand for.” How broadly would you talk about that? Like would you talk about that with your entire company or entire team or more with the people you’re working closely with?  I usually do both. You know, I kind of start off with talking to people who I’m going to be working very closely with, who report to me directly, and make sure they understand and they can therefore help amplify the message when I’m making it more clear to a broader set of people.

[09:07] Bruhmuller’s Set of Principles

 

DAVID MURRAY:

I’m curious, you mentioning this Google Doc, like if you have a set of actual principles or core philosophies that you might want to share for yourself not saying that everyone has to adopt everything you have. But I find that folks have a story regarding how some of these principles get developed. So if you reflect for yourself maybe what are some of the most important principles to you, if not the whole list. Up to you. I imagine a lot of folks would be curious.

LAWRENCE BRUHMULLER:

Yeah. Yeah, I figured. This might come up. And so, yeah, without screen sharing it or anything or reading it all, I’ll give you a couple of high points. And then yeah, this might provoke more questions.

One of them is really specific. You could argue whether it’s specific to how it’s going to software engineering teams should be run versus just management in general. But I really believe super strongly and self-organizing teams. And I think I got into this when I really started to embrace agile and realized that what had I thought I had been doing was not agile and was more mini-waterfall. I got into like actual agile and then realized that I think I felt was underpinning of that was actually having teams that are self-driven self-organized, self-managing and they can rally around a certain higher-level goal and figure out how to accomplish that.

And figure out if they want to go fast or do something big, small, they can do all those things independently. And I had a lot of success in making organizations that way. So that became like my biggest thing. If I saw setups that we’re trying to be more kind of command and control where you have all the orders, you know, dispatched from above, they all go down the chain of command and that people at the bottom of the organization just execute, I just saw how that was fundamentally flawed. But it keeps coming up and you know you think maybe we’d be all beyond that by now but it keeps coming up in a lot of organizations. So that’s probably the biggest one.

Is if you believe in that and kind of go with that worldview, then leadership job, it changes. It changes, you know.  Vision and very high-level goal setting, but then it’s like, how do you actually have a culture where these self-organizing teams can thrive? How do you form them, how you decide how to, you know, they still need like management and support. So how do you do that? That’s probably the number one.

And then maybe a couple of the ones I’ll throw out there. And then, I’ll step off the soapbox for a minute, but I think, you know, having the self-organizing teams means that teams can have their own goals and the team goals become more important than individual goals. And that’s another thing that I just feel strongly about. I feel like the more you get teams of people the right size, really working together as a team, more than a group, you should be looking at what their highest priorities are and the team should be rallying around the highest priority. As opposed to, you know “this engineer works on this, this engineer works on this.” And then, you know, in a spirit of giving everybody something to lead. But then it gets like really distributed. It’s unclear what the highest priority is. Are you starting a lot of things without finishing a lot of things?  Like those kind of things.

I feel like having team goals is a really, really big part of that. So let me pause there. There’s probably a bunch of other stuff I could say, but that’s probably the biggest one that’s in my belief system.

[12:32] Individual Goals vs Team Goals

 

DAVID MURRAY:

For sure. And it’s, it’s great that you explicitly call out like “team goals matter” in that it seems obvious, but there are such a large number of folks, particularly those who over index on the, “make sure my team feels good and is nurtured etc”, [who] over index on an individual’s ability to achieve the things that they want for their job and their career and their growth. But the most recent example of this, I recall for myself, talking with, actually with a mentee on Plato, he was this is a VP of Engineering at maybe like a 50-person startup and he was mentioning that one of the people on his team wanted to leave. And part of that was because he wasn’t learning the stuff that he wanted to learn. And the initial inclination was, “oh gosh, let’s find a project” that lets him, that he was excited about. Some particular type of front-end technology. And, you know, it was like, well, I want to give him an opportunity to learn this, but the actual needs and goals of the team have no interest or opportunity or need for that technology right?

And this where I think if you define clearly that philosophy as you just stated, you know, then there’s a clear winner, right?

And essentially, it’s like, what do you say then, you say, okay, we don’t have this opportunity right now, and maybe there’s a way to explore it and or maybe you have to think about if you still want to be here, etc. But I appreciate the idea of acknowledging this explicitly. That that matters. That is a thing and not everyone does it.

 

[14:13]

LAWRENCE BRUHMULLER:

Yeah and there’s a balance, right, because, I mean, you could go too far the other way, which is saying, hey, you’re on this team this team is supposed to do X, here’s the, you know, top priorities for Team x and that’s all you should be doing and that stack rank, regardless of what you want to do. And that doesn’t work either. Really talented engineers want to be challenged. They can get stale on certain teams. They need to be pushed to get to the next level in the career ladder. So that’s where engineering managers really have this huge role to play to sniff out the motivations of people on their team. The mix of seniority and juniority and just how it’s all going to work out with the team goals in mind. So there’s still a lot of art to it.

You can’t ignore what people’s individual needs are, but it’s just kind of like taking a step back and saying okay “yeah we’re doing all this stuff” this is still in spirit of these team goals and we still making progress on those. And that’s the ultimate kind of measuring stick.

[15:08] CTO vs VPE Role at Optimizely

 

DAVID MURRAY:

100%, totally makes sense. So moving on with questions. How would you characterize the split between CTO and VP of Engineering responsibilities at Optimizely?

LAWRENCE BRUHMULLER:

Good question. Yeah, I got this question even when I joined around what the expectations are this role because previously there was an SVP of engineering and then one of the cofounders Optimizely held the CTO title.

And you know, I think the CTO versus VP of Engineering roles, it’s kind of morphed over time in my 20 years in the industry, 20+ years. Where it used to be that the CTO was like a very technically focused. Sometimes almost purely outbound, sometimes almost purely inbound, kind of [an] IC role.  And the Head of Engineering or VP of Engineering was the organizational leader.

And over time, like sometimes you still see that very clear split, but sometimes you see that morphing into a singular role. And that’s kind of the person who oversees everything but also has a strong technical vision about things. So that’s how I put myself in that bucket. I think that’s why I was, you know, that match that Optimizely needs. And so that’s why it worked out.

You know, to really own the organization and how it’s going to evolve and how it’s going to thrive, but also have a very strong opinion about the technical strategy of the products and how we’re building things.

And the way I think about that is, I’m not the one who’s in there, trying to out code my team or be the ultimate architect, but I’m going to pressure test a lot of stuff, especially on architecture. And you know, I want to be able to understand exactly why we’re doing things the way we are and really ask those kind of tough questions and pressure test things and sometimes it’ll actually influence and change decisions.

But that’s not the goal. The goal is to make sure that the team that is there feels like I really understand what their challenges are and understand the problem. I have a stake in it. I’m not just going to go on, you know, consensus, what do you all think. That’s kind of how I blend the technical aspects with the organizational aspects but the same time, you know, running a big organization that is a huge job and you got to do a lot of stuff just to make sure that it’s healthy and thriving. So it’s a tough balance, but I actually feel that combo role, if you want to call it that, I actually think it’s the right model for a lot of companies. I’ll put it that way. And I’m personally having a great time with it.

DAVID MURRAY:

That’s great. You know, it’s interesting because I imagine most of the folks that have that are connected, who have either served in a VP of Engineering or CTO role or who are in a small startup, for which there is somebody in their chain of command who serves either of those roles or both of those roles. For sure, most of us have Googled “difference between CTO and VP of Engineering” right? And most of us read the same blog articles that talk about exactly what you described, right? That the VP of Engineering is kind of more focused on the people management and the CTO is more focused on the technical thing and like once in a while, there’s that rare Blue Moon where somebody can serve both of those roles and just to confuse things further that person tends to be called CTO, you know, because there’s a chief in the title. Right. And so the thing that I appreciate, though, is particularly folks just diving into this conversation, they’re looking for models and they’re looking for what’s normal, what’s typical and it evolves over time and changes over time, right? And I think what I’m hearing from you is that what’s normal, typical what works for Optimizely and other companies is to have those roles merged, but that’s particularly because you’re capable of doing both of those roles right? And not every organization has somebody who is capable and because of the beauty of the Dunning Kruger effect – feel free to Google that if if you’re not familiar with it – there are plenty of people who maybe think that they’re both or identify as both. But may have so little knowledge about one of them that they think that they’re good at it because they don’t have enough knowledge to assess that they’re good at it. And that whole Dunning Kruger thing.

LAWRENCE BRUHMULLER:

Well, it’s also a little bit about, making sure they’re not overly divided though either. Exactly. I’ve seen cases of where you have somebody in the CTO role and somebody in a VP of Engineering role and they’re almost like so clear, like “I play this position”, “I play this position”. They’re so fundamentally different that the interplay is lost. You have to build an organization with, you know, technology goals in mind. It’s not just, outputting code and outputting features and then turning the crank. So the strategy really is part of that. And so I feel like they really have to work well together. So I think the times when I’ve seen it work well together with two people, they are really, really close peers. They communicate really well. And the times when of course you know we can all probably think of these cases where it goes south is when they’re like, totally different islands.

And you can even suss that out sometimes in interviews where you may see you know there’s a company, usually a start-up, a highly technical really smart founder CTO type [who says] hey, you know, could you join this company and like help us out with that people stuff? Like yeah well I could, but let’s talk about how it works together and what we’re trying to build here and you know really bring it together more. I think that’s the model of success, whether it’s one person or two or more.

[20:32] Management Philosophy for In-House vs. Outsourced Teams

 

DAVID MURRAY:

Hundred percent. Awesome. So moving on. How do you think about your management philosophy on in-house teams vis-à-vis outsource teams or teams supplemented by a vendor.

LAWRENCE BRUHMULLER:

Great question. Yeah. I, I feel that you have to think of this all the same way.  Again this is because we’re doing, we’re talking about software engineering, there’s a high level of ambiguity uncertainty in the work, there’s a high level of trust you have to have with the people. And this is not like factory assembly line stuff. So I think all the same principles that you have around a self-organized team that is, full time employees if your company and your same office versus, something very different remotely, maybe they don’t work for your company.

You really want the same motion to get the same result. So the times I’ve done working with an outsource vendor, it’s been in this kind of team augmentation model. Where they are willing to have really good people, and they’re willing to learn your process and really understand how you want to work. Are you using Scrum or Combine or how do you want to work with PMs and Designers? And they’ll understand that, and they’ll actually make it work with you. So it’s more like a team extension. And those are the times that I’ve actually found it work very well. And so two companies ago, you mentioned, Lohika, the sponsor of this podcast Q & A, I used them to great success, a couple of companies ago at ClearSlide. And actually it was one where I inherited a San Francisco-only local team, and not with the desire to save costs, but with a desire to grow the team in a more effective way, get it distributed, get an increased hiring pipeline, I chose to build this team in the Ukraine. And we built it in the image of, these self-organizing teams and with the agile process we had, we were kind of moving to Dev Ops at the time. And with that in mind, the right vendor, you know, flexed with us and learn with us. So not only did it kind of snap into our process well but also I feel that if you do that kind of thing, you retain the best kind of talent on the vendor side.

These vendors, they have their own job, which is to get the best, most talented engineers into their company wherever they are. And what could happen is if you don’t set things up right or you don’t give them the right kind of work those people will trip. They might not leave that outsource company by they might say, “hey I want move to this other project” and that kind of churn can really be the bane of any kind of offshoring. So one way to really minimize that is to have good work good kind of component or module ownership with the team over there, wherever “there” is and you actually keep the best people. So these are all kind of the things I found really work well, but, they still kind of come down to: treating them not really differently than you treat your own teams.

DAVID MURRAY:

It’s interesting because the way that you described it almost sounds like, outsourced vendors that are particularly affected, whether it be Lohika or others kind of function almost like stem cells. You know, you put them close with a team that has a preset culture and you know, whether they are in Ukraine or in anywhere around the world, they are able to meld and merge with the existing culture and just kind of function as part of the team and still operate independently with their own. If they’re independently driven as you’ve kind of described as your model, they’re able to just do that naturally and organically with the folks around.

[24:20]

LAWRENCE BRUHMULLER:

Yeah, and so that cultural “norming” is a big part of it. So back in the days before February, when we could fly around more freely, I was really big on that. So, you know, when we had these teams in the Ukraine spin up, we’d have the leads and actually a few the other people fly over and spend, you know, multiple weeks in our San Francisco office, really getting to know the team.

Working alongside them. It’s much different when you’re actually working side by side with somebody and don’t just have meetings scheduled. You just kind of work in there and if you have a question, you walk over and talk to that person.

So making those investments which that’s a lot of upfront investment to spin up a team, but doing those things, I felt really paid off. Of course now we have to fundamentally rethink that in the new world, but I think all those investments make it feel more like a team that is just like another one of your teams and not like “those other people”.

[25:22] How Management Philosophy Changes with Environment and Business Needs

 

DAVID MURRAY:

Sure. So this next question is kind of in a somewhat similar vein, which is how does a personal management philosophy compared to the philosophy of “change with the surroundings”, or people or environment business needs, etc.

LAWRENCE BRUHMULLER:

Yeah. So I mean, I think one way I try to suss that out is. It’s helpful if you’ve been had a leadership role at a couple different companies. You can you can just look at your own track record and compare, what felt to you like it was durable across those things? Because you know you those companies were probably pretty different in some ways, and so what really translated well?  And what did you need to adapt? But that that gets back to that question around habits versus your fundamental principles. So the whole thing I talked about around self-organizing teams that is something that I feel so strongly about that, there’s nowhere I would join and thrive that and be the right hire for, that didn’t believe in that. “Actually, you know what we like command and control, we don’t really want teams to kind of make their own decisions, we want them to execute clearly on these this set of requirements” It wouldn’t be something where there’s like an adaptation and make. It would be like fundamentally against my worldview and I would just tell them, I’m not the right leader for you.

But there’s a lot that you do have to adapt to from place to place. And also, you know, even over time the environment changes. So there’s things that I used to think we’re pretty good strategies that I think the environment like the market, maybe changed and I had to adapt to those things. So a lot of the stuff you write down you have like that’s the challenge is like trying to try and abstract it sufficiently so you think it really is durable. And even then, you’re going to change that stuff. So yeah, maybe a little bit of is don’t take it as you writing some gospel. But you’re just writing something to keep yourself kind of checked in your own head, and make sure you have some fundamentals that you’re carrying along.

[27:22]  Pattern Matching for the Right Fit

 

DAVID MURRAY:

Sure. You know, it’s interesting because I come up with really random analogies that are completely unrelated to like engineering world, but somehow seem to you know make things relate. And I think about how, as engineers, we tend to like having black and white answers to things. Very clear yes / no when we’re listening to conversations like this. We’re looking for the absolute like, “am I doing this the right way or the wrong way.” Like, Lawrence, show me the vision of what’s the right way and what’s the wrong way right?

But the vibe that that you’re kind of alluding to is that it’s really more about having clear principles and finding a match for compatibility with those principles as opposed to some kind of absolute. I think the analogy that I was thinking about was, as it relates to like relationships in general, sometimes we think to ourselves that and this could be whether romantic or regular, you know, non-romantic relationship, that there’s some kind of absolute for somebody to be. For somebody that we’re working with within our lives and the reality is that it’s not about finding some kind of absolutes. It’s about compatibility. It’s about sharing values, sharing goals right? And aa result, like it doesn’t matter, whether you’re in software or you’re in hardware or whether you’re in one vertical or another, like, what matters is that you have that compatibility of values and interests and that what you described with self-organizing teams and actually just philosophy in general, a word that I like to use to describe sort of things like pattern matching, right? You’ve had all of these different scenarios or situations where you’ve seen this way of structuring be very successful and so you have this pattern matching. When you have folks who are in teams like this they’re likely to be successful. And as a result, if you end up interviewing with a company and you find that their team and company and organization has a very different set of patterns that they match to, you may find that it’s not a fit and you should probably interview somewhere else. Yeah.

LAWRENCE BRUHMULLER:

Yeah, I think that’s right. I think it is a lot about pattern matching and trying to, again, the more you have a couple of different stints, the easier it is to do this. But trying to divorce the overall success of the company or the project from what you did as much as possible. Because you can definitely have this kind of attribution bias, where you have this one startup ended up not going so well, and so, everything you did there is a big question mark. And meanwhile, you’re over here and your timing was right and this company went IPO. It was awesome. And therefore everything you did there must have been really the right call and you were the best manager or leader ever. And really checking yourself and trying to tease apart, what did you really do that affected the outcome? What learnings from the failed one are still like really good things that you felt good about and would do at your next job proudly?

[30:32] Attribution Bias vs. What Really Works Over Your Career

 

DAVID MURRAY:

I love that you mentioned attribution bias because it’s like such a common thing. Particularly in Silicon Valley right when you have folks who go off and they’re like strike it rich with their startup and it’s very easy to convince yourself, if you’re in some wildly successful thing. I did this, like in year two at Gmail, right? I joined a year or two after it started, still early days, and it was wildly successful and I thought okay, everything that we’re doing must be right because we’re seeing this success, right? But then when I went to like a startup and I took some of these structures paradigms models that were, you know, Google, I don’t know how to like 3000 people or something that, and it didn’t work. Right.

Similarly, you may find that you do something that you see time and time again is successful, for example, like even structuring the teams as you described, and they self-organizing way and you have failure. And because the attribution bias. You might go, oh, I shouldn’t have structured things that way. Right. But it’s “no” confounding variables, if you separate things out. You might find that… I mean actually just happened with my first job as an engineer, and it was audio internet and video which is like, you know, yeah, they didn’t audio back in the day for cell phones, back before smartphones. And like I was like kind of miserable but so I thought, oh, is this what life is like as an engineer. Maybe I shouldn’t do this, and like then kind of went into product for my first full time job, but then later on in life, a couple years later, kind of discovered I really missed coding etc and fell in love with it so that idea of attribution bias of separating out what you’re doing and the results and that those two things may not correlate. They may not… one may not be actually leading to the other, it may just be something else.

LAWRENCE BRUHMULLER:

Yeah. Well, it’s funny because, you know, now at Optimizely, at this company that is all around like the scientific method and rigorous statistics telling you know the result of an A/B test and you know not letting small numbers of samples really skew you. But the thing about your career is you just don’t have, the “n” is not sufficiently high to do you know, a real kind of analysis. So you have to go on something more. You have to take a different approach. And I think that’s where you have to kind of look within yourself. And think about what’s most important to you. And what you would… even if you’re not getting interviewed, it’s like you’re interviewing yourself… what would you really take to the next place and you feel strongly about, you want to build on. And what are you actually going to really adapt. And, you know, talk to people like us, you know, forums like this or other networking ways to make sure you’re not reinventing the wheel or getting feedback. But you have to have a different approach. Unfortunately, two or three data points isn’t going to tell… isn’t going to be a conclusive A/ B test here.

[33:32] Applying Your Management Philosophy to the Whole Organization

DAVID MURRAY:

Totally. 100%. Does your management philosophy apply to your direct reports only or to your whole organization? If the latter, how do you manage if your directors or managers don’t share exactly the same principles?

LAWRENCE BRUHMULLER:

Yeah, I think it really has to apply to everyone. But how effectively, you can do that, you know, depends.  So you know the biggest impact you can have is working with your direct staff and I do a lot of that. So probably relative to the average leader, I would say I spend more time with my direct reports as a group. And really do what I can to make sure we’re working properly as a team, that we’re sharing things across with each other. That there’s people who are driving initiatives that are outside, that help the entire organization, not just their part of it.

So, you know, I do a lot of that. But then, you know, part of that is leading by example and showing people, Hey, that’s what I expect and so therefore you know you with your management team or with your team of engineers, I’m expecting something similar. I’m expecting no silos, no hoarding of information. Do the right thing for the business, not just for your own your team.

And so those things kind of trickle down and then you can kind of augment that by talking about that a bit broadly.  But you know, it’s never going to be perfect. The bigger organization gets there’s going to be some pocket where you get, especially if you do some sampling or auditing and, you know, walk the halls. You got to realize, Oh, well that’s not how I would have done it. And then you have to really check yourself like do I want everyone to be exactly like me here? Or if there’s as long as they’re following a couple of key principles that are the most important things to me, then we’re good. And so I think that’s the kind of check and balance you have to do. But you know there are times again where you will find something that’s different than how you would have done it. But you have to take a step back and realize it’s okay.

There’re other times where you might audit your organization and realize, actually boy, that goes against my worldview. That’s like a no-go. Let’s address that and figure out how to how to really change that now.

[35:42]

DAVID MURRAY:

It makes sense. So the takeaway, I get is that of your core principles or values, there’s kind of a set of them that may be true deal breakers if the folks on your team don’t really truly share them. And there may be a set that are still important, but like if there’s some kind of fundamental core value or belief that conflicts with that from someone on your team that it might still be navigable and you kind of have to ask yourself for a given principle or a given person, Can I live with this or not? And this is why you know sometimes you find that when you have a new leader come in if they really strongly care about a certain value or principle or way of doing things that sometimes it is intractable. Sometimes it’s not going to work out but other times you find that there’s a way to navigate through and I guess that you have to have the conversation, right? About if it’s going to work.

[36:37]

LAWRENCE BRUHMULLER:

I think that’s right. It’s a conversation. It’s a process. There’s no, oh, let me see your documents. Okay, cool. It looks like… 0.4? Nnt for me. And it’s never that black and white. And so it’s also about how as a leader you assess this stuff do you just assume it’s all happening or what are the methods you have for seeing if that what you think everyone should be doing is actually reaching everybody? Do they hear it? Do they agree with it? If that feedback isn’t reaching you. All those mechanisms are pretty important for this topic.

[37:10] Matching Engineering Metrics with Hiring Culture

 

DAVID MURRAY:

100%. So we got about 15 minutes. So I’m going to start going through a little bit of a semi-lightning round.

LAWRENCE BRUHMULLER:

I love it.

DAVID MURRAY:

The questions as you want. We won’t be able to answer all of them, but, um, so, any tips for marrying engineering metrics with hiring slash culture eg. What are some of the most effective ways to engender focus on metrics?

LAWRENCE BRUHMULLER:

So I’m interpreting the question is not around, ensuring metrics around hiring, but how you actually if you want a good metrics mindset, how do you kind of hire for that and how do you have a cultural set for that tot?

DAVID MURRAY:

Exactly. That’s my interpretation as well. Yeah.

LAWRENCE BRUHMULLER:

Cool. Um, yeah. So I think you actually, you just have to interview for it. Like you interview for anything else. I think this is a case where behavioral interviewing is the most important.

You know, there’s a lot of stuff in our industry where you have, the coding focused interview, the more design architectural you focused interview and then you have another one which is really more of a conversation. It feels very conversational, but it’s a very focused behavioral interview by a good interviewer to kind of drill into parts of someone’s experience and find out like how they overcame a certain challenge or executed a certain project. And so that’s where you want to really focus on these aspects that are the most important to your culture. And so having somebody have a real metrics focus is really important. That’s where you’d really drill into something in their past, and try to get a real sense, with concrete real things: What were the, what were the measurables? How you know did you know successful? What were the business outcomes? Who objected to those? How hard is it to measure? And then you spend your hour on that. And I think that’s how you can really do that kind of a hiring side.

On the cultural side I think you just have to make it clear that it’s really important. And just saying metrics are important doesn’t really help. You have to demonstrate that by having metrics that you pay attention to and you hold people accountable to and you don’t kind of lose interest in. So I’ve always been about having a small number of important metrics. So right now, probably the biggest one I think we’re focused on at Optimizely is lead time.

And again, this is not that revolutionary and I’m a big fan of the work that happened with Accelerates and with DORA. All those key measurables being most correlated with high performing teams. But lead time is the one where I feel now we have the most work to do to Optimizely and so we’re focusing on it the most. And so, the more I pay attention and my leaders pay attention to that and keep our eye on the ball and if those trend properly, then we’re a little less focused on how somebody solved the problem. That’s the most important thing, then we’re leading by example. We’re showing metrics-based behavior. And then people can follow that. So I think that’s doing is much more important than telling in this case.

[40:13]

DAVID MURRAY:

Totally so I kind of two takeaways from what you mentioned. Number one is to be explicit and to actually like consciously look for this in hiring and consciously have the conversation, you know, culturally, and then show if not tell. Regardless of whether you tell or not, definitely show you

 

LAWRENCE BRUHMULLER:

walk the walk. I guess is that’s it.

[40:38] How to Manage Upwards and Have a Difficult Conversation

 

DAVID MURRAY:

Totally makes sense. Um, what are some ways to share your philosophy up the management chain with a goal to influencing change. So I know that having your team emulate you, not so hard in that people tend to do that. But if you have, let’s say somebody above you who’s doing something that you kind of feel isn’t really healthy or functional or that you’d like to be different, philosophically. How do you navigate and manage upwards?

LAWRENCE BRUHMULLER:

Yeah, that’s a good question. I think there’s two interesting forks to this question. One is around if people who are above you or your peers are questioning how you’re running your own organization.  Which happens, right? As an overall Head of Engineering, you might have a lot of autonomy, but then you have like the CEO or the Head of Sales who’s like saying, hey, why are you doing things that way? Maybe they really like having the entire team have one big deadline. And that’s immovable and doesn’t have, you know, more of an agile aspect to it. Maybe they want things measured in a way that I don’t agree with. So that’s where there’s a lot of education. Like, hey, you know, maybe the reason you brought me in was because you feel I’m good at this. But let me try to really educate you on how why I feel this way. So if this is the way I think we should be run, let me let me sit down with you and walk you through why, including some previous experience.

So it’s really taking the time to like seek out that misalignments Like maybe the, CEO, maybe the Head of Sales doesn’t actually understand it. Maybe they’re misaligned. So instead of kind of ignoring that and hoping they don’t bother me, let’s seek it out and tease it apart and then have the conversation. So that’s kind of how I’ve had to do that numerous times with peers on an exec team or a CEO.

So that’s kind of on that side. But the other interesting aspect to this question is around just like how I feel about how you know things are going at my level with my peers and let’s say the CEO. And that’s where I just think you have to be even as a new joinee, you have to be willing to find a voice on what you think might change. If you think that this certain meeting needs to go better or you’d prefer things with this way I always just suggest things and I always do with a smile on my face and good intentions. But you know just showing up and snapping in and trying to assimilate is not the job. I think at this level. You really need to come in and find a way to work with people, but bring new thoughts, new energy. Maybe, you know, it’s just been done a certain way and if you show up and have some new ideas, you actually get a lot of appetite. So I feel like that’s a real key when joining a senior leadership team is to bring new ideas and not be afraid to voice them.

[43:36] Leaders Speak About the Elephants in the Room

 

DAVID MURRAY:

Totally. The saying that’s in my mind as you’re talking was talking about the elephants in the room. As things come up that are sensitive and not spoken right I mean in organizations actually just culturally, just in general at wherever we are, elephants in the room aren’t talked about, kind of by definition, right? And as a senior leader, you have an opportunity to share the elephants in the room that are unspoken. I find this is really common with things as they relate to, for example, diversity and inclusion, where there are kind of unspoken things that are going on that don’t feel great to a set of folks for which there’s another set of folks that are completely oblivious to that kind of stuff that’s going on. And sometimes those folks were being affected may not feel empowered or have the energy because they’re just kind of run down by having to deal with this over and over again to surface this. To kind of pick that battle and a senior leaders, we have the opportunity and kind of the obligation to create an environment that’s comfortable enough that those things can somehow be identified and discovered and then be that person to have those “elephants in the room” conversations and mention hey, this thing that’s happening or this unspoken philosophy that exists whether we like it or not, you know, needs to be addressed.

[44:58]

LAWRENCE BRUHMULLER:

Yeah, I totally agree. And I feel like I even try to do this when I’m hiring for a senior leader on my team. Is you’re really expecting this person to come in and add value, not just kind of take over an area and snap into your framework. But you’re expecting them to add their own thoughts and that’s how you get the best people too right? You mentioned compatibility. They have to be compatible. But if they’re just exactly like you or they act exactly like you because they want to fit in, that also is not really you’re not maximizing the value of that hire.

You defined, you know, some more diverse thinking and have a setup where you’re encouraging me to come up and I feel like that’s, it’s part of part of leadership job is to get that dialogue going. And sometimes I’d like to do in front of everybody. Sometimes it comes up separately and you have to tease it out. But yeah, there’s elephants, you know, we all have elephants that we’re not talking about. And you know someone shows up and like, hey, look over there. You go “thank you”. Thank you for saying it. And you have to encourage that. So I feel like it’s a big aspect of leadership.

DAVID MURRAY:

Totally and doing it in a compassionate way. Sometimes we forget about that part right where we just kind of throw the elephants charging into the room. But if it’s done in a compassionate way of and it can sometimes be very well received. Right.

[46:16] Ways to Thrive Post-Covid

 

DAVID MURRAY:

What fundamental shifts do you think that has started with Covid but you believe will sustain past recovery, and we should take advantage of, to thrive post-Covid?

LAWRENCE BRUHMULLER:

Yeah, this is a big one. I’m sure we’re all really thinking about this, like, what is working now and what what’s working now is translatable in like a longer term? As opposed to just, if you think about the current situation as time-bound. And some point [with] Covid, you’re going to have a vaccine. It’s going to be over. Or if you think about, like, hey, what if this was like this for a long time?  How would that change my mindset around doing what I do? So I think we’re all thinking about that quite a bit for me.

Going remote first is has a lot of attraction for me. Since it happened at Optimizely it was only five weeks after I joined by the way so that’s very interesting, where we all just went home.

We had a we have the bulk of our team in San Francisco, we have a small team in Austin. We had some teams where team membership was across both and we had a few people in remote sites. And we had the problem, which happens everywhere, where if you’re the one or two remote people on a team that is mostly co-located, you’re in a world of hurt. You’re always the one being forgotten about, you missing the hallway conversations, you can’t quite hear with the audio quality, and it really affects things. And you try to overcome that by good Zoom and people flying around, but it’s never as good as it could be.

And so, you know, boom, switched to having everybody remote first and some companies have embraced this long time ago. Suddenly, it’s a level playing field. And so I’m seeing that. I’ve kind of always thought that that would be an interesting experiment and now we’re doing it in real time. It’s really working out. Where everyone is the same size picture on the screen. Everyone uses the same tools. And I think teams are really, really thriving. And also I think they’re really, really taking advantage of the fact that they have more flexibility and don’t have these commutes and can kind of quickly snap between things.

It isn’t all good, though. You know, we’re all kind of have this tax over us where you know there’s burnout. You can’t get out of your house. You really can’t do the social bonding with people personally. If anybody has better answers on how to make Zoom happy hours really work, let me know, because I find them, I don’t know. I don’t want to start ranting about it being intolerable like once you get past like three people. I actually, I actually wrote a feature request to Zoom on what I called Happy Hour mode. It’s a story for another time.

I think they’re busy fixing their security, security vulnerabilities right now, but anyway. I feel like this “remote first” everyone’s on the same page is really effective. So how do we make that work post-Covid, in a way where we can still leverage, we can still get the social glue that we’re missing right now. And so maybe that’s like people are more distributed remotely and you don’t have as much dedicated big office space, but you still have some way to get people together, you know, periodically. Maybe it’s once a quarter, who knows? To really hang out and rub elbows with each other when that’s possible. So I think that’s some kind of magic balance there that I’m looking to strike. But we’re definitely onto something. I think going back to how it was is not the way we should do it.

DAVID MURRAY:

Makes sense. We have one attendee who mentioned Happy Hour icebreaker on my team, everyone shows their pets. That’s interesting.

[49:48] Best Ways to Identify Talent in Outsourcing Companies

 

DAVID MURRAY:

We have just a couple more minutes. So we’ll see as many questions we can squeeze in. Someone mentioned I’m considering using teams that are outsourced. What is the best approach when identifying companies and talent.

LAWRENCE BRUHMULLER:

So what I would say there is to start with the goals. Why are you outsourcing? And everything should lead from that because people do it for different reasons. Some people do it explicitly to save money. And if you’re doing that, then you really need to look at what you expect in that total cost of ownership. Think about the overhead of, you know, where the team is and how they want to operate and try to build a total cost of ownership model for yourself and use that to evaluate. And find someone who that aspect of it is what they focus. But there’s a lot of reasons outsource it or not, that they are around, you know, getting access to different pools of talent. It could be around, you’re in more of a customer facing model you need a Follow the Sun, kind of setup. So think about why you’re doing it and find a vendor that really matches to that.

[50:50] Shift Your Mindset When Transitioning from Engineer to Engineering Manager

 

DAVID MURRAY:

Makes sense. When transitioning from being an individual contributor into an Engineering Manager slash lead. How would you explain the necessary shift in the mindset?

LAWRENCE BRUHMULLER:

Yeah, what I say about this one is, your job is not to be the smartest person in the room. And, you know, you could also maybe say that as a senior engineer you also don’t want to like dominate everybody but to some degree as a senior engineer, you are supposed to be really competent, the trusted opinion on really tough issues. So in some cases, you are supposed to be the smartest person in the room, even if you do it in a collaborative nice way.

But as a manager, you’re really trying, it’s your job that the team does the right thing. But without you actually have being deep enough into the domain or actually doing the job and to be, you know, again, like the architect and the lead developer and the boss. There’s a reason why those patterns around having separate career ladders have emerged. Like it or not, it’s not your job anymore. So giving that up is hard for people. And there’s some companies that just kind of have developed their management culture on like not worrying about that. Smartest engineer becomes the manager, smartest manager becomes the VP,and I just kind of reject that. I think you have to understand that this is a different job you have now. And yeah, the fact that you used to be really good engineer, very important. But that’s not your job anymore.

DAVID MURRAY:

Totally and the set of skills required to do to be excellent as a programmer, for example, can be or are completely different from being an effective people manager. Right?  So it’s a good to be sensitive to that.

[52:30] Personal Onboarding Strategy for Success

 

DAVID MURRAY:

Last question, since you joined Optimizely six months ago. What was your personal onboarding strategy to make sure you were successful?

LAWRENCE BRUHMULLER:

Yeah, this is interesting one because in this case there was a period of time where the person who had the SVP role was overlapping with me for a while. And so I felt like I didn’t have to come in and take the operational reins of the team right away. So I actually allowed myself a little bit more of an extended onboarding than I ordinarily would have. Which is good because Optimizely has been around for 10 years. It’s got a really deep set of technology that they use in their products. So there was a lot of reading and a lot of investigation, a lot of archaeology. So I gave myself more time to do that than I would have in maybe a different kind of company. But I think it really paid off. So I spent more time, you know, meeting with more people reading more things, getting into the code a little bit before taking over all the meetings and kind of, you know, assuming the role fully so it was more like a two to three month onboarding instead of, you know, trying to really rush it.

[53:42] Wrap Up

 

DAVID MURRAY:

Totally makes sense. Lawrence. Thank you so much for your wisdom, your advice, your thoughts and reflections. All the attendees: thank you so much for joining very much appreciate all of your thoughts and definitely have a lot to reflect on right?  When we think about philosophy as a whole and what our philosophies are I appreciate that you’re reflecting on being very clear and explicit about what your philosophies are. Being very clear about having an “elephant in the room” conversation that you need to have. And that you know that it’s good to look for matches in terms of that philosophy, but also you don’t want all people that all think and do and act the same because you know diversity is so important as well. So, so with that, thank you so much and I will hand the reins back to Mustafa.

MUSTAFA KHAN:

Yeah, so I guess in the last minute. So thanks, David for hosting and for that, that summary. And then Lawrence, obviously, thank you so much for your time for, you know, being our main guest. And then finally, just want to quickly give a shout out to our sponsor to our partner Lohika. So thanks to them. And in case you don’t know what they do. They help engineering teams scale up their operations, they work with lots of great companies like Okta, Twilio, Airbnb, Asana and then I want to thank you all for joining us. So hope you had a great experience.

Thanks Lawrence for answering, I think, was like 11 questions. So awesome to see that. And then, yeah, we’ll be sending you a video recording so you can share with your colleagues. We’ll also be sending a link to our conference site. If you want to RSVP to register for that. So with that, I want to thank you all. Take care. Have a great rest of your Wednesday, and we’ll see you next time. Bye.

DAVID MURRAY:

Thanks.

LAWRENCE BRUHMULLER:

Thanks Mustafa. Thanks Dave. Super fun. Thanks.

DAVID MURRAY:

Awesome.