Performance Is In Context
Individual performance is often attributed to skills, motivation, discipline, and experience, while the conditions under which work takes place receive less attention. This article examines how work environments influence the ability of individuals to translate their capabilities into measurable results. Drawing on organizational research, socio-technical theory, and principles of system design, it explores the distinction between potential and realized performance, the effects of workflow bottlenecks, and the hidden labor required to compensate for inadequate tools, inaccessible information, and organizational constraints. It introduces Work Enablement as an approach to designing and maintaining environments that allow people to apply their capabilities effectively. The central argument is that improving performance requires more than developing individuals or acquiring technology; it requires creating dependable, accessible, and interconnected working conditions that reduce unnecessary friction without compromising quality, security, or resilience.
FIG 1.0 - Moving a charge beyond capacity
When you try to move a load that far surpasses what your tools are capable of. No matter how much skills you have, there are things your environment will not let you do.
Related Insights
The Tech Stack Tax
When Enough Is Not Enough: The Work-Enablement Problem
Using the bad metrics for productivity
MXI.STUDIO EDITORIAL
Productivity | Work | Metrics | Operations
The MXI.Studio Editorial is a collection of articles, ideas, and reflections written by the people behind MXI.Studio. We explore emerging technologies, innovation, industry trends, and the current challenges of an ever-evolving world.
Performance Is In Context
"On why individual performs better when the environment is properly set."
A n experienced person can understand everything that needs to be done yet still be unable to complete anything. It is not due to a lack of oversight or a lack of involvement but instead the environment itself in which the person is, lacks accessibility to common resources. Information is unavailable, approval never came, systems cannot exchange information to proceed. Performing better isn’t an issue. The issue is that the environment doesn’t allow the person to move at his speed.
We usually attribute performance to how fast a person move and produces things. Skill, motivation, discipline, and experience are the main contributors to being performant. We see those as explanations, but all of these factors end up being internal to the person. None take into account the walls surrounding the work we might encounter. Performance is directly influenced by the environment, and it is the environment that determines what capabilities are available to us.
Work Enablement concerns the capabilities and conditions through which work will be done. The central position is simple: skills, knowledge and experience only become useful when the tools and infrastructure are set to work smoothly together. We are not searching for accumulating tools, rather we want to set up an environment that reduces every point of friction and allow the person to move at his own pace.
The individual-performance bias
When a task takes longer than expected, the simplest explanation might be to blame the worker. A delay will be interpreted as bad organization, lack of skills, or insufficient effort. If a similar assignment is completed faster by another person, the difference will only reinforce the assumption.
The interpretation might be correct, but the signals would probably be more evident in this case. Two equivalent teams might be delivering at different rates because the environment is different. One team might have more access to data or important information. Another team might have less overhead when communicating. A different team could have access to different tools. The faster result is what gets measured, but the underlying conditions behind it are rarely equivalent.
The job-design research of J. Richard Hackman and Greg Oldham provides an early reminder that work characteristics, including autonomy and feedback, can influence important work outcomes. Performance cannot be understood solely by inspecting individual traits while treating the job itself as fixed. Similarly, Albert Bandura's social cognitive theory likewise describes reciprocal relationships among personal factors, behavior, and the environment, rather than a simple one-way chain from personal qualities to action.
Neither perspective implies that the environment explains every difference between people. It establishes a more careful starting point:
before diagnosing the individual, examine the conditions under which the work was done.
Capability is induced by the system
The employee does not rely on personal knowledge alone. The task completion could demand proper tools, functional software, reliable data, permission to use it, instructions, norms, assistance, and cooperation from others. Missing even one of these elements can hamper the execution of an otherwise highly skilled individual.
In 1951, researchers Eric Trist and Ken Bamforth published a landmark study on British coal mining. They looked closely at what happened when mines introduced modern mechanical coal cutters and conveyors. The goal was to boost production, but output actually dropped, and conflict within the teams went up. The new machines broke down the traditional, close-knit groups of miners who relied heavily on each other for safety and support, replacing them with isolated roles and rigid shifts.
This study laid the foundation for the socio-technical approach developed by Trist, Fred Emery, and their colleagues. Their central finding was that the human side of work and the mechanical side cannot be treated separately. If you upgrade tools, machinery, or formal rules without considering how the people on the ground actually operate together, the overall work system will not improve.
The same logic applies to contemporary digital work. A database may be fast, but its usefulness depends on whether the data are dependable and accessible. A platform may have advanced features, but those features accomplish little when users cannot locate them or when the platform does not connect to the next stage of the workflow. A knowledgeable team may still struggle because different departments maintain incompatible versions of the same information.
The environment is not limited to software. It includes physical conditions, documentation, policies, training, colleagues, support arrangements, and the organizational rules that determine what actions are permitted. Work Enablement is therefore not an information-technology inventory. It is an examination of whether the complete arrangement allows necessary work to happen.
Potential performance and realized performance
A distinction is needed between what a person is capable of doing and what a particular environment allows that person to accomplish.
-
Potential performance refers here to the capability someone could exercise under suitable conditions: relevant knowledge, practiced skills, judgment, and the ability to learn or adapt.
-
Realized performance concerns the result achieved under actual constraints, including the time, quality, reliability, and effort involved. These terms form a conceptual distinction, not a standardized psychological measurement scale.
Consider an analyst asked to prepare an operational report. The analyst understands the data, the calculations, and the decision the report will support. Yet the required inputs reside in separate systems with inconsistent definitions. One export requires special permission, and another must be reconciled manually. The final report may be late despite sufficient analytical competence.
More training in analysis would not necessarily address the delay. Better access, a shared data definition, and a reliable exchange between systems might. The same person could produce a better result without gaining any new individual skill.
The reverse remains possible. Excellent tools cannot compensate for knowledge that the assignment genuinely requires but the worker has not acquired. Effective diagnosis must distinguish a capability gap from an enablement gap and recognize when both exist. Treating all difficulty as an individual weakness is misleading; treating all difficulty as a system failure would be equally incomplete.
Results are constrained by bottlenecks
An environment could provide sophisticated solutions, complex tools and advanced programs and still fail to be performant because the environment, although advanced, does not define the authorizations and the managerial layer. A reliable cloud service cannot rescue a workflow whose instructions point to an obsolete data source.
This is a dependency problem. In a sequence of necessary steps, one unavailable prerequisite can block everything that follows becoming a bottleneck. Improving components that are not constraining the work may have little immediate effect while the blocking dependency remains unresolved. Think of it as parallelism in computing. Much like computational execution, parallel processing speed remains capped by its slowest serial instruction.
But not every workflow has a single weakest link. Some tasks have alternative routes, parallel activities, or capacity to recover from failure. The practical point is narrower: overall capability is determined by the relationships among components, not by the specifications of the strongest component. And a workflow can’t be optimized by simply optimizing one components.
A useful investigation therefore traces a real task from beginning to end.
-
What information is required at each stage?
-
Which systems must trigger a response?
-
Where are access permissions validated?
-
Who holds explicit ownership for providing missing inputs?
-
Which handoffs depend on prior task completion?
"The answer often reveals constraints that are invisible in an inventory of purchased tools."
Performance is more than just speed
Time to completion matters, particularly when delay affects customers or
prevents other work from proceeding. But a fast result that cannot be
trusted is not necessarily a successful result.
A usable environment must also support:
- arrow_right correctness, so the work produces the intended answer;
- arrow_right reliability, so tools and processes behave consistently;
- arrow_right repeatability, so ordinary results do not depend on one person's memory of exceptions.
- arrow_right Availability determines whether necessary resources can be accessed when required.
- arrow_right Resilience and recoverability concern how work continues or resumes after failure.
- arrow_right Adaptability describes the capacity to handle new demands without excessive reconstruction.
SIDE NOTE :
These are not merely nice-to-haves or interesting add-ons but are formal foundations of modern software quality engineering. The official standard, ISO/IEC 25000 (SQuaRE), defines quality in terms of reliability, availability, recoverability, and flexibility of the system. In the absence of such qualities, software cannot do its primary role of assisting people to complete their actual tasks without a hassle. In essence, quality engineering is not only about writing good code but also providing an environment in which success can be achieved.
These dimensions can conflict. Stronger security checks may add steps while protecting sensitive information. Additional validation may extend an operation but prevent costly errors. Redundancy may appear inefficient until a component fails. Enablement does not mean removing every constraint in pursuit of speed; it means making necessary constraints proportionate, understandable, and workable.
Nicole Forsgren and colleagues' SPACE framework for developer productivity supports a multidimensional view. It distinguishes satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. A fast delivery count alone cannot describe all these dimensions. Research on developer experience by Abi Noda, Margaret-Anne Storey, Forsgren, and Michaela Greiler similarly highlights feedback loops, cognitive load, and flow as meaningful aspects of the conditions in which software work occurs.
The relevant measures depend on the work, but the principle is general: faster interaction with a tool is different from a more capable working environment.
The environment teaches people how to behave
Tools and procedures do not merely support behavior; they also shape it. When the approved route is difficult, people search for alternatives. An unreliable, shared drive encourages local copies. A missing integration produces manual spreadsheets. Poor search makes an existing answer difficult to find, so another document is created. A slow approval path encourages requests through informal personal contacts.
These adaptations are often understandable. They help complete work despite the constraints. Yet they can create new risks: duplicated information, inconsistent versions, unclear ownership, privacy exposure, or dependencies on a few employees who know how the workaround operates.
Don Norman's The Design of Everyday Things explains why discoverability, understandable mappings, and feedback are central to usable design. When an interface does not make an action or its consequence clear, people must spend attention interpreting the interface instead of advancing the task. That cost may be small once and substantial when repeated.
FIG. 2 — The environment shape the way you move
The obstacle your environment gives you will determine what your actual top speed will be. This why removing the point of friction will make things go smoother. But sometimes those obstacle are necessary to impose a flow.
Bandura's reciprocal perspective adds another useful consideration. Conditions influence behavior, while people's repeated responses can gradually change the conditions themselves. An unofficial spreadsheet may begin as an individual workaround and become an organization's de facto source of truth. The environment has not remained static; its difficulties have generated a second, less visible system.
A workaround should therefore be treated as information about a constraint, not merely as evidence of user resistance or resourcefulness.
The hidden labor of compensation
Many organizations function because employees continuously compensate for weaknesses in their environment. Experienced staff remember which procedure is outdated, know whom to contact when an integration fails, and maintain personal notes that explain undocumented exceptions. Teams reconcile records between incompatible platforms or recreate information that technically exists elsewhere.
This labor can be highly skilled and genuinely valuable in the moment. It can also conceal the underlying problem. When a process succeeds only because particular people know how to bypass its difficulties, the reported output may look healthy even though the system remains fragile.
The risk becomes obvious when an employee is absent, changes roles, or leaves. Knowledge that was never incorporated into usable documentation or tools disappears from the normal workflow. A replacement then appears to perform less effectively, although the difference may reflect the loss of unofficial infrastructure rather than a difference in talent.
Peter Drucker's writing on knowledge work emphasizes the contribution of knowledge and the conditions required to make it effective. In practical terms, knowledge should not have to remain locked inside individual memory for routine work to proceed. Documentation, accessible expertise, and reliable processes can convert personal coping mechanisms into shared organizational capability.
When friction becomes normal
A difficult environment rarely announces itself as a single major failure. It is more likely to consist of small recurring demands: signing into another system, searching for the correct file, requesting access already needed last week, re-entering an identifier, confirming that two reports refer to the same customer, or asking a colleague how an exception is handled.
Each action can seem too minor to justify attention. Across many tasks, however, the same inconvenience consumes time and attention repeatedly. The cost includes not just the action itself but the interruption to the surrounding work and the uncertainty about whether the next step will succeed.
Normalization makes the problem harder to recognize. Expressions such as “that is just how the system works” indicate that friction has become an accepted part of the job. The organization's estimate of how long a task should take may already include the time required to survive its tools and procedures.
A better baseline separates work that creates the result from work required only because of the environment. This does not make all supporting activity wasteful: necessary verification, security, coordination, and learning have purposes. It does make avoidable reconstruction, duplication, and repeated recovery legitimate subjects for improvement.
Accommodation is not the same as enablement
Training has an important place in capability development. Workers need to understand their domain, the tools they use, and the risks attached to decisions. Clear standards and guidance can prevent errors and support autonomy.
But training can also become a substitute for fixing avoidable design problems. If a system requires employees to memorize a long sequence of arbitrary actions to complete an ordinary task, the organization can keep producing training material or reconsider the sequence. The first response helps people accommodate the environment. The second asks whether the environment is unnecessarily demanding.
Paul Adler and Bryan Borys distinguish enabling and coercive forms of bureaucracy. Formalization can support workers by making processes understandable and repairable or constrain them through rules centered on control rather than competent action. The presence of a documented procedure is not enough to determine which effect it has
The same distinction applies to technology. An enabling system gives timely information, explains its state, supports correction, and handles ordinary exceptions. A system that merely forces users to follow a rigid path may create compliance without making the work easier or more dependable.
Accommodation remains necessary when a legitimate constraint cannot be removed, as with safety requirements or protected information. Enablement asks whether that constraint has been implemented in the least obstructive responsible way.
More technology is not automatically more capability
Acquiring a tool is a relatively visible intervention. A license is purchased, a platform is deployed, or an automation is announced. The organization can point to something new. Whether work has become easier is a separate question.
New technology may overlap with existing applications, require additional training, introduce another identity system, or create a new place where information must be maintained. A platform can solve one local difficulty while increasing the burden on everyone who works across systems. Retaining obsolete tools alongside replacements can compound the problem.
This is why enablement must be assessed from the perspective of an actual task rather than from the feature list of a product. Can the relevant information be located? Is it trustworthy? Can the person who needs it obtain access without an unnecessary delay? Do the tools exchange information correctly? What happens when a component fails? How much separate work is required to keep the environment functioning?
The objective is neither technological minimalism nor maximal sophistication. Some tasks require specialized, complex equipment. Others benefit from a single dependable interface. The useful stack is the one that makes the required capability available at an acceptable cost and level of risk.
FIG. 3 — The proper tool has been made available, now we have to clean up.
The proper tool can be used, but still be out of reach or impossible to operate. So, the proper way of changing things is also to take into account who is operating it
Diagnosing the conditions of work
Work Enablement becomes practical when evaluation starts with a real workflow. Rather than asking only whether an employee possesses the required skill, the investigation examines what must be available, known, connected, and reliable for the task to succeed.
A diagnostic review can follow a representative assignment from request to completion, including unsuccessful attempts. It can distinguish time spent producing the result from time spent searching, transferring information, waiting for permissions, correcting tool failures, or rebuilding context. Workers should also be asked which unofficial methods are necessary, and which problems recur despite training.
The next step is to identify the constraint and its consequences. Is the problem insufficient knowledge, inaccessible information, an unreliable tool, incompatible systems, a policy whose purpose is unclear, or a missing support route? Does it reduce quality, delay delivery, threaten security, or make results depend on one individual? Different causes require different interventions.
Changes then need evaluation against the actual result. Removing one approval may shorten waiting but weaken a necessary control. Replacing a tool may reduce manual steps while increasing outages. Better documentation may have negligible effect if permissions still prevent action. The test is whether the work becomes more dependable and less unnecessarily demanding, without introducing unacceptable risks elsewhere.
These questions create a continuing feedback process rather than a one-time technology audit. Environments change as people, tasks, systems, and requirements change. Their ability to enable work must be revisited accordingly.
The environment is part of performance
Individual capability remains important. Organizations still need skilled people, effective training, sound judgment, and accountability. But the contribution of those qualities depends on whether the surrounding environment allows them to be expressed.
An employee who repeatedly reconstructs missing information is performing work but is also compensating for the conditions of work. An organization that adds more tools without examining how people use them may increase its technological inventory without increasing its usable capability. A process that succeeds through personal workarounds may be more fragile than its completion figures suggest.
Work Enablement is the deliberate design and maintenance of conditions that allow people to apply their capabilities reliably, effectively, and with proportionate effort. Its success is not measured by the number of tools installed or courses completed, but by what the environment makes possible and what needless difficulty it removes.
That leaves a consequential question. If technology is continually becoming more powerful and more abundant, why does the experience of doing work not necessarily become proportionally easier?