Voices of Developer Thriving: How Software Jack-of-all-Trades Eli Mellen promotes 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 second interview of the series, Eli Mellen and Principal Developer Experience Engineer Kristen Foster-Marks explore the four components of Developer Thriving:

• agency

• learning culture

• motivation & self-efficacy

• support & belonging

They discuss how these components have manifested in Eli’s career, including how they’ve helped shape thriving environments for himself and his teams.

Eli’s perspective offers invaluable insights into:

• the importance of setting team agreements around ways of working, 

• the roles of incidental and intentional learning in software work, 

• how thoughtful documentation can mitigate learning debt for an entire team,

• The impact task scoping has on motivation and self-efficacy

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

Kristen: That sounds like a dream team. Sounds like you saw and treated each other as real people, and had systems in place to cultivate this. I bet our audience would love to get details from you on the “ways of working” workshop – can I request a future blog post here?

You mentioned that one of the outcomes of that workshop was understanding areas in which your teammates wanted to grow. I’m particularly passionate about learning culture, both at the team and organizational level, and in understanding how healthy learning cultures practically manifest. 

Learning culture also happens to be one of the four components of the Developer Thriving framework. The behavioral science behind Developer Thriving points to the equally important role that individual contributors and leaders play in shaping a team’s learning culture.

What are ways you’ve seen folks foster healthy learning cultures?

Everywhere I go, if at all possible, I always try to start something like a “papers we love” kinda club, where we bring in papers, or blog posts, or talks, and read them together. I’d love to do book clubs, too, but books cost money and take a lot of time to read, so, papers tend to be a good alternative; oftentimes they’re free, and relatively quick to read in a sitting or two. 

Now, as a product manager, I’ve had opportunities to run my own “ways of working” workshops. Especially when run at the start of a project, I think they’re wicked-handy for setting a team mood, or vibe.

Without those, I think it is hard to squeeze learning into the normal day-to-day flow of design, development, and delivery work. Like, my “papers we love” club works with just time, so I guess money isn’t strictly necessary, but it sure helps if you want to pursue learning through books, or courses, or conferences.

Kristen: Learning culture is your secret work obsession!? I love this so much! 😍

We’re quickly becoming friends here, so I hesitate to do this, Eli, but I want to challenge you on something. You wrote that it’s difficult to “squeeze learning into the normal day-to-day flow of design, development, and delivery work.” That bolding of normal is mine.

My question is: Is learning not part of the normal, day-to-day work of designing, developing, and delivering software? If it isn’t, how can we solidly insert it into the process, ideally in ways that make it visible and its value clear?

Eli: No no no! Challenge away — I dig that question so much!

I think learning is a huge part of the normal, day-to-day work of software delivery…but you’ve caught me in a trap of my own making! I probably incorrectly have sort of established a taxonomy or dichotomy in my mind about “types” of learning. There’s the stuff you learn by existing and doing stuff in the world, and then there’s the stuff you learn by thinking to yourself “I wanna learn this thing!”

— maybe some extra time is baked into an estimate, or there is a discovery sprint to figure some stuff out, but generally, it seems like that sort of day-to-day learning is expected to magically happen.

To arm-chair therapist myself for a second, I am pretty certain I hold this distinction between types of learning because I really struggle with the day-to-day, on-the-fly type of learning.

I keep a page on my personal website where I file away useful bits of code and quick explainers for how to use tools that I feel like I should probably know how to use at whim, but because I typically need to reach for them when I’m in the middle of something else, they never really “stick.” 

Now that I’ve said all that, I realize why I’m drawn to working with teams that include or are primarily researchers! What is research if not combining both types of learning that I’ve described!?

Kristen: When you talk about a dichotomy in types of learning, I think about intentional versus incidental learning, which is a dichotomy oft-discussed in the field of Second Language Acquisition (here’s an exemplary chapter from The Handbook of Second Language Acquisition). I think like many concepts in the area of human language learning, this one heavily maps to learning coding and programming things.

And I really just relate to your sentiments so much, Eli. What I’ve discovered in my career is that up to a certain point, I was consistently failing to ask for dedicated learning time. It actually took being an engineering leader, and having an IC on my team tell me (really confidently!), “I’ll need to take a week to just learn and talk to people, and then I’ll be ready to start coding” for me to really internalize for myself the validity of a request like that.

Around that same time, I was introduced to Dr. Cat Hicks’s concept of learning debt, and I was like, “Wow – I have accumulated so much learning debt because I have been too afraid to ask for time to just learn and upskill before jumping into a solution.”

Do you find it challenging to advocate for that intentional type of learning at work? Like, the kind that might manifest via creating a story-pointed Jira ticket during sprint planning with a title like “Upskill in Python asyncio module in preparation for code refactor”?

Eli: Having it all laid out like that, yes, I 100% think that I’ve struggled to advocate for that intentional type of learning at work. 

I think there are a few facets to why. Primarily confidence, but also because sometimes when I see a ticket, I don’t yet know what I don’t know. It’s only after getting into it that I realize, “Oh wow, I don’t know this!” or, more often the case, “Uh oh, this is orders of magnitude more complicated than I imagined it’d be!”

This is why now as a product manager, I prioritize onboarding documentation above pretty much all else. That sort of documentation, while it might not spell out the technical intricacies of a system, will hopefully lay out how to find your way and where to look for guidance. 

Kristen: You’re making me realize that one thing a healthy learning culture includes is a safe space for us to raise our hands mid-project and say, “Whoops – I didn’t know when we scoped this that I need to upskill, but my initial tinkering has revealed that I do actually need to upskill.”

I think you and I could talk about learning and learning culture all day, Eli, but we better move on to the final element of the Developer Thriving framework: motivation & self-efficacy. 

These are inextricably linked, and are present when developers feel:

• engaged with their work

• that they are able to succeed and solve problems effectively

When you think about your software career, what role has motivation & self-efficacy played in your thriving?

Eli: Framing things through the lens of motivation is interesting to me. When I’m highly motivated, I’m typically experiencing one of two emotions: intense anxiety or really intense excitement.

When I’m feeling anxious about some work, either because of a tight deadline, or because I know other folks are relying on me to get it done before they can pick up their tickets, or whatever, I often feel motivated to jump right in. Likewise, when I’m really excited about work, either because the problem I’m tackling is juicy and impactful, or simply because it is fun, I’m also eager to jump right in. 

In both scenarios I’d describe my relationship to the work as, at least slightly, dysregulated. In that state I struggle to put it away. I struggle to walk away from the work, and instead I constantly mull it over — sometimes for good, sometimes for ill.

Generally, with work, at least, I aim for … blandness? Not to say I’m not engaged, or motivated to do my best work, but I aim to size the work such that it remains “the work.” I think of it sort of like chopping potatoes for a delicious meal. The meal will be rad, but right now I have to do this repetitive, sort of dull task, but that doesn’t mean I can’t strive to do it expertly.

That is the sort of space where I think I’m at my best. Which is where self-efficacy comes in for me. By zooming in, or reducing to those sort of dull, micro tasks that need to happen to build up to the larger whole, the full orchestra in bloom, or the meal to the table, I’m able to size the work to what I can achieve in a given scope, within given constraints. When I can make the work “sized-for-one,” or sized to fit totally in my head, I feel the most capable of success.

Kristen: Okay, interesting! So, if I were to summarize, you feel most motivated when you’re sitting in a state of extreme excitement or anxiety about the work, and your self-efficacy is highest when the unit of work feels scoped at just the right level?

Eli: Your summary is spot on! 

Kristen: I love the way you describe your relationship to work when you’re sitting in a state of high excitement or high anxiety: dysregulated. You mention that you struggle to step away from the work in these states – “sometimes for good, sometimes for ill.” I’m curious about when this turns into a negative thing for you.

Eli: I don’t think I’ve ever experienced a dramatically negative effect outside of what most folks call “burnout.” I honestly feel like I’ve experienced this sort of burnout at most every job I’ve ever had, eventually. Saying that out loud makes me wonder if the problem that needs fixing there is maybe me and my relationship to the work? 

When I’m feeling really motivated, and struggle to walk away, it mostly turns negative in that I hyperfocus on one or two specific problems at hand, and either mull them over and over again, or keep running at them over and over, maybe from slightly different directions.

Doing that, I can miss the bigger perspective. If I hyperfocus on an optimal way to handle important data permissions, some way to ensure that only the folks who need to see something can access it, I may sort of tumble down a path that ignores some obvious and easy solution.

A sort of silly example of this is that once upon a time I had to design and implement a system that allowed folks to create nested pages of content. Initially, when working to figure out the most efficient solution I had a schema that included a bunch of categories of things: 

• Pages

• Tags

• Categories

• Etc.,

And on and on. The database was looking wild, and I knew I was gonna end up with some really gnarly code to prevent circular dependencies.

Eventually, though, I actually sat down and started to implement a toy version of what I was thinking of — sort of like a sketch — because I knew time was running out, and I had to get to work in earnest. Doing that, I realized the simplest solution was just to have pages and tags — to allow every page to have one optional parent page, and to have the ability to support an arbitrary number of tags per page. It hugely simplified the implementation and the data-layer of the entire project.

Being able to balance the motivation to find an optimal solution with the space to draw out a sketch of the thing let me hit on a solution that, had I just been excitedly mulling it over, I think I would have missed.

Kristen: In our private communication, Cat Hicks has said to me, “Motivation as a system isn't the same as just feeling really jazzed about work”, and I feel like your example really illustrates that, Eli.

There are a thousand follow-up questions I’d love to ask you, Eli, but I do think it’s time to wrap! So, allow me one final inquiry:

I love your “papers we love” club idea. If you had to pick a paper that’s garnered the “best” discussion, which would it be?

Eli: I just opened so many browser tabs. It is hard to pick just one! 

I think the paper that started and held the best discussion was Peter Naur’s Programming as Theory Building, especially after some citational spelunking to try and align on what Naur really meant whenever he said “theory.” 

One day I’d love to bring Ursula K. LeGuin’s Carrier Bag Theory of Fiction to a similar group. While it isn’t about programming, I think it has a lot to offer about how we think about programs and programming as acts of creation unto themselves. I’m excited about the idea of approaching programs and programming with similar tools as we do art history and literature. I’d love to spend more time exploring critical code studies as a methodology.

Kristen: These are officially opened in my browser. Thank you for having this conversation with me, Eli. I know our readers will benefit immensely from your experiences and perspective on developer thriving!