Damien Soitout
A CTO title is a job with clear boundaries. Learn what the seat covers in practice: collaboration tools, diligence records, and multi-brand operations.
People hear “chief technology officer” and picture someone who evaluates gadgets, signs off on software licenses, or quietly steers every number the firm will ever produce. The title suggests a broad mandate. In practice, at least in the work I do, it covers a narrower and more ordinary set of problems: how the people who run the business share information, keep a reliable record of what they have checked, and operate more than one distinct activity without inventing a private system for each one.
I hold the title at the Foundation, alongside Richard Ohebshalom as co-founder. The useful question is not what the title sounds like, but what the seat actually touches and where it stops. If the boundary is unclear, the role becomes a catch-all. Every difficult problem that does not have an obvious owner ends up on the technology desk, not because it belongs there, but because the title is available. That is how organizations slowly lose the ability to tell who is responsible for what.
The work itself is not glamorous. It is the difference between a decision that can be reconstructed six months later and one that exists only in the memory of whoever happened to be in the room. It is the difference between a new person being able to find the current version of a file and the same person having to ask three colleagues which inbox contains the real one. Those differences compound. Over time they determine whether an organization can hand work from one person to another, or whether it must keep reassembling the same small group of people every time something needs to be understood.
The Foundation FAQ describes the role as building much of the technological stack for collaboration, diligence, and multi-brand operations. That sentence is accurate, but it is also compressed. Each of those words points to a recurring problem that appears in almost any group that has grown beyond a single team working in the same place.
Collaboration is the least technical of the three. It is simply the question of where shared work lives. Documents, decisions, access rules, and the history of what changed. When collaboration is a pile of private inboxes and personal drives, the organization does not have a shared record. It has a collection of individual memories. The person who was present can usually reconstruct what happened. Anyone else cannot. Over time the organization starts to depend on the continued presence of the same people, not because those people are uniquely skilled, but because they are the only ones who know where things are.
A usable system of collaboration does not require elaborate software. It requires that a person in one office can see what they are allowed to see, and nothing they are not, without having to ask. It requires that a decision, once made, has a place that is not someone’s email. It requires that the next person who joins the work can find the current version without a guided tour. These are ordinary standards. They are also the standards that most organizations fail to meet once they have more than a handful of people and more than one location.
Diligence is the record of a check. In the work we do, that check is often about a real-estate opportunity, a counterparty, or a document that must be true before money moves. The useful question is not whether someone looked at the material. It is whether the path the material took can be shown later: who touched it, what was still open, and what someone was willing to stand behind when the decision was made. A folder of emails is not that record. It is a collection of messages that may or may not contain the relevant facts, arranged in the order they were sent rather than the order they matter.
I have seen diligence processes that look complete until someone asks what was known on a particular Tuesday. At that point the group must reconvene, search inboxes, and reconstruct events from memory. The reconstruction is usually good enough for internal purposes and never good enough for anyone outside the group who needs to rely on it. Building the workflow so that the path can be reconstructed without a meeting is not a technical achievement. It is a refusal to treat memory as a system of record.
Multi-brand operations is the least discussed of the three and often the most consequential. The Foundation is not a single shop with a single logo. Work runs in America, Israel, and Ukraine, and the human-capital efforts sit alongside the investment work. Each of those rooms has its own clients, its own regulatory constraints, and its own operators. From the outside they should remain distinct. From the inside they should not each invent a private way to name a client, store a file, or prove that a step occurred.
If every brand develops its own dialect, the group ceases to be a group. It becomes a set of adjacent activities that share some overhead and little else. Adding a new brand then requires either forcing the new activity into an existing dialect it does not fit, or allowing it to invent its own and accepting that the next person who joins will have to learn yet another local language. The stack is the mechanism that keeps the brands legible to one another without making them identical. It is also the mechanism that makes it possible to move a person from one brand to another without a months-long apprenticeship in the private habits of the new room.
The technology seat does not price assets, and it does not decide whether a deal is worth doing. Those judgments belong to the people who will stand behind them. Storing the file is not the same as owning the decision the file supports. When the distinction collapses, two things happen. The people who should be accountable for commercial judgment begin to treat the system as a substitute for judgment, and the person responsible for the system begins to be treated as the person who “really runs” the commercial work. Neither outcome is useful.
The role is also not a running commentary on how modern the firm is. Code on a screen is a means. The test is whether a new operator can find the record, whether a diligence can be handed from one person to another without a heroic explanation, and whether a second brand can be added without creating a second chaos. A slide that says “technology” is not evidence that any of those things are true. The evidence is the week when the person who built the workflow is traveling and the work continues without a series of clarifying calls.
Richard has described the people in these roles as principals rather than employees. The word is useful because it draws a boundary in both directions. A principal is not waiting for a ticket. A principal is accountable for the quality of a function. My function is the shared tools and the records they contain. Valeriia’s function, in the Ukraine work, is the operation itself. Richard’s function includes the overall direction of the group. None of these desks absorbs the others. When a room tries to make the CTO the person who “really runs” a country operation, the room is usually tired and looking for a single throat to choke. The more useful response is to name the person who actually owns the judgment and give them the record, not to move the judgment onto the technology desk because it is convenient.
A week on the seat has a recognizable shape. Access breaks, and the question is who could see what, not whose feelings were hurt. A diligence stalls because a document has no owner; three people have each assumed someone else was tracking the open items. A brand asks for a private exception that would make the next brand harder to understand. Someone requests a number the system should not invent in order to look complete. In each case the immediate temptation is to solve the local problem as quickly as possible. The longer-term cost of that solution is usually invisible until the next person tries to use the same path.
I would rather show a blank field than a confident fiction. A blank field is an honest statement that the information is not in the system. A confident fiction is a statement that the information is present when it is not. The second is more dangerous because it trains people to trust the system in situations where the system has nothing to say. Over time that training produces exactly the opposite of the outcome the system was meant to produce: people stop checking, because the record appears complete.
The practical standard I want is that the collaboration tools, the diligence record, and the multi-brand structure should survive a week in which I am not available. If they die, what we have is a dependency, not a stack. Dependencies are common and understandable. They are also the reason organizations discover, usually at an inconvenient moment, that only one or two people can explain how the work actually moves. The point of the system is to make that discovery less likely.
A clear tool is more useful than a speech about culture, because the tool removes a daily insult: the search for the file, the doubt about which version is current, the meeting that existed only to repeat what a page could have held. People notice the absence of those insults more than they notice most positive interventions. When the daily friction drops, the work becomes more tolerable without anyone having to be motivated to tolerate it.
I have built systems that were clever and cruel. Cleverness is easy to admire in the moment and expensive to live with. A person should be able to finish a diligence step, see that the record is complete, and leave. If the system requires them to be afraid of missing something that is not visible, or to stay late chasing pieces through email, the system is the defect. The same standard applies to hiring. A slow hire is one way to avoid placing a careless person inside a system that will now remember their carelessness perfectly. A fast exit is one way to stop a person who treats the record as optional. The record is not optional. That is both a technology rule and a management rule.
None of this requires a campus or a long training program. It requires that the distinctions the system enforces are visible in the tools themselves. A short explanation of how a diligence is closed is useful. A system that will not let the diligence be marked closed until the required items are present is more useful, because it continues to teach the distinction after the explanation has been forgotten. The goal is not to eliminate judgment. The goal is to make the boundary between judgment and record-keeping clear enough that both can be done without constant negotiation.
The most common failure mode of the CTO title is expansion. Because the tools touch every desk, it is easy for the person responsible for the tools to be treated as responsible for every problem the tools surface. A diligence that is stuck becomes a technology problem. A brand that wants an exception becomes a technology problem. A disagreement about what a number means becomes a technology problem. In each case the underlying issue is usually a question of ownership or judgment that the system can record but cannot resolve.
The useful discipline is to keep returning the question to the person who owns the judgment. The system can show that a document has no owner. It cannot decide who the owner should be. The system can show that two brands are using different naming conventions. It cannot decide which convention should prevail. When those decisions migrate to the technology desk, the other principals lose the ability to do their own work, and the technology desk loses the ability to maintain a coherent system. Both outcomes are avoidable if the boundary is stated clearly enough that people can correct a sentence that gives the technology seat power it does not have, or removes power it does have.
The same boundary applies in the other direction. A technology seat that refuses to absorb commercial or operational judgment is not thereby excused from making the tools usable by the people who hold those judgments. If the only way an operator can complete a diligence is to work around the system, the system has failed regardless of how carefully its boundaries were drawn. The test is practical: can the person who runs a house in one country use the shared tools without needing a translator, and can the person who runs a house in another country see what they need to see without being given access to everything?
If you hold a similar title, the useful exercise is to write down the three things the seat actually covers in your organization, and then to write down the things it does not. What do people share, and where does that shared material live? What record proves that a check was done, and can that record be reconstructed without gathering the people who performed the check? How does a second brand or a second team live on the same system without developing a private dialect that the next hire cannot read? Those are the positive questions.
The negative questions are equally important. You do not price the asset because you store the file. You do not replace the operator who runs a house. You do not accept a private exception that the next person cannot see. You do not let the title become the place where every unresolved anxiety in the partnership is sent. If you can say those things on an ordinary Monday, you know what the seat covers. If you can only say that you are “in charge of tech,” you have a nickname. Nicknames are inexpensive. The cost of an unclear boundary is paid later, usually by the people who have to reconstruct, under pressure, what the system was supposed to have made plain.
Read the about page for the titles it actually prints. Read the FAQ for the three-part job. The title is not the work. The work is collaboration, diligence, and multi-brand operations, inside a boundary you can say out loud.
