2 years at GitHub 🎉

I recently celebrated my 2nd year anniversary of working as a design system engineer at GitHub 🎉

In honour of my anniversary, I wanted to share some of the highlights and things I've loved about the past 2 years.

I still remember the day I saw the "Software Engineer, Design Systems (Australia)" job opening from GitHub and how excited I felt finding out about this opportunity. The job description was not about just nitty-gritty technical details; it talked a lot about the mindset, values, system thinking (specific to the job), collaboration, progressiveness, and the culture. It was quite different from most of the job openings I had seen so far and by far the most well written one. I remember thinking about how clear and confident GitHub is in what they need and are looking for and I was all in for that.

Now, 2 years later, I can say with confidence that it wasn’t all talk; there are many things to love about GitHub’s culture but for this post I'd like to focus on asynchronous communication and hope to write more about other things in the upcoming posts.

Async communication blew my mind

In a nutshell, async communication is leveraging alternative communication methods other than people being in the same place (physically or virtually) at the same time to communicate and collaborate.

GitHub is a remote-first company. We have folks from all around the world, working in different timezones. My team alone is spread across 5 different time zones. To achieve real collaboration in our work, async communication becomes more than a preference for us–it is the only way.

The effectiveness of working asynchronously is still a controversial topic for some, but I strongly believe that when it is done right, async communication has significant benefits. Ben Balter, our director of Engineering Operations & Culture, has a great blog post about all things async working and I highly recommend giving it a read. For now, I'll share some of my experiences and things that made the biggest difference for me.

Recorded meetings

Although I don't have many meetings as an individual contributor (and this is certainly one result of intentional async communication culture), we still have planning meetings, weekly engineering syncs, and company / org-wide meetings. Because we are distributed across the world, there is an inclusive practice across the company to organise these meetings in alternating time zones. I love this practice because it gives me an opportunity to be in the same (virtual) room with my fellow Hubbers but most of the time, recorded meetings are how I catch up on these things. All recorded meetings are accessible in a hub and there is no fomo when being on leave, or when meetings are held in a different timezone. What I love the most about the recorded meetings is that I can plan the time to watch them without interrupting my focus time.

One fun way of utilising recorded meetings I heard —and sometimes practise myself as well— Is by watching recordings of meetings held before joining the team to see what stage things were at and how progress has been made since then.

Meeting Notes and Agenda

Apart from recording meetings, we also take notes in meetings. Note taking is a common practice for many folks and businesses but what I have seen as a difference at GitHub is the way that the notes are utilised. Meeting docs are accessible at any time and are usually linked to the calendar invite. For more efficient meetings, attendees are encouraged to leave topics to the meeting docs beforehand. Whenever I think of an idea, or I am challenged by something that I need to chat about with my team, I go and add that topic to the agenda.

If I won't be able to make the meeting, I look at the topics on the agenda and comment beforehand to share my thoughts and provide my perspective.

Meeting notes are also very useful while catching up with the recordings afterwards. Having dedicated space to leave comments and ask questions helps us keep things organised. We also utilise these notes for further documentation if/when needed.

Collaborating on GitHub pull requests, issues, discussions

Unsurprisingly, we use GitHub for everything, and we are particularly good at utilising pull requests, issues and discussions as a way to collaborate. Compared to my previous experiences where pretty much every decision is made synchronously (now writing that out makes it even weirder), at GitHub we utilise issues and pull requests for discussing solutions as much as we use them for capturing work and keeping artefacts. We initiate conversations on GitHub Discussions to talk about broader architectural decisions, team practices, project kick offs and more.

Collaborating on GitHub is my favourite part yet the most I am challenged by.

Everyone has a different way of thinking, learning, and processing information. When I view collaboration through the lens of inclusivity, I find asynchronous collaboration to be the most accommodating for diverse minds. I appreciate having the time to read comments, analyze them, take notes, and respond thoughtfully. Writing down my thoughts allows me to avoid the pressure of forgetting to mention something in a live conversation. With async collaboration, I can always edit my comment or add another point later. I don’t have to worry about missing a colleague’s valuable input while I'm still processing a previous one. Plus, each comment has a unique URL, making it easy to reference or link back to when needed. Like meeting notes, we can escalate these discussions into documentation when necessary. How great is that?

Now onto the challenging part. Adopting an asynchronous collaboration culture means dedicating a significant amount of time to writing. For many who are accustomed to a synchronous work culture, writing may not come naturally. Even though I have experience working across a 17-hour time difference, the culture at my previous company was quite different, and I struggled. Speaking in a conversation can sometimes feel easier because it's fluid—I can pause, revisit topics, and adjust as needed. Writing, on the other hand, must be concise, clear, specific, and engaging. I’m still struggling with this, but I’m actively working to improve. I take intentional steps like practising writing, attending writing classes, and regularly seeking feedback.