Strategies for Thriving Engineering Organizations

As engineering leaders, we’re constantly navigating change, especially with the accelerated pace of AI advancements. Every day, we’re faced with questions about how to empower our developers to not just adapt, but to thrive. While AI is a significant part of our present landscape, the core of GitHub’s purpose remains unchanged: building happy developers that can do their best work.

In this fast-paced environment, the challenge for leaders is clear—how do we equip our teams to innovate, collaborate, and succeed? In this talk, we’ll explore some strategies, investments, and mindset shifts needed to ensure our developers can do their best work and that our teams can truly be greater than the sum of their parts.

How can engineering leaders get the best out of their developers?

As developers, we know how quickly things can change.

• We’re always learning new technologies, new languages, even absorbing once-in-a-generation shifts like the current runaway train that is AI.
• While the AI revolution is recent, the inherent desire to get the best out of our developers is not new.
• So in rapidly changing circumstances, how can engineering leaders continuously generate the most impact possible??
• What changes, what investments do we need to help our developers achieve their full potential??
• How do we enable teams to be greater than the sum of their parts?

By enabling developers to do their best work

As a first principle, we want to enable developers to do their best work.

• How AI plays into this is a fair question, and we’ll discuss it a bit, but there is so much more that we should be thinking about.
• I’ve had the opportunity in my career to build teams, grow teams, try to fix teams, and if I’ve learned anything, it’s that every situation is unique.?
• For the past 5 years I’ve been focusing on helping GitHub scale and today I’d like to share with you a little bit about how we work at GitHub, with a glimpse at some of our history and how it shaped us.

Let’s start at the beginning, where GitHub was an unintended result of trying to enable developers to do their best work.?

GitHub’s origin story began with painful Git Repos

Our founders actually had no intention to build GitHub. Instead, they were on a mission to bring families together online with a project called FamSpam, an online mailing list for families. Maybe FamSpam would have been a great product, we’ll never know.

Well, while working on FamSpam, the founders stumbled upon a challenge. This new git thing was out there, but it wasn’t very good yet; in particular, sharing content between developers was left to means outside of git, like email or file shares. They wanted a better way to collaborate and work on FamSpam, so they started GitHub, as a side project.

GitHub started with the founders wanting to enable developers to do their best work.?

GitHub’s Hello World

And so GitHub was born, “Git repo hosting, no longer a pain in the ass”.

And word of mouth quickly caught on. Friends of our founders, deeply entrenched in the startup world, began asking to use GitHub, for the same reasons we were using it.??

We implemented an invite system similar to Gmail, leading to public requests for invites on platforms like Twitter and mailing lists. As excitement for GitHub grew, interest in FamSpam waned. Our third co-founder, P.J., joined and took over billing, so obviously we made him the CFO.?

In 2008, we officially incorporated as Logical Awesome LLC.

GitHub.com evolved as GitHub evolved

So this core principle, on which we were founded, enabling developers to do their best work, this applied to GitHub in two ways -?

First, our product was built to enable developers to do their best work.?

Second, we wanted our own developers, those building GitHub, to do their best work.?

The combination of these two, where GitHub developers use GitHub to build GitHub, this was, is and will continue to be something that makes us unique.?

We get to enable developers across the globe, including our own, to do their best work, by making GitHub better.

Building GitHub for GitHub

Early on, as we were shipping features, we actually thought a lot about our own needs.?

We essentially hired great developers and asked them to build a tool that would make building that tool easier and better.

Developers thrived in this environment, and all we had to do to spark creativity was get out of their way.

Creativity is a cornerstone of developer productivity. In these early days at GitHub, in the early days of many startups, progress is fueled by creativity, but how do we keep doing that as we grow?

GitHub Next

Well, fast forward to today.

One way we fuel productivity at GitHub is by creating a dedicated, ring-fenced, team focused on being creative. We call this team GitHub Next; that’s actually the team from which Copilot was born.?

Not unlike GitHub at its core, the Next team still focuses on evolving GitHub to enable developers to do their best work, but without the daily constraints of running or operating the existing service. Microsoft, as another example, has an entire Research and Development organization with a multi-billion dollar budget whose exclusive goal is to be creative and innovate.?

This is an idea worth considering in your own organizations, essentially ring-fencing a team to explicitly forward-looking ideas.?

Driving creativity in teams with existing responsibilities

But what about driving creativity in teams that do have daily responsibilities aligned with an existing product??

Maybe we can’t afford to have a whole team not working on immediate company priorities, or maybe, just maybe, we recognize the importance of creativity in every-day work as well. In the end, helping all our teams bring creativity to their daily work is the goal, but before we talk about how we might approach this, let’s get back to our GitHub story.

While letting developers run ahead and be creative certainly led to some amazing results, it also created a bit of a problem.

At one point we had over 100 features ‘staff shipped’

We were so excited about shipping things for ourselves, we sometimes, dare I say often, didn’t ship it to our customers.?

We have this powerful concept at GitHub called StaffShip, which is basically shipping a feature, behind a feature flag, that is only available to GitHub employees. It’s great, until you stop there and don’t ship to anyone other than those employees.

At one point, we had over 100 features shipped only internally, so what were we to do?

We needed backlog management

We needed some backlog management, desperately and so we hired a product team! Or at least a product person. So what is the first thing our product team did?

They wrote down all the work we were doing. Taking an inventory of our ongoing projects. Every single one.?

Starting with a simple list

If you took a look at the list created,, you’d think we were preparing to take on every tech company out there.

What were we trying to achieve?

This is a very common symptom I see in teams that are struggling to make progress towards goals; they are doing too much, and lack focus.

I believe that investing in how a team works is just as, if not more important than what a team works on.

Team Building Blocks

While cultures are different, mechanics might change, there are a few things that I believe are fundamental building blocks to a healthy team and how it works:

• Make all work visible
• Define work in small chunks
• Limit work in progress
• Fund to capacity
• Bonus: leave capacity for the unknown

So let’s go through each of these.

Make developer work visible

As you saw in our case with GitHub, once we wrote down everything we were working on, it really hit home and it was clear we were doing too much.

Before I was at GitHub, I was running the App Center team at Microsoft. We were struggling to make forward progress on anything. When we wrote it all down we had about 4 features on the board per developer. Over 100 features for a team of 30 devs.?

In that case, we literally declared bankruptcy, closed all the issues and started over.

Size development work into 1-2 week increments

The next aspect is consistently defining the size of work and, critically, making these items small. The topology of work can vary, but it’s so important that teams can close pieces of work in 1 week, at most two week chunks. Not only does this create a sense of accomplishment and progress, it also allows teams to pivot if needed.

Pivot!

Speaking of pivoting, we all know that things come in sideways; teams need to leave some amount of room for that.

We’ve all heard of 20% time, but what the actual percentage is can vary team to team, with some maybe needing less, while others more. The analogy I like to use here is that of a highway. What do you call a highway that operates at full capacity? A parking lot. You need space to move ahead and absorb unexpected changes.?

Limit your work in flight

And once you have all this, the key is to limit the amount of work in flight.?

Say you have a team of 8 individual contributors. How many 1-2 week features or batches should that team be working on simultaneously? I am shocked how often I heard from engineering managers that for their team, this might be 8 or more. The answer is 1 or 2, maybe 3 in rare occasions where one of them is small.

Fund to capacity

So how do you do this? Once you’ve defined the backlog and prioritized it, take the top thing on the list and put as many people as you can on it, until they are actually stepping on each other’s toes. Only after your first item is fully funded, go on to the second.?

Here’s a potentially controversial topic: Encourage pairing.?

Not only does it increase the quality of the work produced, it creates team energy and supports an environment without knowledge silos. When a team works like this, the environment supports creativity. Developers have focus, have support and have time.?

Create time to enable flow

The common theme in both how a team works or having a dedicated team for innovation is creating time.?

The fundamental premise is that developers can be most creative, and productive, if they have the time to do so. We often hear about the idea of developer flow, the magical moment when a developer is truly focused, without distraction, on the task at hand.?

Developers are often happiest when they are sitting in their developer environment, coding away, focused on making amazing things. If we can keep developers there, improve that experience, we help keep them in the flow, keep them creative and productive.?

I mentioned how Copilot was born out of our Next team. The core idea was bringing help to a developer where they do their best work, keeping them from having to context-switch which we all know is a productivity destroyer.

Copilot began with code completion + prediction

It started with the now basic idea of code completion, predicting, very impressively, the next lines of code or even entire functions a developer would write.?

But we’ve built on that, bringing chat right into the IDE so a developer has a true copilot to help them answer questions.

Copilot helps our developers stay in the flow

For us, GitHub operates in a heterogeneous environment with many languages and technologies. This means our devs often have to work in languages and tools they are not an expert in.?

Those same developers are expected to write secure code, but aren’t security experts.?

Normally, developers would go search for the answer, somewhere else, not in the IDE.

I know for me, if I have to open my browser or Slack to ask a question, it’s so easy to get pulled into something else, to get distracted and lose not just the absolute time, but the focus, the flow, I might have been in.

By bringing Copilot and things like CodeQL and Auto-Fix into the IDE, GitHub helps developers stay in the flow, supporting creativity and productivity without compromising on security.?

How GitHub helps teams stay in the flow

AI can help developers stay in the flow, creating the time they need to be creative and productive, but what about teams? How can we help them?

I talked earlier about the idea of managing spare capacity to create the room a team needs to absorb unplanned work. I also mentioned that some teams need more than others.?

I like to think of this as a sort of base metabolism of a team; what is the baseline work to keep the lights on and keep the team in a healthy state. For some teams this is small, for others this can be overwhelming.?

Too much KTLO + toil work destroys team creativity

For us, the amount of “keep the lights on work” a team has is very much a function of how much manual work a team has to do. Talk about a creativity destroyer.?

Manually doing tasks that should be automated is the worst. Can you imagine being a principal engineer manually rebooting MySQL servers all day??

It wrecks morale.

At GitHub I am responsible for our infrastructure and platform services, the base of GitHub, but also where a lot of the toil is. We manage fleets of 1000s of machines and unfortunately, we didn’t invest enough in automation early on.?

We’ve since righted that and one of our top goals is automating everything we possibly can, recognizing that this will create the space our teams and developers need to be creative and move forward on impactful projects.

To create the space and capacity for developers to do their best work, you have to understand and analyze what toil impacts them.

But how can you know what needs fixing?

The genesis of GitHub’s Developer Experience Team

Let’s go back to the GitHub story.?

After we brought more focus and attention to the work we were doing. We were able to really make some amazing progress. While we continued to invest into GitHub for ourselves, we got way better at marrying that with what our customers needed.

The idea of Staff Ship did not go away, but instead became a critical step on a feature’s way to production and our customers.?

As time went on, however, the product itself became more complicated. Not just more features, but the scale at which we operated, the number of customers we supported grew. This had a direct impact on our developers, making their day to day experience progressively more difficult.?

At the time, we really only knew this anecdotally, but enough complaints about this like Continuous Integration (CI) being slow, or buggy, tests being flakey, not ideal workflows, painful dev environment setup, really called to question our lack of direct investment into our developers.

So while investing in GitHub itself was a means for us to enable our own developers, since we effectively used GitHub for almost everything, as we grew it just wasn’t enough.

A significant turning point for us was in 2021, with the establishment of a dedicated Developer Experience team.?

How do you make DX successful? Listen to developers

The first question we had to ask ourselves was how would we know if our developer experience team was successful in actually making developers more productive?

It’s a fundamental question I get asked all the time by our customers. How will I know if GitHub makes us more productive, whether that be with Copilot or any other feature?

My usual response is to ask them how they are measuring developer productivity today - often the answer is they are not. For us, we do internally measure some metrics like lead time or deployment time, but we have put an outsized focus on developer satisfaction.

Why?

Developer satisfaction is the best proxy to developer productivity

Because Developer Satisfaction is the best proxy to Developer Productivity.?

If developers are happy, they are engaged, doing their best work. And…how do you know if your devs are satisfied and happy? Ask them.

Developer Satisfaction Surveys are conducted quarterly

Running a developer satisfaction survey is something I highly recommend for everyone here. Going back to our previous discussion on KTLO and team toil, this is the tool that will show you what those challenges are for you.?

For the past four years, we have run these surveys first semi-annually and now quarterly.

We aim for a 10-minute completion time to encourage participation. The survey includes both quantitative and qualitative questions. We pore over every comment, identifying themes and following up for clarity.

Analyze and follow-up on your survey

Surveys are a lot of work. Part of our DX team is tasked with executing this survey and the results, and we find the time well spent. Why? Because we follow-through.?

A crucial aspect of running a DevSat survey is the follow-through. It's pointless to ask for feedback and then ignore it. At GitHub, we share DevSat results monthly from the DX team, linking improvements back to previous survey feedback.

Improvements don’t happen overnight, they build on each other - gradually. So the constant drumbeat of progress is important. As we learn from our developers what gaps need to be filled, we carefully prioritize and make headway.?

One particularly important area where both DX and our surveys had a big impact for us was Availability.

I am sure many of you here can relate, but at GitHub, Availability is Job #1 and as such, streamlining the processes and tools that enable us to bring the highest quality of service to our customers is critical.?

Our developer satisfaction surveys drove our availability investments

Our surveys revealed issues with our deployment pipelines that metrics alone couldn't highlight, such as the complexity of rollbacks during incidents. Consequently, we improved our deployment safety, build pipelines, and rollback mechanisms.

The surveys also highlighted inefficiencies in our incident tooling, leading to the creation of dedicated Slack channels for each incident and standardized templates for incident discussions and documentation.?

Our improved tools and processes, driven by our developer satisfaction surveys and implemented by our developer experience team, not only improved our developer experience internally, they ended up improving our customers experience tool as they led to quicker and more detailed root-cause updates to our incidents.

Every company should invest in DX

Having a dedicated developer experience team in your organization is something to really reflect on and consider.?

We at GitHub, a product and company literally built on the foundation of enabling developers to do their best work, need one and get immense value from it so I encourage you to either start the team or invest more into it if you already have it. As we grow, we continue to grow our DX team as well.?

We’ve covered

So for unlocking developer creativity and productivity we’ve talked about creating time.?

We’ve discussed:

• Creating a ring-fenced team?
• How you can create the time and space by streamlining how a team operates
• How AI can help developers stay in the flow.
• How removing obstacles can reduce toil and empower teams to focus on business priorities.
• And how a dedicated developer experience team coupled with developer satisfaction surveys provide the right investment mechanism to manage those obstacles.?

But let’s be frank. The day to day experience of developers can be ruined completely outside of the core work of writing code, managing live-site or shipping features.?

Developer experience is about culture, often reflected in all the other things we spend our time on.

Our async + remote culture maximizes developer impact

At GitHub, we were founded on the core principle of enabling developers to do their best work. But let’s unpack the how of that a little. The basis of GitHub is git, and the core purpose of git is to drive collaboration among developers. Even more, asynchronous collaboration as much as possible.

Perhaps a bit of a controversial topic today, with many top companies instituting return to work mandates, but GitHub is a fully remote company, we always have been. And we’ve built GitHub with the idea that remote, distributed, and asynchronous work is the key to getting the best out of your developers.?

The backbone to our async workflows

I’ve already mentioned Slack in the context of incidents. We also use Google docs for some things, but the heart of GitHub’s communication internally is GitHub itself. We all know that a massive distractor of satisfaction and productivity in a developers day is constant context-switching. For us, GitHub itself is the platform that enables us to combat that.?

• We track work and progress of everything from individual developer tasks, to GitHub-wide initiatives using issues and projects.
• We use discussions to celebrate and share wins, discuss proposals or ideas and every kind of announcement you can imagine
• We store durable documents, like playbooks, architectural decisions, company values or business priorities in repos as markdown.
• For all of this then, pull requests are the main mechanism for making and discussing changes.

Notifications pull it all together

But here’s the key, GitHub notifications pull this all together, with the @mention of an individual or team being the cornerstone of bringing context to those that need it.?

This notification flow is asynchronous and developers get to choose when and if they participate. This puts developers in control of their own time, keeping them in flow, and improving their satisfaction and productivity.?

How we enable our developers

To enable developers to do their best work, we want them to be creative and stay in the flow. This all hinges on time, and things like dedicated teams or dialed in how-we-work processes help enable that. We also talked about how modern AI tools–like GitHub Copilot–can help keep developers in the flow.?

Next we discussed what kinds of obstacles, like lack of automation or high keep the lights on costs, can prevent teams from having the time they need to be creative. But having a developer experience team coupled with regular surveys can be used to discover, diagnose and fix these obstacles.?

And finally how fostering a culture of asynchronous collaboration, which we do with GitHub itself, can have an immense impact on a developer's ability to focus.?

Our platform molded our own transparent + collaborative culture

So now you’ve heard a bit of our history, how we use GitHub to build GitHub, and how all of this is in service of enabling developers to do their best work.?

This core principle has shaped our company, and our product.?

If you peel back the layers of Github, you'll find a reflection of one of our core values, Better Together. GitHub foundationally is about collaboration, empowering developers to achieve their full potential wherever they are and whatever they are working on.?

Our platform isn't just a tool for writing code; it's a catalyst for shaping an engineering culture. Creating an environment where engineers can thrive, together, where their work is not just efficient, but transparent.

GitHub can help drive cultural transformation in teams

When teams and companies adopt GitHub, they are often looking not just to improve their tools, but how they work together, which often leads to cultural transformation. All that said, amazingly, we never really started with any of that in mind. We just wanted to make git not be a pain in the ass.?

GitHub builds happy developers

At GitHub, we hope to help build happy developers all around the world. We know that happy developers are productive developers, creative developers, developers that have the time and space to solve the most important problems, developers who are reaching their full potential.?

By sharing our story, I hope some of these ideas can help you build happy developers in your teams as well.?

Thank you.