My amazement report following my arrival at TheFork

Hey, my name is Pierre Brisorgueil, and I’ve been at TheFork (a forkie 🙃) for a few weeks. The article’s purpose is to explain my first impression. I write it in transparency, with possible insights, experiences, and podcasts. I was a manager in a bank and then I started a side project.

Let’s take the story step by step. 🐾

Recruitment

Process

The recruitment went well. I watched the market outside of Paris. My priority remained management, in addition to the location. Not finding my happiness and fan of development, I tried my luck on a job in Nantes.

Naturally, I was redirected to an opportunity in Paris with possible migration to Nantes. A position not opened yet with management. Everything was done to open it. A smooth experience. The quick adaptation of the company to the profile gives you trust.

For the technical part, I took a quick test, nothing too excessive. That’s the right balance. We apply at the same time to many jobs. We meet dozens of companies. Doing dozens of exercises is impossible. The practice period is here for that. A test must be fast and live.

Human

The people I met did not test me. They didn’t explain what we were going to do. Instead, we talked about a vision, a desire to co-construct and how to achieve it together.

In twenty companies, I only had this feeling at TheFork. Companies grow fast. They change, technology evolves, and none works perfectly. Selling a dream would disappoint candidates. Being honest with a willingness to improve creates trust. 👌

This is what made my decision.

Integration

Hardware / Software

On the hardware side, I had it a day before, perfect. On the macOS side, Big Sur was released in 2020, but we are on Catalina. It’s hard to keep moving, but the details matter. macOS offset -> arm offset -> Xcode offset -> iOS dev offset -> retention impacts. I am a perfectionist 🙃.

On the software side, it’s a great integration, Google Workspace, Exchange… I had access to all the tools in a week. Adding a preset of bookmarks would be interesting.

Overall, good experience, optimisable 🚀.

Human

Everyone is welcoming, accessible and ready to help. The relationships were different in the banking industry. That feels good! Just ask, and you can meet someone to get some information.

It’s cool but requires autonomy; it may not be for some people. We are left to our initiatives (Covid context). It’s a complex topic and can also be a goal of recruitment.

Exchange and mutual help are the basis of construction 💪.

Documentation

It’s the dark point. It is not maintained, challenging to find, and has no document management. Everyone uses their google docs/drive, and slides are encumbered. It’s common to every company. Documents are not shared. It’s a part of the knowledge that should not be replicated but updated. Writing culture is essential for sustainability.

A framework can prevent this problem, homogeneity and up to date templates for cooperation. I would target two solutions:

• Good documentation tools, adapted to your target
• Document management

The transformation must be started, sold, and set with a dedicated budget and time. The company will become the driving force, but it must be initialized.

Two points are crucial:

• Be adapted to our customers and accept the segmentation. No one wants to do documentation. Create a pleasant context for everyone. Your top priority is the content.
• Initialize the content to be sustainable. It must survive reorganizations, turnovers, and tools..

It’s familiar but constantly annoying for a newcomer. However, giving a global understanding of the company and its progress to all employees generates more inclusion and cohesion around OKRs.

Operation

TheFork is a B2B and a B2C. My role on the B2B side will be to assist Engineering Managers, help exchanges with the architecture side, and serve the product/customer-centric transition.

To achieve this, I wanted to create my Big Picture.

Everyone is accessible. I’m not overbooked yet. My target is to reverse engineer the organisation. Understand the structure and improvement areas: mind mapping & meeting 👌. I was managing a DataViz team, I love d3.js 🙃, after 30–40 Meetings:

I voluntarily removed the labels. This graph presents the organisation, people, skills, problems and essential topics encountered. This approach allowed me to create a BigPicture in 2 weeks.

Organisation

The organization used Agiles Features Teams. Today, it’s split into domains built on two sources of inspiration the Empowered Product Team, and Basecamp’s Shape Up. Product/engineering directors pair lead areas adapted to present topics. It’s Flexible and scalable. Domains are composed of product/engineering managers team.

It seems a good choice. I tried to draw it 🖌:

First, the Agile to Shape Up shift allows you to increase cycle times and have cooldowns. It limits loop exhaustion and will allow more step back. We can hope for a direct effect on turnover, product focus, and work quality.

Second, domain split allows devs to subject and domain change. As a dev, we end up getting bored. You have to discover new challenges and new technologies to progress. A domain can be born, evolve, and die, like any entity. We can expect an impact on scalability, adaptation, and turnover 👌.

Finally, the Products/Engineering Managers pairs concept helps to support the product transition. We create proximity between products, customers and developers.

In short, this organisation can catch in, scalability, agility, and remote work. That makes sense.

Some points of attention:

• The teams are less united because less together (agility ++)
• Loss of ownership decreases accountability and slows down decision making

Points accentuated by the Covid and remote work. It’s urgent to take them into account. These are the challenges of this organisation 💪. Fortunately, it appears that the people I met have a desire to move forward.

It’s essential to emphasise the “one team on a subject” as much as possible. By the Shape up method, teams work on subjects called “Bets” during six weeks cycles. “Bets” must have private space and generate temporary cohesion as in a hackathon. At the same time, it is necessary to accentuate a notion of subjects owners. Agility pushed to this level should not take away responsibility.

Such an agile model requires strong leadership, vital decisions to shape a common direction. You should not be afraid to step forward and test. The model is made to cash in errors 🙃.

Tech

Great approach! Teams have just switched to Aws, in microServices and TypeScript 👏. We are on an up to date alignment in terms of technology, K8S, Node, Swift, React, Postgresql, ElasticSearch … Monitoring, BI, security, and a Data pole (snowflake) etc…

Everything is there to achieve good stabilisation. Although currently in transition and carrying its technical debt. Classic but significant. Technical debt is corrosive. It has an impact on safety, productivity, and turnover. Good foundations, harmonisation and rigour must limit it.

Let’s focus on a specific subject, microservices. It’s vulgarly dividing an extensive application into several services. They are considered superior to monolithic or consumer of productivity. Recurrent debate, technical and pointless. An architecture choice doesn’t reduce the project complexity. You have to understand its advantages, disadvantages and apply it depending of the context.

The goal is always to adjust your cursor according to your needs. There is a thriving middle ground 🙃.

A little info on Microservices 🙂:

Benefits

• Modules
• Independent deployment
• Diversity of technology

Costs

• Distribution: difficult to program
• Consistency / harmonization
• Operational complexity

As mentioned, there was an organisational switch. Feature teams managing ten microservices became domains involved in 70.

Several subjects are becoming more complex expanding their costs:

• Distribution -> performance and reliability (asynchronous, debug)
• Harmonisation -> maintenance and ownership
• The customer product developer loop -> speed and productivity
• Developer experience -> productivity and turnover (CI / CD, local dev, ..)

The foundations are tested; we must measure the impact, stabilise, and consider the cost.

From birth, we’ve invented microservices for adaptability. There are layered modular architectures and packages to separate code. Accordingly, It’s possible to adjust the split as needed and as organised. The goal is to control the cost/use ratio.

Tech was born with debt, it’s one subject, and I’m not all-knowing. I have met people aware of its impact on productivity and competition ability 💪.

In short, the target and mindset are good. The desire is here. But there is a lack of structuring and decision-making with a roadmap. We usually favour creation over stabilisation. Both are linked.

Visibility is comforting 🤔. Making a mistake is not the problem but hesitating to try is. Too often, refactors remain in discussions. During this time, the experience declines and the debt increases.

Great vision, let’s go 🚀.

*PS: Tech teams are very masculine (Common and complex, but from my past experiences, gender diversity impact is significant)

Product

On the B2C side, I don’t have enough informations. On the B2B side, several companies have been bought. There are different merges. It leads to product legacy and technical debt. The purpose is to reduce them while targeting a customer centric mindset. The goal is value-added products up on the market. Be number 1.

The product discovery axis is recent. It will allow us to better understand the market by taking advantage of inputs, Customers, Sales, Trainers, Dev, Manager …

Thus, customers are in the middle of choices, but the product vision isn’t forgotten. We could speak of an excellent middle ground between customer and product-centric. It’s an already started change of culture and mindset. We need to understand all of the needs, including those that our customers may not yet know. Information aggregation will make roadmap drawing possible.

Everyone wants to move forward 🚀. But after the reorganisation, Shape Up and COVID, these are new methods. Everyone must organise themselves and find automatisms.

We must not ignore the team-building aspect in terms of bets and teams. We must formalise and trace every piece of information collected from sales, trainers and customers with the proper tools. Communication needs to be two-way at the right time. Here is the loop that I imagine:

The subject is linked to productivity and tech. Consolidate the foundations to accelerate transformation. It requires clear common goals, team responsibility, and methodologies. Everything will be refined through optimisation and automation.

Conclusion

My overall impression is excellent. Imagine a rugby match. We are on the edge of getting the try. Everyone pushes to cross the line, despite the tiredness. We lack the last burst of energy to stabilise and start the second half.

An organisation in domains, agile and scalable. Able to adapt to the need and market. It’s ideal for better coping with situations such as covid, and adapting to the talents of tomorrow (remote work, multi-country …).

I love this vision and believe it will be a successful one. But only by paying attention to details, such as alignment, cohesion. We are a modern matrix organisation with high potential. TheFork must keep its simplicity and focus on its objectives. Work should remain fun and focused on impact productivity. When achieved, progression will follow.

All of this to optimize the loop: Market => Product => Tech => Success. Iterate as efficiently as possible and give free rein to the teams’ creativity. In this way, visibility will be brought to customers and all the participants.

I translate it as the need to stabilise the foundations. Take the issues head-on, implement strategies, and unfold. The goal is not to solve everything but to learn and move forward.

A reorganisation is expensive; it must be gradually optimised. Let’s work by update, not by reset 🙂.

It was a great onBoarding. Observed points are familiar to other tech companies. I am very pleasantly surprised at the desire for co-construction 👍. Thank you to all of the people who gave me time!