Transcript
Potvin: This is my kid’s favorite family photo, and it is not mine. I am not a rollercoaster person, but I’m using this just as a representation for a time about two years ago when I was really not having fun, and it felt like quite an emotional rollercoaster. I was doing what I thought was my dream job, what I always wanted. I was VP of engineering at GitHub. I was managing a 500-person team, working on amazing tooling for developers. That was super inspiring and made me really happy, but I was working in a work environment that did not make me happy. Started to feel like my job was extremely political and extremely bureaucratic, and that was not great. I was not having fun. Like so many before me, that was a moment when I started seriously considering leaving tech for good, walking away entirely.
Then I saw something different, and this was exciting. These are my friends, the amazing EngFlow team. EngFlow is a startup doing remote build and test execution. They’re a lot bigger today, this is a recent photo, than they were two years ago. Two years ago, they came to Denver, where I live. They did a company meetup, and I offered for them to do a hackathon in my basement. This small team, it was around eight people, came and did a hackathon in my basement. Remember, this is at a time when I was not having fun, and I saw their energy, and I saw their excitement, and I saw them kicking off into this journey of startup that was just so inspiring. When seeing that, that was the kick that I needed to say, “One life to live. I’m not having a good time. This is what I want to try”. They really kicked me off into quitting my job and jumping full-time into the world of startups.
As you probably realize, this talk is about developer productivity for startups. The origin story for this talk is really what I just told you, how the startup world has given me new energy, new enthusiasm, how it prevented me from walking away from tech entirely, which is something I really thought I was at the point of doing. It’s been a new, exciting journey. I’m really excited to talk to you all about how productivity, from my lens, has been very different at startups than it has been in big tech. The audience for this talk is really anyone who is working at a startup, considering working at a startup, considering founding a startup, but also just anyone who’s interested in developer productivity in general.
Background
I want to give you a little bit more of my background just to frame where I’m coming from. A zillion years ago, I worked in a startup when I was in college, that’s fine. Then I moved to video games. I worked at Ubisoft for six years. I eventually became a tech lead there, which I was really happy about, but that was a grind. I went into management consulting for a little bit, technical management consulting, learned a ton about strategy.
Then in 2008, I had the good fortune to start working at Google. I worked at Google for over 11 years. I started as an IC, but quickly became a manager, and then became a manager of managers. In that time, in my portfolio of teams, I had the great honor and pleasure of working with Google’s famous engineering productivity research team. Emerson Murphy-Hill is an amazing researcher from that team for many years, who I got the honor of working closely with. That team was just doing really cutting-edge research into productivity, looking both at system metrics along with qualitative research to really triangulate and understand the developer experience and make meaningful improvement.
While I was still at Google, DORA, the DevOps Research and Assessment company was acquired by Google, and the phenomenal Nicole Forsgren came to work for me, which she taught me so much more about developer productivity as well. This has been really an area that I’ve been very focused on. In 2019, I left Google to join GitHub, and become a VP of engineering at GitHub. I started with a 100-person team, which grew over time to a 500-person team, very motivating. Then I stopped having fun. That’s around the time when the EngFlow folks came and did the hackathon in my basement. I started doing startup advising, got more interested in the startup world, and finally had the courage to quit my big tech job and join an amazing, fast-growing startup called Sanity, where I run the engineering team.
My claim with this talk is that developer productivity for startups is substantially different than it is in big tech. I do need to start by saying that many things continue to be true. These well-researched, research-backed, science-based frameworks like DORA, SPACE, and DevEx are still excellent and still apply in every context. If you don’t know what any of these are, you can look them up. There’s a lot of research about them. They are flexible frameworks that can make sense for any size organization. I also can’t help recommending this phenomenal book, “Accelerate”, from Nicole Forsgren, Jez Humble, and Gene Kim, the originators of the DORA metric. Many of you likely have read this already.
If you haven’t, it’s a really nice primer to understanding the science and research behind productivity and how drivers of your work can lead to improved outcomes. This graph is probably pretty intuitive. The data comes from a company called DX that does research into developer productivity, building on the DORA framework, and so on. I think it’s probably no surprise to anyone that as your company gets bigger, your eng efficiency does tend to go down. What I like, though, in looking at this graph is you can see the huge variance at the start of the graph in terms of when you’re a really small company size, there’s a lot of variance in how good your eng efficiency can be. In this talk, I want to talk about how do we get to be on the winning side of this trend. I think there’s a really big opportunity to be extremely efficient when you’re in a startup.
Outline
I learned a lot about developer productivity throughout my career, throughout my years in big tech, and there’s many things that I think are still very valid lessons that I learned there today. In the over two years that I’ve now spent collaborating very closely with startups, I do have a different perspective. Startups differ from big tech in ways that you really have different tradeoffs to make. I’m going to go through five things. I’m going to talk about urgency. I’m going to talk about structuring teams and organizations. I’m going to talk about metrics, planning, and finally, experimentation. For each of these sections, I’ll give you my point of view on what I’ve learned. Then I’ll also try to give you a real example from my work that puts them into perspective.
Urgency
Let’s start by talking about urgency. This is going to be a common thread throughout my talk. Everything you do in a startup is geared towards urgency. I want to explain this a little bit more. Startups are unproven businesses. They need to fight to survive to become proven businesses. Momentum really matters. I took this data from CapIQ, and this shows, for some companies that you should recognize, the path from $1 million to $100 million ARR. ARR is annualized recurring revenue, and it’s a pretty good measure of startup success. In the startup journey, if you lose momentum on that journey, you’re going to struggle to survive because you’re going to struggle to get funding. Sanity could be profitable today if we didn’t do any marketing, but that’s not the position you’re in in a startup. You’re unknown. You need to get the word out. You need to grow.
If ever you falter on this curve, you’re going to stop being able to get funding. Of course, it is always possible, some startups pursue the route of profitability. That is a very slow road when you’re unknown and you’re starting from nothing. In this market, with the number of startups that are out there, the amount of competition, the route to profitability and going slowly means you’re very likely to be overcome by your competition. I hope this framing helps you understand how important urgency is.
If you falter on this curve, you may still be able to get VC funding, but it’s going to be at worse rates, and your path forward is going to get harder. Urgency is absolutely paramount. That means that the tradeoff decisions that you make in startups are very different from established companies that have footholds in the market. You need to lean hard into shipping product value, lean hard into acquiring new customers, and be ready to react to the market, to technology shifts, even sometimes to specific customers. For fun, I added one more data point on this slide, which is OpenAI. They shot up to over $100 million ARR, of course, but they’re burning so much money that that is also not a path that is realistic for most of us.
How do you think about urgency? My belief is that in a startup, you need to build a culture that leans into urgency. I’m going to talk about four cultural aspects to build urgency within your startup. The first is effective decision-making. I have seen poor decision-making being the number one factor that hurts productivity. You always want to have an open, clear road in front of your developers where they know where to go, they know what they’re working on. As soon as people start spinning, as soon as a decision is unclear, that’s a disaster. You need to set up your organization to escalate quickly, to find where people are spinning, to have the right decisions being made. Next is healthy risk-taking. There’s a different risk threshold for startups, as I’ve started saying, and so you need to build that appropriately within your organization. I like to lean a lot on the concept of two-way and one-way doors that was popularized by Jeff Bezos. A two-way door is a decision that you can make and come back from quite easily.
An example would be, are you going to be building a prototype? Yes, you can do that, and there’s no big risk to that. A one-way door, something like making a breaking API change is a decision that once you’ve made, you’re stuck with it. Think about that different framework of one-way and two-way doors, and really lean into moving quickly and accepting risk. You need to be able to move forward without always having perfect clarity.
In the startup context, as much as I’ve been a data person for a lot of my life, I do like leaning on data, but I don’t need to overdo it. Intuition sometimes is good enough. Ambition and accountability. We really need to emphasize that everyone in a startup is an owner, and we do what needs to be done. You need to have a see something, say something, do something culture, where everyone feels empowered to stand up, to take action, and get things done. I never, ever want to see a situation where I have a postmortem, and someone raises their hand and said, yes, I saw that coming. In a startup, that’s completely unacceptable. Everyone needs to step up. Finally, focus and simplicity. You need to avoid doing too many things at once, context switching. Don’t go ahead and build too much until you’ve validated your hypothesis with your customer base. Always look for the simplest solution that will achieve the goal, be that in terms of implementation or in terms of user experience.
Two of these cultural items are very similar in big tech and in the startup world, and two are quite different. Any thoughts on which ones are different? Decision-making and focus and simplicity are quite similar between startups and big tech, because where I’ve worked at Google and at GitHub, I had to put in place processes to make sure that the right decisions were happening at the right level. The ones that I would call out as different are ambition and accountability and healthy risk-taking. Healthy risk-taking, in particular, is extremely different because the threshold is just so different. I’m going to give you an example from my life. Last year, we did a major update to Sanity UI. This was a change that affected thousands of files, a very visual update, affected libraries that were used throughout our plugin ecosystem.
Basically, what this means is Sanity has a lot of open-source developers who are working in a plugin ecosystem, and we couldn’t perfectly know what the impact of rolling out this change would be. People have done all sorts of crazy customizations to their Sanity Studio. The Sanity Studio is a React app that is basically on the client side. This change was ready to launch two days before the Christmas holiday. All my big tech instincts told me, you wait. Wait until after the winter holiday and release then. The right answer in the startup context with urgency was actually something quite different. We weren’t reckless. You never want to be reckless. We felt the change was ready. We made a fallback version such that anyone who ran into trouble would have a fallback. We also knew, at the time, Sanity Studio required an action on the side of customers to upgrade.
We knew that our largest enterprise customers were probably not going to be upgrading their studio two days before the winter holiday. We also knew that winter holiday is a typical time where a lot of developers have some free time, kick the tires on new products. We wanted those developers to have the better, more modern experience rather than missing out on that when we were so close to having it ready. We went for it. It wasn’t perfect. Some people did need to use the fallback. We made this decision intentionally.
Then what I did with my team was I did a retro with the team that was responsible, but then also shared that as a case study with all of engineering to say, “This was stressful for some people. We weren’t sure. However, we did it. Here’s what we saw”. Overall, the team agreed. Yes, we got this into the hands of people sooner. That was the right call. Using this as a case study within my engineering organization was a mechanism for getting everyone aligned with this culture and understanding the type of risk that we want to take. Again, not reckless, but definitely leaning forward.
I added this slide because suddenly I realized, my talk is so much about urgency that I didn’t want anyone to take away from this that you should be working crazy hours, that you should be burning people out, that you should have no work-life balance. I really want to emphasize that is clearly not the way, and the research backs that up. We do not want people working crazy hours. That will definitely affect your productivity negatively. You’ll lose people. You’re lowering morale. I hope everyone understands that this is not what I’m advocating for. We do push sometimes. Sometimes we’ll push a little bit extra to get something out the door, but we will also emphasize that vacation and healthy work-life balance has to be the norm. Everything I’m talking about is about being smart and intentional about how we work.
Teams and Orgs
Next, I’m going to talk about teams and orgs. Not surprisingly, the way I think about teams and orgs is geared towards urgency and delivering product value quickly. There’s a spectrum on how you set up teams and orgs, and so not every big tech company does it the same way and not every startup does it the same way, but I’ll talk about some generalizations. The first one I’ll talk about is team size. When I worked at Google and at GitHub, which was increasingly influenced by Microsoft, there was this concept of span of control that always came up. Span of control means, on average, how many reports per manager.
Often, in big tech, if that number was less than seven, you were asked to take some action to remedy that. I don’t care at all about that in the startup world. I’ll just build teams that make sense. I have some teams that are only two people and they’re extremely effective and they’re working really quickly. I’m caring a lot less about single points of failure when I’m building fast to get something out the door. I also have teams that are 11 people because they’re doing something more substantial and that makes sense. I’m just going to pick the team size based on the need and not worry about any metrics or numbers around that.
Next is roles and responsibilities. Typically, what I’ve seen in big tech is you have very clear roles for different people, and typically there’s job ladders that even go along with that. Are you a frontend engineer? Are you a backend engineer? Are you a data engineer? Are you an eng-prod developer? Are you a designer? These are very fixed roles with clear expectations. However, in a startup, we just want to be flexible. It’s all about getting done what needs to be done. Someone can step up and be a feature lead for something one day and go back to being an IC the next day. I have phenomenal developers on my team who have strong design backgrounds who’ve put on the UI design hat for a while and just got that done, and that’s fine. There’s no need to reorg a team to support that. There’s no need to change a manager to support that. You just go for it.
Ownership, this one’s really interesting because I’ve talked to a lot of different startups about this. The ideal in big tech, which I know is never perfect, is that you have stricter system ownership. You have a service catalog. Everyone understands where the responsibility lies for every service in there, and so on. Again, it’s never perfect, but that’s the ideal that you’re seeking. Whereas in a startup, you have a lot of flexibility, things are changing a lot. Spending effort on maintaining clear system ownership is often not the right tradeoff to make. I’ve talked to engineering leaders at startups who are like, I want to do this big initiative where we map out everything and we get clear ownership. It’s like, it’s just going to change later. You really need to have this accountability and ownership and ambition culture where people are just going to step up and do what needs to be done.
Sure, some teams might clearly own some services, but as things move around, we just need to have that accountability of everyone being ready to step up. It’s probably not a good investment of effort to spend a lot of time on the bureaucracy of sorting this all out. Managers in big tech tend to be a lot more people-focused. A lot more of their job is on career development. It’s been very common for me in many years at big tech to give someone a task that I’m not sure that they’re going to be able to complete as a challenge, as a stretch, to let them try and see what they can do. Managers in startups are completely focused on execution and getting done what needs to be done. You’re never going to give someone a task that you’re not sure they’re going to complete. You’re going to give it to the person who can hit the ground running. That affects hiring in a startup. We’re hiring typically a lot more senior for people who can really hit the ground running. There’s a lot less a focus on performance management and career development.
One of my favorite things about startups is this idea of, in big tech, I see so much local optimization. Local optimization for what my career path is. Local optimization for what my team is doing, perhaps at the expense of other teams. Maybe I’m fighting for headcount. I don’t want that team to get headcount because then my team won’t get headcount. Whereas the best thing about startups, my absolute favorite thing, is that everyone is in the same boat, rowing in the same direction on this journey together, and it’s so exciting to be globally optimizing. Everyone in the startup is focused on the overall company success versus these local optimization decisions. I do want to call out, that doesn’t mean that you’re not having huge career development within a startup. I feel like the opportunity to grow because you can jump into so many different things, you can wear different hats, you can expand what you’re learning, is still there. It’s just that the management and development focus is quite different. Just for fun, I’ll give you a quick look at my team.
There are some things I want to call out in terms of how I’ve structured this, which I think is effective. I’m not sure if you can tell by this, but it’s a flat organization. All the principal engineers and eng managers report directly to me. I have no interest in adding a middle management layer. I’m going to keep it as flat like this for as long as I possibly can. I’ve pulled out the principal engineers outside of the teams, and that is key for decision-making. They act as overall architects. They help resolve difficult technical questions across teams. They’re an escalation point for anyone on teams to help resolve questions quickly. Like I said, my team sizes vary hugely. The app teams are often only 2 people, whereas, for instance, platform services is 11 people at this time. There’s no balance in terms of how that goes, and that’s perfectly fine.
Metrics
Next, I’m going to talk about metrics. Urgency means that you likely won’t invest heavily in your developer tooling when you start out. You’re going to get something that works, and you’re going to be focused on getting product out the door. That’s what needs to happen. When you’re in that state, and you have a small team, probably it’s pretty easy to spot where your biggest challenges are, where your biggest opportunities for improvement are. I’ve seen a pattern as startups get a lot bigger where there is a culture where people are just reaching for new tools all the time, and like, let’s try this, and we’ll add this, and there’s not a lot of standardization and consistency. That can become a problem.
As an example, at Sanity, at one point we counted, and there were four different ways to do deployment. We were using GitHub Actions, Terraform, Argo CD, and CircleCI. At a certain point, that just gets messy. It’s hard for people to onboard. As your company grows, investing more in standardization is going to make a lot of sense, as the barrier to entry for people will just become too high. Sanity is now 70 engineers and growing. This is real metrics from us. We recently invested in the DX tool for understanding and measuring our developer productivity. DX is a great tool in that it integrates easily with your system metrics from all different sources, and it also has a very well-researched survey that I really enjoy. There are many tools out there that you can use for this. I’m not advocating for this one over any other. You can also roll your own.
I do think at a certain point, engineers cost money, and these tools probably cost less than an engineer, so it’s definitely worth it to invest. Can you tell in October when we went on a company offsite to Spain and very little work got done? You can see that dip. You can also see in our number of builds that we’ve started to work on standardization and pulling more builds into our standard CI. That’s a very nice thing to see.
This is the developer experience index from DX. I’m just going to touch on it briefly because I really like the research behind it. I chose DX partly because the approach used by this company aligns so well with the work I did prior at Google and GitHub in measuring developer productivity. This work carries forward from the DORA, DevOps Research and Assessment work. Nicole Forsgren is an advisor to this company. That’s my only affiliation, this friendship. It makes measuring these drivers of productivity on the left there very easy via survey. The research shows that these drivers on the left influence the outcomes that you want to see on the right. You can start applying any of this yourself without specialized tooling, but the tooling definitely does make it easy. However, in the startup context, you want to keep it simple. I’m really into this DX core four for understanding how we’re doing in the context of my startup. The key here, as you hopefully all know, is not to index on any one of these metrics in isolation. That would be a problem.
For instance, if you started focusing on average diffs per developer, you could do really terrible things. That one in particular I would call out. You’re not looking at the individual basis. You’re looking at the average. However, you want to look at this holistically. Right now, you probably won’t be surprised to hear that Sanity, my company, is well over the 75th percentile on both speed and impact, and that’s what I want to see for a startup. I’ve been talking so much about urgency that that probably shouldn’t be surprising. We have room, it’s been uncovered, to do better in effectiveness. It’s a little bit like talking about how we have four different ways to build and deploy. That’s something that we’re going to work on. Now, having these metrics, I never want to see a slowdown in speed and impact until I suppose we’re much bigger, but I do want to invest thoughtfully and carefully in effectiveness in a way that’s not undermining these other strengths of ours.
Planning
Now I’m going to talk about planning, and this is really planning geared towards a sense of urgency and focus. If you take away one thing from this talk, I’m going to tell you that when you’re in a startup, doing a top-down roadmap is a game changer. In big tech, you need to do bottom-up planning. So many people, so many teams, it’s really important that teams take control of what their roadmap is going to be. I’m sure many of us have learned over the years that accountability is associated with productivity, so this may feel uncomfortable to some people to think, top-down roadmap, what is this? I cannot overemphasize how effective it is to do top-down planning centrally with your founders, with your core leadership team. They’re probably the people who understand the market and your customers the best, and can make a really coherent strategy that’s then going to line up to your marketing pitch, to what you want to speak to to customers, very effective way to work.
When I started at Sanity, we had a goal of building autonomous teams and pretty quickly threw that out the window and moved to this model, and it has been night and day. Again, like I said, you might feel uncomfortable because you might have learned that autonomy is really important for productivity, but I will say that there’s still autonomy in this model. Teams figure out how to implement in order to meet the goals that we’ve set. There’s nothing like a sense of impact and progress for productivity, and so getting folks to work on the right stuff that lands well with customers is so empowering and so exciting that that impact really supports productivity as well. We used Miro for putting together a little roadmap, and it’s not comprehensive. There is stuff that comes on to the team that’s not in this, but this is the big rocks, the things that we absolutely want to land. It’s focused and it’s in priority order.
Also, from a planning perspective, I’m a huge fan of 6-week cycles. This is the Basecamp model. Basecamp has really popularized this. Almost every startup I’m involved in now is doing some form of 6-week cycles. Six weeks is enough time to land an interesting increment of product value, but it’s not so long that you can’t reason about it, you can’t think about it. Almost any feature that we want to get completed has some implementation that can be done in 6 weeks. We are using Linear for project management. We switched to Linear about a year and a half ago, and again, a game changer, really excellent tool. The way we do this is that each team has a small set of cycle goals. Each of those cycle goals becomes a Linear project. Then there’s really nice Slack integration where everyone updates their Linear project once a week, and those updates are streamed to a single Slack channel, so anyone in the company can follow along in how we’re doing on all our 6-week cycles.
This is how Sanity’s been doing in our 6-week cycles. We started on February 1st, which is the start of our fiscal year, and we got off to a really good start, really landing a ton of value. Then over the summer, we started to dip, and I recognize that as a shaping issue. I’ll talk about that. Then, once we recognized that issue, we got back on track. What is shaping? Again, I’ll take from the Basecamp resources to talk about shaping.
Basically, when you have a goal, and you’re at the start of the process, you don’t know exactly what it’s going to take to implement and achieve that goal. That’s what we talk about as the uphill. In the uphill, you might need to do some experimentation with different UI designs. You might need to do some technical prototyping. You might need to consider what your tech stack is. There’s a lot of unknowns that are unclear. When you get to the top of the hill, then you’re at a point where you know how you’re going to achieve the goal, and it’s just a matter of execution going on the downhill. This is something now that we talk about in engineering a lot. When we create goals, we call out, are they shaping goals, or are they execution goals? We typically try to have shaping goals done before the beginning of a new cycle so that we can focus on execution. This has really been a game changer of having that mindset and understanding it.
I will give you, again, an example from Sanity. We use this tool, Hillia, on some teams. This is a real-life example of one of our products, Sanity Create. It’s an AI product, surprisingly. Before really understanding this concept of shaping, there were just a lot of different tasks that would go into a cycle goal. Sometimes it wasn’t clear how well they were understood at the beginning of the cycle. We had sometimes one-way doors being gone through too early, before reaching that top of the hill. Now, using this tool, we can be very intentional about pulling things in the right order across the hill, getting them done. That has been a real change for productivity. This concept of 6-week cycles, along with the top-down roadmap, highly recommend for productivity.
Experimentation
Experimentation. If your startup is going well, then it’s constantly changing. There’s no point at all spending tons of time on a fancy org structure, on team charters, on deep service catalogs, if they won’t last. One of my most common phrases at work is life is an experiment. The experiment mindset helps you move very quickly.
For instance, when I rolled out 6-week cycles, the idea made some of the engineers on my team nervous because it was a change. I framed it as an experiment, “We’re going to try this. We’re going to see how it goes. We’re not married to it”. After going through the summer, we came to a point where we did retros, and we said, “Yes, this is working. Let’s keep it up”. Same thing when we pulled in DX. You don’t have to perfectly understand everything or map everything out before you start an experiment, which can allow you to move quickly. Also give a quick note on risk mitigation when it comes to experimentation. It’s often a great idea to try simple things to address a problem before going for the big re-architecture. I know many of our instincts as engineers is often to think about the exciting new re-architecture, but it almost never makes sense in the startup context to go away for a year, not shipping product value on a certain team to come back and land something new. That’s just not the way.
An example I can give you from Sanity is we started having some limits with our Elasticsearch implementation. There’s something called attribute limits, which is the number of fields you can have in a file. Some of our customers started hitting that, and we thought, is this a crisis? It turns out we found a simple solution where we didn’t need to index deeply into nested fields. We could make a configurable limit to how deep you nested, and then the problem went away. Whereas the instinct of some of our engineers, of course, was to throw out Elasticsearch and do the massive re-architecture. It’s not like we’re not going to do that eventually. I know that we will. We’re taking stepping stones along the way to make sure that we’re always unlocking value.
I’m going to give you one more example of experimentation, and this is one that highlights how it’s particularly different from big tech. The Sanity Studio team I mentioned before, it’s a React app, highly customizable. They worked on a feature over the summer that touched many files and was quite a substantial change from the UX of the product. They worked in a way that I’ve learned is the right way to work in big tech. Lots of small PRs, merging frequently, and keeping features behind a feature flag before releasing them.
Then what happened was we decided that this wasn’t the right approach. This wasn’t something we wanted to do. Then in our main branch, we had tons of cruft across many files, and that was a discouraging job where the developers had to come in and pull out all of that work that they had done. Not fun. Now this team is doing another project. In fact, it released, called Releases. It’s kind of like Git for content. With this feature, the team said to me, we don’t want to do what we did before. This is a risky feature. There’s a lot of different change. We’re going to experiment on a lot of different UI approaches and UX approaches. We want to work in a long-lived branch. They worked in a long-lived branch. They kept that branch constantly synced to main. They weren’t deviating from main otherwise, but they were deviating only in the feature work they were doing. They did tons of experimentation, lots of pairing, and they didn’t do human code reviews much at all during this time.
Anyone who’s worked in productivity would say that we know code review is really important, but the team wanted to try this experiment, and I said, “Life is an experiment. Let’s go for it. You were burned before. Let’s give this a try”. I did insist to them that they turn on the AI code reviewer from Graphite, because I think that was enough to catch the silliest issues that would make. Of course, before any product went into the hands of customers, it’s critically important that human code review happened. We absolutely did that. We did a really thoughtful code review process before merging this into main. The team is going to be doing a retro soon. I suspect that they will say that this was an effective way to work. It’s not what I would have expected, but I’m open to experimentation, and so I embrace it.
Conclusion
This whole talk has been about how startups differ from big tech, and a lot of it is about the culture that you need to build in a startup to support developer productivity. If there’s four key takeaways for you, things I want you to remember, if you’re thinking of going on the startup journey, if you’re already on the startup journey, if you’re curious about developer productivity for startups, first off, urgency. You need to instill a sense of urgency in your teams. You need your teams to understand that urgency is the thinking that you need to have. You need to lean into healthy risk-taking in a way that’s substantially different from how you would in big tech, where you have a proven company and a proven business. Can’t say enough about top-down strategy, top-down roadmap, and really planning centrally in order to achieve the best outcomes. Finally, supporting a culture of experimentation.
I am Rachel Potvin. SVP of Engineering at Sanity and Startup Advisor.
Questions and Answers
Participant 1: How do you manage technical debt with a sense of urgency? Let’s say if you raise some technical debt in your first few years, and then you realize that’s all you have, do you keep kicking the can down the road and deal with it once you’re out of startup phase, or you try to make it sustainable early on?
Potvin: The question is about technical debt, and how do you balance technical debt if you get a lot of technical debt early in your journey? Do you just keep kicking that can down the road, or do you address it? You have to address it, but you have to do it intentionally. It’s like I was talking about where my team maybe wanted to do a full re-architecture of our indexing. That’s just not the right approach. When we approach technical debt, we try to have the same type of goals as we would for any product value. What’s ultimately the goal of this project? What are we trying to get out of it? It ends up being a balance. Initially, when we did our first top-down roadmap, we focused solely on product goals, and that was fine.
Then I said, we’ll have a technical roadmap on the side where there’s some things about our DevOps experience, how we do deployments, some infrastructure risks that we see, some scaling challenges that we see, and we would merge those in on a team-by-team basis. I’ve learned over the last year that I want those big tech rocks to be in my main top-down roadmap as well. We’ve started intentionally putting things on there so they don’t get starved out. There are also other things we do. All my teams have support rotations. In the support rotation, it’s your week to do what you want to do and resolve any frictions that you see. That week you’re not working on 6-week goals or the roadmap. You’re entirely working on usually tech debt, customer escalations. We try to give that room to developers to get some of the most annoying frictions solved as well.
Participant 2: What lessons do you think big tech should take back from your experience at startups?
Potvin: The stuff I’ve done to facilitate decision-making is something that big tech could really learn from. If people don’t have a clear road in front of them in order to get work done, it’s not only unproductive, it’s demotivating. A thing you see frequently in bigger tech companies was like, we had a meeting and we didn’t actually resolve what the next step is, so let’s come back to the meeting next week and try again. Or, we need a meeting to resolve this. Let’s look at everyone’s calendars. There’s not time until two weeks on Tuesday. That’s languishing. What structures can you put in place to facilitate decision-making a lot faster? This principal engineer route is one thing I’ve done. I’ve also established what I call the engineering council where when there are tough technical decisions, I have a slot that’s reserved for that on a weekly basis where people can come in and get these conversations had really quickly and solved quickly. It’s canceled if there’s nothing. Also, really embracing that one-way and two-way doors, and empowering more people to make decisions that are not going to be world-ending if they’re wrong.
Participant 3: You raised a really interesting question about tool sprawl, about CD pipelines and there’s all sorts of mess. When do you feel like you hit a threshold where you had to make a decision? Also, very curious how you tackle it. Did you have a team? Did they address this issue to have uniformity, or did you make a decision and each team decided to figure out how to use that tool?
Potvin: I feel like it’s a journey and I’m not done yet. That was one thing that when people asked me what was surprising in a startup, I think we have more vendors than employees. Because we’re just using every tool that’s out there. Then our engineers are very strong and they’re very excited about new tools that come out and they want to adopt them. I don’t want to create a barrier to entry to that. I wouldn’t say I’ve solved this yet, but we’ve recognized this as a problem and started to look towards it.
Again, I’m leaning on the principal engineers. Some of the results we got from the DX survey also to show the team that there’s a productivity cost to too much sprawl. We’ve started working on a much better local dev setup. It doesn’t have to be a principal engineer, but often what will happen is some person does something that is actually really good and makes a lot of sense. Then I have an engineering all-staff where we would show that stuff. Like someone did some really great work on observability recently and I want everyone to take on that same tool stack for observability. Show it to everyone first. Get adoption from people who are interested in what they’ve seen.
Then slowly start to say, this is the way we do it. We’ve also created a repository of engineering patterns that are approved and not approved. That comes down to like, what programming languages do we use? What architecture paradigms do we lean into? Again, we start that with suggestions and then we have an engineering council where we say, yes, this is what we were going to do going forward. We’re never going to stop and be like, let’s go fix everything everywhere that doesn’t meet this pattern, but at least going forward, we’re trying to do that. It’s not an easy solution, but it’s something where we’re trying to move intentionally there without slowing the rest of the way we work.
Participant 4: Big tech, mid-sized companies, startups, everywhere in between, what’s the one thing you want us to go back to our companies and fight tooth and nail to make sure we can get implemented to make our lives better?
Potvin: I really believe that there’s nothing that makes us happier. I alluded to the fact that I’m on this startup journey, that it’s a new life for me, that I was very discouraged and considering walking away from tech. Now I feel very empowered and excited by the progress that I’m making and the sense of accomplishment that I have every day. It’s part of the human experience. Every human deserves to have that feeling of moving forward. I’m going to lean back on doing decision-making well and clearing the path for your developers so that people have that free road in front of them where they can just go and have that sense of accomplishment that just feels so good. I think that’s something that applies across any size company is figuring out how to unlock that so that people get that joy of being productive and having impact and making progress.
Participant 5: From your personal point of view, that chasm between big tech and startups, is it inevitable? Every startup will one day, if they of course are successful and grow, become a big tech that has all the things that made you walk away from big tech.
Potvin: First of all, I think it’s not inevitable because most startups will not succeed. That’s something that you have to know when you go into a startup. There’s no magic bullet. There’s a lot of different things of like, right time, right place, customers. One thing I’ve found really fascinating from a startup perspective is, I’m on the core leadership team and I’m exposed to what we’re doing in sales, what we’re doing in marketing. It’s really fun to see that, but it is a risky business. My hope is that Sanity does become a big tech company. We are going well. It’s very likely, and I want to be there for that journey. I think I will be open to it. I’ve done it before, but this would be a little bit more on my terms. Because I would be there setting the culture and being along the journey, along the way versus the situation I ended up in big tech was there was a lot more things coming down on me that I couldn’t control. My optimistic hope is that, yes, I get to be in big tech again via this job that I have currently now. It’ll be a long road. I hope that I can help control the culture as part of that.
See more presentations with transcripts
