At WayScript, we spend a lot of time thinking about developers and the challenges they face, which go beyond the technical. We wanted to hear from others who also spend time in the developer space and get their perspectives on building a business with devs.
This week, we spoke with Ellen Chisa, Founder-in-Residence at Boldstart Ventures. Watch the full interview here.
About Ellen
Ellen is an engineer, product manager, and entrepreneur who previously founded Dark, a platform enabling devs to write serverless backends. Before that, she worked at Blade as an EIR and helped seed the work for what eventually became Lola, an enterprise travel management software tool. She’s also worked at Kickstarter and Microsoft and she’s now the Founder-in Residence at boldstart Ventures, where she gets to do some investing as well as provide hands-on support for founders building pre-product, dev-focused, enterprise companies.
Monica from Team WayScript
How has the role of the software engineer changed over the past 10 years or so? What are some of the added responsibilities/burdens a professional software engineer now faces at their org?
Ellen Chisa
It's so funny, you bring this up, I was in Tel Aviv a couple months ago giving a talk on what the next 10 years of DevOps is going to look like. And when you think about that, you obviously go, “Oh, what was it actually, like 10 years ago?”. When I thought about myself—10 years ago, I was working at Microsoft. At the time, we were still working on software that shipped in a box.
The job of an engineer was quite different, because you'd have this big upfront milestone where a product manager or program manager would write out specifications around everything the software needed to do. If you were an engineer, all you basically had to do was build exactly those features. And then you would throw it over the wall to someone else who would hopefully test it and stabilize it. You spent a lot of time making sure there were zero bugs, which of course, is impossible, as we all know. And then it would ship in a box. You would never have to think about that piece of software you'd written ever again.
When you contrast that with today, first of all, user expectations for our software are much higher. Developers spend a ton more time going back and forth with designers. We no longer necessarily have those dedicated testing teams we once did, so developers become responsible for the quality of their own software. And for most of what we do, we still have some on-prem, but a lot of it is on the cloud, and we're continually maintaining it. So it's not just like you ship it and it's gone.
Even beyond that, there are things we don’t even touch on, like accessibility: we want to be making products that everyone can use. That's a whole specific skill set. Maybe you have one expert on your team, but probably not every engineer is an expert. Another challenge is internationalization and making sure it's going to work well in the entire world. When you're deploying your software, you’re thinking about security and all of the vulnerabilities you might be introducing. There are so many challenges related to modern software.
Team WayScript
Should this worry company leaders? Should they invest in improving developer experience? Who, why, how early should this be a focus?
EC
Yes, definitely. Another trend we've seen over the last 10 years is it's really hard to hire developers today, especially extremely talented people. They have a lot of options: they can go to one of the big technology companies, they can start their own company, they can have their own consulting practice.
When we think about what's really going to motivate them to work with you, part of it is what you're building for your customer and the developer’s alignment with that. And part of it is their day-to-day experience of what's it actually like when they're at their laptop or their desktop writing code every day. Are they able to work in a way that feels fluid to them? It's both from a hiring perspective, but also productivity from the org’s perspective as well.
Stripe released a great report, I think it's a little bit old now, probably 2018, called the Developer Coefficient that talks about how we've spent half of our time developing, not actually working on building new features, which is what we actually want to be doing. We’re just starting to scratch the surface of building effectively.
Team WayScript
What are some strategies / approaches you’ve seen engineering leaders take to improve developer experience that have been particularly successful?
EC
I talked to Peter Bell at one of his CTO summits–which is a great resource, by the way. If people are looking for a like minded group of CTOs or Director of Engineering leaders, the CTO Summit Series is great. But we spent a lot of time talking about how you can do a culture audit, which I think is kind of akin to this.
One of the best things you can do is figure out what your engineering team is actually talking about. Say you have a healthy retrospective setup. On Friday, everyone talks about the highlights and the lowlights of their week. If people talk about the flaky test suite every week, you can start to get the idea that that's something that's really a drag–no one wants to fix it, it feels like technical debt, and maybe it feels like they won't be rewarded for doing that, even though it would improve things for everyone else. In doing so, you can find the lower effort, high impact pieces by spending time with the engineers.
Team WayScript
What else should engineering leaders keep in mind, beyond a culture audit, as they're investing in developer experience?
EC
You have to think about the intersection between what's going to be effective for your organization and what people want.You see this crop up a lot with some cool new language. Recently, everyone likes to talk about Rust and Go or Wasm, and people get really excited. You could add this new language to your stack and it would make someone happy for a little bit. But is it the right technology for the problem we're trying to solve? How are we going to maintain it? And how much complexity do we add to our engineering infrastructure by also adding this? From that regard, be thoughtful about what you bring in when people ask for it.
Team WayScript
Beyond the experience of building the core product software, another major challenge company leaders face is working with (or around) their engineering team to get custom software to support their own initiatives (eg sales requesting customer data from backend tables, product requesting UAT environments, etc). What are some of the barriers between engineering orgs and the rest of the company that make collaboration difficult?
EC
One thing that we underestimate is how differently we think about what we're going to build, when we get down to the level of “I have this technical specification and what I've been asked for”, versus what a non technical user might come in asking for. It’s really easy for, say, a salesperson to come in and say, “hey, I want this report”. And it turns out that the way the database is set up, pulling the report is either really computationally expensive, or is hard to write. Also, maybe that's not exactly what the salesperson needs.
But you need that back and forth to have the conversation and figure out the underlying requirement and all the possible technical ways to solve it. Sometimes non technical users overly specify the solution. And sometimes engineers forget to expand out and ask, “Why am I being asked about this”. One of the great things about being in house is you can have that back and forth.
Team WayScript
In the example you gave, to even enable the nontechnical user to safely access the customer data, you have to stand up so much infrastructure. The question becomes “Is that effort worth it? Is it not?”. Even just setting up the initial version of that takes so much effort, that by the time the back and forth can start, the requirements conversation is almost like a secondary thought.
EC
Exactly. Yes. That's one of the big problems with infrastructure: you end up needing just as much infrastructure to build something internally that you might need to just ship.
Team WayScript
Have you seen what companies do to break these barriers down? Are there any particular success stories on that front?
EC
I think it really depends on the company and what makes the most sense there. When I was at Kickstarter, we had something really cool set up called “GitHub for Poets”. The engineering team taught the entire Community team the basics of how to use GitHub. Just getting into that mindset of “this is how engineers think about building things” and establish that this is one of the core pieces of our workload really helped to build that relationship up over time. And then likewise, people from the Community team would teach all kinds of skills they had.
We had a rotation where engineers would go through and do support tickets and we would get to see the differences there. So there's things like that that tend to work well.
And then I think even what you're saying, the acknowledgement that you are going to need internal tooling and having someone who cares and is responsible for that the same way you would have someone who's responsible for thinking about your external tooling is another way I've seen people do it.
Team WayScript
We often underestimate the human nature aspect of it. As an engineer, sometimes I don't even know my colleagues in the sales or marketing org so it can be tough to have that back and forth when there is no relationship or understanding of how they are thinking through the same problem, which is tough.
EC
Whereas if you can say, “this is our dedicated person who's here for internal tools”, and they can be the face of that effort, they can start to understand the difference between a sales person asking for something, and “oh, it turns out this tool is a great idea and it would be useful for every single sales rep.”
Team WayEcript
Ellen, those are all the questions that I have for you on the changing role of the developer and how engineering orgs can support them. Do you have any last minute thoughts? Or a piece of advice you might give somebody who's trying to focus on developer experience at their company itself?
EC
The one thing I would tell you just for the developer experience piece is, a lot of the time when we talk about experience, we just mean we want it to be as easy as possible, which makes sense. If you're building, say, a shopping cart, you want it to be easy for people to buy your product and checkout. But for developers, most developers got into that because they enjoy the process of developing software. The underlying thing is a good developer experience helps someone stay in the flow state.
Team WayScript
Can you say more about what that flow state is?
EC
Oh, yeah, this is great. There’s a Czech researcher who unfortunately passed away recently, Mihaly Csikszentmihalyi. He has this theory that you have the most engaged experience with something where your level of expertise matches the level of challenge. You always want to be doing something that's a little bit outside of your comfort zone so you're learning something new and you're growing. This is why engineers want the new shiny ticket and not fix this bug they’ve fixed a million times before.
But you don't want it to be so hard that you feel like you're just frustrated and you're stuck. And you start to tell yourself, you're stupid, or you're a bad developer, you don't want that kind of experience either. It's about really nailing it so the team is doing new and challenging things that matter to them without being boring or too hard.
Team WayScript
I love that. And if that work can intersect with what the company needs, it’s all the better. Thank you so much, Ellen, really appreciate you coming on OffScript today.
EC
Thanks for having me!
