Mutuelles et captives d'assurance : offrez l'expérience Alan à vos adhérents. Découvrir
Nos guides RH
Notre sélection d'articlesQu’est-ce qu’une mutuelle d’entreprise ?La mutuelle est-elle obligatoire ?Tous nos articles sur l’assurance santé
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?
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.
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.
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
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”.
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.
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.
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.
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:
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.
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! 👋