Fostering Unity: The Role of Team Manifesto in Software Engineering
How to set up your team for success by laying a foundation for shared direction and values using a team manifesto.
A team manifesto may have many shapes and forms and be ever-evolving but the purpose stays the same. With a team manifesto, you aim on having a set of shared values and ways of working. Personally, I like the following definition of a team manifesto used by the Industrial Solutions Engineering (ISE) team at Microsoft.
A team manifesto is a light-weight one page agile document among team members which summarizes the basic principles and values of the team
Source: Code With Engineering Playbook
Does that sound very simple? If yes, then great! Because preferably, it should be very simple to understand and remember if you ever want to see it in practice. I have rarely, if ever, seen lengthy documents of this nature to be successfully implemented.
But wait! Why do we need this?
I observed several different issues that should lead you to developing your own team manifesto:
Lack of sense-making
The team either does not fully understand the purpose of their work or they have various, or even entirely different, understandings of the purpose of their work. Specifically, the team members are not aligned on answers to the following questions:
- Who are we?
- Why are we building our product?
- How are we helping the customer?
These should be laid out in a team manifesto to bring everyone on the same page and deeply anchor the understanding of the team’s purpose. Not addressing the lack of sense-making is a shortcut leading to demotivated team members, poor decision-making and potential attrition.
Unclear roles and responsibilities
Right after the purpose, come the roles and responsibilities. It is tremendously helpful to set the right expectations for each role on the team, so that the team members know exactly what is part of their responsibility and what is not.
For instance, there will be completely different expectations for a junior engineer role compared to a lead engineer role in terms of accountability and ownership. You might not expect your junior engineers to be held accountable for driving or taking decisions regarding your solution architecture. However, you perhaps expect them to actively contribute in those.
Absence of principles
You may call it principles, rules, do’s & don’ts, foundations or whatever you like but if they are not clear to the entire team and they are not followed, you set yourself on a very risky route. Principles guide us through how we work, how we think and how we make decisions.
For instance, you may have a principle of preferring incremental and continuous evolution of your product instead of executing large-scale replacements in your product aka big bangs. Another example could be a principle of having security always as a top priority when building and designing new features to ensure that it inscribes into daily work.
The principles should form boundaries within which the team members operate rather than becoming a set of steps to follow. This preserves space for innovation and creativity.
Lack of confidence
Encouraging confidence in your team manifesto is perhaps not a very common phenomena. However, in a highly complex and/or business critical product scenario, the team members may lack confidence in taking ownership, making decisions and experimenting. Hence, I believe that using the team manifesto to directly boost confidence and collaboration as a team will turn highly beneficial in the long run.
Let me walk you through how we established a foundation for a team manifesto within one of my teams.
I specifically stated a foundation for a team manifesto as I do not see this work complete but rather as a solid foundation that we can build upon. The motivation to develop a team manifesto stemmed primarily from:
- a recent merger of two different teams working on the product
- lack of knowledge about legacy parts of the product
- lack of confidence among team members
- lack of prioritization and direction from technical as well as from product perspectives
The following is a manifesto that was developed by one of the LEGO® Group’s backend engineering teams:
At the moment, it only contains the principles regarding our focus, prioritization and decision-making in our domain. There are still missing pieces about the team’s purpose and how we help the consumers as well as what are the expectations for our team roles.
However, this is perfectly fine! The manifesto itself should be agile as suggested by the definition from the ISE team at Microsoft. It should evolve as your team evolves and does not need to cover everything from day one. By laying out even just the foundational ways of working in a manifesto, the team can enhance alignment, improve decision-making, and boost motivation. The manifesto’s flexibility and ability to evolve with the team’s growth make it a powerful asset for ongoing improvement.
