Voices of Developer Thriving: How Senior Software Engineer Kathy Lavoie builds for Developer Thriving

In this interview series, we at the Developer Success Lab strive to amplify how developer thriving practically manifests in the lived experiences of software practitioners. The Developer Thriving framework – built on robust empirical research in human wellbeing, learning, and achievement – explores the dynamics within software teams that foster growth, satisfaction, and productivity.

In this first interview of the series, senior software engineers Kathy Lavoie and Kristen Foster-Marks explore the four components of Developer Thriving: learning culture, agency, motivation & self-efficacy, and support & belonging. They discuss how these components have manifested in Kathy’s career, including how they’ve helped shape thriving environments for herself and her teams.

Kathy's perspective offers invaluable insights into the interplay of technical skill, continuous learning, what motivates developers, the importance of psychological safety, and the role of teamwork and collaboration in creating successful, productive, thriving software teams.

Kristen: Kathy, I’m excited to explore the concept of developer thriving with you! Before we fully dive in: Can you tell the readers who you are, what you do, and why you’re in the software development space?

Kathy: Starting off existential! Well, my name is Kathy and I work as a software engineer. I have a pretty strong focus in the frontend, but I’ve been known to dabble in other parts of the stack when it is helpful to the team. I started out self taught, went through a full stack bootcamp, and the rest is history. 

I was drawn to this field because of the endless number of puzzles and the unique ability to combine creativity with logic in a way that people experience - I am very passionate about UX and how users interact with a product.  I feel very lucky to have found myself on this path because there is so much to learn, and the skills that I gain bring tremendous value to a business.

Aside from my passion for frontend development, I am a wife to a wonderful bearded man, and mama to a little kiddo, a very old cat, and a lot of aquatic creatures (mostly goldfish & mystery snails).

Kristen: Mystery snails? Okay, we’re not gonna dig into that now, but we are going to dig into that at some point…

The human component of software development is exactly what draws me to the evidence-based, human-centered work of the Developer Success Lab. Their work around Developer Thriving in particular deeply resonates with me.

The curious nerd in me wants to know how this research resonates with other software developers. So, let’s dive into how Developer Thriving has manifested in your lived experiences as a software developer.

How does that sound to you? Hopefully like a lot of fun! 😀

Kathy: From what I’ve learned so far about the Developer Thriving  framework, it seems like an important collection of principles that seem intuitive, but can be the first to go out the window when things get hard on software development teams. In my experience, taking a human-first approach to difficult situations is often the most effective way to make improvements. I’m excited to discuss it with you 🙂 

Kristen: Amazing! Then let’s dive in.

First, a refresher: What exactly is Developer Thriving? Well, it’s a framework that describes four core sociocognitive dynamics that – when present on software development teams – drives developer satisfaction and productivity.

Those four factors are:

1. learning culture
2. agency
3. motivation & self-efficacy
4. support & belonging

I’d like to take each of these four elements in turn and explore them with you. Let’s start with agency.

To give a couple examples, a developer has agency when they:

• are able to voice disagreement with team definitions of success

• have a voice in how their contributions are measured

When you think about work environments in which you’ve thrived, as well as those in which you’ve floundered or struggled, what role do you think agency played in that thriving or floundering?

Kathy: I think agency is a really important part of growing in a role, but agency on its own is not enough to completely fuel professional growth. To me, having too much agency without enough direction or safety can actually be quite damaging. Thinking about it in terms of Maslow’s hierarchy, agency would be further up the pyramid.

For example, when you start a new role it is easy to think about the impact that you might have, and agency is a critical part of that. How are you supposed to make an impact if you do not have the authority to do so? However, agency comes after basic needs like psychological safety and the freedom to learn and apply learnings are met. I will say in roles that I’ve thrived in, I’ve felt appreciated and that the work that I am doing is important. I feel that I am learning and that what I am learning has a positive impact on the team. Those foundational things have inspired me to exercise my agency in pushing initiatives forward. So I would say agency to initiate change is the result of a healthy environment rather than what comprises it.

Kristen: I’m struck (and delighted) by your positioning of learning as a basic need. Learning – particularly visible, on-the-job learning – is close to my heart, and when you describe “the freedom to learn and apply learnings” as a foundational need, and one that has inspired, encouraged, and enabled you to exercise agency, I wholeheartedly agree. Learning culture is also a component of the Developer Thriving framework.

Have you ever found yourself in a role where “the freedom to learn and apply learnings” was missing?

Kathy: Has “the freedom to learn and apply learnings” ever been missing in my software career? I think the answer is yes and no. No, because it is undeniable that software has always moved fast and I’ve never been part of an organization that has openly discouraged learning. It is a fundamental part of this career path to continue to learn and evolve with the industry. 

I think there are three parts to learning and implementing that learning:

1. Incentive for engineers to dedicate time to learning (when learning & innovation is encouraged, recognized, and rewarded)

2. Organizational support for incorporating new patterns into work (for example, prioritizing making space for maintenance alongside feature work).

3. Authority to make changes, or the space and empowerment to propose improvements.

The lack of freedom to learn and apply learnings has impacted me in a number of different ways. Earlier on in my career, it felt like an impenetrable wall that would cause me to doubt whether I could see myself in a role long term. With more experience I started to see that it was often more of a communication barrier that required working more towards how to communicate the business value for the work. Regardless, it can continue to be disempowering and have negative effects. In my experience...

Kristen: That is so true! And it’s rarely an easy balance to strike. What are some ways you’ve seen both individual contributors and engineering leaders foster healthy learning cultures?

Kathy: I think there are a number of ways to encourage a strong learning culture around some common themes:

• Organizational support

  • Sponsoring learning opportunities through a budget for resources like books or online courses, conferences, or tuition reimbursement

  • Leaders checking in regarding what innovations IC’s are passionate about and whether they are getting the support they need

• Dedicated time

  • Building code health initiatives into feature work and allowing extra time for that maintenance, instead of constantly kicking the can on improvements

  • Hackathons or general “play time” with no expectation of deliverables, allowing folks to experiment independently

• Sharing learnings

  • Showcasing & celebrating enhancements that teams are making

  • I’ve seen varying levels of success with groups that regularly meet - like book clubs, guilds, etc. Anything that becomes a compulsory recurring meeting is often well intentioned, but not always successful. I could write a lot more on this, but I’d suggest encouraging community within concentrations (frontend, platform, etc) with as-needed topic-driven meetings around standards and new patterns.

Kristen: Um, I want to be on a team that includes all of those elements!

Motivation is another component of Developer Thriving. What motivates you as a software developer, Kathy? Have you had developer roles where you felt particularly de-motivated, and if so, what factors contributed to that?

Kathy: Many things motivate me as a software developer. I would split it into two different focuses, though: code and team.

From a code perspective,  I am motivated by quality and the pursuit of it. Coding requires a lot of attention to detail and tiny nitpicky bits, which I love. Whether it is introducing a new pattern, improving UX, or building a new feature that will expand a product’s capabilities, I really enjoy making improvements where I can.

From a team perspective, I am motivated to help others learn and enjoy what they do. It makes me very happy to make other people happy, so I am motivated to help my team be the most cohesive and productive we can possibly be. I’ve really enjoyed working with different parts of an organization like product and design - when you get the right people talking, a lot of progress can be made quickly which can feel awesome.

I have been demotivated when there are issues with psychological safety within a team, for example, if someone acts in a way that makes me or others feel unsafe. It is hard to productively work when criticism feels personal. It has also been demotivating when product direction is unclear, when the momentum of a project is disrupted (or in some cases completely thrown out), and when deadlines feel unreasonable, unexplained, and inflexible.

Kristen: To me, it’s really striking that you’re so motivated to help others and contribute to creating a cohesive and productive team. I think this is a rare quality, Kathy, both within and beyond the software domain, and it’s part of what makes you such a special teammate. When I think about development environments in which I’ve thrived, this social cohesion (which I think is often if not always marked by high psychological safety) is a constant. And in fact, you created that for me in my first “real” software job, when we worked at Zayo together. We weren’t even on the same team, and yet you reached out to me on the first day to welcome me, get to know me, and just make me feel like I was wanted there. Like I’d gotten the job because people there genuinely wanted me in that role. I think that’s a rare sort of welcome in the software space. You have this incredible gift of fostering a sense of belonging among your colleagues.

Kathy: It is so flattering that you would say that. I have spent a lot of time thinking about motivation and belonging because there have been many times that I have lacked one or both of those. At the same time, I’ve always been driven to contribute whatever gifts I have to a greater good, so I have spent a lot of time thinking about what things could make that possible.

I’ve noticed that in general, people are more productive when they are having fun.

For many reasons, many folks do not get the opportunity to pursue what they are truly passionate about. We often work for companies to enable a certain lifestyle, but that doesn’t mean we need to live without passion. I believe that when teams experience cohesion and belonging, when they are seen for what they are capable of as individuals, respected,  and given the freedom to actually do what they are good at, it can provide not only a great sense of personal achievement, but things just start “happening” magically. Deadlines are met. Innovation happens. A culture of authentic high achievement is created. In the best case scenario, that can have a real holistic impact on the mental health and overall quality of life for all involved. Especially when we spend something like ⅓ of our lives at work, that can be a big deal.

It may sound silly, but I think that in many cases...

I’ve seen that happen on several occasions and it is something I truly believe is not only possible, but necessary to a sustainable culture of high performance. I’ve noticed that in general, regardless of work environment, people will feel loyalty because of the people on their team; that’s been the case so much more often than loyalty to a company itself or what opportunity they have to create.

So to summarize, yes – making people feel like they belong is pretty important to me.

Kristen: There are a thousand follow-up questions I’d love to ask you, Kathy, but I have looked at our word count, and so with that, I think it’s time to wrap! Thank you for having this conversation with me. I look forward to watching you continue to facilitate thriving on your development teams!