Q&A: life as an Engineer at Alan

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

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.

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.

Alan has a non-hierarchical organisation that is based on two dimensions: communities and crews.

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.

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:

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”.

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:

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.

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 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.

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...)

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.

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.

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:

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!

Of course 😉. We have also changed our remote policy, our company is now “work from anywhere”. So we welcome remote work.

See you around! 👋