Skip to content
← 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.

4 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 register 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 or a carrier conversation to prove this. I represented engineering to the executive team and the board, and the platform integrated with hundreds of carriers, New York Life, State Farm, and Nationwide among them. 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. The failure is bringing an architecture walkthrough to a question about exposure.

The carrier CIO is a peer. Credibility 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. 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. 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. "We changed how X is stored" is an engineering sentence. The support sentence is what the member can do now, what they cannot, and when that stops being true. For most of 2019 I held engineering and customer success at the same time, which was either a governance failure or an education. It tightened the loop between what shipped and what members experienced, and I stopped being able to treat a support script as someone else's problem. Holding both taught me that delivery language and member language are not two communications problems. They are one fact with two failure modes. Hold only engineering and you can ship something correct and still leave support without a sentence. Hold only customer success and you can write a perfect script for a behavior the system does not have.

The engineers were many time zones away, on a one-round-trip clock I have written about elsewhere. 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, and the night does not care which register you prefer. If you wrote the board version of a 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 the engineering register. It feels like clarity because it is the language I think in. It is not clarity to a board, not usable by support, and not specific enough for a team that cannot interrupt you at 2 p.m.

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. 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 the fifth audience. 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. The old tell was a confused question the next morning. The replacement might just be a bad artifact I now have to read.

Related: Many hats, Player-coach, Distributed teams