The purpose of this page is to present a state of the tech at Ovrsea: current and future projects, technical and organizational choices and desires. We believe that transparency in our projects allows candidates to choose the right tech team for them. It also allows newcomers to be a force of proposal as soon as they join Ovrsea, to better contribute and find their place in the team, for example by challenging future technical choices.

This page gathers projects of all sizes and for all levels of experience, from internship to CTO.

Role, missions and objectives of the Tech team:

The role of the tech team is to develop, maintain, improve and optimize our two products: Atlas and Hermes. It has several missions:

Team organization: Squads

The team is organized in squads. Before the beginning of each quarter, "burning problems" are defined from the OKR. These "burning problems" correspond to strategic objectives, such as improving the onboarding of customers, or the billing time.

The product managers then work in collaboration with a team to create the features that will allow them to reach the objective on the quarter.

Squads are formed at the beginning of each quarter, based on the affinity between the developers and the subject under consideration. For example, for a frontend topic, a squad with a UX designer will be formed. The squads then work independently throughout the quarter

Epics & Projects:

Within a squad, the team works in the form of Epics. Epics correspond to projects lasting one or more weeks and led by a team member.

An epic corresponds to a new feature or a large engineering improvement. The feature is first specified by the product. The tech then provides technical feedback on the feasibility of the epic, and the time needed to complete it. Epics are then prioritized among themselves.

Example of the prioritization table:

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/9a70e5f9-699d-4225-98de-a9485ba76786/Untitled.png

The smaller tickets are gathered in the batch. Each developer manages his "batch" as he wishes: a few tickets between each epic, "batch day", etc.

Each ticket or epic is developed. It then follows a classic process: