Engineering Culture

Working in a safe, inclusive, and challenging environment is key to unleashing creativity and innovation. All the principles that set up this environment are what constitute our company culture. Every engineer joining Tint should fully embrace this culture, and ensure it is well spread across the whole company.
This document describes in detail the principles of our engineering culture. Every section has a "TL;DR" highlighted in this paragraph to speed up your reading.

Here are the few principles that are driving our people:


Keyboard How we code

Over the years, we have established a set of best practices that guide our software development processes, and these practices have proven to be instrumental in ensuring our code stays maintainable and easy to use. One key aspect of our development culture is the adoption of functional programming, with a particular emphasis on function composition. This approach encourages developers to create small, composable functions that can be combined to build more complex features. By breaking down tasks into smaller, reusable units, our codebase becomes more modular and easier to maintain, and it also promotes code readability and reduces the likelihood of bugs.

Additionally, we place a strong emphasis on proper separation of concerns. We recognize the importance of isolating different aspects of our software, such as user interfaces, business logic, and data storage, into distinct modules. This separation not only makes our codebase more organized and understandable but also facilitates parallel development, allowing our teams to work on different parts of the system concurrently. It also ties in nicely with function composition, as functions stay focused on solving a specific problem.

Immutability is another core principle in our development culture. While we acknowledge that there are situations where mutability may be necessary, we strive to embrace immutability as much as possible. This practice not only enhances code predictability and reduces the risk of unintended side effects but also aligns with the functional programming paradigm, reinforcing our commitment to creating robust, reliable software. In cases where mutability is justified, we ensure that it is carefully controlled to maintain code integrity. Overall, these practices, including functional programming, proper separation of concerns, and a focus on immutability, serve as the foundation of our development culture, empowering our teams to deliver high-quality software solutions.

Brain Knowledge Sharing

Learning is one of the main motivations for our jobs. We all want to grow our own domains of expertise to sharpen our skills. It is when we stop learning that boredom sets up.

That's why our team leverages various ways to accelerate knowledge sharing among its members (through peer programming sessions or internal documentation), but also with the global community (via blog posts or meet-ups).

Here are several ways we're promoting knowledge sharing within the Engineering ecosystem.

Tech Intelligence

It's fine (and expected) to do some tech intelligence during working hours.
The engineering ecosystem evolves super quickly: languages change, paradigms emerge, processes are experimented with... It's hard to stay up to date on such a moving landscape.

At the same time, we expect our engineers to filter the latest trends and bring cutting-edge technologies to the team. Indeed, we need to stay up to date with the industry state of the art to keep our technological advantage and to attract new talents.

Fortunately, a lot of engineers love sharing their latest discoveries, allowing the global community to catch up. Either through blog posts or social media, there are plenty of resources to increase the engineering community's knowledge.

It's perfectly fine to do some tech intelligence during working hours. It is part of the job, and all individuals are encouraged to browse and extend their network to increase their skills.

Writing Blog Posts

Every engineer can free up two days to write a Tint blog post.
As an engineering team, we collaborate to find creative solutions to complex problems, built on top of existing design patterns and libraries. These solutions are adapted to Tint, but can also be replicated among other companies. That's why, when a solution can be repeated outside the pure Tint context, we are happy to share it with the world, through  our technical blog .

As no one is better suited to write a blog post than the one that lived a topic, every engineer can decide to write a blog post on their experimentation. Yet, we know that writing a quality blog post takes time. That's why we allow our engineers to focus on writing for two full days per post.

Being a Speaker

Engineers can expense the logistics to talk at major meet-ups around the world.
Writing a blog post is definitely useful to share our knowledge with a broader public audience. However, being able to communicate our ideas to people in person brings an extra dimension to the debate. We can expose our point of view, we can be pushed back, and iterate on it in a live discussion, making new ideas emerge for everyone.

We are a globally distributed team. Hence, we can share our knowledge from almost everywhere in the world. Tint is happy to expense all the logistics to make our team talk in local meet-ups, paying transportation (and eventually hosting if the place is too far) to let you spread the word!

Peer Programming Sessions

We encourage peer programming across the whole team to speed up knowledge sharing and unleash engineers' creativity.
There is no better way to learn than by practice. We strongly encourage peer programming sessions (both as a driver and as an observer) to share knowledge.

More junior engineers would learn a lot from these sessions. And they would also benefit from super valuable tips to boost their productivity: keyboard shortcuts, Bash magic commands, or even simplified explanations about the processes... This is why every new junior engineer has 4h of peer programming sessions every week during their first 3 months.

But peer programming also benefits more senior engineers. When facing a tricky situation, bringing several skilled minds to an issue can boost creativity and innovation to figure out the best solution to the problem.

Code Reviews

Code reviews aim to increase the code quality, but also to learn and ask questions.
Code reviews are useful to identify bugs before they reach production and to increase the overall code base quality. However, they are also an essential tool to share knowledge too.

We expect every engineer (including the junior engineers from their onboarding) to review other people's code. This way, they can learn by example, ask questions, and eventually provide a fresh mindset to find alternative solutions. Engineers are invited to ask questions during code reviews (both as an author or a reviewer), in order to increase the team's knowledge.

Unless specified, reviews given on a PR are not advice that can be ignored. Though debate is welcome, if a comment is pertinent it has to be followed, and the underlying issue has to be fixed. It is not okay to bypass a review and merge anyway.

Hack Days

Once a month, all the engineers are invited to experiment with ideas and technologies they are interested in. There is only one requirement: sharing the learnings with the team.
Every last Friday of the month, a hack day is organized for the engineering team. During this day, engineers do not work on the cycle features. Instead, they are invited to experiment with ideas or technologies that may improve the platform.

Engineers don't need to ship anything to production. Actually, even if there is nothing to show because nothing works, it's perfectly fine. The only objective of the hack day is to provide a report to answer a few questions: what did you learn? what worked? what didn't?

Keeping our hands always in the mud prevents innovation that can bring massive boosts to the product roadmap. That's why we invest so much in R&D. And, it's always fun for engineers to test their creative solutions.

Smiling Face with Smiling Eyes Engineer Growth and Satisfaction

We strongly believe that our company's success is deeply intricated with our engineers' fulfillness. Skilled and motivated engineers provide unique technical insights on our platform. Hence, ensuring engineers are happy and flourishing is one of our top priorities.

Frequent Feedback

Engineers receive frequent feedback with actionable items to improve their skills.
We are all doing our best to increase our skills and grow as individuals. However, it may be hard to know if we are on the right path, what are our biggest improvement areas, or even what we need to learn next to improve.

That's why we are accompanying our engineers by providing frequent and actionable feedback. In addition to your weekly one-to-one with your manager, the team will provide you with some regular on-the-fly private feedback (either positive or negative) to help them grow.

This feedback culture is not uni-directional. Engineers are also invited to provide feedback to their managers, to their peers, and to everyone in the company (including the CEO for instance). We are all willing to improve, and we can't fix something that we don't know.

Twice a year, a company-wide 360 review is performed for every company employee. This session brings a full overview of your work in the company, and provides super valuable high-level insights on strengths and areas of improvement of the employees, helping them to improve even further.

Joining a new company is always stressful, so, it's important to give super early feedback. Hence, every month for the first three months, new recruits receive a full 360 review of their work. It allows the new recruits to understand if they satisfy the company's expectations, moving forward more serenely, or if, on the opposite, they should get more involved to match our standards.

Growth Budget

Every engineer can expense their learning resources to help them grow.
Because the generic online courses platform doesn't necessarily meet all our engineers' growth, we also allow every engineer to expense their learning resources for their growth needs. This budget allows them to buy books, attend workshops, or even attend other online courses.

The expenses should be approved by the manager. But managers are here to help, and approving an engineer's growth expense is generally a simple formality.

Engineer Satisfaction

In addition to the traditional surveys, we have several teams dedicated to optimizing the developer experience of our platform.
Skills are nothing without motivation. Hence, this is a top priority to ensure our engineers are fulfilled in their work. Measuring satisfaction is never easy. Hence, we provide regular surveys to get some company anonymous feedback.

However, these surveys miss an important part of an engineer's job: the developer experience. Even if we also provide a developer satisfaction survey, we also rely on a set of different metrics to optimize our developer experience (eg the initial and incremental build times). Several platform pods are even dedicated to optimizing these metrics, making every engineer's work more comfortable.

Handshake Blameless Culture

Tint nurtures an environment where every mistake is a good opportunity to improve our platform. To ensure such a mindset, we need to ensure everyone is safe to speak up about all the errors they are doing. This is the core principle of the "blameless culture".

Mistakes are Part of the Quality Process

No one should be afraid of admitting their (even huge) mistakes. These are good opportunities to improve the platform, as a team.
Let's take an example with John, a freshly onboarded Site Reliability Engineer. John pushed some changes to the infrastructure. Everything goes well... until he noticed the production database has been dropped.

John does not worry about the team's reaction, as he works in a blameless culture. No one would blame him. Instead, he reaches out to the team, explaining the issue. After the mitigation of the issue (and probably the triggering of our Disaster Recovery Plan), we would identify how John was able to delete the production database. And we will all work together to add a safeguard to prevent this incident to happen again in the future.

In the end, this mistake would have improved the overall platform quality. Hence, mistakes are important in our improvement process.

Don't worry: we already have some safeguards in place to prevent this incident to happen. And we didn't even have to delete the database to set it up. Grinning Face with Smiling Eyes

Speak Up

Every voice in the company should be heard, whatever your profile.
Feel free to speak up about any thoughts that come into your mind. If you face a process issue, some team misunderstanding, or have any technical questions, don't hesitate to speak up, either in one of our company meetings or in private. Transparency is one of our company values, and we also expect you to share your thoughts on every occasion.

Even if you just arrived in the company, even if you are a more junior profile, don't hesitate to speak up with your ideas. Indeed, the idea you are bringing to the table is perhaps an axis we never thought about. That's one of the diversity outcomes: sharing innovative thoughts from different mindsets.

Of course, sometimes, you may be wrong. But that's perfectly fine. Your teammate would then explain to you why this idea can't work. This is important to share our knowledge efficiently.

Team Benevolence

We assume by default that every team member is doing their best for the company,
As a remote and international team, communication is sometimes difficult. Something that is obvious for a team member is perhaps not as clear for another one. We should assume that everyone is doing their best with the information they have.

If there is a misunderstanding, one should not reject the fault of the receiver. But instead, they should clarify the message, as there is a chance that another team member would be mistaken too.

The corollary is that if an engineer is not sure to have understood a topic, they should not hesitate to speak up and ask for clarification. Over-communication is always better than unclear ones.

Openness to Feedback

Being open to feedback is the only real way to progress.
Every engineer receives a lot of frequent feedback, either through 1:1s or through code reviews. This feedback aims to help the engineer grow. It is critical for them to learn from this feedback, and to keep them in mind in the future.

Don't forget to express your appreciation for the willingness of your teammate to provide you with this helpful information.

Gear Full Autonomy

No Micro-Management

Every engineer is empowered to work on their own task, without micro-management.
We trust every engineer to take the right decisions for their tasks. They are the closest to the ground, and they know all the constraints and requirements imposed by our platform. Hence, it doesn't make sense for managers to interfere in their decisions.

Of course, the engineers could always ask for help from other engineers, managers, the product team, or the most relevant stakeholder. And they would be happy to provide all the required support. But in the end, the engineer would have all the freedom required to work on their task.

Team Play

Engineers are invited to experiment with alternative solutions, but they should ensure their team is aligned with this exploration.
Even if there is no micro-management, we still expect our engineers to be team players. They are encouraged to explore alternative solutions or to perform technical discoveries. However, it should be in alignment with the Product Managers.

The Product Managers are responsible for their team's roadmap success. Moreover, they know precisely what the customer requirements are. Hence, they have the final word on the time and scope of these explorations.

If several teams head in different directions, we will necessarily move slower. Alignment is critical to being an efficient company. If an engineer discovers a promising way to fulfill a customer requirement, they should share it with the rest of the team. And they should keep in mind that engineers from other teams may not have the full context. Hence, they should simplify the explanations to make them accessible to everyone.

Outcome Driven

All individuals have a set of clear measurable objectives to work towards.
We are an outcome drive company. It means that all our actions should contribute to improving some metrics, that indirectly contribute to the company's goals.

The company defines some quarterly OKRs (Objective / Key Results), that are then split at the department level, and then at the individual level. It means that every engineer has a clear set of objectives to work on.

These objectives are measured thanks to actionable and measurable metrics. This way, any Tint employee has a clear view of their progress.

Palm Tree Work/Life Balance

No Overwork

Overwork is the exception, not the rule!
Being a fully remote company, we may be lost in the heat of the action. It's always tempting to work a few extra hours to finalize a feature. Having skilled and motivated people doing their best to delight our customers is one key to our company's success. However, this overwork should be restricted in time.

Even if it's acceptable in the short term, you shouldn't repeat the experience in the long run. The accumulated fatigue makes this move counter-productive. You will be less focused in the following days, committing mistakes and oversights.

Tint may require some overwork on rare occasions (due to a short deadline for instance). We are super flexible with our Engineers' time schedules, but we also expect them to be flexible whenever we need it (don't worry, it won't be often). These requested sessions will be limited to a short amount of time. And, in such cases, we encourage our Engineers to work on a lighter schedule the following days (or even to take some time off), to reduce fatigue.

Unlimited PTOs

Whenever they feel exhausted, Tint employees should take some time off and recharge their batteries!
We apply an unlimited PTO (Paid Time Off) policy. We sometimes hear the feedback that unlimited PTO often means no PTO. Indeed, in some other companies, taking some time off is frowned upon. This is not the case at Tint.

We encourage our team employees to take some paid time off. If they feel exhausted, or if they are sick, we prefer them to fully recharge their batteries. We indeed prefer working with 100% battery people 45 weeks a year than working with 30% battery people 52 weeks a year.

Of course, we trust our employees to take a reasonable amount of time off. If they plan to take three weeks off every month, that would be an issue for the company organization and the objectives they are able to deliver. We still need to ship fast high-quality features to our customers.