I always wanted to land a job with 37signals. Wait? What does this have to do with GitHub? Bear with me. This may be a long post.
They recently changed their name to Basecamp. They stopped developing other products, and focused on Basecamp. A project management and team communication tool. They extracted Rails from Basecamp back in the day. Rails had revolutionized web development. Everything based on the Ruby programming language.
My relationship with Ruby and Rails goes back to 2006. That’s when I started freelancing and created my first Rails app for a customer.
My dream was to work remotely, and that was one of the reasons I left my first job as a programmer after 8 years back in 2006. As a freelancer, I could work from home and set my own schedule.
At the time, 37signals was one of the few companies embracing remote work in full. It also had many other values close to my heart:
- Simplicity,
- putting people first and making their lives easier,
- staying small,
- choosing meaningful work,
- opinionated software,
- and more.
It was not easy to get a job at 37signals though. I was not as experienced as I should have been. I would fail the interview or not even get one if I applied. Especially among a huge number of great applicants. You see, 37signals hiring was as slow as a glacier. Growing in snail rates was a core value for them. Whenever they posted a job opening, people lined up in swarms. Even after 15 years, they’ve only recently exceeded the 50 person barrier.
My hopes for getting a job there were not very high. Despite that, I kept watching them. I read their books and gorged their blog.
In the meantime, I worked hard to start freelancing offering my services to US based customers. Soon, I realized it was difficult to get paid for my services. I would have to compete with folks from countries all over the world. Folks offering cheaper services.
With no prior experience or a portfolio to show, I changed my tactic. I decided to offer my services for free. I did that to expand my network and gain experience.
I worked in a couple of closed (i.e. not open source) projects like that. I even translated an older version of Basecamp to Greek. That was back when 37signals was actually doing translations.
In the process, I improved my Ruby skills. I learned how to collaborate and communicate online with folks in a far away timezone. All related to my dream to work from home and set my own schedule.
At the same time, I had another mission back in Greece. I was trying to persuade my boss at my day job to let my team work from home. I was leading a small team of programmers. I had organized the software development department of the small company from scratch. Six months of continuous debates and negotiations went by. In the end, I managed to persuade them to let us do it. My team would work from home 4 days out of 5. I had to sacrifice myself and offered to stay at the office. I would make sure everything ran in a smooth way. It would help us avoid any communication problems and ease leadership’s concerns. I did it for the experience of managing a remote team, so staying at the office wasn’t a huge downside for me.
At that time, and for several years, I have been using Subversion as our version control system (VCS). A centralized, popular and straightforward to use VCS.
In the meantime, another cool company made its appearance and gained a lot of popularity. Back in 2008 GitHub started creating a buzz. GitHub popularized Git, the distributed VCS.
Anyone will admit how difficult it is to learn Git, coming from a centralized VCS. That was keeping me from learning it, despite all the buzz.
In the end, I took the plunge. Git started making sense to me. I even started using it with real projects. As I was ready to make a full move to Git, I saw something compelling in my email inbox. It was an irresistible job post from a board I was following. GitHub was looking to hire someone in support for the European region.
I wrote my email application in what felt milliseconds. I was typing so fast, my keyboard was on fire. Sure, that position meant the end of my programming career. But it was in return of joining a promising cool San Francisco startup. In return of working from home, and I have to admit, getting paid at a rate I couldn’t find in Greece. If joining 37signals was difficult for me to achieve, I could settle with joining GitHub 😀.
In 2010, I started working part time at GitHub. In January 2011, I traveled to San Francisco to meet the 15 person GitHub company. I then started working full time.
I joined the only other person in GitHub Support, Tekkub. When the US was asleep, I was working. We had a lot of overlap of course. I was ecstatic. So happy! Working from home for a company like GitHub, without having to leave Greece was a dream come true.
When I started, we used a support tool that was a mix of a community forum, with public and private threads. It was a bit problematic because folks could reopen old threads, that were irrelevant. There were many threads that had outdated solutions. We needed to clean up things every day, despite some automations we put in place. The company behind the tool was a bit slow accommodating our needs, so we had to find a solution.
We started looking around and trying things. Nothing suited our needs. Some tools were too complicated. Some vendors had misunderstood how to design a web app. We had simple, but quite unique needs. In the end, we decided to write our own tool.
The tool was only one web page. Tekkub wrote it and I was giving feedback on how it should work. We designed it for efficiency and simplicity. It was one page that listed incoming tickets. One would click SPACE and it would open the selected ticket in a different tab in the browser. Once you responded, you clicked SPACE again to open the next one in line. This allowed us to increase our productivity in a noticeable way.
Years later, the tool became a huge internal web application. It helped GitHub Support grow from 2 to 100 people, and serve their customers for more than 7 years.
Fast forward to today. After 9 years at GitHub, it is time for me to move on. Last Friday (Aug 9th, 2019) was my last day at the company.
My colleagues prepared a farewell video. They mentioned anecdotes from all these years. Some, I had completely forgotten. It’s funny how you are not always aware of the impact you have on people. Not until they remind you, when you leave an organization.
Here are a few highlights from my time at GitHub:
- Did and shaped support for many years.
- Started what became our internal support tool for years to come.
- Helped grow the Support team from 2 people to more than 100.
- Contributed to github.com, the product.
- Became a manager when GitHub first introduced management.
- Pitched the idea for creating a Support Engineering team.
- Became the Director of that team.
My time at GitHub was the best period in my professional life. I have learned so many things and contributed a lot. I have met wonderful colleagues and learned from them. As a manager, I had the honor to influence lives in a positive way. I also discovered my teams liked my management style. That motivated me to keep on growing and learning.
Why are you leaving GitHub though? You may ask. Are you ungrateful? Others would go to extremes to get a job at this company!
It’s not that I don’t like the company. It’s not that I am not grateful. It’s not that I couldn’t have stayed and worked on many more things for the years to come. This decision was not easy.
I twitted recently that GitHub has spoiled me. If I ever left, it would have been for
- building my own company,
- be a freelancer again,
- or leave the industry and open a food truck.
Can you guess what I am doing? I am building a new company!
I want to recreate and expand the working conditions I loved all these years at GitHub. To do that, I need to be able to control the whole thing. This is my opportunity to build a company based on Basecamp and GitHub’s values. Sure, I wasn’t able to land that job at 37signals, but this is my chance to create a similar company myself.
What are you building though? You may be curious to know.
My personal mission is helping people have calm and simple working conditions. My experience for the past 9 years has been around support, management, and projects. I decided to take advantage of my experience, combine it with my mission and build a new support tool with the help of Ilias, my friend and business partner.
Yet another support tool you may ask? Aren’t there plenty out there? There is not anything like what we have in mind.
We want to make a difference. Support teams can be one of the most overworked teams in organizations out there. We want to help them be calm, maintain their human voice, and have happy customers.
We want to help companies provide better support. Keep their support engineers longer. Help them grow and accumulate more knowledge. Avoid burnout, and through better support, keep and grow their customer base.
Can you do all that with a support tool? You may wonder.
It’s not the tool itself. The tool helps you avoid mistakes. It’s the whole philosophy behind and around it. We want to create an opinionated tool. A tool that will help Support and Engineering teams work better together. What we offer is not for everyone. An organization would have to want to invest in calm working conditions. They would want to have happy support teams, and happy customers.
That’s what helped us support millions of customers over the years. That’s what I hope, will help you support millions of customers for the years to come through our new service.
I am very excited about this new adventure. Leaving GitHub is not easy, but my vision is a place where people all over the world enjoy their work every day. I can only help create that place through my own company. In the grant scheme of things, leaving GitHub is not a big deal. Who will remember you in 100 years?
Would you like to read more about our new company and the tool we are building? We’ve created heavymelon.blog. That’s where we are going to blog about our philosophy, the company, and the tools we build. We’ve already published our first post there where we talk about this new effort.
There are two basic ways you can help us:
1) Share
If you like what we are working on, please spread the word. Share this article on Twitter, LinkedIn, your network and elsewhere. That by itself is a great way to help us.
2) Subscribe and help shape the tool
You may be curious about the tool itself. You may be working in Support. You may be leading a Support team. You may be looking to replace your existing system.
We’d love to talk to you about it.
We’d love to give you the chance to shape future calm teams. Please send your email address to us, and we’ll get in touch. We never spam or give your personal information to third parties.
Here is to 9 more years of awesomeness!