Harry Brumleve on Optimizing Yourself and Enabling Great Culture

00:35 Introduction

00:35 Harry Brumleve: Well, I've been in software on and off for a long time, over 20 years. I've had an opportunity to start software engineering at a very young age. My mom got me a computer when I was six. I'm sure that's like a common story for people my age, that they just got their first TI 64 and started programming way. I have a degree in German, kind of got coursework in computer science. So still fell in love with computer science, and I had an opportunity to live in Germany for a little bit since my mid twenties. And then when, since I've been coming back, I've been either at a really big company like Nordstrom or a really small startup that you wouldn't recognize. And so I kind of vacillate between those two extremes. My goal is to learn a whole bunch of awesome stuff and make large organizations a little bit better. And then once they may or may not let me do the awesome things they train me to do, then I move to a startup and do that.

01:28 Shane Hastie: So tell us about the Track, optimizing yourself human skills for individuals at a technical conference.

01:35 Overview of the Optimizing Yourself track

01:35 Harry Brumleve: Yeah, that's pretty fun, right? I have a core belief that was shaped a lot by Nordstrom and their human centric design, and their people lab that better software engineers don't produce better code, better people create better products. And so if you want that better outcome, you need a better person and I can't make you a better person, but I can give you the tools to help you make yourself a better person, and that was kind of the goal for this track.

01:59 Shane Hastie: You've given us a goal there, give people some tools. What were some of the tools that came up? What were some of the key things on the track?

02:06 Harry Brumleve: Well, I think, it started off with communication, is a pretty big component and understanding that there are just different communication styles. There's a lot of white guys with a beard in this industry. It turns out we all talk the same and we all saw the same TV shows growing up, but it turns out also that again, we can only produce such a good enough product. We actually, diversity and inclusion practices yield amazing results, better work life, better, better, better, but it also means we have to deal with different people and dealing with those people, we should probably talk to them in a way that they find appropriate. And so things like the neuro-diversity aspect. Beth and I actually we're on the same team at Nordstrom, and she goes to this in her talk that, for the first little bit, there was a little bit of friction, to put it very mildly, not understanding how to work with each other, and then because of the team and Beth wanted to work with each other, they found a way, and it was communication crossing the chasm between neuro-typical and neuro diverse thinking.

03:07 Harry Brumleve: So I think just demonstrating that to people on the track that, Hey, there are people who can drive value and be good people and add to the success of your team if you communicate differently. I think that's where we started with that journey. Going on, it's more or less self-awareness. We had that in a product talk because a lot of engineers probably have a love- hate relationship with their product person, but understanding their perspective, practicing empathy, finding out where they're coming from and then working on yourself to be a better teammate is really important too. Design thinking skills, I think are really important, they focus a lot on that empathy and I'm tricking you into examining yourself to become a better teammate in order to be on a better team. And then the last one was Georgiy’s talk on basically empathizing with your manager. And so this whole track is focused on how do you become that better teammate. But again, I can't make you do that. I can only give you the tools.

04:07 Shane Hastie: So what makes a better teammate?

04:10 What makes a better teammate?

04:10 Harry Brumleve: Well, I think the best teammates are the ones who understand that there are people on the team who are not them, and you start off by either having empathy naturally, which some people are blessed with or cursed with, or having empathy skills, which is the strong imagination or working on your imagination, say, how would I react in this situation that that person finds themselves in? What have I done to contribute to that response? What haven't I done to make sure that person was successful or to help them be successful? And so I think that that awareness is really what makes a better teammate. It's not better software, that's a commodity at this point largely, like sure there's some brilliant engineers out there who are going to make a big difference on a team, there's people who don't need sleep as much, there's people who can find the next tool and learn it real fast.

04:58 Harry Brumleve: But by and large, building software is a commodity at this point being good enough, being a six or seven out of 10, typically can yield a reasonable result for software. But how do you parley that into a team's performance at a seven or an eight or nine? And I think being a good teammate, that is the characteristics of a good teammate, is when you're filling in the gaps for your team, finding out their strengths, finding out when they need help, being able to communicate when you need help. I think those are all aspects of a great teammate.

05:25 Shane Hastie: If I'm a manager, I'm trying to create a team, what do I do? Just randomly pull people together?

05:33 Crafting effective job requirements to attract the right people

05:33 Harry Brumleve: Yeah. In a way I think that's probably better than picking out a type of person. I think it starts off if we want to talk about how do you build a team in this day and age? I think it'd be silly not to acknowledge the internet. Like, you're probably going to get most of your leads through the internet somehow. And you are going to write a job requirement for someone to join your team. And that is your first impression and that is the first barrier of entry for everyone who even looks at it. And so that barrier should keep out the right people and let in those that you want to work with, and you're going to do that whether you intentionally practice that or not, right? Some people are not going to be happy with that, some people are going to be super excited.

06:17 Harry Brumleve: So going forward, I always like writing my job requirements, thinking back, like pretending using the empathy skill, except I'm emphasizing with me and a year from now, how do I feel? And what do I want? Can we train people to be awesome engineers, 100%? Can I train someone to be nice? Maybe that sounds like pretty hard. I'm way better training engineers.

06:40 Harry Brumleve: So when I set out to build a team, I'm going to tell you from the straight out the junior, senior, staff, manager, director, your job is to take care of your team. That's one of the first things. The first thing is we want to deliver product together as a team, we want to faithfully express business intent together as a team, but we take care of each other as a team. And how you do that is arbitrary, largely depends on your role and your passion and where you want to be on the team. But when I like to hire folks, I make sure that they're genuinely nice people who care about others. And if I get that, then the rest of the game is fairly easy, at least I know how to play the rest of the game.

07:22 Shane Hastie: Yeah. Richard Sheridan from Menlo Innovations talks about looking for people with good kindergarten skills. Do they play well with others?

07:32 Harry Brumleve: Sounds fun.

07:32 Shane Hastie: One of the challenges is that most organization’s structures and remuneration models and motivation tools are not designed to help you play well with others. How do we fix that?

07:45 Helping build collaborative culture

07:45 Harry Brumleve: One of the definitions of culture I throw around is, you probably know the providence of it, but culture is the least attractive characteristic tolerated by leadership, right? And so what that means to me is, first of all, the leadership has to be on board with culture, and the culture should be something that rewards people for being people, but also being people in that role that they're in. So how I like to approach that is to first of all, associate myself with an organization whose leaders I think value the same aspects of humanity that I do, start there.

08:25 Harry Brumleve: Second step would be, how do I create an artifact or leverage an artifact. Maybe it's already there, describing the culture and how people want to behave. What are the behaviors that we expect out of people who work here? Then I like to tie that to the roles in which I'm hiring for. And then I make it very explicit that this aspect of culture through the lens of your role is how you're going to be judged. So that, for instance, if we have a culture where, very common with this as boy Scouts, leave things better than you found it.

08:58 Harry Brumleve: So if we say as a culture that that's important to us, it may be that you express that as picking up trash on your way to the parking lot. Absolutely. You nailed it. But that is also not necessarily a great characteristic of a software engineer so much as it could also be a great characteristic for a barista or for an insurance professional. It doesn't really describe that. So how do you express that in a way that a junior engineer for a team or an associate engineer for a team knows how to express that through their role, so you have to tell them in many instances, but you put that through the lens of culture. So something like, leave things better than you found it in terms of a junior engineer might be something like if you find something, a bit of code that's not unit tested, write the test. If you find failing tests, write the test. If you find that some of the product requirements are vague, make them a little better.

09:50 Harry Brumleve: For a manager or a people person, somebody has a humanity. Maybe that's manifests itself a little different, where you have things like it becomes less tangible, but finding a teammate in a bad state, maybe they had a tough day, maybe things aren't working out their way, sitting down with them and just listening, leaves things a little bit better than you found it. So, giving those examples of how your role, that's also a good manager.

10:18 Harry Brumleve: So finding those ways in which your behavior through the lens of culture is identified, I think lets people grow and be respected. So then I can take that back. Say I'm trying to get a race for an associate engineer on my team, and I can say something like, not only does this engineer do XYZ, but also exemplifies our culture that you think is important by the way, because I've aligned myself with management who value this culture, but they do it in this way. Let me tell you why that's important. And so not only is that person performing as a good citizen, but also as a good engineer.

10:53 Shane Hastie: One of the things that we were chatting about earlier before we turned on the recording is influence without inflicting anything.

11:01 Harry Brumleve: Yeah – it’s hard

11:02 Shane Hastie: What do you mean by that?

11:03 Influence with inflicting

11:03 Harry Brumleve: The definition of a leader is largely like I'm going to help this group of people or organization achieve a goal, go somewhere, become better, there's probably a few other ways to describe that. But many people would give authority to that figure and you could wield it. So it could be good news, everybody, you have to do TDD, you are writing tests for everything, I don't want to see any production code in the branches until all the tests fail. And I'm agreeing with all the tests and they match all the problem, okay, I could do that. And that certainly would probably produce some value, but I don't think at scale. And it certainly has a limiting factor, which is me. That team now can only be as good as I am about issuing the right command and making sure that it's followed correctly. And I think that I want something better than what I can imagine.

11:57 Harry Brumleve: And I want something for my team and I want something for my organization and even myself that I think can only be reached when a lot of people work towards the same goal from different aspects and bring different parts of the solution to bear. And I find that influence as opposed to prescriptions often allows me to approach that. What the inflicting part is that sometimes my influence is like, you might want to try behavior driven development. Well, if I'm strongly influencing this individual, perhaps their code gets a lot better, behavior driven development is a great way to have clear requirements and have practice TDD and everybody gets happy, but what if there's a different way? What if that person can produce greater code than they are producing right now? The problem they're experiencing could be just masked by BDD. What if we could find a way to have the same outcome or better, or we're not even on the same plan of existence as the problem or the solution anymore if that person is able to express themselves appropriately.

12:59 Harry Brumleve: Now that's probably a hyperbolic example, but when it comes to solutions, I don't want to be limited by my imagination or my past experience. I want everybody to have that opportunity. So inflicting is the recommendation, even the casual prescription, even describing the outcome. I often try to short circuit them, but because if you don't do anything you're not a leader, you're just liase-fair sitting back, that's a good idea Billy, but it doesn't help always most of the time. So I try to choose one or the other of either prescribing a method or describing an outcome, either prescribing or describing, but never both. And so eventually I can get to the point where I'm prescribing more abstract concepts that have open-ended solutions. And then I feel like that's less inflicting.

13:44 Shane Hastie: What if Billy doesn't know how to do that? They just don't have the skill.

13:49 Harry Brumleve: Yeah. That's part of it, which is being careful, like domain-driven design is a great example. It's a really intricate software design methodology. It's pretty awesome, but it takes a while to get good at, you don't get the hang of it when the weekend. And so having someone in your mentorship or within your leadership support chain that could benefit from domain-driven design, you have to push them in that direction. And sometimes that's a slow slog where for instance in this model, while the way I designed code works, why would I change it? And it's a slow incremental step of now learning and bringing them up to the capabilities and building capabilities within that. But at the same time, you have to be careful of not building a zealot, specifically in the context of domain-driven design, there's places you'd shouldn't use it.

14:42 Harry Brumleve: And so that would be another aspect of inflicting. So bringing someone along so that they understand that this is a way that I've had success in a way that you don't have to have success, but might fit you right now. That's a delicate dance, and it's something I'm aware of.

15:00 Shane Hastie: What I hear described in there as the professional competency of mentorship rather than coaching or consulting.

15:08 Harry Brumleve: I think so. Yeah.

15:10 Harry Brumleve: And there is a book called adaptive leadership. Basically some people need to be mentored. Some people be need to be nudged, some people need to be sent a link. Some people need to watch a video. Some people need to fall flat on their face in front of everybody. Probably everybody needs some form of that at different times in their lives. So yeah. Mentorship in that aspect, for sure.

15:29 Shane Hastie: Let's shift gears a little bit.  We're both part of the InfoQ, Qcon community. This is the InfoQ culture podcast. What's special about the infoQ culture. Why are you part of this community?

15:44 The InfoQ community

15:44 Harry Brumleve: I know it's cliche, but the people, well, people make up communities. So maybe that's not cliche. It's 100% by choice. So it must be something. But I think the people here are very genuine. They want to help. They're super nice. And I don't think I've ever ran into somebody who I regret meeting here and they've always been kind and intelligent and willing to help and teach. That's pretty great.

16:09 Shane Hastie: So what do you do in the InfoQ community, InfoQ and Qcon?

16:14 Harry Brumleve: Ah, so I started off as an editor for architecture and design that was early teens, probably 2010, 11, somewhere around there. I was able to assume the role of the lead editor for architecture and design for a while, and that was something I was really proud of and happy to help others. And that role just basically was a series of, you're not as smart as you thought you were, here's some better architecture minds, writing stuff. So, yeah. Good.

16:43 Harry Brumleve: And through that, the Qcon folks decided to add me to the track host for a few Qcons. So I got to pick the speakers for a few tracks and eventually I was on the program committee for New York and San Francisco. And that was a lot of fun and a great way to help express some ideas without inflicting too much. And then now I just do track hosting. I've passed off the baton of the lead architecture editor role to Thomas Betts who's a much better architect than I, so I'm happy to do that. And now I just get to sit back and watch awesome people do awesome things. It's pretty great.

17:19 Shane Hastie: Harry, if people want to continue with the conversation, where do they find you?

17:21 Harry Brumleve: You find me on LinkedIn. You find me @harrybrumleve at Twitter. Don't check that as often, but I'm sure a quick search of all the Harry Brumleves in the world will be able to yield a good chance that it's me.

17:32 Shane Hastie: Thanks so much.

17:32 Harry Brumleve: Thanks Shane. It was fun.