Born without a street
Hospitality inherited foot traffic. Six months into the industry, I'm learning what customer data can reveal without changing the welcome at the table.
What I've learned building software and working with the people around it.
Hospitality inherited foot traffic. Six months into the industry, I'm learning what customer data can reveal without changing the welcome at the table.
The target architecture was usually clear. The route there rarely accounted for the team doing the work.
We used odd correlations to help moderators choose which threads to read. Years later, I found a pattern in financial data that we decided to leave alone.
AI coding advice is rediscovering an old lesson: clear code, visible architecture, and useful tests beat another page of instructions.
We spent years complaining about micromanagers, then gave AI the same over-specified briefs and bloated documentation.
A tangled frontend can make every change expensive. Splitting the deployment may only move the coordination work somewhere else.
A struggling engineering group tried the trust exercises. Three months later, people were still hoarding information and second-guessing decisions.
On day one, a manager can offer room, support, and the benefit of the doubt. Trust grows from what happens next.
AI taught me to ask how a confident claim was checked. The same question exposes weak feedback loops in teams and leadership.
A new hire notices the problems everyone else has learned to step around. Their first month is organizational feedback, if anyone is willing to hear it.
A remote team looked healthy until its manager left and half the team followed. The conversations that explained it had been happening in private.
AI changed my workflow before it changed my job: the tool no longer gets to decide when the work is done.
A ten-second blame session changed how a team behaved for years. The response to failure says more than a culture survey.
My team rebuilt the architecture I proposed. I now judge that first sketch by how easily they could challenge and improve it.
The community managers I worked with were posting constantly. Members joined in more when we started writing about what they were doing.
About 15 years ago, tiny details such as punctuation helped us decide which conversations needed a moderator's attention first.
I thought the 2/3 cycle followed company growth. Then I started seeing it inside teams, departments, and individual projects.
I went looking for one policy that explained Sweden's tech lead over Denmark. The comparison became less tidy as soon as I checked the details.
The same joke kept turning up: good boss, good product, good team. Pick two. I started looking for the pattern behind it.
Leadership, strategy, and team health can each look convincing until the work puts them under pressure. These are the tests I use.
A fintech team ignored customer requests. A SaaS company shipped through burnout. In both, success gave people a reason to keep going.
Before a two-week vacation, a leader asked the team to choose between two approaches. They wanted to know what the leader would choose.
One organization tried to repair leadership, strategy, and team at the same time. The transition was more than the system could absorb.
A word as ordinary as customer can expose how differently engineers and business colleagues handle uncertainty. Architects have to work inside that gap.
At my first job, we split an unwieldy monolith into services. The extra complexity was deliberate, and it gave the team room to learn.
Ten years ago, I declined a whiteboard exercise and asked to see the company's code. I've used real code in interviews ever since.
I used to treat technical debt like a failure. Thinking in interest rates gave me a more useful way to judge it.
My wife understood the idea in her computer science class, but she couldn't make it work. I remembered how often books had given me the same false confidence.
A backlog can look orderly and still leave every task waiting on another. Vertical slices give the team something it can actually ship.
A junior developer asked why we use dependency injection. My practiced answer lasted until their second question.