Voices of Developer Thriving: How Software Jack-of-all-Trades Eli Mellen promote...

Kristen: Eli, thank you for agreeing to this interview! I’m excited to explore the concept of Developer Thriving with you in the context of your lived experiences as a software practitioner.

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?

Eli: Thanks Kristen, I’d love to! I’m Eli (he/him) — I live and work in Maine, USA. I’m a polyglot programmer, who currently works as a product manager and accessibility specialist in the civic tech space. Previously, I’ve worked on mobile apps for a variety of folks, including an audio book retailer, and various national and international governing bodies of sport. Outside of work, I’m always interested in learning about programming languages, especially lisps, visual programming, and array programming systems like APL. When I’m not at a computer I love reading, chasing my kids around, and biking.

I work in the software development space because I have two degrees in the liberal arts; initially with plans to become a professor of some sort, but, with a family fast approaching, I decided I should probably find a way to make myself employable outside of academia. I hadn’t studied computer science or software development in school, but I’d always been interested in it, and played with it all throughout high school. I love to learn stuff sort of regardless of topic, and software development has proven a ripe space to practice that love of learning and exploration. 

Kristen: You have such an interesting background, Eli. Like, I’m reading this and thinking I want to go drink some beers with you and hear all the details! 

But for the sake of our audience here, I suppose we better focus on Developer Thriving.

As a reminder, the Developer Thriving framework helps to answer what drives developer satisfaction. It’s a measure of developers’ environments that captures whether their teams have four key factors that serve to enable their knowledge work.

Those four factors are:

• agency

• learning culture

• motivation & self-efficacy

• support & belonging

I’d like to take each of these four sociocognitive elements that comprise Developer Thriving and explore them with you. Let’s start with agency.

The researchers write that agency is present when a developer is:

• “able to voice disagreement with team definitions of success”, and

• “has a voice in how their contributions are measured”

When you think about work environments in which you’ve thrived, and those in which you’ve floundered or struggled, what role do you think agency played?

Eli: I think it is really important how you’ve framed agency as having those two facets: 

• The ability to share disagreement about what success is

• The ability to contribute to how that success is measured

From my experience, being able to do both of those things is indicative of a high-trust environment, where safety and respect, and maybe even support among the team, is really important and actively maintained. I’ve struggled when I’m on teams with low degrees of support and trust, but felt like I’ve thrived — been the most content and done my best work — when I’m on teams with high levels of trust and support. 

This all said, I think having agency on a team tends to be indicative of that team having done the work to externalize expectations, and that by doing that folks know they are safe to share disagreement about what constitutes success, and how to gauge that success. 

I’ve thrived when I’ve had a clear understanding of expectations, and the agency to pursue clarity around expectations as needed. 

For instance, when working with a client on a mobile app, they stated that their goal was to share content with their users. As I spoke with them more, it seemed like this wasn’t exactly what they wanted, but was how they were describing it. Thankfully, in that scenario I had the ability to seek further clarity, and working with them we realized that their real goal was to grow their membership, and their content was how they wanted to achieve that growth. 

Kristen: I hear what you’re saying about externalizing expectations. One of the best engineering teams I’ve been on co-created and documented agreements around things like a “definition of done”, and it really propelled our productivity and velocity as a team, it turns out.

You mention “support among the team.” This makes me think of support and sense of belonging, which also show up in the Developer Thriving framework.

Signals of support and sense of belonging include developers feeling:

• Supported by their team to grow, learn, and make mistakes

• Accepted by their team for who they are

Have you been on a team for which you felt an exceptional sense of support and belonging? What specific elements in that environment contributed to that?

Eli: Yes! I’m lucky enough that I’ve been on teams where I’ve felt like I belonged and was supported. 

Most recently when I was serving as sort of a jack-of-all-trades on a team focused on producing strategic, generative research for a government agency to help them better understand any gaps and unmet needs the folks they serve were experiencing. 

I think I felt this way on this team for a few reasons — first and foremost because it was a great group of people who collectively showed up as people. We had the safety and trust to be honest with each other. This meant we could voice disagreement, concerns, or frustration with the direction of the work openly, but it also meant we could drop a message into Slack at 4 AM to let the team know we weren’t gonna be all there that day because we’d been up with a sick kid all night, and the team reacted sympathetically, offering to step in for you that day. Pragmatically that meant we maintained our delivery velocity, but also meant we could take care of ourselves and each other. 

That team also did a lot of work to set shared expectations using a “ways of working” workshop, which was then externalized and regularly revisited in our “ways of working” documentation. An impactful part of that workshop and the resulting documentation was that