Week 5: What!? There are no tickets here? No QA engineers?

When I joined GitHub the first time, I was very surprised on how differently it operated vs past engineering organisations I joined

Hey friends,

Last two weeks, I traveled first to Helsinki for a metal festival (Tuska!). Fact: Finland is the metal capital of the world; they have the most metal bands per capita in Europe. It matters so much, they have a metal section at the National Museum. A final note on it: Reindeer meat is delicious! Highly recommended.

Then we traveled to Switzerland to bike there. Switzerland is the most beautiful country I have ever been to. The mountains, the green fields, and the architectural style just fit. A pleasure to drive and bike around.

It did get me thinking about the fact that Switzerland is a "neutral" country. Of course, being neutral is easy and lazy when you are not directly affected by war. But I also see the benefits: worldwide organizations (WTO, WHO) have a neutral soil to operate. I loved the landscape, but I feel troubled due to their historical support of shady financial operations.

Joining GitHub and work ownership.

I left GitHub a while ago, and lately, I’ve been reflecting on the things I learned about operating as an engineer, and I'll share some of those here.

I joined GitHub in 2017, coming from a small startup. Back at said startup, the team used SCRUM as their daily operating framework, and we had a SCRUM master. My personal experience with SCRUM always felt _wasteful_. My team spent many hours in grooming sessions, estimating, and creating tickets. We only completed 10% of the tickets. It was just a lot of well-intended but useless busy work.

Once I joined GitHub, I noticed my team didn’t use SCRUM. Not only that, they didn’t use anything resembling a project management framework. The way of working was very liberal, and the team used whatever worked for them. That group of people was very effective. I noticed the same pattern when I moved to other teams at GitHub. Teams used whatever process made sense to them, as long as it didn’t get in the way of writing and shipping code. Gergely from The Pragmatic Engineer talks in more detail about it.

But the most fundamental change in my work mindset was thinking thoroughly about my daily tasks. When I joined GitHub, I still had a "ticket" mentality. In agency work and less mature organizations, PMs or EMs define the work for engineers, and engineers simply execute. This was not the case at GitHub. I noticed that engineers there operated very differently and owned all their work from beginning to end.

1. They defined their work. From talking to customers, negotiating with PMs, coordinating with other teams, and fully understanding the implications of their work.

2. They guarantee the quality of their work. There isn’t a QA team to test and confirm things work and no bugs are introduced. You have to go through multiple stages to guarantee your work is of quality: write automated tests, test locally, peer code review, test in an isolated production environment, canary deployment, and then production deployment.

3. Most engineers didn’t just completely disconnect from the feature once released. Before release, they had already set up observability metrics to monitor the performance and reliability of the new feature, look into users adoption and keep an eye on bugs and new code exceptions.

What epiphanies did you have when you joined a new team or company from your previous way of working? Curious to hear your stories.