In software engineering, the way an organization perceives and measures effort tends to reveal a great deal about its level of maturity.
Less evolved models tend to reproduce a logic inherited from manufacturing, where effort is treated as a direct function of time, almost always measured in hours. Even when other metrics enter the picture, there is frequently an attempt to convert them back into time, as if every form of effort could be translated into hour equivalents.
Productivity, in this context, becomes interpreted as volume of delivery per unit of time. This reading assumes that software development behaves as a linear, repetitive, and predictable process, similar to an assembly line.
That premise, however, conflicts with the nature of work in software engineering.
Software is a predominantly intellectual, creative activity oriented toward solving complex problems. The value generated is not tied solely to the quantity of effort applied, but to the quality of decisions made, adequate domain modeling, risk reduction, technical clarity built over time, and the ability to structure solutions that remain coherent as they evolve.
Attempting to translate this kind of work purely into hours reduces a thinking activity to an operational dimension that does not capture its nature.
This reduction shows up in the day-to-day of many organizations in a fairly simple way. A ticket to develop. A ticket to investigate a bug. A ticket to ask a question. A ticket to attend a meeting. A ticket to align understanding. A ticket to explain why another ticket didn't move. In some environments, the board stops representing value flow and starts functioning as a kind of sophisticated time sheet.
The stated justification is usually visibility. In practice, it often becomes surveillance.
The problem is not in recording relevant work. A technical investigation may need to appear in the flow. A meeting can unblock an important decision. An architecture discussion can prevent weeks of rework. An incident analysis can produce learning for the entire system.
The problem starts when every human movement must become a trackable item to prove that someone was occupied.
The phrase "just log your hours" sounds harmless from the outside. But that request never arrives alone. It lands on top of a pile of activities already competing for attention throughout the day: reviewing code, answering questions, investigating strange behavior, participating in alignment sessions, deciphering poorly formulated requests, handling interruptions, making small decisions that unblock other people, and resuming a train of thought that was cut off midway.
Each additional log entry seems small in isolation, but it also requires context switching, mental reconstruction of what was being done, and administrative attention that competes directly with intellectual work. The organization views logging as an operational detail, while the team experiences it as one more layer of low-value work piled onto a day that is already fragmented.
At that point, the organization starts spending energy to measure energy. The effort that should be concentrated on understanding the problem, making better decisions, and building something with impact gets redirected into feeding a control mechanism. The team begins working for the tracking system, when the tracking system should exist to help the team see its work more clearly.
When management cannot see flow, impact, risk, and learning, it tries to compensate with granularity. The less confidence there is in reading the work, the stronger the urge to decompose everything into trackable pieces. From there, the ticket stops being a useful representation of work and becomes an administrative proof of occupation.
The person is not just solving a problem. They are also producing visible signals that they were solving a problem.
This creates a behavioral distortion. If the system sees ticket count, tickets get created. If it sees logged hours, hours get logged. If it sees board movement, the board gets moved. If it sees ceremony attendance, ceremony attendance gets performed.
The result can be an environment full of evidence of activity and poor in impact.
A team can have many tickets, many meetings, many updates, many logged hours, and many rituals running, while still trapped by fragile priorities, poorly framed decisions, and low-value problems. At the same time, a brief conversation between experienced people can prevent a bad decision, simplify an architecture, reduce production risk, and save weeks of future work.
That kind of contribution rarely fits well into a timesheet.
SRE literature helps make this distinction clearer by formalizing the concept of toil. The Google SRE Book defines toil as a type of work that tends to be manual, repetitive, automatable, and tactical, with no enduring value, growing linearly as a service scales.
"Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows."
Google SRE Book
This framing matters because it does not treat effort as a uniform mass. It distinguishes what contributes to the evolution of a system from what merely consumes energy to keep things running. When low-value effort gets treated as productivity, the measurement model starts incentivizing precisely the type of activity that should be reduced.
The same logic appears in Lean thinking, which questions efficiency applied to things that should not occupy the system in the first place. The question stops being only whether something was done quickly, on time, or with many hours logged. The question becomes whether it should have occupied the team's time, attention, and cognitive capacity at all.
"There is nothing so useless as doing efficiently that which should not be done at all."
Peter Drucker
Measuring hours tends to capture execution intensity, but it does not distinguish whether effort is directed toward something that generates value. A team can follow every ritual, fill every field, log every hour, and still work on demands that do not move the product, do not reduce risk, do not increase learning, and do not improve the lives of those who use the system.
This shift in perspective connects directly to agile practices, which introduce a different reading of the role of work. The principle of maximizing the work not done moves the conversation from occupation to intention. Reducing unnecessary work becomes part of engineering competence. Effort stops being treated as isolated merit and starts being evaluated by the result it produces, the risk it reduces, the decision it qualifies, and the capability it creates.
"Simplicity — the art of maximizing the amount of work not done — is essential."
Principles behind the Agile Manifesto
The problem is that many organizations adopted agile practices without revising their underlying control mindset.
They swapped the project schedule for a board. They swapped the status report for a ceremony. They swapped the project manager for new roles. They swapped the vocabulary, the rituals, and the artifacts. But they preserved the same obsession with granular effort control.
That is where the agile veneer appears.
The organization talks about autonomy but demands traceability of every step. It talks about outcomes but tracks occupation. It talks about flow but enforces ticket filling. It talks about trust but requires continuous proof of activity. The practice looks different on the surface, but it keeps operating under the same logic of command, control, and surveillance.
The origin of this tension can be observed in the traditional project management model, structured around time, scope, and cost, with the expectation that upfront planning and detailed control can reduce the uncertainty of the work.
That model needs effort to be a controllable variable. This is why hours become a comfortable unit. They give a sense of precision. They allow comparisons between people, cost estimation, deviation tracking, and report generation. The problem is that this sense of precision can conceal a poor reading of the work itself.
When agile practices are introduced without a change in thinking, a curious composition emerges. The organization adopts adaptive language but continues evaluating the team as if it were running a predictable assembly line. The board becomes a visual schedule. The daily becomes an accountability session. The estimate becomes an informal contract. The ticket becomes evidence of occupation.
The conversation keeps revolving around the same question: how much time did each person spend?
That question is not irrelevant in every context. Cost matters. Capacity matters. Predictability matters. The problem lies in making that question the center of management, as if the sum of individual hours explained the real ability to produce value.
It does not.
Leadership that relies too heavily on this kind of control tries to make work visible through fragmentation. It divides, tracks, demands, compares, requests updates, creates fields, creates statuses, creates labels, creates subtasks. The volume of information increases, but understanding does not always follow.
Leadership with a different kind of maturity tries to make work comprehensible through context. The focus shifts to direction, priorities, decision criteria, relevant risks, dependencies, system capacity, and expected impact.
The interesting point in the idea of context, not control lies in this shift. Management stops acting as a mechanism of permission and continuous surveillance and takes on a harder role: building enough context for people to make good decisions without needing to turn every intermediate move into an administrative record.
"Context, not control."
Netflix Culture Memo
This requires leadership that can articulate direction, constraints, priorities, risks, decision criteria, and expected outcomes. When that context is absent, autonomy becomes a nice word for pushing ambiguity onto the team. People receive operational freedom but not the elements needed to decide well. The result can be misalignment, rework, and dispersion — not from lack of technical capability, but because the organization confused autonomy with the absence of management.
Netflix's own logic does not rest solely on the word freedom. In No Rules Rules, Reed Hastings and Erin Meyer treat talent density as one of the foundations for reducing controls. The idea is simple on the surface but demanding in practice: very good people, working with other very good people, raise the quality of decisions and reduce the need for granular supervision. This does not create an environment without management. It creates a form of management that must focus on the level of the system, the quality of people, the clarity of context, and the maturity of decisions made without asking for authorization at every step.
Autonomy in a weak team can become dispersion. Autonomy in a strong team, with well-built context, tends to produce decision velocity, technical quality, and a distributed sense of ownership. This is why copying the freedom without copying the conditions that make freedom possible usually ends in frustration. When an organization does not invest in talent density, honest feedback, directional clarity, and relational maturity, removing controls can become nothing more than abandonment with a nice vocabulary.
The reverse movement also exists. When an organization demands accountability without offering context, it creates hollow accountability. The team ends up answering for results it cannot fully control, inside a system full of dependencies, unstable priorities, external decisions, and constraints that often never appear in the performance narrative. Leadership looks at the visible end of the work and demands speed, while ignoring the structure that makes the flow slow, noisy, or full of interruptions.
Providing context tends to be harder than demanding ticket updates. Demanding updates requires little repertoire. It means asking for status, setting deadlines, watching board movement, and comparing some number. Building context requires business understanding, strategic clarity, grasp of technical constraints, prioritization capability, and the maturity to handle ambiguity without converting everything into micromanagement.
The same shift in thinking appears when time starts to be observed as a property of the delivery system, rather than a direct measure of individual effort.
The DORA model uses indicators such as lead time for changes, deployment frequency, recovery time, and change failure rate to observe how well the organization can transform changes into value safely and frequently. Time, in this case, helps understand how the work system behaves, not whether a person seemed busy enough during the day.
When an organization tracks lead time, it can begin to see waiting, dependencies, queues, excessive approvals, unstable environments, rework, coupling, and bottlenecks. When it tracks change failure rate, it can investigate engineering quality, testing, review, automation, architecture, observability, and safety in the delivery process. When it tracks recovery time, it can discuss responsiveness, operational design, incident readiness, and learning after failure.
But switching the indicator does not automatically improve the quality of the decision.
A better dashboard does not produce better management when the reading remains poor. Giving an airplane cockpit to someone used to driving a car does not make that person a pilot. In many cases, it only increases the volume of available information without increasing interpretive capacity. Some indicators end up occupying space, drawing attention, and appearing sophisticated without actually helping anyone decide better in that context.
An attitude indicator makes sense in an aircraft because it helps the pilot understand the plane's orientation relative to the horizon, especially in low-visibility conditions. Placing the same instrument in a racing car might seem impressive, but it probably does not improve the driver's decisions on that track. The indicator exists. The information exists. The question is whether that information relates to the type of decision that needs to be made.
Something similar happens in software management. An organization can build dashboards, track percentiles, separate indicators by squad, build productivity panels, measure flow, record incidents, calculate throughput, and still make bad decisions if it cannot interpret what those signals mean.
Sometimes a long tail in a time distribution does not mean the entire system is slow. It can point to a specific subset of cases, an external dependency, a particular type of operation, an occasional queue, or an extreme behavior that needs to be isolated before becoming a conclusion. Sometimes looking only at the average hides users suffering at critical points in the journey. Sometimes looking at a high percentile without understanding volume, segmentation, and context creates a sense of crisis where only a localized problem exists. Sometimes an increase in deploys can represent improved flow. In another context, it can represent fragmentation, haste, or instability being pushed to production.
An indicator does not speak for itself. It needs to be interpreted within a system.
This is a part of the metrics conversation that is frequently ignored. A bad metric induces bad decisions. A good metric, interpreted poorly, also induces bad decisions. The problem lies not only in the instrument but in the reading capacity of whoever uses that instrument to decide.
"When a measure becomes a target, it ceases to be a good measure."
Popular formulation of Goodhart's Law, associated with Marilyn Strathern
When an organization turns a measure into a target for pressure, behavior begins to adjust to the measure. If the pressure is on hours, people learn to fill in hours. If it is on ticket count, they learn to break work into more tickets. If it is on board movement, they learn to keep the board moving. If it is on an uninterpreted indicator, they learn to perform the indicator.
Work starts to be shaped by how it is observed.
This is one of the most costly consequences of micromanagement. Management believes it is increasing visibility, but it may be altering the behavior of the system to satisfy the control mechanism. Instead of better revealing reality, the metric begins to distort the reality it is trying to measure.
Campbell's Law deepens this tension by showing that quantitative social indicators used for social decision-making become more subject to corruption pressures and more likely to distort the very processes they were meant to monitor. This helps explain why productivity metrics, when turned into instruments of pressure, frequently stop representing productivity and start representing adaptation to the accountability system.
"The more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is designed to monitor."
Donald T. Campbell
OKRs enter this discussion for the same reason. When used well, they help make direction, expected outcomes, and criteria for progress explicit. When used with the same surveillance mindset, they become one more layer of pressure, ranking, and corporate anxiety.
The practice can look sophisticated while the thinking remains shallow.
A well-framed objective helps a team understand what matters. A key result helps them see whether meaningful progress happened. Both should improve the conversation about decisions, priorities, and trade-offs. When they become instruments of pressure, they lose force. The organization starts using an alignment tool as a mechanism for individual accountability. The vocabulary changes, but the logic stays the same.
It is the same agile veneer that appears in many environments. The company uses boards, sprints, dailies, OKRs, DORA, an engineering platform, and AI, but keeps operating with a surveillance mindset. Everything looks current on the surface, while underneath the question remains the same: how do we prove that people are busy?
With the recent advances in artificial intelligence, this conversation becomes even more sensitive. For a long time, writing code was used as a shortcut for interpreting productivity. More code written meant more delivered. That reading was already limited, but it becomes even more fragile when tools start generating code, suggesting refactors, and exploring alternatives at far greater speed. What becomes more visible is precisely what was always hardest to measure: the ability to frame problems well, decide what not to build, evaluate trade-offs, and sustain technical coherence over time. If the organization already struggled to see that kind of contribution before, AI simply makes that limitation more exposed.
Evaluating a technical investigation by the number of hours logged says little about the learning generated. Evaluating an architectural decision by the time spent discussing it says little about the risk avoided. Evaluating a delivery by the number of tickets moved says little about the real impact on the product. Evaluating a team by the number of records it produces may reveal more about management's control anxiety than about the ability to ship better software.
Software engineering takes on the characteristics of craft work at the cognitive level. Output is tied to the quality of problem representation, the consistency of solutions, the ability to handle ambiguity, and the intelligence applied to the evolution of the system.
Effort still exists. It just does not always manifest in the form that traditional management prefers to see.
Sometimes effort is a difficult conversation about scope, or the decision not to build a feature. Sometimes it is removing a complexity that seemed inevitable, or a better model that simplifies months of maintenance. Sometimes it is realizing the problem was not in the code, but in how the organization understood the requirement.
None of that fits well inside a culture obsessed with logging hours.
There is still a behavioral layer that deepens this problem. The obsession with control often does not originate only from a poorly designed process, but from leadership with low relational maturity, little security in handling autonomy, and difficulty operating through influence, context, and trust. This type of manager tends to centralize decisions, pull tasks toward themselves, create artificial dependencies, and confuse centralization with management.
In some cases, there is a constant need for recognition, a search for validation, a fragile relationship with loss of control, and something resembling a petty power syndrome, where the title becomes an instrument of personal affirmation. Larman's Laws help explain how organizations tend to preserve power structures even when adopting practices that promise change. The manager who feels productive when everything passes through them, in practice, reduces autonomy, weakens the system, and turns leadership into a bottleneck.
The way out does not go through abandoning measurement. Organizations need to measure, track, learn, and course-correct. The problem lies in choosing the wrong object to measure, interpreting the collected signal poorly, and managing people from an incomplete reading.
A good indicator should improve the quality of the conversation. It should help surface where flow stalls, which decisions are being deferred, which risks remain invisible, which capabilities need to be built, and which outcomes justify the effort invested.
When an indicator becomes only an instrument of pressure, it impoverishes the conversation. When leadership cannot interpret what it measures, the dashboard becomes operational decoration. When an organization measures to control every movement, it diverts energy toward low-value work and still calls it management.
At its core, a management model is also a mental model.
An organization can dress different practices in the same old logic. It can call surveillance visibility. It can call form-filling management. It can call process compliance maturity. It can call occupation productivity.
That is one of the greatest contradictions in many software companies.
They say they want autonomy, creativity, innovation, and outcome orientation, while continuing to spend enormous energy trying to convert intellectual work into administrative trails of hours.
And the more they do that, the more they create exactly the kind of work they say they want to reduce.
