In software development, discussing "technical correctness" is important. However, it is not sufficient on its own. Technical correctness can easily change due to trends in technology, execution environments, or shifts in business phases.
While logical consistency is a prerequisite, in a rapidly changing development environment, it is essential for a team to have a "value system" as a reference point to maintain a consistent evaluation axis.
Redefining MVV in Development Teams
MVV (Mission, Vision, Values) can be interpreted in various ways, but in this article, we redefine it based on Peter Drucker's organizational theory to function at a practical level for software development teams. Instead of grand slogans at the management level, it is important to focus on "who we are as a specialized group in our domain, and what we provide."
- Mission: "What do we consider as our contribution?" What kind of change does our team bring to those we deliver value to?
- Vision: "What is our ideal state?" The team or product we want to realize as a result of continuously fulfilling our mission.
- Values: "What do we believe is right?" The behavioral guidelines for prioritizing during daily design decisions and troubleshooting.
Defining Team Personality: How to Think About It
MVV should not be decided unilaterally by the leader. To define the team as a single "personality," a process is needed to synchronize the recognition of all members.
- Ask "Who are our customers (users)?": Who directly uses our code or system? Clarify what challenges they face and how solving them is the team's "mission."
- Understand Domain and Context: Articulate what role the domain the team faces demands from the team as a personality.
- Extract Criteria: Reflect on past design decisions and extract the common values that guided the team in what they believed was right.
The "team personality" defined through this process becomes an identity that should be inherited even if members change. Moreover, MVV should not be fixed once defined but should be flexibly changed according to changes in circumstances.
Maintaining Consistency in "Team Personality"
A team is a collection of individuals but should function as a single "personality." The team personality is defined by the domain and context the team faces.
Even if there is a change in members, if the team does not maintain consistency in the value and behavior it provides, it will not gain trust from those around it. Defining MVV is essentially the task of defining the "identity of the team personality." With this axis, even if people change, the approach to the domain can be inherited, allowing the team to remain consistent.
Sharing "Thoughts" to Improve Decision-Making Accuracy and Speed
In design and technology selection, the final decision is made by the team's "thoughts." Of course, logical correctness, quantitative data, and qualitative judgment axes are important and should not be overlooked.
However, when multiple "logically correct options" are lined up, without a common thought (Value), discussions can become futile.
- "Do we prioritize delivery speed and accept debt, or do we stick to robust design?"
- "Do we optimize for specific use cases, or do we generalize for future reuse?"
By having a common understanding of these through MVV, decision-making as a team personality becomes smoother, preventing futile discussions.
Promoting Autonomous Improvement through Initiative
An autonomous team is one that can make decisions and complete tasks as a team personality.
Instead of individual members acting separately, it is important for the team as a subject (personality) to constantly question, "Is the current development process optimal?" "Is the direction we are aiming for correct?" and continue to update itself flexibly. MVV serves as a compass for this autonomous improvement cycle.
Operating MVV to Prevent It from Becoming Hollow
To make MVV a living guide, it is useful to integrate it into everyday scenes.
- Display it in places that are seen daily, such as Slack's Canvas or KPT reflection boards.
- Ensure that members can articulate the team's MVV in their own words to potential hires.
- Develop a habit of reflecting on MVV as a reference point when in doubt about decisions.
Example of MVV in a Platform Development Team
Based on the author's experience, a model case of MVV in a team responsible for platform engineering is presented. The composition changes depending on the team's focus points.
| Pattern | Mission | Vision | Values |
|---|---|---|---|
| Developer Experience Focused | Abstract complexity to create an environment where developers can immerse themselves in implementation | A world where anyone can instantly deliver ideas as software | User-centric design / Zero-effort experience |
| Security and Control Focused | Default security to balance freedom and control | A state where all engineers can keep accelerating without being conscious of it | Default safety / Ensuring transparency |
| Reliability and Scale Focused | Maintain a robust foundation that can withstand 100x scale | Infrastructure where all products can enjoy maximum scale at minimal cost | Reliability first |
Conclusion
Engineering is a world of logic, but it is the team's will that determines in which direction that logic is applied. Because technical correctness fluctuates with the environment, it is necessary to define MVV to promote consistent yet flexible development with a common understanding as a team personality. Using the defined words as a compass, the team should continuously refine its way of being, which ultimately becomes the shortcut to maximizing the value of the product.
