In January, we hosted a "Fireside Chat" with Co-founder of RedMonk, James Governor, and our own Principal Technical Marketing Engineer, Cody De Arkland.
The conversation followed the theme of meeting developers where they are–whether quite literally as companies consider bringing people back into the office, or more figuratively in terms of inclusivity and psychological safety.
James has recently posted a followup blog post on this very chat, and we wanted to share the full talk for added context.
This post contains a quick breakdown of some of the highlights, as well as the transcript of what was covered. If you’d rather watch the presentation in full, you can do that below.
Developer experience and user empathy
James and Cody begin by exploring how developer experience should be considered long before people start to use your product, and why it should be centered on empathy for the user.
Great developer experience and advocacy should focus on three things: listening, design, and great experience with tooling.
As Cody points out:
“If somebody's a developer, a creator, a builder, or an operator, [they’ll ask] ‘is there a place where I land that I can figure out how to do this and get beyond the case study or beyond the layers of menus on the page and actually find a code snippet? And, when I get there, is that stuff organized in a way that I can actually have a path through?’”
They also discuss why technical communications, i.e., removing as many points of friction as possible, is arguably the most important focus on the industry right now.
What is the developer experience gap?
Later, James describes the developer experience gap—the challenge that developers face today as the market promises start-to-finish tooling that’s robust, automated, and increasingly intelligent.
But here’s the catch: you have to build and maintain it yourself.
James explains:
“On the one hand, there's all this choice. All of these things glued together. The bad news is once we've done it, we have to manage it. And we end up in an environment where we're seemingly working to support infrastructure that was just there to help solve a problem for us. [...] During the last two years, we've been on this journey, and I think it's becoming ever clearer that there is a premium to good developer experiences. Companies that are providing better developer experiences are getting a lot of attention, and justifiably so.”
The developer experience is also shaping the way people manage productivity and distributed work. Meeting people where they are applies to all of the incredible variations in people’s working situations right now, from caring for kids or aging parents while they work from home, to needing flexible scheduling, to living across the globe and working from differing timezones. For James, providing tooling that makes people immediately productive when they sit down at their desks is a prime example of the industry becoming more inclusive.
“Not everybody has the luxury of getting up at 8 a.m. and coding until 8 p.m.,” he says. “That is an extreme position of privilege. [But] I think our tools for distributed work have gotten better.”
But the question remains: will companies embrace more of the remote work-first approach even beyond the pandemic?
Bringing it back to workflow
What about the developer workflow? Cody argues that the idea that “everything will mysteriously be solved when we move to microservices and throw this in Kubernetes” forgets about the people behind the work and the development workflow. James’s take: “We’ve massively over-rotated on a set of disciplines that are not required for a lot of what we do in software… It’s thinking about the focus on your team.”
To that end, Cody brings us back to LaunchDarkly as a prime example of a well-defined solution to a well-defined problem—one that exists for teams of all sizes. “I like things that translate, regardless of the size of the team, because those are clear problems that exist, one way or another… What we care about is helping you release features and functionality.”
Watch the full conversation unfold, and why we should all be measuring our "mean time to dopamine."
Transcript:
Cody De Arkland:
Welcome to our fireside chat, everyone. My name is Cody De Arkland. I work for LaunchDarkly. We had a couple of things we're going to cover real quick before we jump into the fireside chat. For those who don't know about us and what we do, LaunchDarkly is the number one feature management platform. We help technology teams. We enable teams to ship code faster, breaking up deployment and release into different processes. We get technology businesses, the power to turn on features within 25 milliseconds for any segment of users across any application. This is important for de-risking the way we release stuff. There's a little bit of a script that we work on when we start these up. But the big thing is we make it easier for you to get features deployed to users and get our applications updating and releasing to teams faster.
Couple of logistic things that we want to cover before we get started. Cameras on if you feel comfortable with that. We'd love to see the interaction. In this of many remote presentations, it's good to see faces and see reactions and keep people engaged. So we love that. We will be doing a Q and A at the end of this. We do a 30-minute chat with me and James where we ramble about random technology things and nerd out a little bit, but we'll do a 15-minute Q and A at the end where we'll pull the audience, have you jump in and offer up some questions and chat. Or if you feel brave and want to interact live, I'd love to have some people come off mic and pitch some questions out to us.
Once we pass that 15-minute Q-and-A timeframe, we'll jump into some breakout rooms. And those breakout rooms are more focused on smaller conversations, to really dive deep and jump into some more conversations about how you're deploying software, what Launched Darkly does, kind of whatever you want to be. We can get in there and talk about cookies for all we care. So definitely want to encourage you to stick around for those breakout sessions. Big note, if you were one of the first 50 to register for the event, you should have received a champagne and caviar kit that you should definitely consume while watching this presentation. It lands the feeling that way. So that being said, I think we're ready to introduce the person who really brought everyone here. God knows it's not me. James, how are you doing buddy?
James:
I'm doing great, really happy to be here. You know, I think that Fireside chat with Cody De Arkland. That's going to be my happy place. I'm James Governor. I am co-founder of a company called RedMonk. We're a research company and advisory company. We focus on understanding the decisions that software developers and engineering teams are making today. So historically, IT was all about purchase, long sales cycles. It was always PowerPoints and sales people. These days, clearly we live in a world where the engineers are much more influential in technology choices. So we try and understand the choices they're making, why they're making them and really understand, develop a culture so that we can help our clients to better serve them. We advocate for software developers and that's what we do. We try and understand the world through their eyes.
You've got kind of a big background in this space, right? The services set is obviously very relevant to what you do now, but your background is heavily in this application infrastructure, that building for developer space, right? You've advised people on developer adoption or developer-led adoption, open source technologies. You're huge in the community, right? Like that's where we end up ranting back and forth often on thinking about your path. It's littered with these stories of different aspects of developer focus, developer experience, open source technologies. Any big things that really excited you from your past that you still carry today? Things like that?
James:
No. I mean, that's a great question. I think what's been interesting for us is just the, we really began with our focus being about open source as a firm and over time, we just began to understand that open source, that was another one of these choices that developers and engineering teams were making. We were about developers and that was the journey we went on. We thought we were about open source. We're like, oh no, actually, it's bigger than that. And it is this community phenomenon. That's what we're most interested in.
Cody De Arkland:
It's little off the beaten path where James and I met. So James is responsible for making my career shift from being about infrastructure and servers to really thinking about the application and things that developers are consuming. I'm trying to make him blush a little bit underneath.
James:
It's definitely working. I'm feeling, I'm glad that I hopefully influenced you in some positive ways.
Cody De Arkland:
Yeah. It was a lot of the progressive delivery stuff early on. Really teaching you about the importance of the way we deploy applications, the blast radius we create. That led to just thinking about developers and the way that we enable people to be productive and do these things. It was just such a big shift for me and what I thought my career was going to be. I look back on the past 10 years of my career and that, when I met you and we had those first conversations were big turning points for me. I thank you for that.
James:
Well, again, I try and do the best I can to help people to make good decisions. So if I've helped you on that regard, that's good. And clearly you've ended up at a great place now. So yeah, I'm super happy for you.
Cody De Arkland:
But thinking about that though, right, and thinking about just the shift of the things I focused on going from how I get servers up and running fast to being more out-patient focused.
James:
Yeah.
Cody De Arkland:
You talk a lot about it, especially, and, and Mr. O'Grady, something you guys talk a lot about as a developer experience.
James:
Yep.
Cody De Arkland:
Right? Like the tooling, the overall experience. At a high level, if you could just succinctly define for people here, what is developer experience to you? When you break that down, what is this focus? It's coming up a lot in the community. Tell me about your take on developer experience.
James:
Yeah. I mean, it's difficult because I do think it's quite hard to like, and now I'm like, oh, good we spoke about what we'd speak about, and I'm still here being like, how do I succinctly answer…But I think it ties together in a number of things. One way I think about it actually is if we think about what's the job of advocacy and DevRel and so on? It's like, where do you express empathy for the developer? And it might be upfront. So you are thinking about the developer experience. And that means you're thinking about a whole range of things. What does it mean the first time a developer ever hits your website? Is there a button that they are like, okay, this is for me? Is there, if you are asking for some sort of identity, is it super easy?
James:
You know, don't ask for the credit card, is this just something I can give a GitHub ID and begin to have the experience? You're thinking about the quality of the SDK. You are thinking about the quality of the documentation, which is so important. So developer experience, you might just think it's like, what are the tools look like? But no, let's think about the docs. Because again, what does it look like when I first arrive there and have the experience? So code snippets, just all of those things, so that I can get a sense of what it means to get started. Then you think about design. The design of the API. The design of the CLI. What is it like in the moment? That's the in-the-moment experience for the developer.
James:
And then the posting is like, developer experience means listening, looking at what developers are doing, and advocacy. And that's why I think developer advocacy is important. Not from a ‘Hey, everybody should adopt our shit,’ but ‘Oh, this is the experience you are having. We need to make this better for you.’
So, within that, do you have an opinion about what the experience should be? Are you meeting the developer where they are? You can be like, oh, you got this great code editor, and then you are not supporting all of the syntax for Python or something. Well, that's a poor developer experience.
So it's really about the ‘pre,’ you know, empathy before the developer meets you. Empathy as they're using you, and then empathy afterwards. I think developer experience and that's why I do think it's tied to the world of DevRel and advocacy is those three things: listening, planning & designing, and then those great experiences of tooling. So I guess that would be where we look at what a great developer experience is.
Cody De Arkland:
You know, what's interesting there is like a lot of people, when you ask these questions about developer experience, they immediately go to, “how do I use the tool? How does the tool work? What's the experience? Like with LaunchDarkly, what's the experience of toggling on and off a feature? Is that a good experience?’
And developer experience starts so much further, before that. The first example you gave of when I go to the webpage, is there a spot that I, as a builder, even broadening the definition beyond just developer, like if somebody's a creator or a builder or an operator, is there a place where I land that I can figure out how to do this and get beyond the case study or beyond the layers of menus on the page and actually find a code snippet? And when I get there, is that stuff organized in a way that I can actually have a path through? Or does it just, I get the code snippet, but I have no idea.
James:
Developers as first class citizens! And technical communications is arguably the most important thing in this industry. Here's the thing. A different definition of developer experience is what is your mean time to dopamine? Or mean time to bits. You want to remove as many points of friction as possible. If I have to go through a bunch of clicks, a bunch of weird screens and stuff like, oh, look at this white paper or something, I'm gone. Mean time to dopamine is super important in developer experience.
Cody De Arkland:
This is a little of an inferred question. How do you think that's changed in the year we've had, two years we've had, of remote work, the shifting and priorities, do you think the tooling and the way that developers are experiencing that tooling landscape has changed? The way they expect to consume, the way they expect to work now, or that meantime to dopamine or the value of that dopamine? Even from a, it sounds like a silly link, but the link of mental health to the consumption of these tools, do you think that has changed much in the past couple years?
James:
Well, I think it was already changing. At RedMonk, we talk about the importance of developer experience, but we also talk about the fact that there's a developer experience gap. We've all seen keynotes. It is a golden era for software developers and we can be so productive with these higher level services and there are all of these choices. And it is amazing as a developer today. Certainly for senior engineers, incredible salaries, lots of choice in market. I can identify a problem space that I'm interested in and I can get a job in that space. Lots and lots of opportunity, but there are also some overheads.
Underpinning this golden era are some fundamentals. Open source. I can just go, I've got access to amazing software to do any of the things I want to do. The cloud. If I want to run something, I can just spin up an Amazon web services instance. I can be deploying that software with a minimum of fuss. Well, I say a minimum of fuss, Amazon maybe doesn't have the best developer experience, but we'll sort of get to that. And then also the social coding revolution. So the fact that I can go to Stack Overflow, I can get answers to my questions. I can go learn new things. I can go to GitHub. I can go find the best developer on the planet in a particular area, and literally look at their check-ins. How they develop software. Why they develop software. How big the changes they make are what their style is. I can go and I can contribute to their projects.
James:
So these underpinnings have created this, as I say, this golden era, but there are some downsides. It's like, you've got all this choice. You can put all this stuff together, but then the organization is good. Oh, good. You built it. And again, we even talked about this, you break it, you fix it. You build it, you fix it. So there's a huge responsibility. So the developer experience gap is: on the one hand, there's all this choice. All of these things glued together. The bad news is once we've done it, we have to manage it. And we end up in an environment where we're seemingly working to support infrastructure that was just there to help solve a problem for us. So, in answer to your question, during the last two years, we're on this journey and I think it's becoming ever clearer that there is a premium to good developer experiences. Companies that are providing better developer experiences are just getting a lot of attention and justifiably so. I think Vercel is just a great example that has taken that sort of workflow. They've really thought about static size and then taken that to the next level. If there is a company that is looking at JavaScript, looking at React, basically bringing in frameworks that make that compelling in a recently, okay, we're going to bring in Svelte, Next.js. Let's bring all of this together in a great package, a packaging exercise, and, generally, the best packager in a tech wave tends to win and win significantly. I do think that Vercel, Render, Netlify, all the work they've been doing has been clearer in the last two years. And then, of course, just the valuations of ...
Look at Twilio and where they are now as just an absolutely core piece of the enterprise landscape, developer-led phenomenon. They've focused on developer experience. Jeff Lawson wrote the book “Ask Your Developer.” The key for me would be, tooling aside, the understanding that (and it should be obvious) software development has to be distributed, right? We lived previously in a world where we would pay lip service to distributed development, but then, I mean certainly, San Francisco companies. We're building tools so that people can collaborate anywhere in the world. And then, we hire someone and say, "Must be willing to relocate to say San Francisco." And it's like-
Cody De Arkland:
3 days a week in the office.
James:
Yeah, yeah. Software is eating the world…as long as it's built south of Market.
Cody De Arkland:
But not for you.
James:
Yeah, not for you. So, I do think that that's the big change, is this understanding. And we've seen that in startups, but also look at automotive. Talking to companies like BMW or Audi, companies like that, they had a mindset: "We're manufacturing companies." So, of course, people come and build something on-site, but suddenly, they found that, wait a minute, actually we're doing software. People are not going to be in the office and we need to rethink these processes. So, for me, that's the big difference. I think and I hope that there is an understanding that what we are doing is distributed work and part of a good developer experience is supporting developers to work when and where and how they want to work.
Cody De Arkland:
You ended up on the path that I was just going to hedge around–the gap of developer experience. Solid lay up on that. Do you feel like we've made progress on the gap?
James:
In pockets, in pockets. On the one hand, yeah. I mentioned platforms. Using Vercel is great or PlanetScale. Absolutely. As a database company, the work that PlanetScale is doing, like the CLI, just the whole experience is great. Getting started with a database and knowing it's like my SQL base and it's going to auto-scale. I'm not going to have to worry about a thing. It's just they are really closely focused on DevX, and that's one of the changes. There are so many more companies now that are really focusing on addressing the gap and sort of thinking about meeting people where they are, and/or provide them with such a slick experience that they're going to buy into this. That's the opportunity.
James:
The history of the IT industry is just folks making and remaking remakes of Heroku, right? It's like opinionated platform, make it easy for the dev, just take things out of their hands. Opinionated-ness is great. We saw it with Ruby on Rails. The platforms that we saw a lot of deployment on Heroku, right? It was great, the opinion, and on the face of it, I'd be like, great. This is the future. Everything's going to be opinionated platforms. But of course, I've been seeing a lot of people say that Amazon kind of sucks at the moment. Like, Amazon, is just primitives. It's just a bunch of primitives. Why don't they give a great developer experience? And I'm like, well, it may be just primitives. And we had Verna say, "Well, that's what you asked for at ReInvent."
James:
And people were like, "Oh, wait. Shouldn't you be cleaning this mess up?" And it's like, well, on the one hand, developer experience is great, but on the other hand, if you want a choice of being a billion dollar company or a trillion dollar company, it seems like Amazon kind of got something kind of right. So, yeah. I think that developer experience is super, and we're going to see in the Kubernetes market. We're going to see it in a bunch of these spaces. We do need an opinion, but at the same time, enterprises and software developers are going to continue to make a bunch of choices.
Cody De Arkland:
But I think that leads to kind of the next lay up here is thinking about this: we move on from the idea of developer experience, but it also loops in productivity as well, right? The way we're working and the way we're establishing good productivity habits. To your point about the Amazon thing—two trillion versus three trillion or whatever—obviously, they're doing something right. People are productive in this platform. You talked to DockerCon about the idea of productivity as a form of inclusion, right?
James:
Yep.
Cody De Arkland:
These ideas in the way developer experience is shaping the way people are becoming more productive is a very interesting telegraph. And the way that is bringing people together, even in the remote work scenarios or the distributed development scenario, what's your thinking on that now? Do you feel like we're on a good trend with that? Do you feel like we're on the right path from making this a more inclusive place through productivity? What's your thinking?
James:
Anybody that has kids knows how challenging it has been to get things done during lockdown, right. And sometimes, work has felt like the thing that you are snatching time to do. And so, at GitHub Universe, there was a great talk where they were demo-ing code spaces and Allie, the woman that did this demo, was like, "I have two kids and I want to work when they're having a nap. And I don't want to be spending time spinning up the environment and doing builds and messing around. The idea with Codespaces is that I could just press the button and just have everything in front of me so that I can be working right there and then."
James:
I think that can be an inclusive thing. I think we've all learned a bit about... We love to talk about flow. Engineering flow, developer flow, but when you got a bunch of kids running around or maybe you are caring, not for a kid, maybe you are caring for a parent, or maybe you've got someone in the family that is disabled or maybe you yourself are disabled. You may not have as much time to do this work as you might otherwise have done. And that being the case, meeting people where they are, providing tooling that makes them immediately productive, I think can be part of a somewhat inclusive industry. That said, look, there's a reason why we're having the great resignation at the moment.
James:
And that is because companies are doing a shitty job of caring for their employees. And, generally, in tech, the people that we are definitely doing a poor job of caring for is women in tech and underestimated groups in tech. Black folks are constantly being held to different standards, finding it harder to get promoted, and so on. I just feel like, yeah, we're not doing a great job of inclusion, but one of the things that that can potentially help, weirdly, is just making it easier for people to do their jobs when they need to and have that flexibility, because flexibility can enable inclusion.
James:
Not everybody has the luxury of getting up at 8:00 AM and coding until 8:00 PM. That is an extreme position of privilege. And so, yeah. That was kind of a big talk about distributed work and I think our tools now for distributed work have gotten better. I mean, if you asked last year, we were all using slack, but we've all got better at using it. Weirdly, we ... You don't think we have? Maybe not. Weirdly, we've been using Zoom for two years and we definitely haven't got better at that.
Cody De Arkland:
So far, in our conversation, if there's one way I could sum it up, it's meeting people where they're at. We opened up talking about developer experience and meeting where they're at and now we're talking about same thing in relation to really productivity and inclusiveness and the people involved in the things that we're doing, right? I think that the companies that are having the hardest time being successful right now are the ones who are not paying attention to meeting people where they're at and they're saying, "This is the way things are, this is how we did it before, and we're going to continue that trend now." And you see the great resignation take place, where people are like, "You know what? I can find people who will meet where I'm at and will identify with me as an individual as opposed to any other form of identifying with me."
James:
It was pre-lockdown, but let's look at two companies that made mandates that you could no longer work remote. IBM and Yahoo. Did that do either of those ... I mean, arguably, they have a lot of other challenges on their plate, but that certainly didn't fix the problems they had. So yeah, I think you're right. Meeting people where they are is just super important.
Cody De Arkland:
Absolutely. So, thinking about that concept and the whole way we work thing. You've talked a lot about GitLab and the way that they've worked in the past. Their development culture, do you think, as they've gone public and as they’re changing, do you think that their success in remote work is going to continue? Do you think that that their development-first culture is going to continue to keep them moving forward now that they are public? And what's your read on them? I know you've spoken really positive about them in the past and that's why I bring it up.
James:
I think that GitLab is super intentional about it. And the great thing is it's a manual. You can literally go and read the GitLab manual, like how employees should deal with situations. The onboarding is there, the culture docs are there, everything is clearly documented. And that's one of the most important things that you can do and it gets back. Again, that's another thing where inclusion means making onboarding easier. If onboarding is, ‘oh, I'm going to hire a senior engineer and they'll be able to work it out,’ that's a shitty onboarding experience. You should be able to bring someone with a little bit less experience and onboard them to help work on the problems. What does that process look like? What do they need to learn? They're just very, very intentional.
James:
And then everybody uses the same tools and everything is genuinely done in public. I showed up to do a consultation with Sid, the CEO, one day and he was like, "Oh, we're doing a consultation. Do you mind if I just stream this to all of our employees in case they're interested?" And I've definitely never heard or seen any other CEO do anything remotely like that. He was just completely like, "If we're doing a consultation, why wouldn't we do it in the open?" So they've just got... I think it's something they've done really well. They've ridden that wave, and they've sort of said, explicitly, "This is part of the culture." And I think it's impressive.
James:
I think it lends its own way to... You talk about the inclusion thing that we mentioned previously, it lends to another form of inclusion, right? These aren't conversations or policies that exist behind some mythical closed door that you can never see behind.
Cody De Arkland:
Mm-hmm (affirmative).
James:
These are things that happen out in the open. And people have a natural feeling of inclusion when that happens, and they get to be a part of that conversation and to see what's happening. They're not hearing it three steps removed from their skip-level manager who heard it from somebody else. They get to be a part of that, and they get to see this policy in action. They get to see the consultation happen live and start to understand a little bit more about what's going on. I think that there's a beauty in it.
Cody De Arkland:
Yeah.
James:
It's corny, but there's a beauty in that.
Cody De Arkland:
Yeah. Implicit norms are really troublesome for creating inclusive culture. I sort of know something about that. Just let's look at English people and how they use English. So it's genuinely the slangs: Cockney rhyming slang: apples and pears/stares, mince pies/eyes, scotch eggs/legs. That was a class saying, "We've got a language that other people won't understand." Meanwhile, the posh people, they have things where the way they pronounce things is so mad that anyone else coming into that space were just not... They would make fool of themselves because they sound weird. And we're a bit off topic, but also on topic is manners. So in England, they have etiquette rather than manners. And my favorite example of that is, upper middle class people, if you're at the table and you want the mustard, you don't say, "May I please have the mustard?" Cody's like, "Where are you going with this?"
Cody De Arkland:
No, no, I'm here for it.
James:
You don't say, "May I have the mustard?" You say, and literally it's next to the person across the table, you say, "Oh, would you like the mustard?" And they say, "Oh. No, thank you very much. I'm fine with the mustard, but would you like it?" And you say, "Oh, yes, thank you very much." Literally, that's a thing in upper middle class. And you're like... Actually, that probably is written down somewhere. But if it's implicit norms where you are excluded because you don't know that thing, that just instantly takes all sorts of people out of inclusion and makes life a lot harder.
Participant Question:
So isn't that the argument that an IBM or Yahoo would make for wanting in-person in an office environment for all employees?
James:
I think so. But for IBM, if you have 300,000 employees, good luck with that. I mean, are you going to have every office have that norm and is able to kind of do this? So I think that documenting, trying to document rather than relying on shared norms through the office... And, again, look, some people can't get into the office. It gets back to the inclusion statement.That's one of the clear things I know people that throughout the pandemic for them they were saying. I can now go to any event I want to. I mean, I once ran an event about accessibility, and that was the point at which I was like... Literally, I walked there, and one of the potential venues, I realized if somebody was walking with a stick, no way. If they were in a wheelchair, there was no way they were going to be able to get there. So going through the ramp, the bus to get there, and everything else, for disabled people, accessibility, I mean, for them, it's not an option.
James:
So yeah, I think IBM, Yahoo, I think we should be making accommodation for remote work. And talent is everywhere. Talent is distributed. And talent may be moms, dads, blind people, people in wheelchairs. Talent is everywhere. And if we say, "You have to be in the office every day," we are shutting ourselves off from talent. And that's why I do think being explicit, documenting, having the employee manual, having the company manual, which is something that GitLab did and they did it intentionally, I think it's good. And it's paying dividends now. I mean, literally, everything is online for [those companies]. You can see where they're hiring. And initially people said, "Well, you're not hiring so many people in Africa." Now, you are beginning to see that filling out. Anyone that isn't thinking about, "How I can have a better onboarding experience for African employees," and they might be in Zambia, they might be in Nigeria, they might be in Kenya, wherever they are. If I'm not thinking about how to work with that talent, I'm missing out on just so many amazing people.
Cody De Arkland:
Real quick, if anybody has any questions, we're definitely into the zone of time where we would love to have people ask questions in chat. A couple things that have come through, I see Gilbert mentioning that the idea of a lot of this is around removing pain points and friction.
James:
Mm-hmm (affirmative).
Cody De Arkland:
I think that onboarding is a scary time, and coming onboard to a company is a scary time for any employee. I remember coming onboard at LaunchDarkly five months ago and feeling like, "How am I going to do this? How is this going to play out?" I think that when you do stuff in the public, you're not only opening up to inclusivity, you're also opening up to accountability, and your gaps become very, very visible when these things are publicly accessible by people to see. So I think a lot of this is about removing pain points, removing friction.
Cody De Arkland:
Stephen Cairns mentioned working at a utility and I know where Stephen Cairns worked. They were an in-person type of company. They wanted you in the office. And just because you're in the office, doesn't mean that you're included in things either. That company had 36 floors to that office, not all of which you had access to.
James:
Yeah.
Cody De Arkland:
And this concept of the multi-floor office changes when everybody's remote and distributed. So I think that just being in the office, to the point of like IBM and Yahoo, doesn't guarantee inclusivity. In fact, in some ways, it discourages it for the people who can't make it there, don't have a way. To your point, James, around people who are working in the Africa can never get to an office that's located in Miami or Georgia.
James:
Mm-hmm (affirmative). And especially if we're not going to give them visas, which is one of the big... I mean, I know so many amazing Nigerian developers, and we just make it super hard to get visas. So that's a mess. I mean, there was a comment there from Brian, it was just like... And also, are you more productive in the office? There may be some things you can do in the office, but it's not especially... That was the other thing. I think just as the pandemic hit was when we were beginning to be like, "Maybe these open plan offices aren't such a good idea." Everybody's in there like, "The most important piece of corporate equipment in my onboarding experience was these really amazing noise canceling headphones." The idea that we'll be more productive if we are in a sort of an open plan, stripped concrete sort of... Yeah, I mean, there isn't any clear evidence. Although, I don't know, there seems to be some arguments that they're making now about productivity being better if people are in the office. But I don't think it's necessarily clear, and it's not true for everyone.
Cody De Arkland:
Great quote, Gilbert. I like that. I like that quote.
James:
Sardines aren't terribly productive in the tin. There you go.
Cody De Arkland:
Yeah. A little bit of a gear shift here. Giving people a chance to come up with some questions. Thinking about the developer, developer practices, development practices, who are some people… I always like to give the people who attend these things something to walk away with. Who are some companies, some places people should be looking at in the space of development practices? People that you admire that you think are companies... You mentioned Vercel, you've mentioned Netlify, you mentioned Twilio. Who are some places that you really encourage people to take a look at, that you admire from a development practice standpoint?
James:
There's a guy, at the moment, called Gergely Orosz, who worked at Uber and is now doing a lot of work looking at... He has a website called the Pragmatic Engineer, and he's just doing a lot of work looking at helping people to get better jobs, helping Europeans to get better jobs, to get the sorts of salaries and compensation that we see American companies giving. But also, just a lot of wisdom about work and employment. Console.dev, David Mytton and Max Jennings. Anyway, great site for dev tools. So it's like a newsletter. And every week, it's like, "Check out these dev tools." I think that's really nice.
James:
I think that the great thing is that stuff is so much more in the open now. Ian Coldwater is just... If you were to ask me like, "Who's the number one security person in containers on the planet right now?" They would be top of my list. So let's say Ian is top the list and just joined Twilio to basically improve their security posture by offensive testing. And I'm sure that some of what they're doing is going to be in the open, and we could all learn from what it means to have offensive security as part of what you do in securing your environment. So I'm both glad that I mentioned Ian, although slightly embarrassed about my pronouns. That was not cool.
James:
But anyway, so yeah, doing things in the open and teaching other people, there are just a huge amount of assets. Oh, final one. Matthew Skelton [and Manuel Pais] have a book called Team Topologies. I mean, look, there's all the stuff we know. So you've got to read Accelerate, follow Dr. Nicole Forsgren's work. But Team Topologies by Matthew Skelton [and Manuel Pais], really interesting, because it comes as like, don't worry about microservices or monoliths, or whatever it is. Think about the team. What is the ideal size of the team to solve the engineering challenge? And I don't think that we, as an industry, even though we’ve got Metcalfe's law and stuff like that.... What does it actually mean to be intentional about the ideal team? Survival of the fittest isn't about the best team win. It's about fitting into a niche. So I think those are some folks that I have been just enjoying their work recently and thinking, "Wow, we can learn a lot from them."
Cody De Arkland:
I love that you mentioned the teams things. I think that we forget about the people workflow of this. And when we get wrapped up in this idea that, like the microservice example you gave, "Everybody needs to break down their monolith into microservices." Incorrect. If you're a small development team, two or three people, do you really need to? I question the need.
James:
Mm-hmm (affirmative).
Cody De Arkland:
There are a lot of reasons why that might not be true. But generally, the team structure and the way your development process and the way you build, the way you push, the way you release features and functionality, the tool chains that you use, all of these influence way more the way that you are working with an application versus everything will mysteriously be solved when we move to microservices and throw this in Kubernetes, right? Just, we've rotated so far into that realm of everything's a microservice, everything's a Kubernetes pod now, and we forget about the people behind it and the development workflow.
James:
It doesn't make any sense. We've massively over-rotated on a set of disciplines that are not required for a lot of what we do in software. And so, I think, what I like about Matthew's work, and the Team Topologies book is that it's really pushing back against that. And it is: “let's think about the job we are doing, and let's have a team that is the right size to solve that particular problem.” And we're not over rotating to, as you say, oh, we're going to have clearly, tens of thousands of Kubernetes pods. Everything needs to be microservices. It's thinking about, hang on, to your point, focus on the team.
Cody De Arkland:
It's a little vendor shill moment here, but this is why I like what we do at LaunchDarkly, because, ultimately, what we care about is helping you release features and functionality. We're solving a problem, right? It's a problem that is the same problem if you have one person on the team, or 10 people on the team.
James:
Mm-hmm (affirmative).
Cody De Arkland:
We're helping release features and functionality into applications better. I like things that translate, regardless of size of team, because those are clear problems that exist, one way or another. It's not...one could argue that a 10 stack microservice application is far more challenging to manage than a monolith and a team of five developers. A small environment, that big, managing that many systems can be its own type of challenge. So I like things that are well defined problem space and well defined solution space.
James:
Yeah, for sure.
Cody De Arkland:
Move beyond the people involved, right?
James:
Oh, on that note, one other person to follow, Simon Willison has a platform that he's building called Datasette. If you want to follow someone that just comes up with great hacks on a regular basis, that are going to make you more effective, super great.
To your point about LaunchDarkly, look, de-risking and decoupling deploy from release. If we're going to have organizations with psychological safety, where you can make mistakes—and we're all going to make mistakes anyway, but my business partner, Steven, has a great phrase that came from a very good and dear friend of the company called Alex King, and his phrase was, "Let's make better mistakes tomorrow”—and I think that feature management is one of the ways that you can make better mistakes. And, that's just gold for creating, again, an inclusive, safe, high-performing team.
Cody De Arkland:
I think, and this sounds like such a marketing lay-up, and I apologize deeply for it, but it goes back to what got me started in this realm, the progressive delivery stuff and being able to control blast radius. That was the light switch moment for me, was the relation of progressive delivery to controlling a blast radius, and being able to make it as big or small you want, or take that away when something is wrong, or narrow it down to a specific part of your application, or decomposing it down. And it really made, for me, the transition to thinking about microservices easier, the transition to future rollouts easier. And it's just that concept and the idea of feature flagging, feature management that tie in so nicely together. But that progressive delivery concept, it's the well defined problem that has a good, methodical solution around how to approach it.
Since I saw that, I think, when Roy introduced us all those years ago-
James:
Yeah.
Cody De Arkland:
It's probably three, four years, now. How do you see the future of progressive delivery? And, before you answer, we're coming up about seven minutes or so before the breakout rooms, if anybody has questions, jump in, toss them in the chat. I'll get you live, and you can ask them as well. But, curious where you see progressive delivery going, now that we've got this well defined space of feature management?
James:
Yeah, I think that culture change is supported by tool change and platform change. And so, it's one thing to identify a set of tools. It's another thing to identify a set of practices. It's the interplay between them that can help make us more effective. So it's one thing for me to say, "Oh, I've identified that CICD is great, but, by the way, there are a set of disciplines around blue-green deployments, canarying, dark launches, with great observability. There are a set of disciplines." It's one thing to identify the way some companies have done that. It's quite another when vendors and clearly, that was one of the things that the whole, my work with LaunchDarkly was exciting. Feature flags was core to that. And LaunchDarkly was, yeah, the patterns you are describing, meet us where we're going from a product management perspective. Because, as it was, you didn't invent feature toggles. You didn't invent feature management. The continuous delivery book, 10 years ago, Martin Fowler was talking about that stuff. But, there were some things we didn't have. I say 10 years ago, it was a bit more than that, now.
James:
But, cloud, we didn't have all these abundant resources. So there are a bunch of things that we have now that we didn't have then. How can we take advantage of that? How can we take advantage of modern routing infrastructures in all that we can? To your point, take a cohort, a named segment of users, offer them an experience, look at what it looks like, and/or even just a named segment of your production infrastructure, what does that look like? How does it perform? Again, the psychological safety of, we know this works, because it's working in production. That's progressive delivery.
James:
And for me, what I'm interested in is seeing...the example is, every time you do an event, the sessions I'm looking for is observability vendors doing things with feature flags. So it'll be the Datadog, or the Honeycomb or the Dynatrace session. That's the one where I'm saying, “This is exciting.” And it's self-serving. It's because that's progressive delivery. And I want to see. Obviously, I would hope that the thing I've described we will see more of.
James:
Now, a whole bunch of things. Enterprise is not quite ready. My big question is, do you ship on a Friday afternoon? And if your answer is, we wouldn’t, of course not, we'd be idiots. We would never ship on a Friday afternoon. We would never ship at Thanksgiving. We would never ship at Christmas. Okay, look, I like the holidays. Don't get me wrong. So, I can understand. But, if you say, "We won't ship on a Friday," then you are saying, we can only do things, we can only release new services four days a week.
James:
And that's...Okay, if we want to do a four-day week, I'll have that conversation. That's an, I think, interesting idea. Three day weekends, four day weeks. Okay. We can have that conversation. But the big question for the enterprise is, is it that I'm not confident to deploy and/or release on a Friday? Progressive delivery is about making the business more comfortable and confident, that they've done everything they can, and then, the product owner or the business owner can decide, now we're turning the service on. And I think that's the progressive delivery. That was what excited me.
James:
When I first started talking about it, there was just the nerds. And then I talked to some CIO's and they were, oh my God, you mean it's not just going to be some developer pressing a button and, yeah, give me progressive delivery. So, yeah. Tools to support that, I think, I'm watching the build out with interest now.
Cody De Arkland:
This part is when people ask me the questions of building versus buying. Hey, I can do feature toggles myself with JavaScript in a contig file. But what you start to lose out on is the ability to do that globally. And the user targeting aspect of it, the anybody who's got a header that's being pushed, that's got the dev header present gets the different configuration and is able to gradually roll that out. It's the logic behind, “how do I trickle this up to 25% of users? How do I back it down to 10? Because I think there's a problem, but I'm not a hundred percent sure, so I want to see on a little less of a pool.” It's the scale. It's the ability to impact this, and orchestrate this at a greater size.
James:
And also, look, bottom line is, what you just described is definitely not the job of most companies building SaaS solutions or enterprise software. That's not their job. That's something that you should work with someone whose job that is, because that's a hard problem.
Cody De Arkland:
Totally. It's not saying I want the log on to be white versus black this week to see if people click more.
James:
No. And I clearly remember that. I remember the day, literally, talking to a New Relic engineering team and they're like, “we built our own, but does that make sense?” Across the board, we should focus on our customers. We should focus on not...You talked about server huggers and stuff like that. No, we should focus on building functionality that serves the customer. And yeah, progressive delivery, that's something we should do, but it's not something that we should be building, necessarily.
Cody De Arkland:
And, to go back to the psychological safety aspect of it, the ability to turn that all off when things go very wrong, and the confidence in that, and getting to a place where you trust the system to do that, the Datadogs of the world, the Dynatrace of the world. If you get a hundred 502 errors in 10 seconds, it's broken. The system should shut that off. You can do that with a feature management platform. Writing that yourself is actually quite challenging, quite challenging to do.
James:
Yeah. As Thor Walpart just said, “Let's Wardley Map it. Decide if you really want to build that.” And, wise words, my friend."
Cody De Arkland:
It's scary. How do you build something that you're that confident in? So. I think we are at time, I think, for our people hosting, I think it's time for us to break into the breakout rooms. Before we do that, though, James, this was an awesome conversation. I really appreciate it, man. You know I love these, and I really appreciate all the work you do in the community to make us all have better jobs, better workplaces, and a community that we understand a little bit better. You're always so approachable with this stuff. And it's just, I know it's universally appreciated.
James:
Well, thank you, Cody. That is extremely charming. And I know that I have now earned my glass of wine for the evening.
Cody De Arkland:
There's no caviar and champagne, right?
James:
No, I'm ready for a glass of red. It's late. Champagne, I think, is earlier in the evening. But, yeah. No, this has been great. Thank you. And I'm going to hang around. I don't know which group I'm going to drop into, but I'll be around for a bit. And if anyone has any questions, as Cody says, I'm @monkchips on Twitter. I try and be as approachable as I can. And RedMonk, we love talking to folks about this stuff. So, feel free to drop us a line.
Cody De Arkland:
I want to see you get back to doing conferences on the walk. There's a couple times where you did conferences, where you had the camera out, and you were walking around doing-
James:
Yeah. Yeah. I've done a couple of those.
James:
I should do more. Well, maybe I need to talk to LaunchDarkly about that. Maybe you've got an event coming up, and you want me walking around, talking about stuff.
Cody De Arkland:
I've got some ideas. I've got some ideas on the progressive delivery thing. We might have to make a round two of that.
James:
That's amazing.
Cody De Arkland:
We'll be in touch.
.webp)
