From developer to partner: a career in IT services

I often hear people talk about careers as if they were a ladder. One step after another, one title after another, and in the end some kind of neat, complete meaning. Then I look at mine and I can’t help but smile, because I don’t see a ladder. I see more like a series of different rooms, each with a window onto a piece of the IT services market.

This isn’t a “motivational” story. It’s more of a notebook thing, almost an anatomy. Because in hindsight I realize that every phase left me with a different lens. And today, as I work as Head of Tech and partner in a small ICT company, those lenses are finally starting to overlap.

## The strange thing about non-linear careers

Linear careers may have never really existed, but for a while we believed in them. I definitely did. Then I found myself moving from Interface Developer at one of Europe’s largest luxury e-commerce groups (before it entered the Richemont orbit), to CTO at a deep-tech startup in oil & gas, all the way to managing a portfolio of projects that are very different from one another in a company of about ten people.

If I have to say what these stages have in common, it’s not the technology. That changes, and it changes faster than we like to admit. The common thread is something else: every role made me see *how IT services are bought and sold*. And above all, why decisions that look technical often aren’t technical at all.

## Phase 1: inside a big player, from the code side

When you’re in a large organization and you’re not in management, you risk thinking certain dynamics don’t concern you. In reality they still run right through you—you just experience them “by reflection.” I was in the code, but working in a group at that scale makes you see things that stay invisible from the outside.

For example, how the relationship with technology vendors is actually managed. Not in theory, not in the deck, but day to day. I saw that behind an architectural choice there’s often an organizational choice, a budget choice, sometimes even a power choice. And I also saw a difference that annoyed me at first, then I understood it was simply real: vendors chosen for competence and vendors chosen due to contractual inertia are not the same thing, but on paper they look identical.

The first rule I carry with me from that phase is this—and maybe it’s a bit cynical, but it feels true.

**The best vendor isn’t the one with the best proposal, it’s the one that understands how the client organization works.**

It’s a rule that’s hard to put into a framework. It’s qualitative, contextual. And it requires an understanding of internal dynamics that you often only pick up by being there, by osmosis. I still wonder today how many bids and selections fail not because the provider isn’t capable, but because they didn’t read the client’s “nervous system.”

## Phase 2: the startup, i.e., the real cost of choices

The jump to the startup was, without exaggeration, the one that changed me the most. As CTO of a deep-tech startup vertical in oil & gas, I found myself doing everything. Tech stack, hiring, processes, budget, clients, delivery. All at once, often on the same day.

And there you learn something that stays more blurred in big companies: the cost of decisions isn’t an abstract concept. It’s immediate. Every choice has a direct impact on the P&L, on time-to-market, on the team’s sustainability.

In that phase I learned to price IT services not “based on the market,” but based on the structure of real costs. Which sounds trivial until you crash into it. I also learned that a service priced too low is more dangerous than one priced too high, because sooner or later someone will pay the difference. And often the one who pays is the client, in the form of technical debt, delays, turnover, rushed patches.

Another important piece was contracts. Not the ones written to win a negotiation, but the ones that let you work. I understood that there are contracts that “protect” and contracts that “work.” The first are full of penalties no one wants to enforce. The second define aligned incentives, a collaboration zone where both parties have a reason to do the right thing.

The second rule, here, became almost a conviction.

**The quality of an IT service is decided before the project starts, in the architectural choices and in the processes the provider sets up.**

When the code starts flowing, many games have already been played. Not all of them, of course. But many.

## Phase 3: the multi-client portfolio, where boundaries blur

Today I work in a small ICT company, about ten people, that operates as a B2B technology partner. Clients range from large corporates to Public Administrations. My role is a continuous intersection of technical leadership, sprint planning, DevOps, compliance, and architecture. And above all it’s “portfolio” work, so with very different contexts living side by side.

In the same period we might be involved in a regional healthcare information system, a people analytics SaaS platform, an industrial IoT infrastructure, cybersecurity services as a certified partner of a leading vendor, regulatory compliance projects, and custom development for the PA.

This phase is the one where the two previous experiences lock together. On one side I have the memory of the big player, so I understand how enterprise clients think, what truly worries them, what the implicit constraints are. On the other I have the startup sensitivity, so I know what it means to be efficient with limited resources, and how much automation and operational discipline matter.

But the new lesson—the one I didn’t expect—is another.

**The IT services market is fragmented in ways many advisory frameworks don’t capture.**

We’re not a generalist system integrator, but we’re not an ultra-specialized boutique either. We’re that slightly awkward thing to label: an agile technology partner with cross-cutting skills. And in certain contexts we compete with players ten times larger, not because we’re “better” in absolute terms, but because processes are leaner and, more and more, because AI-assisted development is changing the relationship between productive capacity and team size.

Maybe it’s here that I realized how much the map doesn’t match the territory. In quadrants and reports some categories are crisp. In real life, much less so.

## What these phases taught me about IT sourcing

If I try to translate all this into practical implications for sourcing, three ideas come to mind—which are also three recurring “flaws” in the way providers are evaluated.

The first comes from the big company: sourcing decisions are often organizational decisions disguised as technical decisions. So whoever does advisory should understand the client’s internal dynamics as much as they understand the provider’s capabilities. Otherwise they risk recommending the “best on paper” and getting the worst in practice.

The second comes from the startup: the economics of IT services are far more granular than they appear in market reports. A provider’s margin on a single project can swing enormously based on architectural choices, the level of automation, process maturity. And if you don’t read these dynamics, you don’t truly protect the client. You only protect them formally.

The third comes from portfolio work: the real market is more diverse than frameworks suggest. The tech SMEs that serve Europe’s economic fabric often don’t show up in the quadrants, but they deliver a significant share of IT services. If you don’t know that segment, you’re offering clients an incomplete set of options. And you might not even realize it.

## The cumulative value, and why it matters now

There’s a pattern I notice in careers that produce “non-conventional” value. It’s not the single experience that makes the difference, but the intersection.

An analyst who has only worked in consulting knows the frameworks, but maybe has never lived through delivery when things go wrong. A technician who has only worked in development knows the code, but doesn’t always see the business. A manager who has only worked in corporate knows the political dynamics, but risks losing touch with real costs and operational grind.

The meaning of my trajectory, if it has one, is crossing these worlds. And it seems to me that today this ability to connect is no longer a “nice to have.” With AI entering processes, European compliance becoming increasingly stringent, pricing models changing, reshoring and new expectations around security and data sovereignty, complexity isn’t going down. It’s going up.

And when complexity goes up, simple answers start to sound suspicious.

## The next step, with a bit of honesty

Lately I feel that the natural evolution of this path is to bring this integrated perspective to those who have to make high-impact sourcing decisions.

Not as an operational consultant—that’s what I already do. Rather as a market analyst, researcher, strategic advisor. In a context where depth of operational experience and the ability to produce actionable insights are the core of the value proposition.

It’s the kind of role that some companies, with a lot of effort and a lot of investment, try to embody well.

Not because I have the right answers. On many things, honestly, I’m not even sure I have a single answer. But because I believe I have the right questions—the ones that come from having seen the IT services market from different angles. And maybe that’s exactly what’s most needed today.

*Next in the series: how the European regulatory storm is redefining the criteria for evaluating IT providers, and why the advisory market still isn’t ready.*