The Dev-X Project is a series of features with industry leaders sharing their developer experience insights. In each “episode”, we ask an industry leader 10 interesting questions about DX, collect their responses and insights and share them with you.
In this episode, we’re featuring Rebecca Murphey, Head of Engagement & Insights at Swarmia
About Rebecca: Rebecca is the head of engagement and insights at Swarmia, helping the team build tools that are responsive to the needs of software companies while always keeping the individual contributor experience in mind. Previously, she was an engineering leader at Stripe and Indeed, working in the developer productivity space.
About Swarmia: Swarmia is a productivity platform for development teams that gives engineering leaders, managers, and other stakehokders the insights they need to see what’s slowing them down, and the tools to resolve those blockers. Swarmia, measures key engineering metrics (like DORA, SPACE, and more) and uses those insights to enable dev teams to improve their productivity, collaboration, and workflow and more.
You can follow Rebecca on Twitter and on LinkedIn.
When did you decide to become a developer?
I dabbled a lot in my late teens and early 20s, but I got my first real job as a developer in 2006 or so, making banner ads and landing pages for a local web development agency.
Before that, I mostly worked in print — a lot of what I learned there made me really gravitate toward front-end development, right when it was really taking off.
What are the key ingredients to a really good engineering culture?
Clear goals, high trust, and responsible autonomy.
Clear goals, so we aren’t constantly rehashing what it is we’re doing and why.
High trust, so people can take smart risks and involve just the right people in decisions.
Responsible autonomy, which means individual teams can execute independently, and can choose to take on their own debt, but should never unnecessarily create debt or friction for other teams or the org as a whole.
Let’s say you’re building something from scratch. What does your ideal stack look like?
Depends a lot on what I’m building, I suppose (to be fair, it’s been a while since I wrote code as my day job).
Generally, I’ll choose the simplest thing that can meet the project’s needs, while also providing a decent (read: fast) developer experience.
It’s amazing how much you can do with static sites and serverless functionality these days.
Tell us about an epic engineering fail you’ve experienced in your career. What did you learn from it?
Probably the most expensive incident I was directly connected with was a small change in the markup for a company’s checkbox component in its design system.
I forget the details, but the upshot was that one particular form that used this component was always posted without the checkbox checked, regardless of whether it was checked in the UI.
Our napkin math suggested this cost us on the order of $2.4 million in the data that was lost.
How important is “Developer Experience”? Do you see this as a trend that will evolve into dedicated teams/functions for mainstream tech companies?
The ability for an engineer to focus on their work, to focus on the business problem at hand and to not get dragged down and distracted by parts of the system that aren’t directly related to their task – that’s not important, that’s imperative.
I worry sometimes though that calling this “developer experience” makes it easy for a company to dismiss the value of it – it’s not just about developers having a good time writing code, it really is an essential capability for an engineering organization of any substantial size that wants to move with speed and agility.
What’s your POV on “platform engineering”? Is this just another buzzword? Or is this a trend that will make a tangible, positive impact on development teams?
I think this goes hand in hand with Developer Experience.
For an engineering organization of any substantial size, the developer ecosystem itself is a product. My hope for the emerging “platform engineering” conversation is that it highlights this reality, and brings cohesive, product-minded thinking to that product.
What’s most important to remember is that the developer ecosystem is a product whether there’s a platform engineering effort or not — platform engineering can bring strategy and long-term thinking to decisions that were made locally when the org was smaller.
How has the macroeconomic climate impacted your company’s engineering objectives, goals, and strategy?
For Swarmia, the economic climate has reinforced the value of the platform and tools we provide: more and more companies are looking for ways to get things done more efficiently, and are recognizing that they have a ton of debt in that area — culture, legacy tech, processes that long ago failed to scale.
The economic climate has crystallized the need for us to help more software companies achieve impactful change by identifying and eliminating bottlenecks in the software delivery process.
How are you using AI to impact your developer experience and your team’s overall workflow?
We’re still in the exploratory phase, but opportunities abound, especially in the area of making recommendations for specific actions or improvements based on quantities of unstructured or barely-structured data.
Share some tips to help remote teams collaborate better.
This depends on so many things. Obviously, communication is key, but even the mechanism for that depends on the norms, culture, business needs, and tools at your company. The outcome of that communication should be that many kinds of meetings simply disappear, because work, status, blockers, and even risk are all visible asynchronously. Meetings are reserved for solving problems with low latency and high throughput.
For me when I’m working away from my peers, there is always the time before we meet in person, and the time after that – and the time after meeting is always higher trust and lower latency.
On the developer experience front, one thing I’ve learned is how much the experience of different tools can vary depending on where someone is located. A tool that runs an I/O-heavy script in the middle of the night in the US is running that I/O-heavy script at the start of the day in Europe, for example, making the tool unusable during European mornings.
Do you want to share anything else? Please share anything you think would be of value to the broader developer community:
Productivity, efficiency, velocity, developer experience, even “platform” — all of these words are just a slightly different lens on a fundamental challenge of software development: as a company grows, or even as a codebase grows, delivering high-quality software starts to be harder than it used to be.
What really matters is what you’re doing about it, not what you call it.
Want to upgrade your developer experience with a single “up” command? Check out what we’re building with Preevy - an open source tool that enables you to easily provision preview environments per PR.
Like what you see here? Want to get featured? Check out our DevX Project for other great features and to apply to share your own developer experience wisdom
