Q&A: life as an Engineer at Alan
When we speak with engineers outside of Alan, we often get the same questions around our organization and our way of interacting within the company. Basically, what is the day to day job of an Engineer at Alan like?
So we decided to let two of our engineers — Alexandre Gerlic and Rémy-Christophe Schermesser — give you a direct answer to these questions.
What does it mean to be an engineer at Alan?
Everyone is a Tech Lead
Alan engineers have a large role. They’re not just handed specs — they work with the product team on the discovery and definition steps and have ownership of the development and release. Because of our strong notion of ownership, engineers of all levels of seniority are expected to define their plan for the week themselves, in coordination with their teammates. This also means that we don’t have “Tech Leads”. Each of us is a Tech Lead of a part of our stack. We expect senior engineers to have a broader scope, but there is no upper bound: a junior engineer can own a large scope!
As we are all tech leads, it is our responsibility to propose technical changes and improvements, and as with any change in the company we do so in written form.
Scope
Engineers are also specialists that are disguised as generalists. We require every engineer to at least be able to solve small problems in the frontend/backend/data/infrastructure. That being said, people are free to gravitate towards projects on the part of the stack they feel the most comfortable with.
How are you organized?
Communities & Crews
Alan has a non-hierarchical organization that is based on two dimensions: communities and crews.
- A community is a group of Alaners from the same discipline, sharing a similar expertise and set of responsibilities.
- A crew is a group of Alaners working together towards a common objective for a limited period of time.
An Alaner can be in one and only one community. An Alaner can be in multiple crews at the same time, but most of us are in only one. When a crew is started, it has a set of objectives using the OKR methodology. Then, the Alaner responsible for this crew, the Crew Lead, requests people from different communities to achieve the objectives. It can be product designers, product managers, engineers, insurance experts, etc.
Crew organization
Some crews don’t need engineers, like the “sales — large companies” crew.
Each crew is the owner of the way its members are organized. Alan offers a “standard” organization format. We believe that each crew is different, so their needs and organization might be different! In general a crew is composed of:
- One Crew Lead
- Four engineers
- One Product Manager
- One Product Designer
- And any other useful role. It could be Care (our support team), Sales, Data, Operations, etc.
Even if Alaners are part of a crew, it is their responsibility to know what to work on. We also push engineers to split their work in 80/20: 80% on “crew work”, 20% on “non crew work”.
How do you plan your OKR/roadmap?
At Alan, we use the notion of appetite, inspired by Basecamp. Instead of estimating how much time and resources an initiative will take, we ask ourselves how much we want to spend on it.
Every quarter, we run a 3-step roadmapping exercise:
- Product managers, engineers, and designers share customers’ problems and company opportunities. Based on that input, we determine our company’s appetite: how much we want to spend on those problems.
- Based on the company appetite, we create what we call product crews: the best group of Alaners (product, engineers, designers, data referents, …) with the right set of skills to tackle the problem. Their first task would be shaping their own objectives for the quarter.
- Then, each crew shares its goals, resolves possible dependencies with other crews, and sets the metrics for each goal before starting to work on it.
Here is an example of our 2020 Q3 road-mapping timeline.
After each road-mapping process, we run a retrospective meeting in order to improve the process and learn from it.
Do you have engineering managers?
Managers at Alan
If by engineering manager you mean someone leading the technical impact of a team and nurturing the personal growth of its members, then no, we don’t have that role at Alan.
Within the engineering community, we have split those responsibilities between three roles: engineers, crew leads, and coaches.
- Engineers: all of our engineers are also tech leads and are responsible for driving engineering excellence at Alan. If they think something should be changed, they take ownership and open a Github issue to move forward.
- Crew Leads: a Crew Lead is responsible for organizing the crew to deliver on-time high-quality work. They are also part-time “regular” Engineers. They still code!
- Coaches: a coach is responsible for nurturing personal growth. Coaching time is aimed at helping mentees realise their potential and define the next steps of their career path by conducting regular 1:1 meetings and leading mentees’ performance reviews. It is an activity Alan employees perform alongside their regular job, not a full time position.
Engineers can become Crew Leads and/or coaches after 3 months at Alan. They can also move from Crew Lead to another role and back every 3 months if they want to change their focus.
How do you deal with career progression?
There is just 1 track: software engineer. We’ve described it here.
We use career levels from C0 (lowest) to G (and above). You can get promoted if you are performing at the target level already. A promotion committee meets 2 times a year after the reviews.
Your level impacts only your salary and equity, not what you can do (leading a crew, becoming a coach…).
What is your tech stack?
Keep it simple
We believe in straightforward and simple engineering. Our tech stack also follows those principles. We have three layers in our architecture: a frontend, a backend, and a database.
Tools
Our frontends are in Javascript, React/Redux for web, and React-Native/Redux for our mobile applications. We also have some Typescript, mainly for our design system. Our backend is in Python/Flask. We use SQLAlchemy as our ORM. Our database is PostgreSQL. We also use Redis as a messaging system. We are deployed on Heroku/AWS. All of our code is in one mono-repository, and we deploy one application, so no microservices here.
We have a CI/CD built with Github Actions. The CI runs the myriad of tests we have, both for backend and frontend. We don’t have full integration tests, where we test both the front and back at the same time.
We like to be straightforward and simple. That doesn’t mean we aren’t open to new solutions/technologies. When engineers want to introduce a new technology, they open a written discussion about it; it’s like any decision making we do.
How do you share knowledge among engineers?
Every decision is written
All decisions are discussed in Github issues. It makes it easy to understand why, how, and when we’ve made changes.
On a daily basis, we do code reviews for each pull-request. In addition to manually picking reviewers, a bot randomly selects one; this helps to share the knowledge within the engineering community.
We also share a weekly Engineering Gazette to share tips as well as keep the community updated on changes, discussions, and decisions.
Every month we run tech talks where engineers can share a specific topic with the community. Recent examples include React hooks and SQL injections, and we regularly invite external speakers to those talks.
What are your current tech/product challenges?
We released a blog post on that topic a few months ago. We are also working on a new blog post which will be published soon!
Are you hiring?
Of course 😉. We have also changed our remote policy, our company is now “work from anywhere”. So we welcome remote work.
See you around! 👋
