Ideas worth developing beyond a short post.
Practical perspectives on technology decisions, architecture, software, operations and business. Approved notes are released here according to their editorial schedule.
Documentation does not fix disorder
Before documenting a process, understand why it exists, where context is lost and which decision it is meant to control.
Read note
Buy or build is not a technology question
The real decision is where standardization is useful and where the business needs deliberate differentiation.
Read note
What comes next
At the end of the year, the question always comes up: what comes next for software? I do not think the answer lies in a list of tools. I am interested in looking at which problems are worth…
Read note
What to measure next year
Next year, I do not want to fill a dashboard with indicators. I want better answers for making decisions. How long does work take from agreeing on a need to reaching production?
Read note
Buy or build
Not every problem deserves custom software. And not every process should be distorted to fit inside a SaaS product.
Read note
People versus capacity
For a long time, conversations about capacity began with one question: how many people do we need? I still believe people matter. Experience, judgment, and coordination do not appear by…
Read note
The new technical leader
A technical leader does not need to know every line in order to be accountable for the result. They need to know which decisions can change the direction of the system.
Read note
What I would not delegate
There are many tasks I would delegate without thinking twice. But there are five things I would not delegate without remaining involved:
Read note
What was just hype
Not everything that impressed in a demo survived contact with real work. Some promises looked huge until simple questions came up.
Read note
What worked
When a year comes to a close, it is easy to remember what made the most noise. The new tool. The big promise. The project that seemed capable of changing everything.
Read note
AI-first
Putting a chatbot on top of an old process does not change the company. It only lets people have a conversation with the same disorder.
Read note
Designing for AI
Most of the systems we use were designed for a person clicking through them. The screen tells that person what they can do.
Read note
Administrative AI
When artificial intelligence comes up inside a company, the conversation usually starts with technology. But much of the work that consumes the most time does not involve writing code.
Read note
Agents
There is an important difference between artificial intelligence telling you what to do and being able to do it. An assistant can draft an email.
Read note
A CRM without living in it
A salesperson should not have to choose between serving the customer and feeding the CRM. But sometimes the system ends up becoming a second job.
Read note
The interface is changing
Working with software today also means remembering where everything lives. Where an opportunity is recorded. Where a project is reviewed.
Read note
The system keeps the record
A system should not limit itself to storing the result. It should also preserve enough context to understand how we got there.
Read note
Software is no longer the tool
For years, we learned to use software by entering screens. We opened the CRM to review customers. The project system to find pending work.
Read note
Small teams
After leading large teams, you learn that more people do not always mean more capacity. They also mean more coordination, more waiting points, and more context that can be lost between a…
Read note
Technical debt on steroids
Artificial intelligence changed the speed at which we can accumulate technical decisions. Good ones and bad ones. A solution can work today while leaving duplication, unnecessary…
Read note
Documentation does not fix disorder
Documenting a disordered process does not make it orderly. It only makes the disorder easier to describe. A manual can explain perfectly ten steps that should never have existed.
Read note
QA is not friction
Reviewing a result before delivery appears to add time. Skipping the review does not eliminate that time. It only moves it.
Read note
Architecture matters more
Artificial intelligence can multiply a good decision. It can also multiply a bad one. When producing code took longer, some poor decisions spread slowly.
Read note
Cheap code
Producing code is becoming cheap. That does not mean producing good software is becoming cheap as well. When writing a function takes minutes, it is easy to confuse volume with progress.
Read note
The first 30 days
If I discovered tomorrow that my entire team was using artificial intelligence, I would not start by banning tools.
Read note
Accountability remains human
When a system fails, no one accepts this answer: The artificial intelligence decided. The customer did not hire a model.
Read note
Are we more productive?
Saying that a team is ten times more productive because it uses artificial intelligence does not tell me much. Ten times more what?
Read note
Buying is not adoption
This pattern existed long before artificial intelligence. A company buys a CRM and the team continues managing customers in personal spreadsheets.
Read note
Information in chats
Do you know what company information your people are pasting into a chat? No one needs to download an entire database.
Read note
Banning AI
Banning artificial intelligence looks like a control decision. Often, it only makes its use invisible. If a tool saves someone hours, a blanket policy rarely removes the incentive to use it.
Read note
What your team actually uses
There is a significant difference between the tools a company buys and the ones its team actually uses. The official list may say Microsoft, Google, Jira, Slack, or any other platform.
Read note
Eight months
I asked a business owner how much artificial intelligence his team was using. He told me: None yet. His team had been using it for eight months.
Read note