Establishing DevEx at high-growth companies like AirBnB

Abi: I’d like to start off with hearing a little bit about your experience at Airbnb, and then kind of loop it back to what you’re doing at Notion currently. And as I understand it, you spent eight years in various roles, projects, leading infra at Airbnb. And I know your focus evolved a lot throughout your time there. So I’d love to start there. What did your journey look like as Airbnb kind of went through hyper growth, I’m sure, during the time you were there?

Willie: Yeah, absolutely. I’d love to share the story of the developer experience journey at Airbnb, with a little bit of a focus on potentially common themes of hyper growth companies in that domain. I think oftentimes you’ll have a business that is growing fast and you want to capitalize on that momentum. And you hire more engineers to move faster, to build more features, and even better product. And I think a lot of companies at this stage often lack experience in headcount planning, which is pretty normal. You do your H1 planning, you stack on your projects, and look at your head counts accordingly.

And I think what’s often implied here is that the teams with the most appealing projects are kind rewarded with the head count, under the false assumptions that engineers are productive immediately. When in reality, it takes six to 12 months to onboard. And it creates a lot of pressure to deliver and creates diminishing marginal developer productivity.

And so you’ll quickly find that just doing that actually slows you down over time. This is something we definitely saw at Airbnb in the early days. And Will Larson, who I think was one of the guests on the show recently, has a good blog post titled Productivity in the Age of Hypergrowth where I think the key takeaways are that sometimes when you have more engineers you have more problems. You have your tenure folks spending all their time onboarding new hires, and the system doesn’t survive an order of magnitude growth.

And I’m curious, when was this pain most felt at Airbnb, or what stage of the company?

Yeah, I think there are different stages of this, and we’ll go through a couple of them. I think in the very beginning it’s more just a lack of a recognition that, hey, we need to set aside time and resources to focus on developer productivity. Just because the company is going quickly and things are going well, it doesn’t mean that developer velocity is going to keep up with that. And so what we had at Airbnb was that the engineers will often feel this pain first. And this is probably going back to around 2014, I would say.

And so oftentimes we’ll have engineers lead grassroot efforts of different skills to address the frustrations that they have with developer productivity. And really important in these stages to support these efforts. At Airbnb, we actually had a few engineers self-organize into a developer happiness team that did much of the crucial early work and quality of life improvements to a developer experience. And really put together an early version of what a development environment that helps new engineers get started more easily looks like.

But then even with these grassroot efforts, things like releases often still get to a place where the developer frustration accumulates beyond just paper cuts. And this is a very obvious place where people will feel that they aren’t productive, right? Because it’s common to say, “Hey, we have twice the number of engineers now, but why aren’t we shipping twice as much?” And also every engineer wants to be empowered and feel that they’re not blocked and able to deliver meaningful value every day. And nothing frustrates us like having to wait in line for a release that disrupts their day.

And on top of that, when you have this type of contention on releases, incidents become these cascading effects. This is why companies deploy merch locks during holidays and are strategic about what time they do releases. Because just the way the math works, as you have more changes, the more it is that you’ll maybe have a bug in a release. And you can have a real cascading effect there. And so that was sort of a second stage in which even with the grassroot efforts, we suddenly realized we needed to have a concerted effort around improving releases.

Gotcha. So sort of quality of life improvements, which were very grassroots, bottoms up, was the beginning of developer experience at Airbnb. But then it sounds like reliability and incidents was kind of more of a hammer, a forcing function for, hey, this is something we really need to look into and understand.

That’s right.

Yeah. Well, so I know that during your time at Airbnb you worked in a number of different areas. Could you just share a little bit more, how did your role and your focus and projects of evolve during your time at Airbnb?

For me, I started my career at Airbnb, and I essentially worked on developer experience in some form throughout most of my time there. And I think in the beginning it was more focused on specific domain areas. So I was very fascinated about the observability space. And that ended up I think being an important piece, and we can talk about this more a little bit later, but one of the strategies that Airbnb took was to break its monolith into more services. Which had a lot of good benefits, but also a lot of good challenges we could talk about later.

But one of the things you really need in that is a good observability stack. It’s much, much harder to understand what’s really going on in a system when you need multiple points of instrumentation and being able to chain that together. And so I focused on that for a number of years before shifting focus to releases. And by the time I joined releases, this was kind of past the anecdote I mentioned earlier.

Things were much more stable already, but it was more around getting to the next level of more continuous deployment, getting to more codified releases, and building in automated canary analysis so that all the different services can have that out of the box and migrate to a automated deploy system, have that incentive to do so and so forth. And so I focused on that for a while before gradually expanding my focus more and more holistically. And in my final years there was really focused on the overall development environment, and making sure that that was something that enabled engineers to be productive in a service oriented world.

Well, thanks for sharing that, and we’ll definitely come back more to the monolith topic, as well as talking about some of those specific tools you worked on. Something you had mentioned to me before was you sort of remarked that you’d kind of worked on productivity and then you worked on experience. And of course those are two terms out there, right? Developer productivity and experience. And you mentioned to me that you prefer experience. You said that’s what it’s all about. Could you kind of expand on that thought?

So I think everyone wants to be productive, right? And so I think that is a very natural word. But I do think that sometimes that term, I mean that term’s very subjective, and I think it can elicit feelings of, oh, like I am just a resource that is here to be productive for this company. And one of the themes that we really focused on in more recent years at Airbnb was this customer first mindset. Where the customer is all the engineers at Airbnb.

And one of the things that we believed is that, while developer productivity is difficult to quantify, individual engineers or engineers as a whole generally have a pretty good sense of how things are. If you just ask around, “Hey, how are you feeling about things?” Or the surveys, or just surveys in general, you get kind of like a sense of what is the state of things just depending on how things bubbled up.

And so I really prefer the term developer experience because, if you have a really good experience, you’re really empowered and motivated to build great things. Whereas productivity is this really subjective, obviously experience is subjective as well, but it’s coming from the perspective of the engineers. And that’s something we really like and we think that sends the right messaging around how we’re here to really empower you to be successful.

I love that, and of course definitely agree with that. I want to double click on that sort of customer first. I’ve heard you mention that a few times, this importance of listing the customers. At Airbnb scale, and with the number of I’m sure different pockets of the company and different tools, practically speaking, and you mentioned surveys, I’d love to know more about that too, but how did you be customer first at Airbnb internally?

Yeah, that’s a good question. So before I answer that, maybe let me set a little bit of context in terms of where that focus came from. So I think where we left off the story was probably around maybe 2016, '17, earlier. And we fast forward a couple of years. By the beginning of 2020, Airbnb had a fairly service oriented architecture, a very service oriented architecture, approaching around 500 different services.

And it became really apparent that it’s really hard to be productive because it was difficult to develop and test effectively across so many dependencies. And in 2020 we had a new director of engineering join for developer platform. and we were in the midst of the struggle, and I’m sure she had many conversations with folks and took a look at the problem. And she really introduced this theme of developer first. It was kind of a banner that was repeated over and over again in different all-hands at different levels. And what it really is about is a mindset. The mindset that our core purpose here is to deliver a customer value.

So you kind of take Amazon’s customer obsession, but your customer is the engineering team. And you build a culture around celebrating your customers and celebrating the value that you can provide for them. And so this does a few things. The repeated messaging signals to the other org leaders that, hey, we’re taking this really seriously. There’s some element of repairing or building trust who may have lost faith in infra’s ability to improve developer productivity. Or just thought that that’s something that they were on their own.

And we have a really senior leader like that come in and make this such a theme, that’s a really powerful, powerful thing. People really look to that leadership. And so it jump starts partnerships that are critical for piloting the changes that you need to improve developer experience at that skill. Because once you’re beyond a certain skill, no change comes easily. Almost every single change comes with some level of migration of some sort. And so you really need that buy-in, right? And so having that set of pilot customers closes that loop, builds the fast feedback loop, helps you build momentum, and gives you evangelists on different product teams. And we often talk about product-led growth. And you really want that internally within a company as well. You want to build a great product for your customers, and let word of mouth sell it for you. As opposed to mandate, hey, this is what we’re using now.

And the second thing that this customer first mindset introduces, I think is a level of humility. Don’t assume that you’ve built the right solutions, or even assume how developers actually work at your company. It’s kind of parallel to when you’re running a startup in how you look for product market fit, right? You want to kind of fail fast, ship early, and actually see how people are using that product.

I think oftentimes when you’re building out say a developer flow, it’s easy to imagine the ideal flow and how people will use it. But it almost never actually happens that way. You have to constantly look at how people are actually using it, and trust that the users actually are doing things for a reason, and they understand that this is the path of the least resistance in how to work with that.

And I think the third thing that having a customer first mindset really does is it really attracts talent, really attracts folks to this problem. You’re signaling that, hey, this is the most important problem that we need to solve. And as you see more and more senior IC leaders move to this space, more and more folks are excited to work on it.

So that’s the mindset. But in terms of concretely what you actually do, a lot of that is around, I mentioned earlier putting this theme very front and center in all hands at all layers of the company. So every single all hand for the developer platform where this was a really big theme, we brought customers’ stories, we celebrated their success, we really shared our progress. And this is also a really big theme across engineering as a whole. It was around saying, hey, this is really important. It’s a big point of topic at almost every CTO Q&A, either through the questions that people asked and how we responded to them, or through presentations on where we’re at and so forth.

And the listening sessions we did at all levels. Our director would go and talk to her partners and also jump in on different teams. Our teams were regularly sitting in on product team meetings and sharing our progress and so forth. And all of this is to build a culture in which developer experience is really valued.

Well, what a powerful story. And there’s so much there. I have a few follow up questions to some of the things. So first of all, I loved your mention of product led growth. I’d never thought about that in the context of DevX teams, but that’s so true. I mean, I don’t know how else you really can do it. I mean I’m sure there are instances where there’s sort of the top… I mean if you’re breaking up a monolith, that’s not really grassroots per se. But in terms of new tools for observability or orchestration or monitoring, totally makes sense that those types of initiatives need to be really product led. Let developers vote with their feet.

I’m curious, you mentioned this sounds like an amazing leader who came in and instilled this developer first banner. I’m curious, was it up to your group, the infra group, to really propagate this? And you kind of touched on it by mentioning it was captured in an all hands, but I’m curious, was this developer first a message or pillar being championed at the C-level as well, or was it really just your group kind of shouting it into the rest of the company?

Yeah. No, that’s a good question. Oh, it was absolutely championed at the C-level. In fact, this director, her name is Kamini, by the way. You can easily look her up on LinkedIn. She joined as the director of developer platform, focusing on developer experience. And one of the things that I was really excited about that happened after I left was that she actually was promoted to be one of Airbnb’s first VP of engineering overseeing all of infrastructure. Now I don’t know the details of that story, but I think it’s clear that developer experience is really important for Airbnb at this stage. And I know that Airbnb’s CTO have a lot of trust in Kamini as a leader.

And so this message of customer first, and then the work that we were actually doing as a result of that is one of the most important and most visible initiatives at Airbnb. We have this collection of initiatives called Tech Stack 2.0. And this piece, internally it’s called AirDev, is really focused on really upleveling and reimagining what that developer experience looked like, what that developer environment looks like.

Yeah, that’s so inspiring. I meet so many companies that don’t yet have that. I’m sure you’ve heard some of our past podcast episodes with folks who are really trying to build a DevX function or pillar from the bottoms up without that C-level support. So sounds like you guys were able to establish that support, and then ride the wind in your sail so to speak and have success.

Absolutely. But I think part of the reason why that came together in recent years actually happened because it was so painful. There’s an interest rate to tech debts that you take on. And I think for many years our investments in it was, I mean under what the interest rate was. And I think it grew to a level where it became very visible that it was difficult to be productive. And all systems have kind of an ability to self-correct. Sometimes it takes a little bit longer. And so there was an element of the debt building big enough and coming up enough, and sort of exit surveys and just a general sentiment of this became a big thing. But it is really great that leaders at Airbnb recognized that and shifts were made to make this such a big focus.

Yeah, I want to stay on that topic. And I’ve mentioned this to you before, I used to work with some folks at Airbnb. And at one point I had heard from them that developer experience was a big concern for the company, and that it was specifically top of mind for the CTO because it was identified as a top source of developers leaving the company. So I’m curious, while you were working in infra, were you also sort hearing about the attrition problem related to developer experience? Was it just rumors?

Yeah, absolutely. I mean this is well known throughout the company as a point of frustration. One thing I would say though is Airbnb actually has great retention. Almost too good, honestly, to some extent. I was there for eight years and some of my best friends from the very beginning are still there, which is I think incredible in this industry. But I think for the folks who did leave, this was one of the commonly cited reasons for departure. And I do think that people vote with their feet, and that did lead to changes and the importance of investing in this.

And I think one of the challenges we had for many years was attracting very senior folks who want to work on this. I think a lot of times on the infrastructure side, you have very experienced engineers who want to work on really hard technical problems that were more purely technical. Which I think speaks to the challenge that people want to solve, and also not necessarily wanting to have to navigate organizational challenges as well. And also challenges like developer experience doesn’t necessarily have a right answer. So I think that can be really challenging to navigate.

And so it took alignment at very senior levels to say, no, no, no, this is a really big focus. We’re going to advocate to bring some of our most experienced folks to this problem. Tell them, “Hey look, this is the thing that we really need to solve.” And then from there you kind of really build the momentum around it. And when we did that, that was actually a huge moment because we had teams that had been trying to work on improving the developer environment, specifically at Airbnb for quite some time. And it was a big moment to have folks that they really looked up to with a lot of experience who were able to really help advocate for the work that was already being done.

Yeah, that’s again inspiring to hear. And this is I’m just personally curious, as someone who was there during this time, I mean was it a lot of just kind of grumbling across the company and some attrition here, attrition here, then manager here mentions it to director here, then CTO here? If you’re at another company that’s sort of in this earlier phases of the interest on that tech debt occurring, what’s the right way for the scale to tip?

Yeah. No, that’s a great question. And I think this maybe goes to some of the lessons that I took away from my time there. And one of the things is to start early on developer experience. And that’s one of the lessons that I took to Notion, and we can talk about that in a little bit. But it’s important to start early because, in the earlier phases, the amount of the investment that you need to make bigger changes is much lower. And so you don’t start incurring both organizational and technical debt. Because once you lose trust in the ability to work on this, either with other engineering teams, or even within the infrastructure team, or hey, do our leaders care about this, once you have that, you also have an organizational debt to build up on top of that. And so I think it’s really important to get started early, and say that, hey, this is something we want to build a culture around.

And one of the ways I think about this has to do with your confidence in your business, right? Because I do think it is probably possible to get started too early. If you don’t quite have product market fit yet, that’s maybe not the right focus, right? But if your company is in a very fortunate position of having a very strong product market fit, and you have visibility into that growth far out, then really, it’s a sign of confidence to say, “Okay, well we should be planning for that future and investing in this today.” I don’t know what the counterfactual could have been, but I think for a long time I felt like we were constantly trying to pay off that initial debt of the early days where we were too reliant on grassroot efforts instead of really putting a focus on this. And I think really listening and having that customer first mindset I think is always really important. And so mentioned quite a bit about that already.

But I think the third bit is around being intentional about your architecture. That’s really difficult to get right. Airbnb embarked on this journey of moving to a service oriented architecture because of challenges in the developer experience, where it was difficult for everyone to be working on one monolith. The challenge is that with more services you come with different types of problems. And for example, in storage. More teams need to understand how to capacity plan, or otherwise you have a centralized storage team that’s overwhelmed. You have to invest a lot in observability. You have to invest a lot in tooling and culture to create a DevOps mindset so that teams can own their services effectively. And if a SOA is not well designed, you can easily end up with a distributor monolith that represents just a distributed version of a monolith in which it’s harder to test and you still have cascading failures and so forth.

But I guess going back to your question on how do companies start thinking about this and getting ahead of it, I think it will probably be different at every company. But I think that narrative of, hey, how much confidence do you have in your business? Do you want to invest ahead of time for that, I think is one that I’m a big fan of. And then the other thing is, it’s actually something that I really validated before coming to Notion, to know, hey, how does the most senior level leadership think about this problem? So that I know that we had the buy in before coming in to know this would be a priority for the company. And I think very fortunately in the case of Notion, we are a productivity tools company. And so the importance of productivity and building abstractions and investing in the long term is really built into the company’s DNA. And so we’re in a very fortunate position there.

Yeah, I love that mean. It seems like every developer should be asking that question when they’re interviewing at a company, right? How invested is leadership in making sure my job is relatively easy to do.

Yeah, absolutely.

I love how you describe the impact on developer experience of monolith versus services. Are you much more pro-monolith than you were in the early days of breaking up the monolith at Airbnb?

That’s a good question. I don’t think there’s one right answer. Airbnb had to break up its monolith. I do wish we were more opinionated about how to structure the monolith. I think part of what had happened was we built really great tooling that made it easy for any team to spin up a new service. But without very strong guidance or at least alignment across engineering on when do you build a new service and what is the relationship between services?

And so what happened was there was just a huge proliferation of services. You build a service. At least this is how the myth went. In practice did this actually happen, I don’t know. But the myth was if you wanted to get promoted, you build a new service and roll it out. And all of a sudden you have N+1 services, and that just kind of kept cascading out. I don’t know if that myth was actually ever true, but the fact that people thought that was really not a great incentive.

And so one of the things that Airbnb is going through right now is this multi-year project to reorganize its service oriented architecture into what we call a block architecture, where you have different service blocks that together service certain set of use cases. You’re able to prove that as long as you’re able to test within that block, you don’t have to test outside of it. And so you can kind of reason about just subsets of it.

I think monoliths have their own challenges as well. There’s a different type of investment you need to make to make sure that scales. You need to have very strong and clear ownership boundaries within the monolith. You have to be able to make these builds very quickly and so forth. And so I think there are no silver bullets to these challenges. Companies have to make decisions at juncture points. And it does really pay though to have experienced folks. We have seen parts of this before, who are able to put the right guardrails in place as a company continues to scale.

Yeah. Well I really love that example of the sort of guardrails or principles you guys put around not having too many services because the ever proliferation of services seems to be a pretty common problem when organizations transition. I have one more question about your time at Airbnb, then I want to move on to Notion. But we’ve spoken to a lot of leaders of infra and DevX groups, but not many who worked at the scale of Airbnb. So one question I’ve had for you is how unified or disparate were the tools used by developers at Airbnb? And then similarly, how was your platform or DevX group broken up or aligned or organized around those different areas, if there were different areas?

Yeah, good question. I would say that the build, test, deploy style tooling themselves were relatively standardized. And the reason for that is because it generally didn’t make sense to go off, or maybe it wasn’t even possible to go off and roll your own deployment tooling, roll your own kind of system that ran continuous integration and so forth. And so that was relatively pretty well standardized. Of course, your mobile teams will need a different build, test, deploy pipeline and so forth. But within these different, what we call platforms, they were pretty well standardized.

Differences laid more in approaches to testing and some specific testing frameworks that teams would use. Payments for example has a much higher requirement around the correctness of things. And so there was always a lot of debate on how much to rely on end-to-end integration tests, on the one hand, and guaranteed correctness. But the larger your test suites are, the less reliable they are, the more it is that they’re brittle and flaky, right? And so there’s some differences there.

The big difference lay in how different teams did development itself when it came to the development environment. Teams have vastly different development flows. Some teams had essentially staging instances number one through 10, and they were using Google calendars to reserve them in order to do the testing. And this was a reflection that what was supposed to be the standardized development environment was not working for them. Either because dependencies were not present, or the test data in those environments just were not representative, or they’re unable to debug edge cases that were very common without being in a more production-like environment. And so that was pretty scattered.

And I alluded to this big project called AirDev earlier that really was about trying to bring all of this together. And there were many, many hours of listening sessions across different teams to even understand how people were actually using the disparate offerings that existed. And in terms of how the developer platform org organized these scopes, at least at the time when I was there, things may have changed over the past year, but we had a set of teams focused on the platform agnostic layer. And this is actually the area I was focused on. Your build, test, deploy tooling that were shared regardless of what platform you’re on.

And then you had a platform specific layer. When I say platform, I mean things like front end, backend services needed and so forth. And so that side of the team focuses on the different frameworks needed for different platforms, as well the different build systems needed for different platforms. And the developer environment was kind of this difficult crosscutting piece that we drove in the form of an initiative. And over time we pulled more and more teams into this initiative so that really was the central focus. Because we considered the most important piece to up level the developer experience at Airbnb.

‍That’s that. That’s awesome, and that makes sense. It’s interesting, like you said, it was sort of a longer term initiative, pulled more and more teams into it as it gained momentum. I’d love to pivot though and talk about you joined Notion fairly recently. I know when we first spoke you said they were around 130 engineers, expecting to grow a lot. And I think when you joined they were at that point where they were of recognizing that each incremental engineer was becoming less incrementally productive, right? Tell me more about the impetus for them bringing you on and making this investment and focusing in this area.

Yeah, yeah, makes sense. Before I dive into that, I’d love to maybe just make sure your listeners have some familiarity with Notion. So at Notion our mission is to make it possible for every business and person to tailor software to their problems so that the world can be better at solving its problems. Today, software is the basis for most of the tools that we use in our personal and professional lives, but most people don’t have the ability to build their own software tools. So we’re really passionate about providing a kit of legos that give anyone the power to design the tools that they need, whether they are a startup founder, a content creator, a small business owner, or just students taking notes in a class or just planning vacation. And in the last couple years we’ve grown quite a bit in popularity among startups, students, and creators, and generally anyone looking for an all in one collaboration or life organization tool.

And so I was really passionate about this mission, and so that brought me over to Notion. And when I started talking to them, they were really looking more for just a manager of the infrastructure space. Infrastructure at the time was just one team, and they were really interested in the experience that I had at Airbnb to be able to have a sense of, oh, what will happen over the next couple of years and what to anticipate?

And I would not say that the focus on developer experience was one that had already existed, at least at this level. It was seen as potentially an important investment, but all the ingredients were there. And so it was one of the things that I really pushed for once joining, making sure there was a team dedicated to this, making sure that there was someone advocating for it, and creating sessions to bring us closer to our customers.

‍And in terms of Notion’s sort of timing, you mentioned earlier start early, is Notion early, are they late, are they right on time? What’s your observation?

Yeah, that’s a good question. It’s never possible to tell in the moment. It’s something that I’m excited to look back on, and learn from the things that hopefully we got right and the new mistakes that we’ll make along the way. And I think that’s part of the fun of these journeys. When I look back at our time at Airbnb, there were many challenges along the way. But there’s always an appreciation for, at different stages, folks made the best possible decisions that they could have with the resources that they had at that time. It’s all just a part of a company building, organization building, infrastructure building. But I do think we’re starting, at least compared to what I started, I do think we’re starting much earlier. So that’s something I’m really, really excited about.

You mentioned to me, developer experience is sort of a new function, a new practice, a new thing at Notion. And you mentioned to me you’re really working on building that culture, or the passion for that kind of work within Notion. So what are you doing to do that, achieve that?

Yeah. No, great question. So the first thing is just around, I mentioned earlier, kind of seeding a team in this area. One of my observations is that there are problems everywhere to solve, and everything is always harder than it first meets the eye. And so if you have someone focusing on an area, they will find problems in that area. And so you have to be somewhat strategic about where you place your seeds. Because once you’ve seeded, that will tend to grow maybe faster in areas that you haven’t seeded. And so part of that was just making sure that that was a set of seeds that we planted in the developer experience area.

And then doing everything you can to start encouraging that culture of customer first and of saying, hey, developer experience is really important. It’s something that we value here. We want a culture where people are passionate about enabling other developers because it’s an awesome feeling, and because that is something that’s really important to the company.

And then in terms of what that actually meant in practice, in the very beginning, a lot of it is actually around just evangelizing what already exists. And I remember listening to one of the podcasts that you hosted, I think it was the Ibotta team, and they talked about how the first step was just sharing, hey, we already have these observability tools, or these things that people were underutilizing. And so we too set up a number of evangelization sessions, observability 101, 102, and so forth that just generated interest in what existed already. And that really made a difference for the team. Because suddenly you’re like, oh, actually people actually are really passionate about this/ they care about this. What we do is important.

So you improve the documentation of the things that already exist so that people are able to leverage them more. And then you make space for some of the obvious low hanging fruits that already exist. You start doing more kinds of listening sessions and building the discipline to generate some quick wins out of those listening sessions. One of the things we’re doing right now is, on a very regular basis, every six weeks or so, we have a sprint that’s focused on quick wins. And you can work on anything that you think people are really excited about that, really vying for. And this enables us to be able to on the one hand demonstrate that momentum and keep the team excited about the things that we’re doing, but also make space for the medium and longer term projects in the space that required time.

Because oftentimes it’s difficult to weigh, oh, this is a really value adding thing that just kind of came up today. Should I work on that, or the improvements that we agreed to focus on for the next couple of weeks? And so this structure really enables us to have the best of both worlds there. And then publish our wins in newsletters. And one of the things that we’re going to start doing more is actually sharing this in more forms at all hands of different layers so that people know what is being done and that this is important to us, and so they can give us feedback.

Well I love that. Sounds like your developer experienced journey is off to a great start there. I’m curious, I mean you’ve seen a company like Airbnb at such a later stage and scale than Notion is today. So it sounds like you’re focusing a lot on being customer first and quick wins, while also identifying these longer term things. So I’m curious, I’m just really interested in what you’re seeing? At Notion, are you seeing things where you’re like, this is something we’re going to have to do something about in 12 months? I’m curious, what are those types of things you might be seeing that you know are around the corner, but not maybe things to focus on quite yet?

Yeah, that’s a good question. So we already talked about the importance of just seeding a focus and building a culture around developer experience. So that’s one thing. One of the things that often came up in conversations with other leaders who’ve gone through this space, I talked to a bunch of folks before joining Notion. And the other thing that folks often talk about starting early is around building a program around your hosting costs, infrastructure hosting costs. Because that’s also a cultural element. Because oftentimes companies in hyper growth, it’s the top line that matters and not the bottom line, until suddenly it’s both, or it’s the bottom line, right?

And with these things it takes time to build that culture, to build that orchestration muscle, to build that program management muscle and attribution and so forth. And so that’s one thing that folks often talked about kind  of getting started earlier, and that’s something not as much in the developer experience kind of area, but something that we’re thinking a lot about.

In terms of things that we have to do looking to the future, there’s so many possible answers to that. I think one of the things we’re focused on now is enabling the teams here to adopt a more DevOps mindset. The mindset of, hey, owning the things they work on. And a lot of that is around providing the observability tooling to do so, establishing best practices around how we do on call, postmortems, and so forth. Setting examples there, and so forth. So I think that’s one big focus.

Another thing I think that we’re really focused on is how do we think about our architecture? And I think for developer experience, there’s kind of this hierarchy of needs, where the clarity of your technical and product direction is actually even more important than the quality of your tools and services, which is actually even more important than the health of your code base. So this is kind of like this triangle. And maybe folks will debate whether that’s kind of the right ordering. But knowing exactly where you’re going is the hardest strategic piece to give, but has the most implications. Because depending on how you structure your code base, everything else follows. And so that’s something that we are starting to think a lot about, but we’re trying to be really practical.

One of the things that really enable Notion to move fast today is the fact that the code base is relatively monolithic. It’s a very client focused code base, but it doesn’t have a lot of services. You’re able to build new features very, very quickly. Now, how do you evolve that that developers can move faster? We’re starting to see that different teams are needing the same shared abstractions, but they’re having to build their own.

So as an example, Notion is really based on this idea of blocks. And there’s actually this blog post that one of our colleagues Jake wrote called the Data Model Behind Notion’s Flexibility. And so we have this tree-like structure where it’s often times when you build different features, you really want to count the number of blocks with a certain property inside of a tree.

And so it’d be really helpful to have a recursive document index or recursive index of block properties that are shared across all these different use cases. And so we’re now thinking a lot about what are these different layers that we want to build out to enable that? And then eventually over time thinking about how we want to architect Notion so that new engineers only have to think about a subset of the code base as opposed to their entirety. But approaching this in a more incremental way, first focusing on the layers that we know we already need to have today.

Willie, it’s been so awesome talking to you, hearing about Airbnb and the work you’re doing now at Notion. Thanks so much for your time today.

Yeah, absolutely. Abi, thank you so much for inviting me onto the show. I’ve really enjoyed this conversation. And thank you so much for all that you are doing to promote developer experience. It’s such an important part of our industry. So love what you’re doing, and thank you so much for the time.

‍