← Posts

The title was CTO, the job was translation

The CTO job was less architecture diagrams than making the same facts make sense to a board, a carrier CIO, support, and engineers far away.

August 15, 2026 5 min read

I joined Life Happens as a Laravel developer in February 2018 and left in December 2023 as CTO. I expected the last title to be about architecture. It was mostly translation.

The same facts had to make sense to a board, a carrier CIO, a support team, and engineers working many time zones away. If I got one of those registers right and left the others in my native dialect, the work was not done. I had only talked to myself.

I am not going to invent a board meeting to prove that. I represented engineering to the executive team and the board. I am not going to invent a conversation with a particular carrier CIO. The platform had connections and integrations across hundreds of carriers, including New York Life, State Farm, and Nationwide, and I sat in those peer conversations as a technology stakeholder. The receipt is the job, not a reconstructed scene.

Four audiences. Four languages. The facts did not change.

The board is risk and money, on a quarterly clock. They do not need the schema. They need to know what can go wrong, what it costs, and whether the people in the room have a grip on both. A risk conversation at that altitude is generic on purpose. I will not dress it up as an incident. The failure, when it happens, is bringing an architecture walkthrough to a question about exposure.

The carrier CIO is a peer. Credibility is earned early, and it is earned by not wasting the first minutes on a tour of your stack. They already have a stack. They have a platform that has to talk to yours, or already does. New York Life, State Farm, Nationwide: those names are integrations, not trophies I am hanging on a paragraph. The language that works is the language of the join. What we will send. What we will not. What happens when it fails. What we will not pretend we can promise. I do not have a transcript of a first meeting. The language that works is the language of a peer who has to live with the integration, not a vendor who has to finish a slide.

The support team needs something they can say to a person who is already upset. That is a different compression of the same fact. "We changed how X is stored" is an engineering sentence. The support sentence is what the member can do now, what they cannot do, and when it will stop being true. For a stretch of 2019 I held engineering and customer success at the same time, from January to October. That was either a governance failure or an education. It tightened the loop between what shipped and what members actually experienced. I stopped being able to treat a support script as someone else's problem. The same ambiguity that wasted a developer day showed up later as a person who could not get an answer.

The engineers were many time zones away. The team was India-based contractors, typically five and peaking at fifteen. The company had about fifteen US W-2 staff. Support and engineering together meant three continents. You get one round trip per day. Specificity is the language. Not motivation, not a vision paragraph, not "let me know if you have questions." The document has to survive the night. I have written that lesson elsewhere. Here the point is narrower: the night does not care which register you prefer. If you wrote the board version of the fact into an engineering ticket, you burned a day.

What nobody warns you about is the volume. A surprising amount of the job is restating the same fact in four registers, then noticing which one you just used by habit. The failure mode is assuming the register you are fluent in is the neutral one. For me that was usually the engineering register. It feels like clarity because it is the language I think in. It is not clarity to a board, and it is not usable to support, and it is not specific enough for a team that cannot interrupt you at 2 p.m.

Running engineering and customer success together taught me something neither hat would have taught alone. Delivery language and member language are not two communications problems. They are one fact with two failure modes. If you only hold engineering, you can ship something correct and still leave support without a sentence. If you only hold customer success, you can write a perfect script for a behavior the system does not have. Holding both was uncomfortable. It was also the closest I came to hearing the translation fail in both directions at once.

This matters more now, not because I miss the title.

The agent needs the specification register. The stakeholder still needs the risk register. The translation job did not shrink. It acquired a fifth audience that never gets tired and never pushes back. A model will accept the board version of a fact and build from it all night. It will not tell you that you handed it the wrong compression. That is a worse failure than a quiet room, because the quiet room at least looks like a problem. The model looks like progress.

I did not expect the CTO years to be the preparation for that. I assumed they were the least relevant part of the background once I went back to the keyboard. The transferable piece was not the org chart. It was the habit of asking, before I speak, who has to use this sentence, and what they will do with it if I am not in the room.

I am still working out how to write the same facts for a fifth audience that will not tell me I was unclear. I know the four human registers well enough to feel when I have used the wrong one. I do not yet have that feeling calibrated for a model. I am still figuring out whether the old tell (a confused question the next morning) has a replacement, or whether the replacement is just a bad artifact I now have to read.