The Green Dot

From busy to useful

Walk into any company chat and look at the dots. Green, green, “in a meeting”, green. Everyone is busy. Now look for the thing that reached a customer this month. It is often hard to find.

Success now means three things: ship fast, keep the quality, and hear from customers early. Busy is not on the list. The good news is that this is easy to fix, one team at a time, and it starts with an hour.

The hour

A developer asks a question in the team channel at 10:14: “Should the export include archived users?” The product manager is in a meeting. So is the lead. At 11:30 someone writes “good question, let’s discuss in the sync”. The sync is tomorrow. The developer guesses, and the dot stays green.

Now the same hour, done differently. The developer asks an agent to check what the old export did, what the biggest customers do with the file, and what the ticket says. Ten minutes later she has two options, with the cost of each. She picks one, writes it in the ticket, and moves on. Nobody waited. One person saved an hour, and when a whole team works like this, the hours turn into days.

The day

A pull request is ready at 9:00. Only one person knows that part of the code, and he has eleven meetings this week. He reviews it at 17:40 and asks for a small change. The author has gone home. The fix takes four minutes the next morning. The second review takes another day. Two days for four minutes of work.

Now the same day, done differently. The team is two people. Each owns half of the code, and each has agents that can read all of it. An agent does the first review in three minutes, against the team’s own rules: tests, access, the things that broke last time. A human does the second review the same morning, because it is the only one waiting. Merged before lunch, checked and tested. Now it is ready for the step that matters most: a real customer.

The week

A ticket is written on Monday. Planning is on Tuesday. The estimate meeting is on Thursday. Then a question goes to the architect, whose review board meets next Wednesday. The sprint closes and the ticket is “carried over”. The work was never hard. The calendar was.

Now the same week, done differently. On Monday the agents draft three plans. The two humans pick one over coffee. By Wednesday a first version is in front of one customer, who says: “We don’t need an export. We need this report in our inbox every Monday.” The team changes direction. On Friday the weekly email ships, with half the code of the export. They wrote less code than planned and shipped more useful software. When a few teams work like this, the whole company starts to feel different.

The month

A competitor launches a feature. A leader asks for a deck on how to respond. The deck goes to a monthly steering group, which asks for a cost estimate from two busy teams. The quarter ends before anything is built. Nobody did anything wrong. Everyone was busy.

Now the same month, done differently. The leader gives a small team one sentence: “Can we match this, how long, and what do we drop?” The agents read the competitor’s docs, the team’s code and the support tickets, and the team brings back options the same afternoon. The leader decides the next morning. Four weeks later customers are using it, and already asking for the next thing. That is a big company acting like a startup. None of it needed a big plan from the top. It needed people who own their decisions.

Ownership

“I raised it in the meeting” is the sentence that stops work. It means the problem went to the room, and the room gave it to the calendar. When nobody owns a thing, nothing moves.

In a small team every product has one name on it. That person decides within a day, writes the decision down, and is allowed to be wrong, because the agents can redo in an afternoon what used to take a month. Owning more does not mean working more, and that is the part people often get wrong.

The new working day

The fear is that agents mean longer hours. It is the other way round. The agent does not get tired, so the human does not have to. The human does what humans do well: choosing, judging, talking to customers, noticing when something is off. The agents do the heavy lifting, even overnight.

A good day for one person in a team of two:

Time The human The agents
09:00 - 09:30 Reads the overnight notes, makes two or three decisions Wait for direction
09:30 - 12:00 Writes the asks for the day, reviews the first results Build, test, fix, in parallel
12:00 - 13:00 Lunch, away from the screen Keep running
13:00 - 15:30 Reviews and merges, one short call with a customer Build the next piece, draft the release note
15:30 - 16:30 Sets the overnight work: the big refactor, the full test run, options for tomorrow Start the long jobs
16:30 - 17:00 Writes the handoff note: what merged, what is open, what is next Keep running
17:00 Stops. No pings, no 22:00 “quick look” Work through the night, with a limit: five tries, then stop and report

Eight hours, one lunch, no evenings. “Too many meetings” is the oldest excuse in the office, and the funny part is that it is true. Meetings are not going away. What can go away is the hour of nothing while you sit in them.

So plan the day around the meetings, not against them. Before you join a call, give your agents work. One builds the next piece. One runs the tests. One reads the tickets, the customer emails and last week’s notes, and writes one page: what we know, what is open, what we need to decide. You walk in with the facts, so the meeting is about deciding, not remembering. While you talk, the agents work. When you come back, there is something to review instead of an inbox to catch up on. The meeting took 45 minutes. So did the build.

And yes, some days the body just says no. That is allowed. Even Lord Vishnu sleeps four months a year on his snake, and the world keeps turning. His trick is worth copying: set things up before you lie down. A tired human with agents already running still ships. A tired human with nothing set up just has a green dot.

The time was always there, hidden inside meetings and waiting. Use it, and the week has room in it. That room fills up fast if the team grows.

Two to five

A team of two can decide over coffee. A team of eight needs a meeting to plan the meeting. Every new person is one more person to keep in the loop, and agents cannot do that for you.

So keep two people per product. Go up to five only when the work crosses platforms: backend, iOS, Android, web, and one person who owns the whole and talks to the customer. Each has their own agents. Five people, a few dozen agents, never more. That sounds easy for a startup. In a big company it sounds like a dream, but it does not have to be.

Starting in a big company

You do not change a big company in one go. You change one team.

Pick one product and give it two people, their agents and one clear owner. The leader’s job is to remove the blockers: the approvals, the waiting, the monthly meetings. The agents follow the same security and compliance rules as everyone else, so nothing is skipped. Then let the results speak. When other teams see one team shipping every week and hearing good things from customers, they ask to work the same way. Change starts in one small team. When customers cheer, the rest of the company follows.

What the dot should mean

Status should be a thing, not a colour: “Merged.” “With customers.” “Customer said X, changing Y.” If a leader wants to know what is happening, the answer should be a link, not a meeting.

Agents made code cheap. Software that customers love is still rare, and that is where the race is now.

The dot shows you are online. The customer shows you are useful.