In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Ravi Lachhman about the state of developer happiness through the COVID-19 pandemic, engineer burden and avoiding burnout
Key Takeaways
- The State of Developer Satisfaction survey is trying to learn how much impact COVID-19 has had on the daily lives and the long-term goals of software engineers
- More than half of developers,(52%) are happier in their role since COVID-19 began
- Factors such as age and income level have significant impacts on developer happiness
- Learning and development are one of the key top of mind concerns around remote work
- more than 75% of organisations are planning to maintain their remote teams post the pandemic
- Engineer burnout is a real danger and the complexity in the modern tech stack increases the risk due to cognitive burden
Subscribe on:
Transcript
Shane Hastie: Good day folks. This is Shane Hastie for the InfoQ Engineering Culture Podcast. I'm sitting down across the miles today with Ravi Lachhman.
Shane Hastie: Ravi, welcome. Thank you very much for taking the time to talk to us today.
Ravi Lachhman: Shane, super excited to be on the podcast. Thanks so much for having me.
Shane Hastie: You and I have just met. We were introduced through some of the work that Harness have done on the State of Developer Satisfaction survey.
Shane Hastie: Before we get into that, please tell us a little bit about yourself and your background and a little bit about Harness.
Introductions [00:51]
Ravi Lachhman: My name is Ravi Lachhman. I'm an evangelist at Harness.
Ravi Lachhman: Harness, we're a continuous delivery as a service platform. More recently, we're more of an engineering efficiency platform. Let's say that as a software engineer, we have a lot of responsibility going from idea to production. There's lots of disparate steps, lots of disparate ways of thinking and testing and disparate infrastructure we have to tie together. We help wrap that all up as a service with our opinion.
Ravi Lachhman: As an evangelist, I'm fairly lucky. I get to talk to a lot of our customers, a lot of our prospects. I really focus on the system.
Ravi Lachhman: I'm based in Atlanta, Georgia.
Shane Hastie: Servicing and providing services to engineers, what's your engineering background?
Ravi Lachhman: My engineering background started when I was in middle school and high school. I used to make kiosk applications. Then, ironically, I wanted to be a technology writer, but writing Java paid a lot more. So instead of being a writer, I actually became a software engineer. Most of my stack background's been in J2EE.
Ravi Lachhman: I've been building large scale distributed Java applications for pretty much most of my career. I've worked at a few firms. I worked at IBM, Red Hat, and Mesosphere, so really building large scale distributed systems. Then now coming over to my passion of engineering, I really like helping people get their ideas out pretty quickly. Here I am at Harness, helping people enable that.
Shane Hastie: Let's jump into and talk about that Stage of Development Satisfaction Survey. When was it done and what was the intent?
The State of Developer Satisfaction Survey [02:15]
Ravi Lachhman: It was done in, I guess, in North America in the summertime. Really, it was trying to track the impact of the pandemic. As a software engineer, the State of Developer Satisfaction, we're trying to learn how much impact has it had on the daily lives and even the long-term goals of software engineers.
Ravi Lachhman: Us being a SAS software company based in San Francisco, we are in a very privileged position to avoid some of the pandemic. It is stressful. We had a lot of, let's say, learnings to do in our organization, how people started working from home completely. We wanted to interview peer firms about some things that they're doing and also just a level of stress that people are going through, if either they're feeling more efficient or less efficient. Those are some of the driving goals of the report.
Shane Hastie: What did you find out?
Ravi Lachhman: Actually, we found out some pretty interesting things. One of the ones that stuck out with me throughout the whole report as a software engineer, especially a well-to-do software engineer, we always have these things called nits. Nitpicks. We might focus on the smallest little grievance, "Oh, why did someone do this?" In the grand scale of things, normal human empathy might go out the window. If you and I got into a squabble in the street, we wouldn't fight over something small. So one of the biggest things that poked out with me was more than half of developers, 52% actually, are happier in their role since COVID-19 began.
Survivor Guilt? [03:34]
Ravi Lachhman: That's very, very telling. Maybe some of the reasons behind that, I like to say it's survivor's guilt. As a software engineer, I'm able to work from home. I don't have to go out if I don't need to so I can basically avoid the healthcare system. Just assuming that folks in a similar position to myself are very thankful for that. Also, I'm able to keep my job. I don't have to go work in the front lines. I don't have to go to a hospital. Relatively stable. I'm able to provide for my family also. I guess other folks, that's something that resonates.
Shane Hastie: What are some of the trends that were coming out? One of the points that somebody made to me was the age factor having an impact.
Age as a Factor of Satisfaction [04:12]
Ravi Lachhman: Absolutely. This is funny. I compare myself to my father and the report mimics this. I don't mind working from home. I have a quiet space. It depends how you like to work. I'm able to focus a lot. Being a software engineer, you have to focus. Getting distracted is the biggest buzzkill ever. When I'm in the office, I like to talk to people. Vice versa, my father, he's too distracted at home. He might watch TV. He might go on his favorite couch and sleep, take a nap in the middle of the day. All those things are fine, but it'll really deter him from doing work.
Ravi Lachhman: What we've seen in the report, the older generations actually very much disliked this longevity of working from home. They long to go back to the office. I thought that was strange and I realized my father was in the age range, of the top of the age range, like, oh yeah, he goes nuts sitting at home. It might be my mother. Who knows? But he always goes to the office even though he's the sole person in the office sometimes.
Shane Hastie: Were there any other interesting trends or pointers that came out?
Ravi Lachhman: There were some trends that were unspoken which the report really brought up.
Money has an Impact [05:13]
Ravi Lachhman: Money talks. The more money that people made, the more happy they were in their job. I guess especially during with the pandemic, especially the upper end of the salary. We asked, and it was 150,000 US and over were predominantly just more happy. I guess, A, because those job's a little bit harder to get. And B, if they were still employed during the initial surge of the pandemic when lots of people were getting laid off or the unemployment rate was rising, they still had a very consistent and good income that was coming in. So money does help. It was one of the points that came across.
Shane Hastie: What does it say about remote work in general?
Ravi Lachhman: It is challenging. I think that remote work, there's a lot of unspoken stresses.
Remote Work is Not Universally Enjoyed [05:56]
Ravi Lachhman: This might be blending some of our own internal findings at Harness with the report also. Not everybody likes it. We actually did just butting up against, if we aggregate the numbers in the report, which is fairly close to our internal survey numbers that we did, it was about 50/50. That doesn't entirely say one way or the other, but it does show that people are very split about it. Some people do enjoy the comradery, the tapping someone on the shoulder versus, "Hey." You're able to focus at home.
Learning & Development Challenges in Remote Work [07:08]
Ravi Lachhman: There's lots of things to bring up for that. Digging into that also, it's like, what are some of the learning and development goals? When you're in the office, let's say you and I were sitting next to each other, I would learn a lot from you being the more senior engineer. That osmosis process was getting lost. Learning and development was one of the factors in the State of Developer Satisfaction. It looks like learning and development was actually one of the key top of mind concerns that folks had.
Shane Hastie: How do organizations overcome that learning and development concern in the remote age?
Ravi Lachhman: It's an interesting mix. Let's mimic if we were sitting in the office, what learning and development would be. If you were looking at more official continuing education, CED type of things, it would be classes you take, conferences you go to, but minus the osmosis effect of learning together. I would say it's hard to measure that kind of curriculum for your learning from your coworkers. What we've seen companies shifting to, even we started shifting towards it too, it's, there's a big increase in virtual events. A big increase of people buying, let's say, a subscription, something like O'Reilly. You just buy a learning subscription for a year, something like Katacoda, and you can just learn.
Ravi Lachhman: Also, since the entire team is becoming remote, or the big push, there's a very big push of people being remote, not only that yourself is remote but your entire team, so that level of empathy increases. What we've seen especially in our firm at Harness, is that there's been a lot of self-organization. The number of Slack channels exponentially exploded. People try to self-organize. It's like going to a conference, like a dev ops conference. Some of that part is self-organization, feeling the ebbs and flows. That hasn't been lost in the virtual world. Where there's a will, there's a way, and just always innovation that will occur.
Shane Hastie: Do we have to rely on people in the team to self-organize? Or is there something that if I'm a team lead, a manager in a technical area, I could be doing, should be doing, to actively create that?
Enabling Self Organization [08:32]
Ravi Lachhman: It's all about culture. Funny you bring it up. I'm a first-time people manager. I left the individual contributing world and took a dive into management. There's always things that you have to think about it and there's some intrinsic ask around that. Do you feel more of a professor, or a coach? How do your people in the team like to learn?
Ravi Lachhman: I'm more of the coach side. I don't really try to push anybody on the team. People certainly know what they like. I remember myself, I certainly had opinions what I like and don't like, so I'm dealing with myself. How do I like to get talked to or spoken to? It's very deep in the organization. Learning in an organization should be one of the goals. We're people and you can really tell if certain organizations are focused on learning. Do you still have a education stipend? Can people still take classes? Yes. Do you want to buy a book? "Sure." "Don't even ask me that. Expense it."If it was a thousand dollars then we'll have a talk about buying a cheaper version of the book. It's stuff like that. I'm really encouraging people to learn. Do you read InfoQ? I love that site. The questions that you poke people towards and giving them a source of resources they could look at.
Ravi Lachhman: Internally at Harness, for the broader people manager team, even we're getting coaching. It's a first time, this unprecedented scenario, we're all learning together. Even the first time managers or the seasoned managers in the company were banding. Not banding together but learning from each other, like, "This works. This didn't work." I'm lucky that I only have a few people on my team. I don't have a 20 person team. I can be very individual with the folks as we scale out.
Shane Hastie: How long is remote going to be normal?
Remote is Here to Stay [09:46]
Ravi Lachhman: In our report, it was overwhelming that more than 75% of people said that they were planning to maintain their remote teams. This is interesting. I always had a very remote-centric job because I don't live in Silicon Valley. I live in the east coast United States. I've been fortunate I've been working in Valley-based firms, several firms that I worked at. Usually they have an extremely strong office culture. The office culture dictates how fast you move and stuff like that. We also interview peer firms. I've always been pretty fortunate when I would fly into San Francisco, I don't have that long commute. I'll stay next to the office, but a lot of folks will be coming in and out.
Ravi Lachhman: When we interviewed peer firms, three-quarters of them said they're going to maintain their remote team to which was, if you think about what it's like in San Francisco, Seattle, Boston, they're very, very centric of the office. That was mind-blowing, that three-quarters of them will maintain their remote teams if they need to.
Ravi Lachhman: I'm sure that number has increased. If you've been keeping up with some of the news, firms like Google and Facebook, they might be indefinite remote at some point.
Shane Hastie: What benefits are organizations getting from it?
Benefits of Remote Working [10:37]
Ravi Lachhman: The benefits that organizations are getting is that they're able to continue business. Depending where you live, legality about how many people can gather and whatnot, the Bay Area has some of the strictest in the country. They have to legally maintain six feet separation and there's math. Funny, at our office, if everyone would show up, they could not legally sit there in the office together. And so allows businesses to continue. That's the first thing, to continue running the business.
Ravi Lachhman: Also, it helps with the talent too. If your team's remote, you're able to get talent from all over the place. This wasn't really in the report but it's kind of what's going in at Harness. For example, our team is growing and I'm able to consider someone living in Australia for the first time, just because they don't necessarily have to be in California or don't have to be living close to where you work. It broadens the talent pool significantly. The irony of it, the world is becoming smaller. Well, legitimately for us, our team, we can pick from a really wide talent pool now.
Shane Hastie: How do you then keep a good, strong company culture or team culture with a distributed workforce?
Maintaining Culture When Remote [11:36]
Ravi Lachhman: That's hard. It really depends. One of the firms I worked at before, they had an entirely remote development team. I see this kind of changing. What I was told from one of the product leaders there is, either everyone has to be remote, or there'll be favorites. If some people are at the office, it's out of sight out of mind. The benefit now, everybody's remote so you have equal level playing field.
Ravi Lachhman: Maintaining that culture is difficult. What we do in our team, we have several meetings. Trying to avoid Zoom fatigue, but we have to meet up in Zoom. Some sort of screen-sharing program. We just have meetings to hang out. We had brunch today. My boss will hand out gift cards to Uber Eats or Deliveroo, "Here's $15. Go buy brunch and just jump on a Zoom and we can just eat and talk." Where it pops up, it pops up, if it doesn't, we'll just hang out. Similar to being in the office. We try to scale that across the company. We have events. For example, we have a masquerade ball today after this call which is pretty funny to do.
Ravi Lachhman: It is difficult. One thing that's hard to replicate is culture. How do you measure it? Are people smiling? Are they happy? What is culture? In, I would say, the cutthroat technology world, culture is the only differentiator, really. It's a very cliche saying, but having it permeate is hard. Some people are more introverted. Some people are extroverted. Just playing into that. Do you have virtual events? Do you send them little gifts to their house? Do you recognize them in certain ways? Just bringing everyone together and giving them opportunity to be together virtually is very important.
Shane Hastie: Moving on from culture, or perhaps it's part of culture. You spoke about engineer efficiency. We mentioned earlier the concept of engineering burden. Is it efficiency or effectiveness that we're looking for from our engineers, and how do we avoid burning them out?
Managing Engineering Burden and Avoiding Burnout [13:19]
Ravi Lachhman: Burnout's probably, I would say, one of the hardest things to get in front of and avoid.
I'll take a step back about one of the topics I'm extremely passionate about, is engineering burden. Going to my career when I started out of university, I was a J2EE or Java Enterprise Edition engineer. My world was very centric to Java. I wrote Java, I built a Java application, and I deployed to one of three application servers. That was it. Everything was to J.
Slowly creeping in now, as I became more senior and eventually a principal engineer, was infrastructure. Things that I was definitely not good at. Not only did I have to package the application, I have to automate how the application's built. I have to automate how to test the application. I have to automate, where are the applications going? And I have to be very generic. The old adage in computer science, you're just moving complexity left to right like a abacus.
Unfortunately, as an engineer, I had to follow the abacus. Not only was my vertical skills important, I had to have horizontal skills and things. Ironically, as a personal anecdote, my all-time biggest outage, my largest production outage I ever had, was due to a networking error. I miscalculated a cider, which before then, I thought a cider was made of apples and I would drink it. It's not. It's networking rules. Me being a Java engineer was like, whoops. I ended up blocking half the internet to our production application for four hours. That was probably part of the problem. But it showed a problem that, not a problem, but a burden that, not only didn't you know the features and functionalities of the application, but you're now a networking specialist because we have to deploy in AWS, you have to get the VPC right, you have to get these rules right. It's like, Oh boy.
It's kind of a duality. When you talk to an engineering hire today, they sound a lot like an IT department. You're looking for, not only do they have development skills, but they have infrastructure skills, they have operational skills. There's a long-winded answer to this question. There are two companies that I wouldn't name but I'll give you their location. There's a book company in South Lake Union in Seattle, and there's a movie company in Los Gatos, California, that they have this notion of being a full lifecycle engineer. If you write it, you run it, or you build it, you operate it. That could be very stressful. How do you expect someone who could just write a feature, now they're complete owner of that?
That's how I see burnout occur. You're under the gun to get something out during a sprint. Agile is high-burn. Don't let it fool you. You can't be delivering stuff every two weeks without a break. Then also, you have to operate it. How do you compensate for that when you're under the gun developing stuff? There needs to be a lot of platforms around that. If you really dissect how those firms do it, A, they pay their engineers a lot, but B, they have platforms supporting them to help out with that.
Shane Hastie: What can individual developers do to manage that burden? What can managers, leaders, team leads do to not put that burden on people?
Advice to Avoid Burnout[16:12]
Ravi Lachhman: It's hard. If you're taking a look at no matter what, if you're coming from the bottom-up or top-down, I would say those people want to better the craft as a software engineer. You want to do better for the craft, and better in the craft is always pushing yourself and it's like, Not only do I know how to write a feature, but I can operate it. That's technically, you're better in the craft by doing that.
Let's say for not putting so much burden on people, let's take a top-down approach and I'll do the opposite. Don't do the bottom-up approach. As a first time tech manager, just understanding that people are people, you can't have too aggressive of a sprint. You need to understand, how do I successfully achieve the backlog without killing your people? As cliche as that, that's concrete advice, "You're a person. You know what you're capable of." Discount a little bit for the team.
I've been fortunate that I've probably been a part of a dozen development teams, so I understand the learning curve. I understand that when a new engineer, he or she comes on, they'll go through the same ebbs and flows that I have. One is empathy. Don't forget that new people will come on your team and leave the team at some point. So compensating for that learning curve. It's unfair to toss a new engineer into a very critical two week sprint. Totally unfair. Let him or her learn. Let them gradually learn.
Now, from a bottom-up approach is pushback. Earlier in my career I would say yes to everything. Maybe because I like to please people or maybe I was up for the challenge. I wanted to show these other senior engineers and principal engineers I could do it. But then you'd start working insane hours and then you start being really stressed out, "Why can't I figure it out?" When I interview people for engineering roles, I asked them one question, a very intrinsic question.
Shane, I'll ask you this question. If you can't figure something out, what do you do? Very intrinsic question.
If you can't figure something out, what do you do? Well, me, I've got a number of people that I know I can turn to and ask for advice. And I'll also Google it.
That's very fair. I would say a majority of people would say that.
When you’re Struggling with a Problem – Take a Break [18:11]
What I learned, a little bit of coaching when I talk to the interviewee is, if I can't figure something out, I take a break. Simple as that. Take a break. An experienced engineer would tell you, go for a walk, take a break.
Play with the dog. My dog will come in at some point. But play with the dog. Do something that's going to take your mind off of it because if burning cycles through that you'll get really stressed out.
The older I've gotten in my career, as simple as those kindergarten teachings, nap time's important. I found that taking 10 minute, 15 minute breaks or just staring off into space really, really helps out. If you're feeling overburdened, definitely say something. Raise your voice. The last thing that, let's say from a matter of perspective, is that you're coming to the end of your wits and your manager didn't notice it because you were performing so well or you didn't say anything. Then, boom, it's an explosion point. It's not good for anybody. Make sure to breathe, take a break, and early and often, raise the flag.
Again, as an engineer, this is a bottom-up approach, you know the best how long something will take. Now, clearly when you're starting, things might take a little bit longer than when you're, let's say, more ramped-up. Same thing when you're staffing. Coming back to the manager personality. When we're looking to deliver some functionality and when we're putting people together, clearly principal engineers expect you to perform a little bit differently than a junior engineer. You need to remember that. Factor that in. It's common sense for you and I to talk about that, but you see people forgetting it all the time.
It sits right in the core even when we name the function, human resource. No, we're not cogs in a machine. We're not all the same. Every individual is different. Engineering is a creative skill. Software engineering is hugely creative.
Shane Hastie: How do we nurture those creators? How do we create that effective space for them?
Software Engineers are a Creative Part of the Process of Delivering Value [19:55]
Ravi Lachhman: Nurturing creativity, it all depends what problems people like to solve. For myself, I always like to build stuff. There's definitely been a shift in mentality. I'm a big, big fan of the shift in mentality. I'm actually agile, the high burn actually brought this more to the forefront that your developers or software engineers, they're business value. They're a creative part of the process.
I can remember clearly when I was a product engineer 15 years ago, I would have requirements just given to me. Then I would read them and be like, "What was this person thinking? Who wrote this? I didn't write this. Who's the customer?" Now looking at most engineering organizations, especially the more forward-thinking ones are, they're part of the business process. Let's say we have to build new features. We all sit down and we talk about it. Even direct interaction with the customer from an engineer, you're, A, showing important to them in the process of building something. And B, their opinion is only as far as they know.
There's an adage, the fog of war. I call it the fog of development. You only know so much. The system is too big. Your situational awareness might only be from the data points you have. And so a part of that creative process involves making sure that people are involved early in the process ... But it could be any part. It could be operations folks too. Usually the old adage, ah, they'll figure it out when we have to go run it. No, we bring in, especially for our organization, we bring in our SREs early on, we bring in the dev ops folks early on. They're part of the original sprint planning that we have. How are we going to run it? How are we going to make it robust? Can we have new learnings?
Same thing with our AppSec folks. Bringing all the expertise together early on really helps people, time in and time out, what they do too.
Shane Hastie: Thank you for that. Ravi, if people want to continue the conversation, where do they find you?
Ravi Lachhman: You can visit us at www.harness.io. Or you can hit me up at @ravilach, R-A-V-I-L-A-C-H on Twitter. Love to talk to people. Love to converse.
Shane Hastie: Thank you so much.
Ravi Lachhman: Thanks Shane.
Mentioned: