Moving from Individual Contributor to People Leader

Shane Hastie: Hello, everyone. Just to let you know, our online software development conference Qcon Plus is back this November 1 to 12. You can expect curated learning on the topics that matter right now in software development. Qcon Plus is a practical conference, laser-focused on learning from the successes and failures of domain experts at early adopter companies. If you enjoy the conversations we have on this podcast, you'll get a lot out of Qcon Plus. To learn more about the conference, head to qcon.plus.

Introductions [00:52]

Good day folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today, I have the privilege of sitting down with Sam McAfee. Sam is the founder of a company, Startup Patterns, and he provides a lot of leadership, guidance, and support to particularly technologists moving into the leadership space. Sam, thanks for taking time to talk to us today.

Sam McAffe: Thanks for having me, Shane. It's a pleasure to be here, I appreciate it.

Shane Hastie: Why Startup Patterns?

Sam McAffe: Well, in a lot of parts of my career I've worked with startups over the years. I got my start in software engineering as a web developer during the dot com boom, and a lot of startups around. And so, I myself have had the pleasure and pain of participating directly in about a half dozen adventures as a co-founder or early-stage hire and I've also provided a lot of advising and advice and support for startups over the years and had noticed certain patterns. I'm a fan of design patterns as an engineer and so the name was originally for my book, Startup Patterns, and so the company is named after the book.

And the book was basically a collection of my observations and advice for people trying to build new tech companies from idea to initial working money-generating product. And so the book captures as many patterns in spirit of design patterns of trying to find what are the things you're going to run into along the way and trying to articulate that so that new people building new products and services can benefit from my experience and the other folks that I interviewed for the book. That's what Startup Patterns comes from.

Shane Hastie: If we can extend the patterns' analogy, what are some of the patterns that you are finding in the space of technologists growing their careers?

Many technologists come to a point in their careers where they must chose between cutting code or leading people [02:50]

Sam McAffe: I think there's a couple of things. I think that most of the people that I work with and help with their careers are on the boundary, or having just crossed it, from being a hands-on individual contributor, software engineer, or other technical person at some point, possibly through being a team lead, gaining some managerial responsibility but still having their hands in the code. And eventually, folks reach a point where they have to make a decision. They reach a fork on the road where your career is going to be managing people or it's going to be pushing code to production but you can't really have both after a certain period.

That's my opinion. I'm sure there are folks that have other opinions, but what I've seen, the work of being a leader in an organization just expands as you get more responsibility and more authority, managing more people, managing different groups and teams. That's a full-time job, there's really not any time for coding. And so I think that the folks that I work with often struggle to develop a whole new set of skills that are required to operate as a manager, as a senior manager or leader of folks that are doing technical work, where you're not really in the trenches anymore. You're there to inspire, support, remove blockers, to support with helping get resources that the team needs, that sort of thing. Talking to other non-technical parts of the organization to represent the team.

And those are very different skills for folks who have been engineers for a long period of time and feel really comfortable doing engineering. And you're now learning something new, you're a little bit starting from scratch as a skillset, and that can be very hard. I think one of the patterns is that starting over feeling that I used to know what my job is and now there's all this new stuff that I don't know and it's a little scary. That's one of the key patterns that comes up a lot.

Shane Hastie: I'm going to say that most engineers haven't got a lot of formal or informal training on how to become these leaders.

Most managers receive little or no training in leading people [05:01]

Sam McAffe: Oh, that's certainly true. Although I would say that being a leader or a good manager in general actually isn't that common. And when you look at other leaders and managers in non-technical parts of organizations, they may have MBAs, they may have learned some business administration, they may have learned about how the business works, but being a good manager I think it's probably more common now but it hasn't traditionally been a thing that is taught. It's something that's picked up on the job usually by looking at your manager and following their example and seeing, well, what's expected of a leader or a manager in my organization. You mostly pick that up from the people that you observe, that you report to, and follow in their footsteps. It's a very culturally passed on or inherited set of behaviors rather than something you would necessarily be trained for.

Shane Hastie: Is that a gap?

Successful companies have cultures that take leadership skills seriously [05:58]

Sam McAffe: I think it is. I really think that companies that I've seen that are high-performing, that have really positive, productive cultures, and I don't just mean it in a touchy-feely way, but companies that are producing positive outcomes in the market like producing products that people want and they're doing well and their customers like them, that have those kinds of outcomes tend also to have cultures that take leadership really seriously and have systems in place or mentorship or coaching programs or whatever it is, curriculum, they invest essentially in developing those skills for those people whose job it is now to manage people rather than build the widgets. And so I do think that there's a gap in that.

I think as companies grow from an early-stage company just achieving product market fit can very quickly become of victim of its own success. As more money is coming in and customers are asking for more features and we're hiring more engineers and we're growing the team, that growth can happen really quickly. I mean, that's the problem everyone's trying to have. If you do a startup we want to have all this growth, we want to hire all these engineers, but then when you add that many people, each of those individuals has a personality. They have feelings, they have values, they have backgrounds and experience. And if you're lucky or really intentional, rather, those are very diverse backgrounds and experiences. And that requires some intermediation through management, through governance, through various kinds of structures that allow people to organize the outcomes that they want.

I'm certainly a big fan of self-organized teams. As a long-time agilest I definitely believe in a lot of autonomy and self-organization. And I think there is a place for good management to act as the connective tissue between different nodes of self-organized teams in an organization that's getting larger. And so when you say, is there a gap? I think what typically happens is organizations will grow beyond their capacity to have a really safe and effective culture. And there's a lot of playing catch-up, oh, okay, now we've got all these people. We've deputized people as managers, they've never really been taught how to do it, and now what do we do? And so that's often where someone will call me and I'll have to come in and start maybe from scratch and say, "Okay, let's define what we mean by management and leadership in a technical organization."

Shane Hastie: Maybe we can start there. What does management and leadership look like in a technical organization? Perhaps, I would say, what does good management leadership look like in a technical organization today?

What does good management look line in a technical organization?[08:43]

Sam McAffe: I lean heavily on the lessons gleaned from lean and the Toyota model in particular. The concepts that a technical audience is usually pretty familiar with agile, and agile in many ways derives a lot of its patterns and its values from the original lean movement and there are a lot of parallels there, it's a descendant or a cousin of lean. And so one of the things that I notice is that building technology products or services or platforms, or however you want to think about it, is creative knowledge work.

I like to say product development is a team sport. And so you have different specialties, engineers, designers, user researchers, product managers, all the different roles that come together in a true cross-functional team to produce those outcomes, providing valuable products that actually solve a problem that customers want to pay for. That's a team sport that requires a lot of coordination and a lot of communication and iteration. That style of getting people together to work on a common goal doesn't always happen organically if you just throw people in a room. A little bit is countered to major parts of our culture, at least here in the U.S., for sure. It's a little bit more of an atomized individualistic culture.

And so the getting people to work together in groups for a common goal is work. It requires effort. It requires focus, it requires reflection and discussion. This is why agile presumably has the concept of a retrospective in it as one of the patterns, one of the practices, because retrospection and learning is core to the method. And so I think that in a good, effective, high-performing technology organization, you have teams that are relatively autonomous in how they do the work. The direction of what work to do hopefully is at least somewhat abstracted to a prioritization scheme that reflects the business value of the items going into it. Don Reinertsen stuff or something like that.

Some intelligent way of organizing so that it's not managers giving people work to do, but rather there's a transparent and open way of deciding, according to our business we've chosen this particular strategy as a business and there's a product strategy that goes along with that. And there would be a technology strategy that supports product strategy, and so we're working on this backlog of things to achieve that strategy, to deliver these products to the market. And the teams are going to be effective if they're left to execute on the how to get those things done, but they need a lot of support in how to work together. Not everybody gets along on a team. People have to different personalities, they have different styles of communication.

And so I think for managers in that environment it's really important to be able to continue to support people with all the different things that come up as we're trying to get work done. Disagreements, we step on each other's toes, there's some confusion about what to do next, that is the role, for me, for good managers or good leadership in an organization. Certainly not, I have all the answers that I'm going to tell you what to do, it's you are smart, we hired you to be here to work on our team. How can I help and tell me what your needs and let me create some guidance for you? Let me allocate some resources for you if you need them, that sort of thing.

Shane Hastie: That's quite a hard shift for the person who has come up from the technologist ranks and who's been successful by being the one with the answers.

Sam McAffe: Yeah.

Shane Hastie: How do we let go of that?

Making the hard shift from technologist to leader [12:32]

Sam McAffe: Oh, yeah. Yeah, yeah, that is definitely a tough one. I think that first acknowledging that that's happening is probably a place to start. Right? I'm a software engineer, a lot of my friends are software engineers, I've worked with software engineers on my career for the most part, we're people who are smart. We consider ourselves smart, we are figure things out, we solve problems. It becomes part of our identity to have those answers, to be able to rattle off and go, "I think we should try this type of architecture. We have an instinct for it. I'm sure this particular QAD system would be perfect for this job."

I think it's important to point out that heart of the problem-solving ability, that engineering mind that people have that maybe we're not paying as much attention to is the ability to learn. When I was coding, I was around when stack overflow first came out, and that concept that you don't have to know how to make everything when you first get hired for a technology job. You got to know how to look stuff up. You got to know how to ask people, "Hey, I got this thorny problem. I don't know what tool to use here. I don't know how to do this algorithm." You ask, you search, and discuss as a team.

When you realize that, when you realize that a lot of engineers talk to each other when they're trying to solve problems, what's happening there is what I think Carol Dweck would refer to as a growth mindset. That there's a notion that we are using learning, we're using a learning loop. We're going to try things and make mistakes and then adjust as part of how our thought process works. It's so innate to engineers that I think sometimes we don't notice that that's actually a really core part of being an engineer, is being wrong, being wrong a lot and being able to quickly adapt to that wrongness and find something that's a little more right and steadily move in that direction of finding the right solution.

The thinking skills are very similar to what is needed for coding, the implementation medium is different [14:30]

Sam McAffe: I tend to point out to new technology leaders that the way that they brain worked when they were coding is not actually that dissimilar, it's just a new environment. Now you're working with words, you're working with communication. You need to be able to talk to people. You need to be able to do conflict resolution between two co-workers who aren't getting along. You need to be able to make an announcement, write a pretty decent, concise email that tells everybody something important they need to know. Those are all skills that aren't that different from learning how to code, it's just the media is different. You're working with words rather than executable lines of code. But you still have to learn how to do it and it's still iterative and it can even be collaborative.

Sometimes you have to write documents. I have a person that I'm working with who is in a non-technical role in business development at AWS. They write documents. A lot of it is passing documents around internally around strategy and approach and some of those documents are written by 12 people. You got to learn how to... that's basically coding. 12 people working on a document collaboratively might as well be a GitHub project. And so I think even though it's words rather than syntax, the cognitive processes are really similar. So I try to point out those patterns in that you're learning something new and you can apply the learning methods that you used for technology to this new domain and, hey, it's going to be okay.

There's a lot of fear involved in getting out of your comfort zone and so it's really important to give managers support and training and also give them space to struggle and to fail a little bit, to fail in a safe way, to experiment, just like we do with our software systems, just like we do with our products. I think we're getting to a point where we're building experimentation into our methodologies and our philosophies. We need to do that with our management philosophies and our internal cultures as well.

Shane Hastie: Safe. Psychological safety is almost a buzzword today. How do we make it real?

Making psychological safety real [16:42]

Sam McAffe: Oh, yeah. I love that question. I think it's important to understand, or to reason about why it's even a thing, what do we actually mean by psychological safety? A lot of it I think goes back to the distinction between the old industrial management styles famously characterized by the work of Frederick Winslow Taylor, Mass Production, which a lot of people will associate with process with time and motion studies and that sort of thing. But I think that even more importantly, what Taylor really brought to industry at the beginning of the 20th century was a separation of thinking from doing. There were two different classes of people, some were doing the thinking and some were doing the doing. And what lean and later at agile really been about for me is bringing the thinking and doing back together and also doing it in a very collaborative way.

When you look at how management has traditionally worked in large, maybe industrial corporations born of the 20th century, it's a very top-down command and control style of leadership and it doesn't leave a lot of space for creativity or even for variation. And so, for me, I think the idea of psychological safety is there are lots of different parts to it. I'm certainly not necessarily a deep expert on it, but to me, I think it needs to account for the fact that there's a lot of diversity in what their personalities are like, how people think. We know that people have different personalities. There's lots of ways of looking at that, different ways of measuring, cognitive preferences, neurodiversity. There's a lot of good research and science that's gone into understanding that people think differently, people make decisions differently, they perceive data differently.

And so, what we would want to do in a healthy organization is have a culture that creates a lot of space for different types of thinking and different types of people who want to think and work in a different way. For me, I think that psychological safety is in some ways a reaction to a previous cookie-cutter mode of managing people, there's only one way and you have to conform or else. And I think movement towards psychological safety is a recognition of the fact that people are different and they have different strengths and they have different vulnerabilities and different weaknesses that a good manager will be able to respect how to do that.

Specifically, I think of a relatively trivial, at least, I think it's a fairly simple example, of some folks tend to be really rigid and structured and methodical in their thinking and they want to have a process nailed down. They feel more comfortable with checking the boxes and coloring within the lines. And other engineers that I've worked with have a more fluid, creative, entrepreneurial, adaptive way of looking at things and they're more comfortable with uncertainty. I would suggest that those people do different kinds of work in a system.

For example, I would tend to guide the more structured thinkers toward maybe doing more backend or data engineering or platform level work because their cognitive strengths are really good in that space and they're going to be much less comfortable doing a lot of rapid iteration front-end. We're just testing a bunch of ideas with the customer, we're not really sure what's going to work. That kind of work, the folks who are more creative-minded around, well, we'll do some experimental, we'll do some AB tests, we'll see what works, we'll be comfortable letting it go and trying something else. They might be more suited for an environment where they're working in those less certain areas.

And so I think a good manager or a good leader in that company or that org would pay attention to where people are going to be most comfortable given their cognitive differences and make those opportunities available to them, and not dictated, either. That we would create a way where people can gravitate to parts of the organization where they're going to really feel enriched and feel empowered and excel, be able to use their strengths for the maximum value and outcomes, and they're not in a job that just doesn't feel right for how they think and how they want to work. That's what it means for me.

Shane Hastie: We hear a lot. And some of the things that we put on the InfoQ Trends Report, the Culture Trends Report this year, we've covered some of them. But team self-selection, taking that autonomy to the extreme. Have you seen much of that and how does it work?

Exploring team self-selection [21:35]

Sam McAffe: Admittedly, I haven't seen a lot. I was excited to see the idea when it started to emerge and I've read about it a little bit. I haven't seen a ton of it in the wild, I've seen a little. And I think that it definitely resonated for me in terms of a pattern or a phenomenon that we would want to explore more and invest in. I think there was some research done that team self-selection produced some better outcomes, playing with different variables of teams being able to choose their work and teams being able to choose other people on the team, that sort of thing. And that's... my recollection is a little fuzzy, but it was something like that.

And it was really neat to see some of that evidence come in because I've always had an inkling. In a way I think in a different domain, some of the work in lean has also gone some way to prove some of this. A team is not just a group of people working next to each other. A team has a shared goal and an ideal scenario and they're working towards a shared goal, shared outcome. And there's some diversity on the team in terms of skills and backgrounds and experiences, and that they're more than the sum of their parts. They leverage those different abilities to produce more than any of them could on their own or even a team of people who are more or less the same wouldn't necessarily produce.

And so I think that the idea of having people choose what team they want to be on and who they're going to work with is a real, really, really powerful concept. I'm sure it probably feels a little radical to folks who are used to assigning, used to designing org charts as part of your job. We've all met those managers. And so I think that for managers to let go of the idea that they will design the org chart is probably the biggest hurdle. It's a big, scary thing because I think it probably feels to them they're taking on a lot of risk. Letting go of control of who's on what team feels like a lot of control to let go of. So really those leaders are probably the ones that need the most support in starting to think in a different way.

I have a little bit of a background in social impact organizations and volunteer organizations and put a lot of events together and conferences and things like that. And I think when you look at organizations of people where they're volunteers in the wild, you can really see self-organization as almost a natural human phenomenon. When something needs to be done people form around that outcome to get together and find the right mix of folks, the right size, given how much work there is. When it's done in a healthy way people can give each other feedback on how it's going and like, "Hey, could you help me a little more on this thing?" Or, "I need a little bit more of this from you." Or, "Maybe we've got too many people. Maybe I'll peel off because you guys seem to be fine." Those kinds of just human interactions are really powerful when you see it done in a volunteer context.

And so I think the idea of seeing more of that in companies in a corporate place or in a technology organization where, I think you need a fair amount of leadership and focus around what the plan is, what the work is, what the strategy is, but now that we've got these things, we've picked these sort of three core objectives or whatever it is, or we're supporting these products, we've got all of you folks, it would be a really fascinating experiment to allow your teams to just form around the stuff that they want to work on.

And because when people are doing work because they feel a sense of purpose, they want to be working on that product or they want to be on that team, they're going to have a lot more inner drive and motivation and that will produce better outcomes overall for the teams. Firstly, I think it's one of the things I'm most excited about as a trend. I mean, it's obviously very early stages and it probably scares the heck out of a lot of corporate VPs, but I'll push for it more, that's for sure.

Shane Hastie: Sam, thanks very much for taking the time to talk to us today. If people want to continue the conversation, where do they find you?

Sam McAffe: There are two key places where I hang out. I'm a big fan of LinkedIn, I'm a big LinkedIn user. I would love it if people would find me on LinkedIn, I'm pretty easy to find, and send me a connection request. I've met a lot of great people that way and I like to meet new folks and talk about all these topics. Please don't be a stranger, reaching out to me on LinkedIn is number one. My company's website startuppatterns.com is where we keep our main blog. Folks who do know me know I'm a pretty prolific writer. I put a lot of content out and I'm usually putting it out there. If you want to follow our work and what we're doing and what I'm writing about, Startup Patterns would probably be the place to go, and either of those two would be a great place to connect with me.

Shane Hastie: Thanks so much.

Sam McAffe: My pleasure. Thanks for having me.

Mentioned

• Startup Patterns book and company
• Sam on LinkedIn