Voices of Developer Thriving: How Senior Software Engineer Lauren Marsillo Uses Science to Advocate for Change

In this interview series, we at the Developer Success Lab (DSL) 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 third interview of the series, Senior Software Engineer Lauren Marsillo and Principal Developer Experience Engineer Kristen Foster-Marks explore not just Developer Thriving, but also DSL research on AI Skill Threat, and the value of using empirical research to initiate change on software teams.

Kristen: Lauren, I’m beyond excited to chat with you! Can you start by telling the readers who you are, what you do, and what led you to software engineering?

Lauren: I’m a software developer with about four years of professional experience, but I’ve been coding and working with tech for much longer. I’ve always been interested in computers and technology, so I was certain pursuing a Computer Science degree was what I wanted to do with my career. I still spend a lot of my free time looking into the latest technologies and trends so that I can stay up to speed with the industry.

Currently, I’m a Senior Software Engineer at Sun Life, working on developing generic CI/CD pipelines for data scientists to train, test, and deploy machine learning models. As part of this work, our team is working on ensuring proper standards and best practices are followed when developing and deploying these models so that they can be properly iterated on. 

Kristen: I imagine that’s a really interesting niche to be in, building CI/CD pipelines for machine learning model development. It’s a burgeoning space, from my understanding.

My team at the DSL heard about you after you brought “The New Developer” research to your team. I’m curious to know how you learned about that research, and then what compelled you to bring it to your team?

Lauren: Sun Life is in the process of implementing Generative AI tools like Github Copilot, as well as experimenting with Generative AI in things like chatbots for various business cases. During a Generative AI discussion at a town hall, the panel speakers were asked if they had thought about AI Skill Threat, and how they intended to implement these Generative AI tools with that concept in mind. A coworker then shared “The New Developer” research in the chat, which introduced me to the DSL and the concept of AI Skill Threat.

When I read “The New Developer”, I was fascinated by the findings, and thought that since Sun Life is now trying to implement Generative AI tools, the paper was very pertinent to us and our work. On my team, we have weekly meetings where various engineers in the department meet to discuss anything having to do with engineering and their work, so that we can align on best practices and have support from other developers should we encounter any issues with our work. At these meetings, there is a rotation for each person to bring something engineering-related to the group to discuss.

I brought “The New Developer” during my rotation. I wanted to highlight to folks in the engineering department that there are developers who are worried about AI, and that there are ways to mitigate this worry. I hoped this would spark a discussion on how well we are supporting our developers, and maybe consider if we are being thoughtful with how we are introducing Generative AI tools.

and in case any developers on the team were feeling unable to speak up about their worries, I thought this research would validate that they’re not alone, as the evidence suggests AI Skill Threat is fairly common. I also wanted to present the correlations between lower AI Skill Threat and positive attributes like establishing a learning culture and sense of belonging, so that the team would feel more empowered to continue encouraging those attributes, as well as fighting the negative ones.

Kristen: Lauren, I appreciate your desire for folks on your team to not feel alone in experiencing feelings of AI Skill Threat. I think that points to a high level of empathy on your part! And your instinct in bringing the research and the concept of AI Skill Threat to your team to discuss was astute; we suggest that teams hold a pre-mortem to collectively surface fears, anxieties and worries around Generate AI, and what you did with your team sounds really similar in concept and purpose.

I’d love to explore this idea of computer science being an intimidating field that can cause folks to feel “unable to speak up about their worries”, to borrow your words. What do you think are some of the things that make the Computer Science and software domain feel so intimidating?

Lauren: It seems like the field attracts a lot of bright, analytical minds, which is great to see. However, some of these people can be quite opinionated and vocal about those opinions, and I find that can be intimidating to those who find it hard to speak up. It’s easy to start comparing yourself to those around you, and when you’re surrounded by very smart people who are staunch in what they consider to be the right way, it can be hard to ask questions to try to better your understanding.

Since Computer Science attracts smart people, oftentimes people value their intelligence and knowledge over other things. For some, it can seem like having a discussion about a new tool or process is actually challenging that intelligence. And because people hold their intelligence so close, it can be intimidating for new developers to ask questions out of fear of seeming “dumb”.

The New Developer research discusses some of the negative traits that are prevalent in Computer Science, and it was very validating to see these aspects of the culture I was feeling put into words. There’s likely a lot of contributing factors, and I would love to know more. I think what I mentioned above only scratches the surface of what contributes to the intimidating culture.

Kristen: You mentioned that software engineering “naturally gets competitive very quickly if leadership isn’t actively doing their part to stop it.” In your time as a software engineer, have you observed leaders taking action to address these competitive contest cultures?

Lauren: No, I haven’t. I think there could be two reasons for this: Either the culture isn’t obvious enough to them since leaders are typically fairly far removed (maybe it’s affecting people who don’t make their opinions/voices heard), or

On my team, leadership tends to let the engineers conduct and organize themselves. I believe this is to give us the freedom to work the way we want and to emphasize that they trust us to make the right decisions. I think this method has its pros and cons. One con is that those who are the loudest take over, and these loudest voices see others not speaking up and assume they are not smart enough, when really their silence could just be an environmental issue.

I think the biggest perpetuator of contest cultures, though, is unfortunately much harder for individual leadership to mitigate. I think this is pretty common in most companies, but at the end of a fiscal year, each employee is “graded”, and that grade determines your bonus and raise for the next year. There are only so many As available for the team. So when the grades are distributed, if you feel you didn’t get what you deserved, it’s easy to start comparing yourself to all your colleagues and resenting them if you feel you did more than them. This can get exacerbated if it feels like you aren’t being heard, i.e. if you raise how you feel about the evaluation and are told, “That’s just the way it is. It’s out of our control.”

Kristen: This idea – rather, this reality – of high performers holding the power to perpetuate unhealthy cultures without being held accountable for bad behavior is just so poignant.

We had a previous conversation where you said that being able to walk into conversations with colleagues and leaders armed with findings from empirical, scientific research has given you confidence in making assertions about how things should be done, or how things should change. Can you expand on that?

Lauren: It’s really helpful to refer to empirical evidence on how a work culture should be cultivated. When your work life is in a highly competitive culture where coworkers and leaders act in individualistic ways, it’s easy to second-guess if change is necessary, since that’s what it feels like everyone around you is abiding by. However, having that research that challenges those ways of working is a helpful reminder to push for change.

I feel like most people want what’s best for the workers as well as quality work output - we just need reminders and frequent check-ins to make sure we are not falling into bad habits. So having research that breaks down succinctly and clearly what contributes to healthy and balanced work cultures for developers is extremely valuable. It means that someone like me who wants the best for everyone can put more effort into developing the relationships and specific processes to ensure my team is doing well, and less on figuring out how to do that, since I can simply follow and reference what the research already specifies.

Kristen: You’re speaking my language here, Lauren. There’s so much advice peddled on how to best do software development, and how to best organize software teams, and so little of it is evidence-based! So little of it draws on robust, empirical research. Entire products and companies get built around untested theories, in fact. And so the fact that you’re out there putting empirical research into practice is the beacon of light that makes what we do at the DSL worthwhile!

Do you have any advice for software engineers and leaders who want to find, read, and incorporate empirical science into their engineering practices?

Lauren: What I try to do is keep up with websites and research labs like the DSL that have put out work that – to me – seems thorough, empathetic, and empirical. This isn’t common, though, so usually I am just reading individual papers from various academic institutions.

I also find curating my socials with people who inspire me and that I respect often leads to some interesting research or opinion pieces.

Kristen: It sounds like you’ve got a robust process for finding and incorporating empirical software engineering research. I hope our readers can take some inspiration here and start infusing empirical work into their own practices!

There’s so much more I’d love to ask you, but I think we’d better wrap it here. Thank you for having this conversation with me, Lauren. I just know that our readers will have learned a ton from you through reading this interview!