Individual impact in an engineering team
Hugo
What has been your impact in the last 6 months?
Does this question seem difficult?
Sometimes developers don't participate in shaping the product, even though tomorrow's products can't be built without the engineers who make them.
And while the reasons may vary, sometimes it's the developers themselves who step back and misunderstand the impact they can have — or how to achieve it.
The first part of an engineering career is about learning technical skills and methodologies. It's a steep hill to climb, especially since you quickly realize this work must continue for a lifetime to keep up.
But this is actually not the end of the road.
The impact you can create doesn't depend on expertise alone, even if expertise is necessary.
It's all about impact
I'm going to talk a lot about impact here. So I think it's worth grounding that word in something concrete before going any further, so it doesn't remain just a vague concept in a corner of your head.
The simplest definition would be "all the positive effects of your actions on the product or business of your company."
Ok, that's still pretty vague.
Let's take some examples:
- Cutting test execution time by 50% improves overall team productivity
- Contributing to a 10% improvement in your product's sign-up funnel conversion boosts your company's bottom line
- Regularly hosting internal talks improves team knowledge
- Proposing a technical solution that solves application performance issues, pushing PageSpeed scores above 95 and decreasing bounce rate by 20% on e-commerce pages, improves revenue
- Facilitating and/or leading a complex, multi-team technical project helps get it across the finish line
- Finding a technological solution that **unblocks **a business situation
Sometimes it's not possible to put a number on the impact, but you'll notice that I've tried very often to do so. Without numbers, it's very difficult to be objective about the impact generated. I wrote about this in another blog post.
I pay attention to these kinds of details when I look at a resume, because I find it quite telling how a person presents their past accomplishments.
Some people will write this:
- Leading a team of 10 people
- Technical lead on several new features: decision making on technical implementations
- Exchanges with external providers
- Setting up KPIs and reporting
- Roadmap planning and follow-up based on company needs
- Migration from old architecture to a new one decided in an architecture meeting
- Writing epics and user stories to feed the Kanban backlog
And others will write this:
- Improved B2B mobile app NPS (from -30 to +7) and reduced online booking no-show rate (-30%)
- Contributed to growth from €0 to €10M+ GMV
- Created the training activity within the company, which now generates 10% of revenue
If the context of the company doesn't always allow a clear vision of your impact, it still says a lot when someone can articulate it this way.
That's what we should all be looking for in the end. What is my impact? Not just what my function was in the company. Conversely, the fact that I've held a specific title before doesn't carry as much weight in my view.
Different impacts by archetype
The impact you can have as a senior doesn't take the same form for everyone. Some will be able to solve complex technical problems, others will have a knack for coordinating large initiatives, others will have a very positive impact on methods and tools.
It's common to talk about senior types, or archetypes. I like to refer to the site staffeng.com which lists 4 types of archetypes: the tech lead, the architect, the solver, the right hand. To these four I would add: the explorer and the product engineer.
Of course, these archetypes are exaggerated visions of reality, and an individual can have characteristics of several archetypes.
Let me show you examples of the impact that each of these archetypes can have.
For the first four, I invite you to refer to staffeng.com for more details.
Tech Lead
The tech lead is characterized by strong organizational and coordination skills. They can step back and find solutions to drive complex issues to resolution.
Example:
Nicolas Payot - Frontend Guild Lead at Malt
Date: 2022 Topic: Coordination of the Vue 2 to Vue 3 migration for a team of 100 people
In 2022, Malt was using several frontend technologies, including Vue.js version 2.
Nicolas is the leader of the frontend guild. A guild is a community of practice, and the lead's role is to facilitate this community in order to surface best practices and a common technological vision.
In the summer of 2022, Nicolas led a discussion about the end of support for Vue 2, scheduled for late 2023, and the need to anticipate this.
As part of this work, the tech lead created presentations and prototypes to explain the changes. Nicolas also coordinated all the work on cross-functional libraries to ensure compatibility between Vue 2 and Vue 3, enabling the smoothest possible transition once a team started migrating.
The sheer size of the codebase added to the challenge. The project involved 80k lines of code across 11 applications. A centralized approach wasn't feasible. Nicolas therefore had to work with the Tribe Directors (lead PMs) to convince them of the project's importance and get the work prioritized in product roadmaps.
Thanks to this coordination effort across a team of 100 people, the Vue 3 migration took place over 4 months with minimal disruption to team workflows.
The Architect
Architects are comfortable with solution design. They work on long-term issues, scalability, and any other problem that requires them to zoom out.
Example:
Nicolas Grisey Demengel - Staff Engineer at Malt
Date: 2020 Topic: Standardizing calls to external services
In 2020, Nicolas noticed that our web service calls were facing many problems:
- Error recovery: what to do if the call fails?
- How to handle rate limiting at the scale of a distributed system
- Message deduplication
- How to guarantee that an order has been processed despite asynchronicity or slowness of the final service
- Can we batch calls to optimize?
- How to handle a persistent error after retry without blocking a user?
Out of this work came a command queue system that is now a standard at Malt.
This work drastically improved the robustness of our systems and, above all, standardized solutions that were previously implemented inconsistently across the codebase.
Today, 40k calls per day go through this command queue for about 15 external services. The average error rate is 0.2%, but only 0.02% requires manual review — the rest is handled by the command queue's retry mechanisms. The command queue reduced to zero the error cases related to rate limiting, which used to pile up for manual handling.
If you want more details, this work has been described on the Malt blog.
The Solver
This archetype groups together people who are capable of solving complex problems. The architect works on the long term, in advance. The solver works on an existing and often urgent issue. If there's a complex problem that requires a lot of methodology and technical expertise, they're frequently called upon.
Example:
Guillaume Darmont - Principal Engineer at Enedis
Date: 2014 Topic: Long-term serialization system for business information
In 2014, a project was using a lot of inter-service communication with information exchanges in JSON. This JSON represented business entities and changed regularly as the code evolved. Each change meant deleting old data stored in the previous schema, as it was no longer compatible with the new one. This problem had to be solved before the production launch 2 months later.
Guillaume stepped in to find a durable, backward-compatible serialization method. The data had to be storable in different types of systems: column or relational databases, distributed memory cache, message broker, etc. The existing codebase and the few-week timeframe made it impossible to rewrite the existing Java business model using an Avro or Protobuf schema.
The objectives of the serialization system were:
- To integrate seamlessly into the existing codebase, without modifying the business model, so as not to slow down development
- To provide forward and backward compatibility, necessary for application versioning and long-term storage
Guillaume worked to set up:
- A binary storage protocol definition
- Components for transforming from one version of the model to another
- A server and its client, with a dedicated request/response protocol
- Various components to integrate this system into existing applications and storage layers
His work allowed the project to ship on time, and the system is still in use 8 years later for its functionality and reliability.
The Right Hand
This role isn't the easiest to understand because it's very versatile. It's only when a certain team size is reached that this person appears as a free agent, representing the technological or organizational vision. This type of person is sometimes part of what's called the CTO office. They're often a Staff or Principal Engineer.
Example:
Nicolas Martignoles - Principal Engineer at Doctolib
Date: 2022 Topic: Technology strategy at Doctolib
In 2022, Doctolib had 77 product teams, and alignment on a shared technological vision was a crucial issue.
Nicolas's role at Doctolib includes a large part of discussions with teams. He works as a Principal Engineer on clearly identified subjects — migration to Datadog, performance work on Redis, etc. — but also as a free agent with teams. I'll quote Nicolas directly here:
... I keep some time to talk to people in real life. My calendar is sometimes blocked with a 2-hour slot, which I devote to physically going to discuss and exchange with developers. My role doesn't work on authority. People have to want to come to me and have to know what I can do (or not). This is done through influence, which we build by speaking, writing, and especially by going to talk to people. There's no team of "experts" at Doctolib wisely waiting for work. It's up to us to go find the problems and to impact all of Doctolib.
What's interesting and representative of the impact of a "Right Hand" is all this important work of immersion in the teams, collecting problems to be solved, and influencing best practices — which then enables technological alignment across tens of teams.
The Explorer
This archetype is very rarely listed and sometimes confused with the Product Engineer. Charity Majors is one of the few who mentions it:
https://twitter.com/mipsytipsy/status/1057133939544846336
some are good at bootstrapping new projects
So I'm going to detail it a bit more.
The explorer is the person who explores unknown paths. This is typically the ideal person at the beginning of a startup, but not only. This person, like the Product Engineer, is characterized by their ability to prototype quickly, test, and throw things away. However, the Product Engineer is more likely to be found in an already established structure, especially in partnership with a Product Manager. The explorer is more of a free agent. They can look in directions not originally envisaged. This is also what I would call an "entrepreneur." The explorer is often not a "finisher." They regularly change subjects. They can easily shake things up, but they're also impatient and won't want to spend time shepherding the change they've initiated. This fickleness can sometimes cause frustration later on for the people who finalize the work.
Example:
Jean-Baptiste Lemée - Co-CTO at Malt
Date: 2016 Topic: The Punchout
In 2016, Malt was already working with large companies, and most of them use ERPs, especially for purchasing.
Some wanted to use their purchasing system to add the ability to pay for freelancer services on Malt. In 2016, this was a totally unknown world for us.
Jean-Baptiste worked alone on the subject to understand what was technically behind ERPs, and he studied the cXML protocol, which defines an exchange protocol theoretically compatible with all ERPs. He quickly developed a prototype to integrate an entire purchasing and contractualization flow from an ERP in punchout on Malt, and this was put into production with a live client.
This exploratory work, even though it had to be mostly redone later, gave us an enormous amount of knowledge on the subject and demonstrated that it could work with a real client.
Today, we continue to expand Punchout adoption among large companies. This has given us a real competitive advantage.
The Product Engineer
This archetype isn't detailed on the staffeng.com site, so for this one I'll refer you to Pragmatic Engineer for a detailed explanation.
This is the ideal partner for the Product Manager. They're one of the archetypes who best bridges the gap between the technical and business sides of the company. The Product Engineer shares several characteristics with the Explorer, such as the ability to identify the Minimum Viable Product to move forward quickly. But unlike the Explorer, they're able to focus on details and spend time refining a product with the Product Manager to address all open opportunities until the expected benefit is reached.
Example:
Sahbi Ktifa - Staff Engineer at Malt
Date: 2022 Topic: Development of the advance payment feature
Malt offers an advance payment feature for missions. Concretely, a freelancer uses Malt to contract on the platform and will be paid at D+5 by Malt, which handles the payment at the end of the mission through a partner.
This feature was previously used only for large clients, as the partner didn't support all types of companies.
The feature had several flaws. It had been developed several years earlier and offered no abstraction. In addition, the user workflow wasn't smooth, requiring documents to be sent for identity verification (KYC — know your customer).
By the end of 2022, the feature was handling 35% of financial flows despite these shortcomings.
Sahbi Ktifa is a tech lead on the team that handles payments at Malt. In 2022, Sahbi's team had to manage several changes.
First, the advance payment feature had to work for new countries, which wasn't possible with the existing partner. Second, in new markets, they had to be able to work with smaller companies.
As the tech lead of his team, Sahbi worked on modeling the advance payment flows to create an ideal scenario, with extension points so that new payment partners could be added as needed and all the friction from the old workflow was removed.
The work carried out increased the share of financial flows benefiting from factoring to 70%, in all open countries. Integrating a new advance payment partner now takes only 2-3 weeks.
At the end of 2022, the legacy partner unfortunately shut down. It's thanks to this work that the incident was resolved transparently. ::
Growing impact with experience
You may have noticed in my examples that not all of them have the same scale of impact.
Let's take a famous example: Kent Beck. Among his achievements, he's the author of all xUnit testing frameworks. He's also the author of the Extreme Programming method.
Indeed, we can say that Kent Beck has had a significant impact on the industry.
But does everyone need to have impact at this level? Of course not. Impact grows with seniority.
During our career, we can have successive impacts on ourselves, our team, our department, our company, and our industry.
Without trying to be exhaustive, let's take a specific example to illustrate these levels of impact.
A "chapter" or "guild" in the diagram above is a community of practice. It's, for example, the group of people interested in frontend development or security.
- Participating in the guild to learn best practices is an individual impact.
- Collecting information and making sure that these best practices are applied in your squad is a team impact.
- Actively contributing to the guild with pull requests, participating in design discussions creates impact within the guild.
- Initiating a guild, bringing people together around a theme, and providing leadership is an impact at the product department level.
- Driving guild initiatives that result in significant productivity gains or business gains (e.g., improving web performance practices and gaining SEO) has company-level impact.
- Generalizing the work done to make it a best practice outside the company has industry impact (e.g., Kent Beck with the xUnit framework).
This is one example, viewed through the lens of a guild. But as you saw above, there are multiple ways to create impact, depending on your archetypes.
Career path and impact
It's usual — or at least that's what we do at Malt — to align impact level and career path:
- Junior — Individual impact
- Senior — Team impact
- Senior — Cross-team impact (between guild and product team)
- Staff — Cross-team impact (between product team and company)
- Principal — Cross-functional impact on the company
- Distinguished/Fellow — Industry impact
However, it's important to understand that this is very contextual. Being Principal Engineer or CTO in a company of 20 people doesn't translate directly to a company of 10,000.
You have to understand this through the lens of impact.
But I won't dwell on that for now — career paths aren't the subject of this blog post.
Questions for you
What has been your impact in the last 6 months?
Can you measure it? Express it in business value?
What are the archetypes that characterize you the most?
No comments yet. Be the first to comment!