Background
For a long time, productivity has been a common subject of measurement. Lines of code, the number of PRs and reviews, bug density, coverage rate—let me be clear, measuring productivity is futile.
The reason is simple: projects are inherently complex entities. Additionally, humans are inherently lazy, self-centered, and subject to varying interpretations, making them ambiguous creatures.
Experiencity
Experiencity refers to the degree to which one can work comfortably.
There are similar concepts such as developer experience or Engineering Effectiveness. Let's list a few more intuitive phrases:
- Ability to focus
- No interruptions
- Unblocked thinking
- No noise
- Ability to use work styles and tools that suit you
- Creativity
- Neither too difficult nor too easy
- Not boring but not too busy
- Absence of "disruptive elements" like ignorant managers or brilliant jerks
- Not burdened with business or sales tasks
For engineers and creatives, you are likely already familiar with this feeling. Our intuition is indeed correct. What matters is not management or becoming a cog in the team; it's working comfortably.
Experiencity operates under the belief that when you are comfortable, you naturally perform your best. This is referred to as the Principle of Experiencity. While this principle does not apply to all situations, it is generally applicable or adaptable in modern projects.
Implementing Experiencity
To practically implement experiencity, both individuals and organizations need to define their own indicators.
Start with Engineering Effectiveness as a Reference
As mentioned earlier, Engineering Effectiveness is easy to understand. This concept, advocated by ThoughtWorks, encourages measuring inputs rather than outputs. Here's a comparison from their philosophy:
| Measure ... (INPUT METRIC) | Don't measure ... (OUTPUT METRIC) |
|---|---|
| The time it takes to do code reviews | The throughput of pull requests |
| The amount of interruptions affecting engineers | How many hours engineers have been working |
| The amount of unplanned work affecting a sprint | Sprint points burned by the team |
This approach is truly experiential. It respects the experience of "being able to focus on engineering tasks" and values maximizing this focus. To maintain this, it monitors factors that detract from focus.
As far as I know, EE is the only example of properly established experiencity. Hence, I recommend using EE as a starting point. You can develop your own organizational experiencity later.
Following Definitions of Developer Experience Can Also Be Helpful
When asked "What is developer experience?" how would you respond?
There is no right answer. Even a brief deep dive will reveal various organizations using different definitions. Generally speaking, there are three main schools of thought on developer experience:
- 1: The Sensibility Group
- The realization that one's work has real meaning and is linked to value
- Typical organizations like Microsoft, Atlassian, or the Japan CTO Association tend to lean toward the Sensibility Group to connect to "business value"
- 2: The UX Group
- The UX of tools and environments developers interact with
- This perspective has gained particular importance in recent years, reflected in movements like Platform Engineering
- 3: The Stress-Free Degree Group
- The few obstacles developers personally feel to doing their jobs easily, minimal stress
Therefore, when implementing experiencity using the axis of developer experience, you need to consider to what extent to adopt the perspectives of these three groups.
There is no correct answer. Platform Engineering fully commits to the "UX Group," while modern engineering organizations often emphasize vision and teamwork, showing a tendency to value the "Sensibility Group."
Personally, I find the "Stress-Free Degree" most crucial, and as a Knowledge Architect, I focus on maximizing stress-free conditions for individuals when working on experiencity implementation. For example, I use concepts like role-sharing or diversity, and integrate ideas from the Teal Organization.
Conclusion
We introduced experiencity as a concept beyond productivity. If you are struggling with managing or improving productivity, feel free to consider this perspective. Until next time.
Top comments (0)