Traction changes a team’s job when growing demand turns product work into manual operations. The warning sign is simple: the person hired to build the next release is spending the morning keeping today’s transactions from breaking.
At 8:12 a.m. in Tunis, Sami saw a bank statement open across his engineer’s second monitor. Call Sami a composite of founders facing this decision. His engineer, Youssef, had a code editor open on the first screen and a spreadsheet on the other, matching cash deposits to customer accounts one row at a time.
The next release was already slipping. A business customer expected a payment feature that week, and one missing workflow still stood between the team and delivery. Yet Youssef could not return to it until every deposit from the previous evening had a clear owner.
The work traction quietly creates
Three months earlier, manual matching had looked sensible. There were few transactions, edge cases surfaced quickly, and Sami could inspect each exception himself. Automating the workflow then would have consumed runway before the team knew which rules mattered.
That decision had been correct.
The problem was that nobody had decided when it would stop being correct. More customers arrived. Deposits came through with shortened names, inconsistent references and amounts that could plausibly belong to more than one account. Each new transaction created another small judgment call.
By 8:40, Youssef had found two possible matches for one deposit. Choosing the wrong customer could credit money to the wrong account. Leaving it unresolved could delay access for the person who had paid.
Meanwhile, the release branch remained untouched.
This is how traction changes a team without announcing itself. The product still has the same screens. The company still has the same job titles. But the engineer’s real responsibility has shifted from building what comes next to protecting what already exists.
A dashboard might show rising activity as good news. The calendar tells the harder truth. If the person responsible for shipping spends each morning clearing yesterday’s queue, growth has created an operations system that the team has not named.
The decision was larger than automation
Sami’s first instinct was to automate deposit matching immediately. Youssef could write a rule, apply it to the obvious cases and remove the spreadsheet from his morning.
But the ambiguous deposit on the screen exposed the danger. A rule could make the same uncertain choice faster and repeat it without hesitation. In financial workflows, speed can multiply a weak decision.
The useful question became narrower: which part of the work was repetitive, and which part still required judgment?
The team separated the workflow into three pieces. Software could collect the transaction data and suggest likely matches. Clear cases could move forward under rules the team could inspect. Ambiguous cases would enter a review queue with the relevant evidence beside them.
That boundary mattered more than the automation itself. It kept the machine away from decisions the team could not yet explain, while removing the copying and searching that consumed Youssef’s morning.
The same distinction appears in the evidence trail behind two convincing matches. A plausible answer can still be unsafe when nobody can reconstruct why the system chose it.
Measure the interruption before building the fix
Founders often notice this problem through frustration: the roadmap keeps moving, everyone looks busy, and features take longer than they did a month ago. Frustration is a poor specification.
Sami needed to see the interruption clearly. For several mornings, the team recorded when matching started, which cases required judgment, what evidence resolved them and which product work waited. They did not need a complex reporting system. A small log was enough to reveal the shape of the work.
That record changed the build decision. The team did not need a grand automation project. They needed to remove a repeated search, preserve human review for uncertain matches and make every decision traceable.
This approach protects limited runway because it avoids two expensive reactions. The first is hiring someone to absorb a process nobody understands. The second is asking an engineer to automate the entire process before the exceptions have stopped changing.
A manual workflow can be useful product research. It shows where customer behavior refuses to fit the model. It becomes a problem when those observations remain trapped in one person’s memory and consume the hours meant for building.
Give the engineer a different morning
With the review boundary defined, Youssef could work on the narrowest useful change. The system prepared likely matches and placed uncertain deposits where Sami could review them. It also retained the information behind each suggestion.
The ambiguous deposit from that morning remained unresolved until the team checked it. That was the right outcome. Uncertainty had somewhere to go besides an engineer’s private spreadsheet.
The next time Sami arrived early, the bank statement was no longer stretched across Youssef’s second monitor. The release branch was open, and the review queue held the few decisions the software should not make alone.
Traction had still changed the team’s job. This time, they had changed the system around it.
Comments
No comments yet.