Developer Satisfaction Is Key to Engineering Success

Transcript

Shane Hastie: Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. Today I'm sitting down with Lilac Mohr. Lilac is an engineering leader at Pluralsight. Lilac, welcome. Thank you for taking the time to talk to us today.

Lilac Mohr: Thanks for having me, Shane.

Shane Hastie: Let's start a little bit and who's Lilac, what's your background?

Introductions [00:25]

Lilac Mohr: As you said, right now I lead software engineering teams that are working on the Flow product at Pluralsight. Flow's the software delivery intelligence platform. So we look at development workflows holistically. We look at all the different activities that make up an engineer's day, how engineering teams collaborate, how well they're doing unpredictability of being able to deliver on their commitments, and the general efficiency of the workflow.

And it's really fun because we get to use our own product and continuously improve the product and the process. And prior to this job I led other engineering teams, but I was also a developer for a very long time. So I'm still very connected to the software engineering side.

Shane Hastie: What are some of the things that get in the way of engineers being productive today?

Challenges engineering teams are facing [01:20]

Lilac Mohr: We try to stay away from the word productivity, we don't want to measure engineering productivity. We want to really have a holistic view. Make sure that we're looking at engineers as people, at what makes their day good. At the end of the day ask them the question, "What were the blockers you had today? And then what were things you were really excited about today?"

And as an engineering leader, I do have to talk about deliverables, being able to deliver with excellence and the outcomes, but then it comes down to the people who are really behind the code. Every line of code comes from an engineer, and it comes from a collaborative process. And some of the things that I've found have been creating friction to that's delivery. Right now I think with the Great Resignation it's very difficult for me to keep a healthy team because people are leaving, so I think that's where the culture plays in and it's important. When someone leaves, it puts a big burden on everyone who's left. So I want engineers to feel like they can keep moving forward and don't have to take on a lot of extra work.

I think that's a big challenge that all engineering teams are facing right now. And as something we do with our Flow product, is we're always talking to our customers and trying to understand what it takes to have great engineering teams. We ask them the question, "Are your team set up for success?" And we get a wide variety of answers. It's actually a difficult question to answer. A lot of times engineering managers focus on the process and the tools and say, "If I have the right tools, if I have an agile process, then my teams are set up for success."

And that's not digging deep enough, in my opinion. I think that a lot of times that's based on an old playbook. Everyone is still talking about agile transformation as they have been the last 20 years. And with all the attrition that we're seeing, you need to really focus on people. You need to take a broader view of everything that goes into making teams healthy.

Shane Hastie: What does a healthy team look like and feel like today?

What makes a healthy team [03:39]

Lilac Mohr: I think it comes down to developer satisfaction. And actually, I'm really big into metrics, and I think part of that is looking at the data itself, for how they're able to deliver what their day looks like. But then part of it is also being able to survey them and ask them, "How are you doing? How are you feeling? What's your confidence level right now?"

So I think it's a combination of those factors. And I think a healthy team is a team that genuinely likes everyone on the team. They like working together, they like solving problems. They feel empowered to be able to make decisions that are closest to them, the engineers are the ones that are the closest to the code. And they want to feel that they understand the value of the things that they're producing, and that they're empowered to be able to make those decisions.

Shane Hastie: As an engineering leads, how can you influence this? How do you create this space?

Leaders enable the culture [04:43]

Lilac Mohr: It all comes down to culture. And I think that visibility is really important. I think that when you have the right metrics and you have the visibility into those metrics, then you let individuals make decisions about their team, what's best for their team. And I think that drives the culture.

I think that it's also important to have gratitude and have a culture of constantly acknowledging people's hard work and their contributions. And not just coming from leadership, but encouraging them to acknowledge each other and have that space where you can provide feedback across teams, up, down, all around. It just becomes part of the culture. And the example of how we do this at Pluralsight and at Flow is we have Gratitude Fridays, where on Friday everyone posts the co-worker of the Week and recognizes someone who just moved the needle a little bit on making their experience that week fantastic. And it's really fun to see everyone just acknowledging each other.

And I know, doing a skip level review with one of the new engineers, I remember him telling me, "At first I was really sceptical and thought it was really cheesy to do that. But then after someone tagged me and acknowledged me for the help that I provided that week, it felt really good, and I get it now." I love hearing that type of feedback and seeing people just appreciate each other and enjoy working together as a team.

Shane Hastie: The perspective that you just mentioned from that engineer, "It felt really tacky," it does kind of sound like that. As an organization, as a leader, as a co-worker, how do you prevent that from becoming tacky?

An example I can give is one organization that I spent some time with used a weekly 15-5, where they asked five questions, 15 minutes, "How are you doing?" And if anyone seemed even vaguely dissatisfied, a very senior leader, out of genuine care and concern, would immediately get hold of that person and say, "What's going on? How can I help?" But to the engineers this felt intrusive and creepy. So they stopped reporting it was tough, everything was shiny, so they didn't get the personal phone call.

Creating trust and enabling openness [07:18]

Lilac Mohr: Yeah, I think you have to create that trust in each other. And I think that a lot of those types of initiatives need to come from within, not from leaders saying, "Hey, this is the great new thing we're going to do." Maybe they can get it started and then make sure they have that feedback loop and that ear to the ground to ensure that it's being carried on by the team members, that they appreciate it and that they share it with each other. And I think that's important.

For example, like what you mentioned in one-on-ones. Everyone talks about how important it is to get that feedback in one-on-ones and how employees are doing, and making sure as a leader that you can address some of that's discontent. But there's ways to do it that are healthy, and I think there's ways to do it that feel weaponizing. It's about creating that safe environment. And being able to ask, if someone shares some information with you about how they're doing, make sure that you ask them, "Is this okay if I share this with anyone else?" Sometimes you want to keep that relationship private.

I think as humans, when someone says that something's wrong, you want to immediately react and say, "Well, I want to fix it." Or you want to make them feel better. Sometimes all you need to do is just validate them and say, "What, if anything, would you like me to do about this? Or do you want me just to be a sounding board just to listen?" And sometimes people say, "Right now I just need you to listen."

Shane Hastie: One of the things you mentioned earlier on, Lilac, was the importance of metrics and getting that feedback about what is actually happening in the team, the way work is flowing and so forth. Couple of things if I could explore with you there. One, what are some of those important metrics?

The importance of metrics [09:13]

Lilac Mohr: First I'd like to zoom out and just talk about the importance of metrics in general. I think a lot of times engineering leaders are very comfortable with using metrics to measure systems. We want to know how is the database operating, is the system up or down? Things that are less human. And then when they think about their humans they get a little bit uncomfortable about using metrics.

And I think that discomfort probably comes from focusing on a single metric. I think that the holistic approach is what you really need to take, where you're not looking at just a single dimension. We all know that if you focus on a single metric, that's what you're going to get. And sometimes you are optimizing one little piece, but it actually creates tension somewhere else. Or maybe you're focusing on the wrong thing. A lot of times that's called the streetlight effect, where maybe you dropped your keys on the way to your car and the dark, but where you're going to look is under the streetlight because that's where you can see them.

Examples of metrics that can be useful [10:20]

Lilac Mohr: At Flow, we really try to create this holistic view, where we're looking at engineering metrics down to the primary level is your code commits. So making sure that engineers have good habits around code, and those habits need to come with a purpose. The reason that we want to commit frequently is because we don't want to hold onto code until it gets stale. We want to have that safety to check in the code and then be able to quickly get some peer review on it and get the process moving. We want to make sure that we're freed up to code frequently. How frequently you commit code is not about how fast you're working, it gives you an outlet as an engineer to say, "I don't have time to do my work because I keep getting pulled in these different directions," or, "I have meetings all day." And it allows you to have those types of conversations with your leader.

That's at the primary level, just things you should be doing is making the time to be able to code and doing frequent commits. And then the next level is collaboration, which I think is the most critical to code quality. A lot of times we think about code quality as lets have tools that analyze our code for that quality. But the quality really comes from helping each other on a team. Doing that peer review and doing it effectively, and being able to get all that work in progress moved through the system.

We take a look at pull requests, at the type of comments you're getting on pull requests. How long they're sitting in queues before another pair of eyes takes a look at them. And then also making sure that we're not just rubber-stamping them as they go through. It's a great way to learn and to help each other in that quality, so that's the second level. And then the highest level that we track in Flow is at the ticket level, which is, these are the things that your team committed to doing in the sprint or in this chunk of time. Are you able to deliver on those, and what are the blockers to flow? Where is that work getting stuck in queues? Where are there unnecessary handoffs, anything else that we can improve in that higher level process.

I think all those things stack on top of each other and help you get an understanding of how, as a team, you're able to deliver code. And important part of using those metrics is using them to guide discussions. They're not supposed to be used to punish teams, to make teams feel bad about their process, to blame anyone. It's all about being able to identify things that sometimes your intuition doesn't realize that some of that friction is there. It gets conversations going. And I think that if it's framed that way, then those metrics are enabling.

Shane Hastie: How do we ensure, and as a manager, how do I make sure that we're not bringing that blame culture in, that we're not using those metrics in the ways that would be so easy to do, but as you say, are not right.

Empowering people to own their own improvements [13:49]

Lilac Mohr: I think visibility is the key, in having access to the metrics. We have an engineer who was using Flow at her previous company. And she said that her leader would come in and show the Flow metrics to the team and provide some insight, but they didn't have access to that data themselves. And she was curious, she was like, "Well, if they're tracking this information about me, what else does he know? What else is in there?"

I think that what we're trying to do with our customers is encourage them to let individual contributors have access to their own metrics. And we found that by doing that internally in our own team, a lot of great insights come out. Sometimes what we do is we just say, "Okay, just explore the metrics and come back with one thing. One thing that you found that's interesting, maybe something unexpected, or something that you want to improve on as an individual or as a team." And we've found amazing things come out of that because it's open, it's not coming from engineering managers. It's not something punishing like, "I found this thing we can improve upon." It's asking them to be empowered, to look at their own data and make improvements.

Shane Hastie: One of the things you mentioned earlier on that I'd like to just delve into a little bit more again, if I may. You spoke about how team performance does come when people like each other and work effectively together. How do we prevent that from becoming a monoculture?

Avoiding monoculture [15:28]

Lilac Mohr: I think that's an important topic. And a lot of times we find our teams do have a subculture. The teams, we let them pick their own names and they're really proud of who they are. And I think that probably needs to be balanced with the culture for the entire engineering organization, because one of the problems is a lot of times it creates problems with inclusion. For example, an engineer who maybe is older, who's on a team with younger individuals, they talk about different things. And I've heard some of this feedback. They talk about things that he feels he can't relate to. So how do we create that sense of inclusion on a team and still allow them to feel really close to each other [inaudible 00:16:18]?

Pluralsight does really well because we talk about inclusion and diversity a lot. We just make it ... It's not a special topic we discuss, it's just part of how we think. So we're constantly asking, "Am I being inclusive?" And being able to stand up for each other and be able to provide that feedback and say, "I feel that this person was left out of the conversation," or, "Can we choose an activity that might be more inclusive to do as a group?" And by talking about it a lot it makes it safe. And it makes it something that, when it's not calling people out, it's just pointing out something that we all are aiming towards. We all want everyone to feel good.

And I know that personally, as a female software engineer in a very male-dominated industry, I've been doing this for about 25 years. So back in the late '90s, a lot of times I was at startups where I was the only female. Sometimes the only female engineer, sometimes the only female in the entire small organization. And there were a lot of awkward situations where I didn't feel like I belonged. And coming into Pluralsight and being able to say, "I belong here” was really powerful for me. Because looking back, I didn't always have that feeling. And I think it comes from just creating the importance around belonging, where everyone really wants everyone else to feel like they should be here. And it's huge.

Shane Hastie: One of the things that we see, and I'd love to know your experiences around this, becoming an engineering leader, we often take the best technologist and we throw them into a leadership position. And one statistic says 58% of new managers receive absolutely no training.

How do we help people who are transitioning into those leadership roles become leaders? Because the skillsets are very, very different from the individual contributor to the leader.

Helping new leaders [18:30]

Lilac Mohr: It's definitely a challenge. I know in the Flow organization, we do have that culture of taking the best engineer and saying, "You're going to be the leader," and it doesn't always work out. A lot of times we have seen those leaders go back to being individual contributors. And we make it okay, we make it okay even within the organization to do that because otherwise they would leave the organization to become ICs.

But part of it is making sure that they get the satisfaction that they did from being able to generate a lot of code to help their team, to be able to focus on other high-performing engineers and be able to raise the level up of the entire organization. I think it's just that mind shift. It's very difficult to let go off code because we enjoy writing code, but how can you be more impactful? Instead of just grabbing tickets and then becoming a bottleneck for your team, how can you coach others to be able to get to the next level with our own careers?

And then also, how can you keep your fingernails dirty in the code, because that's what you love. Maybe doing some pairing with engineers to help them get their own levels up or be able to be involved in architectural discussions. Ways that you can still help at a technical level, but you're helping not just in the code, but helping the team move up and improve their own career paths and being able to deliver.

Shane Hastie: In your position as an even more senior leader, what are you doing?

Transitioning into more senior leadership [20:14]

Lilac Mohr: For me, the transition from individual contributor to a leader of one team, to a leader of multiple teams, it was tricky because you're responsible for more. You know that ultimately, I'm responsible for all these outcomes, but I have to resist the urge to micromanage. I have to trust people.

I think that I would focus that effort where I want to dig in and be able to know everything that's going on, to focus on coaching and focus on that higher level of enabling people and putting that trust in people and using data. We always come back to the data. The data to help me understand what's going on with my teams, but also helping those leaders do the same thing, where they're not micromanaging, but they're driving and understanding where they can be helpful on reducing friction on their teams as well.

Shane Hastie: And cycling back to another point that you made that's hanging over us all at the moment, the Great Resignation. Keeping things flowing through it and retaining great people, how do we do that?

Advice on retaining people [21:27]

Lilac Mohr: The first thing is you need to value your people. It sounds really easy, but a lot of people don't genuinely care about people at the level that they should. I remember I was interviewing for a leadership role for a very small company, and the owner of the company made some offhanded remark about engineers are a dime a dozen. And I remember having a very strong reaction to that comment and trying to think about it. Was my reaction due to me thinking that engineers need to be treated like special snowflakes? Is it because of my experience with hiring new engineers and how difficult that was?

And I think what it came down to is you can't have a successful company at any level unless you really value all the individuals there. And you're not going to have individuals put in their best work unless they know that they're cared for, that they're valued. I think it all comes down to that, putting people first. Not thinking about people as resources but as human beings, and I think that that helps with retention.

Shane Hastie: And when we do lose people, as inevitable in these times, how do we let them go well?

Lilac Mohr: We need, as a group, to celebrate the opportunities that they have, and leaders can set the stage for that. I think that if a leader handles someone leaving well, then the rest of the organization feels like it's okay, it's not something that they need to panic about. And I think that a lot of times I question my own leadership abilities in different areas, I think everyone does. But some feedback I've heard that made me feel really good is that I can be a calming force amidst all the change. And I remember talking to one engineer who admitted that they were thinking about leaving. So it was about a year ago they were thinking about leaving and seriously considering it and not happy. And they decided to stay because of me, because of a discussion they had with me.

To me, just knowing that even if I saved one person and made them feel like they can have a successful career staying here at Pluralsight, that gives me validation that I did my job as a leader. You can't save everyone, but if you can make a difference, even in just one engineer's life, I think it's worthwhile.

Shane Hastie: And then the flip side of that, how do we bring people into the organization well?

Onboarding people well [24:14]

Lilac Mohr: A lot of times we're looking in the wrong places we're looking for, "Let's bring in the top talent," instead of thinking, "How do we bring in really good people and then be able to grow them?" I think that mind shift helps us bring in people who feel like they're going to belong. We know that they can have good problem-solving skills, that they're going to work together with their team members, that they're hungry to learn to solve these problems. And I think those sometimes make the best engineers, especially in the long-term, because then you get to cultivate them and be able to watch them grow and learn.

I think that's definitely the first step, is thinking about who you're hiring and why. We know that diverse teams are better performing teams. Bringing in that diversity and then making sure that it's not checking a box, it's bringing in the best people, and then making sure they feel like they belong, I think is really playing the game for the long-term. Making sure that you're building a healthy team, not just for now, but into the future.

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

Lilac Mohr: They can find me on LinkedIn. And we're constantly hiring, so don't hesitate to reach out.

Shane Hastie: Wonderful. Thanks so much.

Lilac Mohr: Thank you.

Mentioned

• Pluralsight
• Lilac on LinkedIn