When we speak with engineers outside of Alan, we often get the same questions around our organisation and our way of interacting within the company. Basically, how is the day to day job of an Engineer at Alan?

So we decided to let two of our engineers, Alexandre Gerlic and Rémy-Christophe Schermesser, give you a direct answer to all those questions.

Photo by Christina @ wocintechchat.com on Unsplash

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 out specs. They work with the product on the discovery and definition steps and have ownership on 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 like any change in the company we do propose it in a 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 organised?

Communities & Crews

Alan has a non-hierarchical organisation 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 organised. Alan offers a “standard” organisation format. We believe that each crew is different, so their needs and organisation might be different! In general a crew is composed of:

One Crew Lead
Four engineers
One Product Manager
One Product Designer
And any other role useful. 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-stepped road-mapping exercise:

Product managers, engineers, and designers share customer’s 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 organising 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 to help mentees to realise their potential and define the next steps of their career path by conducting regular 1:1 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.

This impact 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 front-end, a back-end, and a database.

Tools

Our front-ends are in Javascript, React/Redux for web, React-Native/Redux for our mobile applications. We also have some Typescript, mainly for our design system. Our back-end 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 two mono-repositories, and we deploy two applications, so no microservices here.

We have a CI/CD built with CirceCI and Heroku pipelines. 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 opened 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 on 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.

Every 2 weeks we run:

An engineering retrospective to share pain points and things that work. During the latest ones, for example, we covered topics like database migration conflicts, CI slowness, etc.;
Tech talks where engineers can share a specific topic with the community, recent examples include React hooks, SQL injections and we regularly invite external speakers to those talks.