__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](https://www.linkedin.com/in/agerlic "LinkedIn: Alexandre Gerlic") and [Rémy-Christophe Schermesser](https://www.linkedin.com/in/r%C3%A9my-christophe-schermesser-0204834/ "LinkedIn: Rémy-Christophe Schermesser"), give you a direct answer to all those questions.__

![christina-wocintechchat-com-computer-unsplash](//images.ctfassets.net/ovjsyiqhqmlf/19doNJIEjccFQPgyVGFhbt/e1997459618225e735698a8a7aeda4b0/christina-wocintechchat-com-6bI69ihF3MI-unsplash.jpg)
Photo by Christina @ wocintechchat.com on [Unsplash](https://unsplash.com/s/photos/software-engineer?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText "Link to 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](https://blog.alan.com/bien-etre-au-travail/pour-faire-progresser-votre-equipe-donnez-lui-les-cles "Alan Blog: donnez les clés à votre équipe (in French)"), 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](https://en.wikipedia.org/wiki/OKR "Wikipedia: OKR"). 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](https://basecamp.com/shapeup/1.2-chapter-03#fixed-time-variable-scope "Basecamp: the time variable"). 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:

1. 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.
2. 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.
3. 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.

![engineer-okr-at-alan](//images.ctfassets.net/ovjsyiqhqmlf/36OOkyuFqwrT9B8DmDXszV/d3ceb02c5b4c86ee026259577a45ff40/84406231-8a1c1200-ac09-11ea-8431-654f28e70849.png) 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](https://medium.com/alan/engineering-career-path-at-alan-e5de5c2e740c "Engineering career path at Alan").

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](https://en.wikipedia.org/wiki/Object-relational_mapping "Wikipedia: 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](https://en.wikipedia.org/wiki/CI/CD "Wikipedia: 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. 

## What are your current tech/product challenges?

We released [a blog post on that topic](https://medium.com/alan/engineering-challenges-at-alan-de6f294e6dd3 "Medium: engineering challenges at Alan") a few months ago. We are also working on a new blog post which will be published soon!

## Are you hiring?

[Of course](https://angel.co/company/alan-25/jobs/222046-fullstack-software-engineer-full-remote-possible-details-in-the-description "Alan on Angelist") 😉. We have also changed our remote policy, our company is now “work from anywhere”. So we welcome remote work.

See you around! 👋


Remy-Christophe Schermesser

Q&A: life as an Engineer at Alan