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 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:
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.
To practically implement experiencity, both individuals and organizations need to define their own indicators.
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.
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:
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.
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.