Driving innovation through engineering intrapreneurship
A preview from the CTO Forum that will take place at VivaTech on June 17
This article was written in collaboration with Scaleway and originally posted on their Blog.
Scaleway is hosting its first-ever CTO Forum at VivaTech on June 17. A place dedicated to engineering, with 60+ CTOs, VPs Engineering, open source maintainers & up-and-coming developer tool founders to discuss evolving technical, organization, and employee experience challenges.
I am looking forward to speak at the event and meet tech leaders from France so that I can learn from the community and share some insights about Teads.
Implementing bottom-up innovation through intrapreneurship
One of my main goals at Teads is to support structured bottom-up innovation. Namely driving our organic tech growth while ensuring that we are not losing our innovation DNA along the way. That means pursuing innovation and shipping products while onboarding new developers and dealing with business priorities of the competitive Ad Tech market — which is a delicate balance. I’m working on making it all work cohesively.
We have an interview process that includes a culture-fit interview. We have an onboarding process to help newcomers understand our culture. We clearly define who are the people responsible, accountable, consulted and informed for the projects. We also have a process to define missions and visions for each team.
Intrapreneurship within the company is key to driving innovation. It is one of our core values. Our software engineers are driven by taking on projects and leading them from start to finish. So I strive to organize and optimize how we achieve that to ensure that our engineering team can express themselves in a structured way for the company. And as we grew, the question became: how to continue to innovate on a scale of 190 people?
The importance of prioritizing the work
One strategy that directly impacted our organic growth and helped us scale is task prioritization. Great engineers want to make an impact. Task prioritization and establishing a vision that is likely to make a great impact will be key in making them successful.
Aligning company priorities that we can cascade to different feature teams is important so they can assess in autonomy how to best contribute to it. We do it before hiring new engineers so that our focus is on the execution of those priorities. So we took the time to define those priorities, choose projects for us to work on, then hire accordingly for those teams — not the other way round. When several teams are hiring, we define the team that fits the best candidates at the end of the process.
It can be demoralizing for a team to work on a project that doesn’t go to completion, does not have a business impact or simply doesn’t work. Sometimes success is the result of multiple cycles of failures and learnings so it is also the role of leadership to help the teams to continue until success is found. In the same way, when a team works on a project that brings growth, they are more stimulated. It’s a virtuous circle. So we consider it our role as leaders to make sure we feed great projects that are more likely to be successful to the most relevant teams, by spending time evaluating and prioritizing. And it’s up to product managers to analyze the market, the competition and work with engineering leaders to give engineers a great structure to work and be free on.
We did this by leveraging autonomy: we organize teams by features aligned with business priorities in engineering. We call those teams “extended feature teams”. Each team has a manager, software engineers who are autonomous from infrastructure to application development, a product manager, a business sponsor and a salesperson who is the voice of a key client or someone representing supply. So all factors and perspectives are represented while building on an idea. We regularly synchronize with team members who aren’t on the technical side, so we have fast feedback iteration during development.
Innovation to the unknown?
Innovation consists of making bets. It doesn’t always find its market fit. To minimize that, we are helped by our product teams, who do a big chunk of the upstream research on the industry’s evolution.
They give us a direction on where the industry is going and how we should transform ourselves. They express priorities, shape roadmaps and the most relevant team to answer them will find responses and deliver iteratively.
We avoid projects with too far off a deadline. Instead, we work with quick market insight. We need to be able to differentiate ourselves early on to facilitate adoption, so iteration is based on accurate data that will allow a product to thrive. We have a global footprint with offices in 31 markets and we count on local beta tests and feedback to efficiently explore new areas and iterate on the product functionalities to provide more value. We also have a dedicated strategic sales team working hand-in-hand with the most prestigious brands on the planet to understand opportunities by collecting direct feedback & needs.
Launching a project from an extended feature team
Another important element for us: our engineers make more than 40 releases to production every day and extended feature teams launch new products as you would do in a startup. Teams are encouraged to try, learn and adapt. The time to evaluate whether a new product or project is interesting, or how it should be conducted, should not be rushed. Once we find the answer to a problem — i.e. how we will make our product — we then industrialize and integrate the new project into the global chain.
We try to work on a smaller scale to start developing a new product and deliver incremental value.
When we start developing a new product, we always define an owner and give the tool for that person to execute the project from start to finish. This helps with project ownership, which is deeply ingrained in our culture. People interested in joining us need autonomy the same way we need autonomous people. Our entrepreneurial spirit starts in the hiring process; we detect autonomy, and what drives someone.
Autonomy and freedom… within a scope
To make all that work — namely giving autonomy and freedom to propose projects — we need to guarantee a structure whereby each and every one of us understands its scope, i.e. its vision and its mission.
We also built and bought a few internal tools that allow for productive autonomy. And we automated our infrastructure to enable any developers to push proof of concept easily. We have transversal teams called “core teams” dedicated to that, in support. If we aren’t mutualizing, we’ll spend our time rebuilding what already exists.
I am looking forward to meeting the tech community at the CTO Forum, come join us!
