For most of my career, I didn’t want to become a manager.
That wasn’t because I had anything against management. I simply really enjoyed being a Solutions Consultant. I liked sitting across from customers, understanding what they were trying to solve, challenging requirements that didn’t quite make sense, building a technical approach and then demonstrating that approach directly. I liked walking into a meeting with an unclear problem and leaving with something concrete. Most of all, I liked the feedback loop. You knew quite quickly whether what you were doing worked. A customer understood the value or they didn’t. A demo landed or it didn’t. A technical objection was resolved or you went back and figured out why. There was something very satisfying about being close to both the problem and the reaction to your solution.
I also never saw management as the inevitable next step for a successful individual contributor. I don’t think it should be. Being very good at Solutions Consulting doesn’t automatically mean you should eventually stop doing it and manage Solutions Consultants instead. For years, I was perfectly happy becoming better at the craft itself. Better discovery. Better demos. Better understanding of the technology. Bigger customers, more complicated environments and more strategic sales cycles. I wanted to become a better Solutions Consultant, not escape being one.
My CV today describes more than 20 years in technical pre-sales and solutions engineering. By the time I seriously started thinking about management, I had spent the better part of two decades playing variations of the same game. I don’t mean that negatively. It was a game I genuinely loved. But if you’ve ever spent hundreds of hours playing a computer game you really enjoy, you’ll probably recognise the point I eventually reached. At the beginning, everything is new. You are learning the controls, discovering the map and figuring out which approaches work. Later, you become better. You understand the mechanics, recognise situations faster and make fewer mistakes. Eventually, though, you reach a stage where you have explored most of the map. New challenges still appear, but increasingly they are variations of things you’ve encountered before. You can still improve, but the improvements become smaller.
That is roughly how Solutions Consulting started to feel to me. There was always another customer, another technology and another unusual requirement, so I would never claim that I had literally seen everything. But I had seen enough patterns that genuinely new situations became less frequent. After a while you recognise the shape of a difficult sales cycle surprisingly quickly. You have experienced the demo that fails five minutes before the customer joins. You have dealt with the requirement that sounds critical until discovery reveals that nobody actually needs it. You know the account where everyone wants a proof of concept even though nobody has agreed what success would look like. You have handled difficult objections, major technical escalations, large enterprises, partners, RFIs, RFPs and enough strange corner cases to know that there will always be one more.
I was still learning, but the learning curve had flattened. Getting better increasingly meant improving details rather than discovering entirely new dimensions of the job. It felt a little like continuing to level a character that was already at a very high level. You can still find another piece of equipment that gives you two percent more performance, and if you enjoy the game that’s perfectly fine. I did. But at some point I started wondering whether there was another level I hadn’t played yet.
Management Wasn’t the Endgame. It Was a New Map.
That was when I began questioning an assumption I’d held for years: that moving into management would mainly mean giving up the parts of my job I liked. I worried about losing customer contact and becoming disconnected from the actual work. I imagined calendars full of internal meetings, spreadsheets, performance reviews and conversations about budgets while everyone else got to do the interesting stuff. There is some truth in that stereotype, by the way. Your calendar definitely changes. But what I hadn’t understood was how much of my Solutions Consulting experience would remain useful, just applied to very different problems.
When the opportunity came to take on the EMEA Solutions Consulting team lead role in 2023, I decided to try it. The timing mattered. Five or ten years earlier I don’t think I would have made the same decision because I still had too much I wanted to explore as an individual contributor. At that point, however, I was ready for something that would make me a beginner again. The team lead role also gave me a useful transition because I was still operating as a Principal Solutions Consultant. I had one foot in the game I knew extremely well and another in something completely new. By January 2024 I moved into management full time, and in 2026 my scope expanded again into a Senior Manager role across EMEA and APAC.
What surprised me was that management did not feel like quitting the game. It felt like unlocking the next level of it.
The underlying world was still familiar. Customers still had problems. Sales cycles still needed technical strategy. Demos still mattered. Discovery still mattered. Product gaps, competition, qualification and relationships still mattered. I hadn’t suddenly moved into a completely different industry where twenty years of experience were irrelevant. Instead, the perspective changed. I was no longer controlling one character on the screen. Suddenly I could see more of the map, and my decisions influenced how an entire team played.
The First Trap: Picking Up the Controller Again
The dangerous thing about moving from an experienced IC into management is that you are usually quite good at the old job. Someone comes to you with a complicated opportunity and, before they’ve finished explaining it, part of your brain is already constructing the solution. You know which questions you would ask, how you would position it and what you would show. If a demo is heading in the wrong direction, your instinct is to jump in. If someone is struggling with a technical problem, taking the keyboard and fixing it yourself feels incredibly efficient.
For someone who has spent years being rewarded for solving problems, this behaviour feels natural. It also becomes one of the easiest ways to limit your team. If every difficult situation eventually results in the manager grabbing the controller, the team learns something very quickly: when the level gets difficult enough, the manager will play it for us. You may get past today’s obstacle faster, but nobody else develops the experience required to handle the next one.
This was probably one of the hardest adjustments for me. My experience was still useful, of course, but I had to learn to use it differently. Instead of immediately saying what I would do, I started trying to understand how the person in front of me was thinking. What have you tried? What do you think the customer is actually trying to achieve? What options do you see? What would happen if we did nothing? Sometimes I would still give a direct answer because coaching every single situation into a philosophical exercise would drive everyone insane. Management does not mean refusing to answer questions. But there is a fundamental difference between sharing experience when it adds value and making yourself the answer to every difficult problem.
That distinction matters because coaching initially feels less productive than fixing. If I solve something myself, the result is immediate. If I coach someone through it, the conversation takes longer and they may still make a mistake. But the return appears later. The next time the same person encounters a similar situation, they don’t need me. Eventually they start coaching someone else through it. One solved problem has turned into additional capability inside the team. Once I understood that, I started seeing management very differently.
The Feedback Loop Doesn’t Disappear. It Gets Longer.
One of the reasons I had been reluctant to leave the IC role was that immediate feedback loop. As a Solutions Consultant, you often know by the end of a meeting whether you made progress. You can read the customer. You can see how the sales team reacts. Sometimes you can almost pinpoint the moment when somebody finally understands why the solution matters. Management doesn’t usually give you that. You can spend an hour talking with someone about their development and there is no green success message at the end telling you that the conversation worked.
For a while, that was uncomfortable. There were weeks where I had been extremely busy but struggled to point at something and say, “I made that.” As an IC, I could point to the demo, the proof of concept, the technical design or the customer meeting. As a manager, some of the most valuable things I did were almost invisible. A conversation might prevent a problem several weeks later. Helping someone think through an opportunity could lead to an excellent customer meeting that I never attended. Removing an unnecessary process could save each member of the team a few hours every month without anybody outside the team ever knowing why things suddenly became easier.
The feedback loop was still there. It was just longer and less direct. Eventually I started noticing different signals. Someone handled a difficult situation without escalating it. A person who had previously been nervous presenting to executives started leading those conversations confidently. A new hire became productive. Somebody challenged my thinking because they had developed enough confidence to disagree with me. A team member got promoted. Those became the new achievements, and something interesting happened: I found them at least as satisfying as delivering a great demo myself.
That is when the role really clicked for me. I hadn’t lost the feedback loop I enjoyed. I had changed what I was measuring.
One-on-Ones Are Where You Discover the Side Quests
There are some parts of management that look terribly mundane from the outside. One-on-ones were one of them for me. Suddenly my calendar was full of recurring meetings and I wondered whether we were all going to spend so much time discussing work that nobody would have time left to actually do any. It took me a while to understand that a good one-on-one isn’t a smaller version of a team meeting and it certainly isn’t a status update. I can get opportunity status from Salesforce. I don’t need thirty minutes with someone to ask which deals are closing this month.
The interesting conversations usually start one or two questions below the status update. What is taking more energy than it should? Which salesperson are you struggling to work with and why? What do you want to learn next? Which part of your job would you happily never do again? Is there something we’re doing as a team that makes no sense to you? Is there something I am doing that makes your job more difficult? Those questions expose the things that dashboards rarely show. Sometimes the biggest obstacle to someone’s performance isn’t missing technical knowledge. It might be a broken process, an unclear expectation, lack of confidence, a relationship problem or simply too much work.
I also learned that development doesn’t always mean giving someone another challenge. Managers love stretch assignments. They sound positive and proactive. But if someone already has a full inventory, handing them another quest isn’t necessarily development. Sometimes the best thing I can do is remove something. Can we automate this report? Why does this meeting exist? Does every SC really need to perform this administrative task? Are we using highly skilled technical people to solve a problem that should be fixed in the process instead?
That was another change in perspective. As an IC, if a process was annoying, I usually found a workaround and continued playing. As a manager, repeated friction became something I was responsible for addressing. If five people are independently working around the same bad process every week, the cleverest workaround is not necessarily the solution. Fixing the underlying mechanic is.
The Same Customers, but a Much Larger Map
Moving into management didn’t remove me from Sales. It changed the altitude from which I looked at it. As an individual contributor, my natural unit of thinking was the opportunity. What does this customer need? What do we need to prove? Who are we competing against? What could prevent the deal from moving forward? Those questions don’t disappear as a manager, but other questions become just as important. Are we bringing Solutions Consulting into opportunities at the right stage? Are we spending time on the right deals? Where does technical discovery repeatedly fail? Which product gaps appear across multiple customers? Where are we creating work that has little influence on an outcome?
Instead of only playing the individual level, you begin looking at how the levels are designed. That naturally pulls you into closer relationships with Sales leadership, Product, Customer Success, Marketing, Enablement and Operations because many of the problems your team experiences cannot be solved inside Solutions Consulting. A sales leader might see an urgent customer request while the SC sees a poorly qualified opportunity. Product might see a single feature request while SCs working across a region recognise the same request appearing in several strategic accounts. Customer Success may be dealing with a problem whose root cause goes all the way back to expectations created during the sales process.
This was another area where my years as an individual contributor turned out to be enormously valuable. Solutions Consultants already spend their lives translating. We translate business problems into technical requirements, product capabilities into business outcomes and technical limitations into language customers can work with. Management uses the same skill, except that a surprising amount of the translating now happens internally. Different departments aren’t necessarily disagreeing because one of them is wrong. Quite often they’re simply looking at the same situation through different windows.
Metrics Are the HUD, Not the Game
Another area I became much more interested in as a manager was data. As an individual contributor, I had a very detailed understanding of my own work. I knew which opportunities were complicated, where I was spending my time and which customers needed attention. Once you’re managing a team, and particularly once your scope covers multiple countries and eventually regions, intuition becomes increasingly unreliable. You simply cannot have the same depth of context on everything.
That is where metrics become useful, but I think it’s also where management can go badly wrong. Measuring the number of demos someone delivers does not tell you whether those demos were useful. A high activity number can mean a highly productive team, or it can mean a team spending enormous amounts of time on badly qualified opportunities. Win rates, proof-of-concept outcomes, workload, opportunity coverage and resource allocation can all provide useful signals, but none of them explains itself.
I think of metrics a little like the heads-up display in a game. Health, ammunition and the minimap give you information that helps you understand what is happening, but staring at the HUD isn’t the same thing as playing well. A metric should make you ask a better question. Why did this change? Is this a capacity problem, a qualification problem, a product problem or simply normal variation? Does the number actually measure what we think it measures? Used that way, data gives a manager visibility they otherwise couldn’t have. Used badly, it just gives micromanagement more charts.
Senior Management Unlocked Another Level
I had assumed the biggest change would be moving from IC to manager. In many ways it was, but becoming a Senior Manager and expanding from an EMEA team into a broader international organisation across EMEA and APAC introduced another layer I hadn’t fully anticipated. The same basic game was still there, but the map became much larger. Time zones matter. Markets work differently. Sales organisations develop different habits. Customer expectations differ between regions, and something that works perfectly in one team can be a poor fit for another.
At that scale, being the experienced person with all the answers becomes even less realistic. You cannot attend every important meeting or understand every opportunity in detail, and you definitely cannot be the approval stage for every meaningful decision. If everything important requires you personally, you haven’t built a strong organisation. You’ve built a bottleneck with a management title.
That made me think much more about the environment in which people work. How do we share knowledge between regions so that several teams don’t independently solve the same problem? How much consistency do we need around technical discovery, qualification and proof of concepts? How do we onboard someone so their success isn’t determined by which colleague happens to have time that week? Where should we standardise, and where should regional teams deliberately work differently?
This is the point where things like enablement, methodology, knowledge management, dashboards and operational processes become much more interesting than they probably sound. I don’t particularly enjoy process for the sake of process. Nobody needs another workflow simply because a manager discovered a new box that can be added to Salesforce. But good process removes repetitive work. It gives people a starting point instead of forcing them to rediscover everything themselves. In gaming terms, I don’t want to tell everyone exactly which path they must take through every level. I do want to make sure they don’t have to spend the first twenty minutes searching for the controller settings every time they start the game.
There Are No Walkthroughs for the Difficult Parts
The part of management that has probably taught me the most is also the part that none of my previous technical experience could completely prepare me for: people are considerably less predictable than software. There is usually no log file that explains exactly why somebody is frustrated, no configuration change that fixes motivation and no rollback button after a difficult conversation. Sometimes you make a decision with incomplete information and only discover later whether it was the right one.
This becomes particularly obvious when things aren’t going well. Leadership is relatively easy when targets are being hit, the team is stable and everyone knows what comes next. Periods of organisational change and uncertainty are different. Sometimes people want answers you genuinely don’t have. One of the lessons I have learned is that silence isn’t a substitute for certainty. You don’t have to invent an answer, and pretending to know something you don’t know usually damages trust faster than simply saying “I don’t know yet.” You can still explain what you do know, provide context, listen to people’s concerns and be clear about what happens next.
I used to think credibility came largely from knowing the answer. That makes sense in a technical IC role because a significant part of the job is expertise. As a manager, I’ve found that credibility also comes from being predictable when you don’t have the answer. Do you communicate? Do you make a decision when one is needed? Do you explain why? Do you treat people consistently? Do you change your position when new information proves the old one wrong? Those behaviours matter much more when the environment around the team is uncertain.
You Don’t Need to Respect Your Entire Character
Like many people moving into management, I read leadership books and looked at managers I respected. There is plenty to learn from both. The mistake is assuming that becoming a manager means replacing your existing personality with some generic leadership template. I tried aspects of that in the beginning and it never felt particularly convincing. There are leaders who naturally command a room, leaders who are extremely structured, leaders who are fantastic storytellers and leaders whose greatest strength is remaining calm when everyone else is running around with their hair on fire. Copying their behaviour without understanding why it works for them doesn’t automatically make it work for you.
What worked better for me was using traits I already had in a different way. I’m curious and I like understanding how things work. As an SC, that helped me understand technologies and customer environments. As a manager, it helps me ask questions rather than immediately jumping to conclusions. I enjoy getting into technical detail, although I now have to recognise when staying in that detail stops being useful. I like challenging assumptions when I think we’re solving the wrong problem, which is just as useful in an internal planning discussion as it once was during customer discovery. I also use humour quite a lot because work can be serious without every conversation needing to feel serious.
I didn’t have to abandon the character I had spent years building. I needed to learn a completely different skill tree.
What I Would Tell Someone Considering the Same Move
If you’re an experienced Solutions Consultant wondering whether management should be your next move, I don’t think the answer is automatically yes. Management isn’t a promotion from Solutions Consulting in the sense that level 20 is automatically better than level 19. They are different jobs, and there is nothing wrong with wanting to remain a deeply experienced individual contributor. If you still get energy from direct customer work, still feel challenged by the craft and still see a lot of unexplored territory ahead of you, becoming a manager simply because it looks like the expected career progression may be a terrible reason to do it.
For me, the timing mattered because I had reached a point where I wanted a steeper learning curve again. I hadn’t stopped enjoying Solutions Consulting. I had stopped being surprised by it as often. Management changed that immediately. Suddenly I had to learn coaching, hiring, performance management, organisational design, capacity planning, executive communication and how to lead people through situations where there was no technically correct answer. Then, just as some of those things started becoming familiar, taking on a larger international scope opened another set of problems.
And that, more than the title, is probably why I still enjoy the move. It gave me the feeling of being a beginner again without throwing away everything I had learned before. Nearly every difficult situation I experienced as an individual contributor is still useful to me. I understand what it feels like when an SC is dropped into an opportunity too late. I know the pressure of presenting to a room where the outcome matters. I know how frustrating poor discovery can be, how much preparation a good demo requires and why an apparently small internal process can become painful when you repeat it across dozens of customer engagements. The experience from the previous level came with me.
What changed is what I’m trying to optimise. Earlier in my career, I wanted to become better at delivering the work myself. Later, I wanted to help individual people become better at it. Today, I spend much more time thinking about how to create an organisation where talented people can succeed without success depending on one particular person, one manager, one country or somebody making a heroic effort every time something gets difficult.
I still enjoy being in front of customers. I still like technical conversations, and I still have fairly strong opinions about what makes a good demo. I don’t think that part ever completely disappears after you’ve done the job for that long. But watching someone on my team handle a complicated customer situation brilliantly without needing me has become every bit as satisfying as doing it myself used to be.
For most of my career, I thought moving into management meant leaving the game I enjoyed playing.
It turned out I had simply unlocked the next level.
