• Medium

Free online content available in this course.


Got it!

Last updated on 4/30/19

Tech Team

Log in or subscribe for free to enjoy all this course has to offer!

As expected in a startup like ours, we do have a Tech team. ūü§ď

Because "software is eating the world" as they say, Tech has an important role here at OpenClassrooms. However, crafting good software is difficult (we've learnt this the hard way over the years). It is as much a science as it is an art.

What does the Tech team look like? Are they a bunch of¬†Red Bull swigging geeks who used to¬†program rocket software in school assembly and hack¬†NSA servers in under¬†an hour? Which software do they use and what are their habits? Let's¬†find out... ūüēĶ


The Tech team's mission is to build the learning platform we need to provide a great education experience. To do this we need great, reliable software.

The Tech team has also a vision that guides this mission, which is to focus on core business. It means that we don't try to do everything, because it would be expensive and exhausting. We focus our efforts on the very core of our business, if there is no available offer to meet our needs.
If a solution already exists, we look for the best service, matching criteria like scalability and cost…

The Tech Team focuses on real business problems, like "Our learners get stuck on MCQs because they don't know how to validate them, we should do something". They help the whole company to deliver a great education experience.
This is important, because technical teams sometimes tend to focus on technical problems just because they look exciting. This is not what we do (but don't worry, we have our fair share of¬†interesting challenges ūüėĀ ).

Tech Stack

One question we get asked quite often is: "What's your tech stack? Do you use the latest hot languages? Did you try X.io and Y.js?".

While we're open to using new tech, we try not to use the "latest hot stuff" just because it's hot. Why? Because everything moves very fast and could become obsolete quickly, especially in the frontend world. We need a good reason to add another language to the tech stack.

That being said, we use:

  • PHP: one of the most used web programming languages in the world, powering the likes of Wikipedia and Facebook, to name just two.

  • Symfony framework: it would be crazy not to use a strong framework like Symfony on top of PHP these days. It facilitates a lot our work: we don't have to reinvent the wheel every time.

  • PostgreSQL: this has been¬†our database of choice to store our data for many years.

  • LESS: as a CSS preprocessor.

  • jQuery and jQuery UI: you have heard of them, haven't you? ūüė∂

  • React.js: to provide¬†a more cohesive code and a better frontend experience to our users.

  • Amazon Web Services: we're hosted on AWS. We use EC2 instances that we spawn automatically depending on traffic (we have some in-house code for this), S3 for object storage, RDS for databases, etc.

We also rely on many third-party services, more on that later.


Approximately 15‚ÄĆ people work in the Tech¬†team. The roles should¬†not be a surprise for those who've met tech teams before. ūüėČ

  • Backend developers: they work on the backend code, crafting PHP code on top of the Symfony framework. They create the¬†inner workings of our systems, which are crucial to deliver the software. They¬†regularly mumble things about "code coverage", "design patterns" and "broken builds".

  • Frontend developers: they craft HTML, CSS and JS code to build the frontend pages. They constantly optimize page size and speed. Some say a kitten dies each time someone uploads an unoptimized JPEG file to the servers. ūüôÄ

  • Mobile developers: at the time of¬†writing, we're just¬†starting to build our mobile apps, starting with iOS.

  • QA managers: their mission is to ensure the project's quality by testing it through every angle from a user point of view. They write tests that can be automatically repeated. Previously this job was done by Pierre, our co-founder, but now it's being taken care of by more specialized people.

  • Designers: our¬†UI and UX designers¬†work upstream on each tech project, to refine our needs, provide mockups, test them with users and then design the page before handing it to developers. You can hear them talk about "personas", "alignment" and "golden ratios", while wondering why everyone talks about flat design these days now that we can easily use round corners and shadows with CSS.

The Tech Team also has¬†some interns,¬†working in¬†frontend or backend. We¬†get requested quite often for internships and tend to select¬†those who have an interesting story to tell, who can show some personal projects, etc. ūüėČ

Culturally, the team is very open. Yes, we emphasize on excellence, but that shouldn't scare you to talk to or join to them! You don't need to certify that you've been geeking around since the age of 9. ūü§ď
In fact, that's quite the opposite. We like to be around with people with a lot of potential. Several developers come from a different background, like creative arts or sound engineering for instance.

Who's The Boss?

The Tech Team has a CTO (Chief Technical Officer), Romain, who happens to be one of our developers and has been in the company for many years. The CTO is in charge of the product's planning and ensuring everything's running smoothly.

That being said, the Tech Team has developed its own cultural habits when it comes to team collaboration, emphasizing trust and responsibility. Their influence with the rest of OpenClassrooms is important, as their strong experience in agile project management appeals to many people.

The one thing you have to remember here is that the CTO codes everyday. We like everyone to be very hands-on here and the CTO is no exclusion.

Decisions are made quickly and efficiently by the team. The CTO animates meetings, where discussions rarely last very long. People agree on a course of action: even if it's not perfect, as long as it seems like a good decision, we go for it. This is how we avoid analysis paralysis.
If required, the CTO can make a decision if he feels like we're going round in circles.


The Tech Team is a bit like a clock when it comes to meetings: they are well defined, regular and as short and efficient as possible.

They work in a two-week sprint framework: it's a well-defined period in which the team delivers one small iteration of the product.

So, what are those meetings?

  • Stand up meetings: every day at 9.45 am sharp, the team meets in the kitchen. In turn, members of the team state what they did¬†yesterday, what they're going to do today, whether they're stuck and if they need help. This is not to check that everyone's working (we trust this is the default here at OpenClassrooms) but to help the team stay in touch with what's happening. We've found these meetings¬†very useful to make small adjustments through the development process. Our former intern Erik wrote about stand up meetings at OpenClassrooms¬†if you want to know more.

  • Planning time:¬†every 2 weeks, the team looks at the backlog (the big never ending pile of tasks to do), analyzes priorities and decides what needs to be done for the next 2 weeks. Each task is analyzed: we estimate how long it will take and if something needs to be done before. If a task takes more than 2 days, it is considered "too big" and will be broken down into smaller tasks.

  • Retros:¬†every 2 weeks, members of the team write down what they've found¬†helpful for doing¬†their job, what was not helpful and what traps they expect. This is how they¬†continuously enhance how¬†they work. Feelings are shared in these meetings and people try to find solutions they can easily implement over the next 2 weeks. People are mindful to keep their egos at bay to avoid tensions... and it works quite well! Consider this conversation that happened during one of those meetings:
    - "Hey X, you've been impossible to live with, always checking what I was doing, I was constantly interrupted."
    - "OK, I get it, I'll try to minimize interruptions from now on. I'll regroup my remarks on your code at the end of each day, if that works for you."

The Tech Team usually doesn't have impromptu meetings during the day. When they have other meetings, it's because they need to talk with a developer from another company to build an integration, or because they're interviewing someone who applied for a job in the team.

What Agility Means To Us

The Tech Team is inspired by the agile manifesto. We used to follow a stricter SCRUM methodology in the past, but we have learnt to develop our own methodology, which suits us more. This way, we're closer to the agile principles (SCRUM is just an implementation of agile principles anyway).

What does it mean to be agile? It's a spirit. We prioritize individuals and interactions over processes and tools, working software over comprehensive documentation. We continuously respond to change, because building a three-year plan just doesn't work in our environment: there's too much uncertainty and evolution.

We have three pillars:

  • Excellence: we aim for excellence in our craft and we mean it. The reason is simple: the resulting software is better, more reliable... and we're just happier when we do great work. ūüėÉ

  • Sacrifice: people in the team are willing to sacrifice for the others. Not literally, don't panic! It means that whenever¬†you have¬†a problem,¬†you should hear someone check out and say: "Hey, is there anything I can help you with?"¬†(even if¬†this person already has his¬†own set of problems). In other words: we're not selfish!

  • Continuous improvement: we're not perfect, we're just getting better everyday. We know it takes many little efforts to make a great product. We don't¬†try¬†to make¬†everything¬†perfect immediately, but we do our best and we are confident that we'll be¬†back to enhance it. We¬†follow¬†the boy scout rule: "Try and leave this world a little better than you found it". This applies to nature, but also to code. ūüĆĪ

Technically, the code should facilitate change, because specs will evolve over time (we use to say that change here is the only constant!).

Our Development Practices

We have implemented many development best practices, including:

  • Automatic staging deployment

  • Code reviews

  • Continuous deployment

  • Continuous integration

  • Pair programming

  • Test driven development

  • 100% test code coverage

We deploy several times a day, sometimes several times an hour. As soon as some code is ready and has been validated (both by another developer for code review and by a QA manager for user testing), it's launched into production. ūüöÄ
This helps us add features bit by bit, instead of rolling out enormous changes that can have a big impact. The more lines of code you deploy at the same time, the riskier it is!

We're inspired by the work of Robert C. "Uncle Bob" Martin (be sure to check out his Clean Code videos!), Martin Fowler, Kent Beck and many others.

If you've never seen an Uncle Bob video, do it NOW!
If you've never seen an Uncle Bob video, do it now!

We have set up a complete clean architecture, which is a bit complicated,¬†but rewarding: it helps us ship very high quality code. While we're not competing to be the best, we do look for excellence as we've said (which looks¬†kinda the same, but with a subtle difference). We¬†were happy to hear from an external auditor that ours was one of the best codes he has seen in all the companies he has audited (not bragging, but we'll put our sunglasses smiley here anyway ūüėé ).

How Do We Get Stuff Done?

Like in any company, the Tech Team gets many requests. More than they can handle, actually. From our experience, that will always be the case: crafting good software is harder than asking for many features. This is why we focus on the core business (and leave the rest to other services) and why prioritization is an important topic to us.

Requests come from everywhere, internally (other teams) and externally (customers, partners...). Internally, we create requests on JIRA (our project management platform) for small bugs and requests.

When it's a bigger feature though, it gets discussed with our CTO. It might enter our roadmap for the coming months:

Our Roadmap
Our Roadmap (just a sneak peek!)

A typical feature follows these steps:

Our feature creation process
Our feature creation process

The feature is really being built when UX starts working on it. They imagine what it could look like, ask users and create the first rough mockups. It's crucial because this is where we decide what's going in the feature or not.

When we know, we can create the UI. Then the feature is created as a ticket in JIRA to be handled by developers. It enters the famous "backlog" (our never ending big pile of stuff to do). As soon as we have available developers, it enters the next 2 weeks sprint in which the task follows these steps:

A ticket journey through a sprint
A ticket journey through a sprint (when "Developers build the feature")

What do these steps mean?

  1. To Do: the task has to be done this sprint. Someone will pick it up.

  2. In Progress: the task is being developed (picture someone with a screwdriver¬†ūüõ† ).

  3. To Review: another developer has to check the code to validate it.

  4. To Translate: someone has to ensure the application is fully translated if there are new strings (in French and English).

  5. To Verify: QA has to check the whole feature from a user point of view. Does it react as expected?

  6. Verified: the feature is fully validated and is ready to go live.

  7. Done: the feature is live in production! Hooray, it made it! ūüôĆ

Application stack

We rely on several services to help us in our work. Here are the most important of them.


JIRA is our project management tool of choice. It hosts all our tasks (this is where the never ending backlog is). This is where you'll find the work you have to do as a developer. We use a Kanban view to show our progress throughout the sprints (from "To Do" to "Done").

JIRA shows what has to be done, what is being done and what's already done!
JIRA shows what has to be done, what is being done and what's already done


GitHub hosts our code. As you might have guessed, we use Git as our version control tool. We use GitHub to create pull requests, which is an important part of our code reviews. A pull request is when a developer wants to merge his code with the main codebase.

GitHub hosts our code. This is also where new code gets validated before going live.
GitHub hosts our code. This is also where new code gets validated before going live.


OneSky is our translation app. We use it to internationalize OpenClassrooms: each string used by the app is available here for translation, usually by someone else in the team.

OneSky helps us to easily translate the website interface strings
OneSky helps us to easily translate the website interface strings


Segment is our data router. Everytime a user updates his data or makes a significant event (like "subscribes to a course"), it goes through this router which then sends the information to several other services we use, like Amplitude (data analysis), Customer.io (marketing automation), Zendesk (support), Google Analytics, etc. We code events once, and they're sent everywhere we need them. This is how the support team knows that this person is a Premium Solo user, or how the Education Team can check which course has more usage.

Monitoring and quality

We rely on these services to monitor our code and overall quality:

  • New Relic: to monitor our servers' performance and watch for unexpected congestion¬†problems. We have put a TV next to the Tech Team, which¬†shows New Relic's OpenClassrooms dashboard¬†in real time. This way, we can quickly react if anything goes wrong (hint: 99% of the time, it's after some code deployment ūü§ď ).

  • Atatus: to monitor the app from a user standpoint and detect JavaScript errors.

  • Travis: ¬†for continuous integration. It runs all our unit tests to check the code¬†works as expected. If a build is broken, it is shown in¬†the GitHub pull request. No one will ever make a code review for you if your build is broken!

  • SensioLabsInsight: to monitor our code quality.

  • Coveralls.io: to monitor our code coverage (did we write enough tests for all¬†these¬†lines of code?).

  • Blackfire: to test our code¬†performance (how much time and memory does this function take?).

A TV showing servers performance with New Relic for the Tech Team
A TV showing servers' performance with New Relic for the Tech Team

Other building blocks

We use many services to help us build the platform. Remember that we focus on core business? Of course, it would be fun to create our own search engine, chat platform or payment gateway, but other people do this very well already.

So here are a few of them: we use Zuora (subscription management), Adyen (payment gateway), Layer (chat), Algolia (search), Mailgun (mail router), Frontdesk (appointment system for mentors)...

Phew! There's a lot of stuff going on! ūüėĶ


Stand up meetings

We already say that stand up meetings are part of the daily routine. The team has developed a curious cultural habit: because these meetings only work when everyone is here, we ask people to be available at 9:45am sharp for this meeting. Each time someone shows up late, they get a cross. 3 crosses and you'll have to bring breakfast (usually, we like chouquettes) to the rest of the team. ūüėč

Does it seem stressful? It really shouldn't be! It's just a way the team has found to ensure cohesion to start the day. Everyone participates, and even the CTO gets his own crosses sometimes. ūüėČ

Chouquettes. More Chouquettes.

Originally, people brought chouquettes when they've been late several times for stand up meetings. But now, even if no one showed up late for the last stand up meeting, people in the Tech Team are used to bring chouquettes often in the office for breakfast.

If you don't know chouquettes, they're French pastries with a little sugar on top. They're also very addictive.

Hi, I'm a chouquette. Eat me!
Hi, I'm a chouquette. Eat me!
Example of certificate of achievement
Example of certificate of achievement