Nitsan Seniak: “Technology for technology's sake has never interested me”

He helped build a product that became a business worth 200 million dollars in ARR, led teams of 200 people, went through an acquisition by IBM, entrepreneurial failure, bailiffs, layoffs, and infrastructure capable of absorbing 600,000 events per second. At every stage, Nitsan Seniak came back to the same conviction: technology only has value when it solves a problem for someone. An idea that shapes his view of management, hiring, and artificial intelligence today.

As a child, Nitsan Seniak did not yet own a computer.

Yet he had already decided he would become a developer.

The first machine he ever saw was in a university lab. The father of a classmate, a researcher, gave them a tour. Nitsan watched the adults type on a keyboard and receive a response from the machine. He stood frozen in front of the screen.

He wanted to understand.

Back then, a personal computer was expensive. He saved up for several years. While waiting to be able to buy one, he got hold of a programming manual and wrote code on paper. Thousands of lines that he patiently copied into notebooks, without being able to run them or check that they worked.

The day he finally received his computer, he typed it all in.

Almost nothing worked.

That memory could sum up much of his career. Build, test, get it wrong, understand, start again. Not out of some abstract love of technique, but to see an idea become real.

"Technology for technology's sake has never interested me. What drives me is solving problems for people."

The machines have changed. So have the languages. But that conviction has not moved.

Creating something that reaches other people

As a teenager, Nitsan sold his first piece of software. A program designed to produce electronic music, bought by a small Parisian publisher.

The amount was modest. The effect, far less so.

For the first time, the code he had written left his bedroom. Someone else was going to use it.

He then studied computer science all the way to a PhD, convinced that research was the pinnacle of the discipline. He discovered fascinating subjects there, but also an environment that suited him poorly.

What bothered him was not the intellectual difficulty. It was the competition between individuals.

Nitsan realized he had no desire to build alone against others. He needed cooperation, shared goals, a team.

Competition between companies motivates him. Internal politics, far less.

So he left research after his thesis and joined ILOG, one of the few French technology companies of that era. The company worked in particular on expert systems, an early form of artificial intelligence based not on learning but on sets of rules capable of reproducing certain human lines of reasoning.

He joined ILOG as a developer.

What he learned there, above all, was how to become a manager.

His first management mistake

A few years after arriving, Nitsan took charge of a small team tasked with turning a technology engine into a real commercial product.

The product worked. It found its market. The team grew.

Then it grew some more.

Nitsan gradually found himself leading 70 people. He structured responsibilities, organized processes, clarified working methods. On paper, everything was clean.

On the human side, far less so.

He was so focused on the product, the organization, and efficiency that he did not see demotivation setting in. He did not take enough time to understand what the members of his team wanted to learn, what worried them, or what gave meaning to their work.

The organization worked. The team did not.

"I was completely obsessed with organizing the team well and having the right processes. I wasn't doing the human side of management. It blew up in my face."

A consultant then helped him approach the subject differently. To listen before structuring. To treat individual aspirations as a component of the work, not as a distraction.

That mistake would become one of his main reference points.

Management is not about fitting people into a perfect organization. It is about creating a framework in which they can work well together.

The product developed by his team contributed to ILOG's growth, and then to its acquisition by IBM. Nitsan stayed on to support his colleagues through the integration. He soon led an international organization of around 200 people, spread across several countries.

There he discovered that, beyond cultural differences, the fundamental expectations change very little.

People want to be respected. They want to understand what is expected of them. They want some form of autonomy. They want to be able to do their job without being treated, by default, as people who need to be watched.

IBM allowed him to discover how a global organization operates, with teams spread across several countries and coordination challenges at a very large scale.

That experience also helped him pin down the kind of environment in which he thrives best.

In an organization of that size, the various layers of management can sometimes drift away from the product and from the teams' day-to-day work. Nitsan then understood that he prefers more direct structures, where trust flows easily and where everyone stays close to the shared problem to solve.

Technology is still there. But for him, it only makes sense if it stays connected to the people who build it and use it.

A good product is not enough

After IBM, Nitsan wanted to take the adventure all the way. He founded a company with two former colleagues.

They built a solid product. Technically, it worked. It provided a genuine service. But almost no one knew about it.

The company never found its market.

Nitsan then discovered a truth that seems obvious once you've understood it: building a good product and knowing how to distribute it are two different jobs.

"If no one knows about it, it's pointless. Acquisition is a job in its own right. And it's very hard."

The two other partners eventually left. Nitsan carried on alone for six months, more out of stubbornness than conviction. Then he stopped.

The failure was painful, but still legible. The product had not found its audience. Mistakes had been made. He could analyze them.

The next experience was more brutal.

In a second entrepreneurial venture, the promised funding did not arrive properly in the French subsidiary he ran. Salaries were paid irregularly. Contractors and social charges went unpaid.

One day, bailiffs knocked on the door of his home.

Nitsan tried to protect his family, kept part of his troubles to himself, and somatized. He would eventually leave the company and, several years later, recover the wages he was owed.

But the damage cannot be reduced to a sum of money.

He had just understood that trust never removes the need to verify. A partner's words, his self-assurance, or his supposed track record are no substitute for a genuine checking of the facts.

After several difficult projects, doubt set in.

"I asked myself whether I hadn't become bad at this. Maybe everything I'd succeeded at before was just luck."

That doubt is less spectacular than a bankruptcy or a visit from bailiffs. Yet it runs deeper. It no longer concerns a project. It concerns his own ability to build.

Hiring to create a culture, not to fill an org chart

When he joined Iziwork, Nitsan was looking for a project ambitious enough to prove to himself that he could still succeed.

The company wanted to digitize the temp work market. It had significant resources and had to build its platform quickly. Nitsan arrived among the first technical hires and made an immediate choice: he would not write code.

Not because he no longer loved it.

Because he knew he could not be both the first developer and the person responsible for building a large-scale team.

In a year and a half, he hired around 70 people.

That period transformed his view of hiring. Until then, he had recruited occasionally. Now he had to create a system capable of quickly identifying the people who could work together over the long term.

His first filter was not technical.

It was values.

For Nitsan, a team does not become high-performing simply because it brings together the best specialists. It works when its members share the same way of thinking about work, responsibility, and the product.

He looks for developers who care about the end user. People capable of going beyond their own scope. Profiles who do not consider a task finished the moment the code has been written.

Technical level remains essential. But it does not make up for a deep incompatibility in ways of working.

A skill can improve. An opposing conception of collective responsibility creates permanent friction.

So Nitsan formalizes the values he is looking for and prepares questions capable of surfacing real behaviors. He does not want to hear a candidate explain that they value teamwork. He wants to understand what they do when an incident occurs, when a colleague makes a mistake, or when a product decision does not match their technical preference.

Hiring for values does not mean hiring carbon copies.

It means building a common foundation solid enough to allow disagreement.

This approach may explain why several developers followed him from one company to another. Some had joined his teams as interns. Years later, they agreed to work with him again.

They knew his standards.

But they also knew that he would protect them.

The invisible role of the CTO

At Iziwork, Nitsan measured concretely what it means to protect a team.

As the company grew, expectations multiplied. You had to move fast, structure, hire, and maintain a high level of standards. In that context, his role was not only to organize technical output.

He also had to preserve a coherent working framework despite that pressure.

This meant very concrete decisions: defending a team member when he felt a judgment was unfair, resisting metrics that would oversimplify the reality of the developers' work, or preventing pressure from mechanically trickling down into the team.

It is a rarely visible function of the CTO.

Translating, protecting, absorbing part of the pressure, and deciding what must not travel any further down.

For four years, Nitsan stayed because he was proud of the product built, the team created, and the people he had convinced to join him.

That experience taught him that a CTO is not only responsible for the technology. They are also responsible for the framework in which it gets built.

And that trust between founders, managers, and teams remains an essential condition for lasting.

Finding founders capable of trusting

When a headhunter suggested he meet the founders of MEE6, the role did not really exist.

The company was actually looking for a product profile. Yet the recruiter thought a meeting could work.

The fit was immediate.

The two founders are much younger than Nitsan. That creates no difficulty. They are ambitious without trying to hide what they don't know. They understand technology, value his experience, and do not see pressure as a management tool.

Above all, trust flows both ways.

After his previous experiences, that had become his main criterion.

MEE6 was launched very early in Discord's history. The bot is profitable, widely adopted, and carried by a still small team. During the Covid period, Discord usage accelerated sharply. The founders decided to structure a real company and hired Nitsan to support that scaling.

He reproduced what he had learned at Iziwork and quickly hired around twenty developers.

Then growth slowed.

The Covid effect faded. Discord grew more slowly. Competition increased. The company's costs had grown in anticipation of a trajectory that did not materialize.

Three waves of layoffs followed.

Nitsan had to let go of people he had himself convinced to come, some of whom had been part of his network for years.

He does not try to present this period as a success. Laying people off remains a painful experience. But the way it's done matters.

The reasons are laid out clearly. The departure terms are negotiated to be as fair as possible. The economic decision is not turned into a personal judgment.

A company can be forced to reduce its team without stripping the departing people of their dignity.

600,000 events per second, and a small team to absorb them

Behind its apparent simplicity, MEE6 operates at a considerable scale.

The bot is present in millions of communities. Every interaction on Discord can generate an event. At peak activity, the infrastructure has to absorb around 600,000 of them per second.

The challenge is not only to process that volume.

It has to be done quickly, reliably, and at a sustainable cost. Endlessly adding servers would solve part of the technical problem while destroying the economic equation.

When he arrived, incidents were frequent. Two or three times a week, the service could degrade or go down. The team fixed things in a rush, sometimes in the evening or on weekends.

At that frequency, maintenance ends up consuming all the capacity for creation.

Nitsan and his team then strengthened the platform's observability. They collected more signals, identified degradations before they became critical, and automated part of the responses.

The goal is not to produce the most elegant architecture.

It is to allow a small team to maintain a massive platform without spending their lives putting out fires.

Once again, technology remains a means. The real measure of success is human: fewer nighttime alerts, less burnout, and more time devoted to the product.

Going back to code to become useful again

After the various headcount reductions, the technical team was down to just a few experienced people.

Nitsan went to see the founders.

He had been hired to build and manage a growing organization. He was no longer hiring. He had almost nothing left to manage. He offered to leave.

They preferred that he stay. The company was still looking for new growth levers and might need him if it took off again.

Nitsan accepted, on one implicit condition: to regain immediate usefulness.

He started coding again.

This return was nothing like a nostalgic gesture. He was not trying to prove he could still write a function or fix a bug. He came back to code because it was now the place where he could contribute most directly.

And because he still loves it.

The timing is particular. After years away from day-to-day development, he rediscovered the craft precisely as artificial intelligence began to transform it.

First with autocomplete. Then with assistants capable of understanding a request, modifying several files, and producing entire portions of a feature.

Had he remained a CTO entirely detached from code, he would have watched this revolution through articles, conferences, or feedback from his teams.

By practicing it himself, he understands its strengths, its limits, and its concrete consequences.

Why the best developers can resist AI

One of the paradoxes Nitsan has observed is that the most experienced developers are not always the first to adopt these tools.

They have good reasons.

A senior developer has built, over the years, a way of working that lets them perform. They know their tools, their shortcuts, their methods. Every new technological promise also represents a risk of losing time, degrading quality, or replacing a mastered system with a gadget imposed by management.

That caution can look like conservatism. It is often the product of experience.

To convince them, Nitsan believes in neither speeches nor mandates.

He experiments. He demonstrates. He creates an element of surprise by quickly completing a task that would previously have taken far longer.

Adoption comes when developers see a real improvement in their own work.

Not when an executive tells them to use more AI.

He is especially wary of companies that turn the use of these tools into individual metrics: number of requests, volume of tokens consumed, or budget spent.

As soon as a measure becomes a target, it often stops measuring what it was meant to represent. An employee can artificially inflate their AI consumption without working better or learning anything at all.

What you get then is visible compliance, not transformation.

The point is not for developers to use AI.

The point is for them to discover the situations in which it lets them build better.

AI reveals what developers really love

For Nitsan, the arrival of artificial intelligence makes the distinction between two profiles even more important.

There are developers passionate about crafting the technology itself: writing code, solving an algorithmic challenge, designing an elegant architecture.

And those who see code as the means to bring a product into existence.

Both approaches can produce excellent engineers. But they do not react to AI in the same way.

For the first profile, the assistant can feel like a competitor. It takes over part of the work that provided exactly the pleasure.

For the second, it becomes a multiplier. It shortens the distance between an idea and its availability to users.

Nitsan clearly belongs to that second category.

He does not miss writing every line himself. What he loves is seeing the product move forward.

Code has always seemed to him like the closest thing to a superpower: a few instructions are enough to create a system capable of acting in the world. With AI, he says, that power is multiplied.

This shift will also change the structure of teams.

A company designed from the start around assistants, automation, and new development practices will probably be able to accomplish with three people what once required a team of thirty.

This does not mean the disappearance of developers.

It shifts where their value lies.

Tomorrow's developer will need to understand more than code

AI already knows how to quickly produce plausible code. It is less good at understanding why a feature should exist, what economic constraints it must respect, or how it fits into the whole of a product.

It can respond correctly to a request that was poorly formulated.

It can build something logical, yet contrary to the real objective.

The developer's role therefore shifts toward context, architecture, intent, and arbitration.

For Nitsan, the most valuable profiles will be those who understand the whole chain: the technical side, but also the product, the design, the user experience, and the business.

Not to replace every specialist.

To be able to give the AI the right context, evaluate its work, and connect a technical decision to a larger objective.

He recommends that senior developers experiment without setting limits too quickly. That they hand the tools tasks they may still think impossible. That they accept failure in order to discover exactly where the boundary lies.

He also invites people to rethink products themselves.

Adding an assistant to existing software is not enough. New entrants capable of designing an experience entirely organized around AI will be able to challenge incumbents that merely graft a few generative features onto their interfaces.

An ATS, for example, would no longer necessarily be conceived first as a succession of pages, buttons, and forms. It could start with a conversation capable of cross-referencing information from recruiting, emails, and the company's other tools.

The graphical interface would remain useful.

But it would no longer necessarily be the center of the product.

Building remains a collective adventure

Nitsan Seniak is now looking for a project early enough to let him use the full breadth of his experience.

Coding at the beginning. Laying the foundations. Understanding the product. Then supporting its growth and structuring the team when the need arises.

He is no longer looking for a title for himself.

He is looking for a context in which he can be useful.

The project will need to place technology at the heart of its value. It will also need to be led by founders with whom trust can exist both ways.

The rest is secondary.

Since his first lines of code, the technologies have changed.

The languages have changed.

The architectures have changed.

Artificial intelligence has arrived.

But one thing has stayed the same.

Behind every line of code, there are women and men who choose to build together.

And that, perhaps, is the true role of a CTO.

Article written from the interview conducted by Bluecoders with Nitsan Seniak on June 12, 2026.