Your Instincts Stop Working the Moment Your Org Changes | Manuel Drews, Director of Engineering, Native Instruments
This week’s guest is Manuel Drews, Director of Engineering at Native Instruments, a Berlin-based company that makes software instruments and hardware controllers for musicians, producers, and DJs.
Manuel has been at Native Instruments for over sixteen years, working his way from Software Engineer to Director of Engineering. Seven years into his tenure, as Chapter Lead, he co-designed the company’s career framework for engineers, a process that shaped his thinking on what it actually takes to create the conditions for growth, not just define it.
He writes regularly on engineering leadership on LinkedIn, covering org design, career development, iterative delivery, and the structural roots of team dysfunction.
Takeaways
Career frameworks fail when they describe growth but don’t create room for it. A Staff Engineer path that requires cross-team influence means nothing if senior engineers are fully allocated to roadmap work.
Org design problems have long feedback loops. They don’t fail loudly on day one, they accumulate as coordination overhead and ownership confusion, until the structure itself becomes the bottleneck.
Leaders without an org design mindset tend to misdiagnose structural problems as people problems, and reach for solutions that can’t fix what’s actually broken.
AI speeding up implementation doesn’t speed up value delivery if discovery, decision-making, and adoption stay the same.
Yassine: You’ve written that when one engineer is consistently outpacing their peers, that’s often less a talent story and more a signal something structural hasn’t been solved. How do you actually act on that insight in the moment, when the instinct to celebrate that person is completely natural?
Manuel: My default is still to celebrate them. High performance deserves recognition, and in most cases I’ve found that these people are acting in perfectly good faith and genuinely want the project to succeed.
The key is to be mindful of what I celebrate: their dedication, ownership, mastery and technical judgment, the ability to deliver under pressure, not the individual heroics.
In the same breath, publicly, I name what wasn’t great, but without putting it on them: “This project asked far too much overtime of you, please take that time back over the next few weeks,” or “It’s on me to make sure the load is spread better next time.” That signals to the whole team how I actually want things to work, and that I own the fix.
In private, I thank them again, so they know the appreciation is real and not just a public gesture. But I also use that setting to discuss the flipside of becoming indispensable: their impact is genuine, but precisely because it’s so concentrated in one person, it’s a risk we need to address. For their sake as much as the team’s. Then I ask for their help building a plan to spread that capability, and I make executing it part of their growth and performance goals. So the work of fixing it is recognized work that helps them in their career, not an extra burden.
That way the engineer hopefully feels genuinely appreciated, and the organization learns from their success instead of quietly depending on it again the next time.
Yassine: As Chapter Lead you co-created a career framework for engineers at Native Instruments, that’s a different kind of work than managing a team or shipping a product. What did building that framework teach you about what engineers actually need to grow, that you wouldn’t have learned any other way?
Manuel: The biggest realization for me was that defining growth, complex as that already is, is still kind-of the easy part. Creating the conditions for growth is much harder.
When we sat down to discuss and align our perspectives, it became increasingly clear to me that the career framework itself is only one part of the puzzle, it can’t live in isolation. We could write down the perfect set of expectations for each level, if the day-to-day reality doesn’t allow engineers to actually meet those expectations we’d either create frustration or incentivize a ‘promotion-driven development’ culture where people chase checkboxes instead of meaningful impact.
For example, if becoming a Staff Engineer requires influencing the technical direction across teams, but the senior engineers are fully allocated to delivering roadmap work in their own teams, we’d have created a conflict of interest that pits their career goals against their team’s success.
So, my takeaway was: career growth requires opportunity, not just clarity. Engineers not only need well-defined expectations and feedback, they also need access to experiences that let them demonstrate and build those capabilities. That’s my responsibility as a leader: I need to deliberately create those opportunities, so that engineers can develop on the job, instead of squeezing growth into their evenings and weekends.
Yassine: In “The Great Scope Wars” you write that getting leadership to trust the iterative path requires “a leap of faith” from them, they give up the “comforting illusion of upfront certainty.” What do you actually give them in return? What does that conversation look like when someone above you genuinely needs to see a plan?
Manuel: First, let me clarify one thing that I didn’t bring across well in the article: I’m not against having a plan. Quite the opposite: I think every project needs a clear plan that states the goals, priorities, key trade-offs, and current assumptions. Without that, you can’t meaningfully decide on “the next most important thing”.
The key question is: what does that plan look like? Is it a Gantt chart with fixed dates, treated as a commitment? Or is it a living reflection of our current best thinking, our priorities, the risks we see, the sequence in which we intend to tackle topics, roughly how long the next steps might take, updated continuously as we learn?
When a leader asks me for a plan, the latter is what I give them.
I won’t pretend that it’s always an easy sell, nor that I’ve always been successful here. Naturally, the benefits, less overhead, lower stress, earlier validation of business value, and reduced delivery risk, only become obvious over time, while the leap of faith is required upfront. And the higher the stakes and investment, the more people want visibility into progress and confidence that the project is on track. They all need to buy into this approach. It’s also not only leaders and product managers. There are also engineers who feel deeply uncomfortable not knowing exactly what they are supposed to deliver.
It’s probably one of those things you can’t fully embrace unless you’ve experienced it. So my current best thinking is to gradually build these habits during lower-pressure periods when the perceived risk to the bottom line is low. Once the routines and habits are established and people have seen them work, it’s far easier to convince them to maintain that way of working even when the pressure picks up.
So, my goal isn’t to eliminate planning; it’s to replace the illusion of certainty with transparency, evidence, and continuous course correction.
Yassine: Most engineering execs learn delivery, people management, maybe strategy. Very few are taught to think explicitly about org design. In your experience, when does that gap start to hurt, what’s the moment where not having that muscle becomes the actual problem?
Manuel: My short answer would be “change.” It’s the moment when yesterday’s successful playbook stops working, even though nothing obvious appears broken.
As long as the environment stays relatively stable, leaders can often rely on intuition and the practices that made them successful in the past. But when the company scales rapidly, goes through a merger, or the leader moves into a new org, those instincts stop being reliable. That’s all the more true if the leader ‘grew up’ in a highly functional environment they didn’t have to shape themselves, where they inherited a structure that worked without ever having to understand why it worked.
The tricky part is that organizational problems have very long feedback loops. A structural issue rarely fails loudly on day one. Instead, it shows up gradually as more coordination overhead, slow and unclear decision-making, ownership confusion, or a general sense of friction and slowdown. Without an org-design mindset, it’s easy to conclude that the people or the processes are the problem, and the temptation to fix those symptoms with straightforward-looking ‘solutions’ is strong.
I believe that the companies in our industry are mostly full of smart, motivated people. When people like that consistently fail to collaborate well, the problem is often less them than the structure they’re working inside. And that’s when the missing org-design muscle becomes the real problem, because optimizing meetings or adding task forces will not fix that structure.
Yassine: You write a lot about the gap between how orgs say they make decisions and how they actually make them, through structure, incentives, role design. What’s the conversation you think engineering leaders at most companies are still avoiding, especially in 2026, as the industry is being disturbed significantly?
Manuel: I’ll say upfront that I don’t envy executives and senior leaders these days. The pressure they’re under must be immense, and the temptation to reach for quick, easy ‘solutions’ must be enormous. Kudos to every engineering leader who manages to resist this to some degree.
That said, there are two conversations I don’t hear nearly enough, at least in public discourse.
The first is the old ‘output-vs-outcome’ discussion. We’re spending enormous energy discussing how AI changes software development productivity and what that means for engineering orgs. But writing code is still only one step in delivering business outcomes. If AI makes implementation twice as fast while product discovery, decision-making, governance, and customer adoption stay the same, we’ve mostly just moved the bottleneck somewhere else. So for me, the strategic question we’re not asking nearly enough is: “How do we redesign our organizations to create value faster?”
The second conversation I am missing is about capability building. I absolutely believe the role of software engineers will change significantly, but I don’t think we will be removing humans from the loop anytime soon. If anything, human judgment will become more important: deciding what to build, making architectural trade-offs, navigating ambiguity, managing complexity, and deciding what constitutes good software in the age of AI.
That raises a question I’m not the first to ask, but one I rarely see tackled strategically: where will those experienced engineers come from if today’s juniors never get the chance to develop those skills? In our excitement about maximizing today’s productivity, we risk underinvesting in the development of tomorrow’s technical leaders. So, I’m less worried about AI replacing experienced engineers than I am about us accidentally stopping the process that creates them.
📚 Manuel Drews’ Go-To Resources:
3 people I follow and recommend:
John Cutler (“The beautiful Mess”) - the Systems Thinking inspiration for me. Lately he’s often a bit too abstract for my taste, but still a great source of inspiring ideas and concepts
Simon Sinek - For me one of the definitive authorities when it comes to what it means to be a leader
Johanna Rothman - lots of insights and practical ideas around true agile work management.
1 podcast I make time for:
A newsletter I rarely skip:
A book I recommend:
The book that first pushed me to seriously think about organizational design and better ways of structuring work - and has therefore had a significant influence on who I am as a leader today is “Reinventing Organizations” by Frederic Laloux.
Thank you Manuel for your time and insights!
This interview is part of the “Exec Engineering Dialog” series where I interview seasoned tech leaders on the topics of talent, product, management and culture.
If you liked the insights shared in this interview, consider giving feedback and/or sharing it with your network, it’s the best way to help this segment improve and grow.
Yassine.