This newsletter is sponsored by CodeWalnut.
“AI bloat is slowing down our code reviews.”
“You can’t trust AI-raised PRs.”
“My developers have become agent babysitters.”
If any of this resonates with you, don’t miss this masterclass.
In 90 minutes, you’ll get an insider view of how to build a software factory. Lauren Tan shipped 2,000 PRs last month. It’s your turn next.
Thanks to CodeWalnut for sponsoring this newsletter. Let’s get back to today’s thought!
Intro
My book The Multiplier Mindset published by O’Reilly has recently been released, and has also been a #1 Bestseller (or close to) on Amazon for the past 3 weeks.
In the part 2 of the book, I feature 8 case studies of successful multipliers (tech leads, engineering managers, staff engineers, and architects), looking at:
How they multiply others
What makes them successful
How they use AI
Their advice to engineers and engineering leaders to thrive in the AI era
Today, I am sharing the case study of Simone van Buuren, Staff Engineer at Neko, which is included in the book. At the time I was talking with her about her work, she was a Staff Engineer at Pleo.
This is an article for paid subscribers, and here is the full index:
- What Simone van Buuren Does?
- How Van Buuren Succeeds In Her Role
- How She Multiplies Others
🔒 How She Leverages AI
🔒 Her Advice For Engineers
🔒 Last words
Let’s start!
What Simone van Buuren Does?
The staff engineer role means different things in different organizations. While Simone van Buuren still spends a lot of time writing code and working hands-on, a large part of her role is technical leadership and shaping the company’s technical vision.
She influences technical direction across multiple teams, builds relationships, identifies initiatives that should move forward, and coordinates work across the organization.
She acts as a point of contact for other engineers, helps unblock projects, and creates alignment between teams. She also emphasizes the need to be a multiplier.
“Sitting in your ivory tower architecting things,” she says, isn’t the only way to help:
A lot of my work is building relationships and identifying where initiatives can be driven forward. It’s cool that I take ownership, but it takes a village. So how do I identify my other villages?
A lot of my work is that as well. I often act as the point of contact for other staff engineers and other teams who have initiatives or drives that they want to spread across the company.
She usually works on multiple projects simultaneously. One project involves automating the operations team’s manual email workflows.
While this initiative appears simple on the surface, it introduces a new technology that could benefit the entire company.
A senior engineer officially leads the implementation, while van Buuren supports the logistical and strategic aspects. Her larger goal is to establish this technology as part of the company’s “golden path.”
Another project focuses on defining service level objectives (SLOs). This initiative involves engineers, product managers, customer success managers, and operations teams.
They work together to define what matters, how to measure it, and how to track success.
How Van Buuren Succeeds In Her Role
Building relationships and understanding how to influence people is critical, van Buuren says.
Learning from failure
She also stresses the importance of learning from failure.
“I have failed a lot. Like, I have, yes, deleted the production database. Not in recent years, but I’ve had that stress.”
She’s worked on projects that customers disliked and made significant mistakes. The important part, she says, is the learning.
Being pragmatic, open-minded, and curious
Those experiences of failure taught her pragmatism: how to balance the desire for elegant engineering with the practical realities of business needs and risk management.
She also believes in holding strong opinions loosely. She welcomes challenges to her thinking, and she is comfortable saying “I don’t know” when she lacks knowledge. Her true superpower, van Buuren says, is her focus on the details.
Van Buuren also credits her “continuous curiosity” as a major factor in her success.
“You need to genuinely have a vested interest in the things that you work on. Being a little bit of a geek really has its benefits in this world.”
How She Multiplies Others
She particularly enjoys helping others grow and succeed. This is how she does that.
Understanding each engineer’s goals and interests
The first thing she does is understand how each individual works, what they want from their career, and where they currently are. Once she understands those things, she can help them grow in ways that align with their interests.
For example, one midlevel engineer on her team is highly ambitious and customer-focused but not particularly interested in architecture or design systems.
However, he is fascinated by AI and fast feedback loops. So instead of forcing traditional technical projects on him, she gives him opportunities to experiment with AI tooling and automation.
And in general, she tries to find opportunities that match both each engineer’s goals and the team’s needs.
Beyond projects, she encourages people to do the following:
Present to wider engineering audiences
Give demos
Write internal and external blog posts
Develop their communication skills
Analyzing and preventing edge cases
Van Buuren is especially drawn to failure scenarios and edge cases. While many people focus on happy paths, she focuses on system failures and how to prevent them: retry mechanisms, data consistency, failure handling, preventing duplicates, and worst-case scenarios.
“I have a positive view of people, but a very pessimistic view of computers and the stuff that we shove into them,” she says.
She’s often the person others come to when they need to figure something out, when “there’s a bug or an incident and you need to just dig, dig, dig, dig, dig.” Debugging complex issues and finding root causes is what she is best at.
Reviewing and learning from others’ work
Another big part of van Buuren’s role is reviewing other people’s work across architecture and ADRs, design, and code, all of which she enjoys.
She realized early in her career that “some companies use code review as a gatekeeping mechanism, and other companies use it as an async learning mechanism.”
She strongly prefers the latter, noting that, for her, this learning-centered thinking has “propagated its way up into designing the systems, designing the architecture.”
She appreciates collaborative feedback. “Instead of sitting in isolation, you get everyone on board and make them poke some holes in your theories. That’s really valuable.”