What does the engineering culture look like at Algolia?
3.4K+ developers have started their personal blogs on Hashnode in the last one month.
Write in Markdown · Publish articles on custom domain · Gain readership on day zero · Automatic GitHub backup and more
Algolia's culture is defined by five core values: Grit, Trust, Care, Candor and Humility. Those are owned by the company as a whole (not just engineering) and we explained them in this detailed article on Medium.
Initially this list of values was not formal, and our main way to approach work was based on ownership: own it and ship it. This is still our way of thinking today, along with having our values as guiding principles.
By using Algolia’s own history I will detail how our engineering culture looks like today and how we got here.
When I joined Algolia (a hosted search API) in February 2015, we were seven engineers (including CTO and VP of Engineering) out of 11 employees. Today we are 50 engineers out of 140 employees.
Algolia was a flat organization (we said it aloud and meant it) with no middle management: we wanted new engineers to be managers of one. With that much freedom, new projects were spawning monthly, and the majority was successful. This worked well until we reached a size of ~30 engineers.
Things then started to be tricky to handle, most importantly:
- Since we did not recognized leaders officially (via a title for example), nobody was taking decisions on heavily debated topics
- No official teams made it harder to understand who was responsible for what, and newcomers were confused by the blurry organization
- Many projects were solo-work and thus failed at scaling or knowledge sharing, and therefore not as successful as they could have been
- Many decisions, hiring work and projects ended up on our VP of Engineering’s shoulders. And he was already stretched people-wise: having to handle 30 one on ones while keeping the head in product development and all the projects was tough
- Employees sometimes felt left out by not being able to more regularly talk about their aspirations and need for recognition, with a mentor for example
Algolia was and still is an amazing place to work; issues like this are shared by most hyper-growth startups, where every six months or so we have to revisit and iterate on the way we work and organize.
Right about that time, teams started to take shape naturally: the more engineers worked on similar projects, the more they looked like teams. Leaders were also standing out more given what they had accomplished or how they were helping others achieve more. Still, without any common agreement and statement, the overall organization felt blurry.
This is where we started discussing our engineering organization and culture closely. Taking ideas from experienced tech startups with the same kind of hyper growth as us (Spotify and Facebook), we built Squads.
Squads are Algolia’s engineering teams. Each squad has one technical product manager and one technical leader, and handles one or multiple projects. There’s no predefined process on how they work: it’s their own decision. Some have weekly meetings in the office, some have asynchronous daily standups using Standuply, and yet others have a simple #team-log channel where they drop what they are working on right now.
Squads meet regularly to ensure that technical and organizational roadblocks are not getting in their way. Every squad member has managerial and operational one-on-ones every week or two with their squad leader. In the one-on-ones, squad leaders will ensure that people are feeling safe at work, communicating well, achieving their goals and growing inside the company.
Every quarter, each squad is asked to draw a roadmap on what they want to achieve in the next three months. This can be a hard task because it forces us to revisit what we are working on, but we found it to be absolutely crucial. This is also a time where we follow all the feedback we got from our team of success engineers, our users via GitHub and Stack Overflow, and our support.
The whole engineering organization does a one day off-site every quarter. Our focus: share knowledge, think about how to contribute to company goals, and have fun. Some squads also started organizing their own off-sites (or hack days), which works for team building.
What we improved over time is how we onboard new engineers. The choice of new equipment (typically a Macbook and a phone) ensures that they have the best tools to work efficiently and enjoyably. We now ensure that each squad plans a detailed onboarding plan for their new team members (along with the company onboarding). Those onboarding missions will include a short project where new engineers will be able to commit and push to production in their first week. Then there are bigger, quarter project involving deeper API design and thinking. This is really key for new hires: we want them to feel involved and welcome at work from day one.
Another challenge we faced is that, after two or three years spent in a company, even when they are generally happy, people need to have a clear view of their career path. Engineers wanted to know how they were performing in more detail and what kind of career decisions they could take at Algolia. Ultimately, we built a clear career framework where we define:
- the kind of engineering track they want to pursue at Algolia: individual contributor or leadership contributor
- different levels for each track (intern, junior, experienced…), detailing every aspect of the level so that you can identify yourself in one level and see how to reach the next one
Moving through levels may sound like a simple gamification of our workplace, but reaching new levels require hard work and is based on facts and shipped projects (rather than perhaps on popularity in the office or long working hours)
Today’s Algolia engineering culture hasn’t changed that much: we are working on an awesome product and we are free to start and choose projects to work on (as long as they benefit Algolia’s growth). What changed is how we consider and tackle projects. We think more long term rather than quick wins, and we ensure that team's objectives are well defined and driven by product needs.
Last but not the least, we tried to implement the least amount of organizational changes and we avoid office politics in our engineering culture. Our way of doing product engineering is focused on the same principles as when Algolia started: solving problems and building a great product.
If you read this far, feel free to visit our careers page!