Making Decisions & Getting Stuff Done
Organisational Structure
Domain Description
The domain is a distinct area of influence, activity and decision making within the organisation. It is held by either circles (teams, business units or similar) or roles (assigned to people). One way of looking at it is that the domain is an empty description of mandate that becomes real only when it's populated by teams and people. The domain usually contains:
Primary Driver
For self-governance to work, first we need to define a purpose. Remember, it's a purpose and wisdom hierarchy. Thus, we have a purpose for the whole organisation, for every business unit, team, smaller helping team or projects, and roles. Ultimately, they should all be aligned and pointing in the same direction. The primary drivers are our managers, guiding us in every decision. Primary drivers, as sub drivers, are defined using Situation–Consequences–Needs, as described above.
Comprend's primary driver:
[Situation:] We live in a world that changes at a breakneck pace which has become increasingly complex and uncertain. [Consequences – Opportunities or Challenges:] Communication is at the heart of bridging this challenge and the ability to adapt and change is what sets us apart from our competition. [Need:] We help companies change their approach to communication. We know how.
The primary driver is, as every agreement, "set in stone" until we collectively decide otherwise. Those accountable for the domain are those who decide how the primary driver, and the whole domain description, should be designed. If we later discover that our decisions and actions aren't aligned with the primary driver, we choose to either update the driver or make new decisions. Or terminate the circle. It's a way of making sure that we do the right things and get maximum impact with minimal effort.
Tip: A good way of starting a meeting is to start by showing the primary driver. You don't have to go into the details of it or discuss whether you think it's a good driver – simply make sure everyone has it top of mind when making decisions.
Key Responsibilities
Very simple. What are we responsible for in order to get stuff done?
Example, Team Plan B's key responsibilities
- Keep our clients happy
- Market intelligence and understanding trends and development
- Challenge, give new insights and keep clients updated on what’s new in the digital world.
- Communicate our competence and offer in a clear way Get new clients
- Upsell and increased sales
- Etc
Constraints (Budget, Resources, Time, Reporting, Other)
Constraints are the opposite of key responsibilities. What is naturally limiting our work? There is a trap here, though: Constraints should not account for obstacles that can easily be changed. Knowing whether something is easy or difficult to change, however, is not always easy. But pinning down what is out of our control is helps us focus on what's most important.
Example, Team Plan B's constraints:
- KPI Average percentage of occupancy 80%
- Income budget mSEK, decided by team not CD
- Budget for team activities Proposal based
- Resources Secure all competencies in team whilst making sure that effectiveness and psychological safety is high
- Reporting CS mgmt group, Time reporting to Finance
- Governing Self
- Learning Responsible for self, Regular team reviews
Preferred qualities, skills, experience
How can co-workers help our team? When it's time to recruit, this is a good resource. It's easy to get stuck in the details, so organising the list with headlines could be a good thing.
Example: Team Plan B's qualities:
- Great willingness to cooperate
- Team player attitude
- Willingness to learn new things
- Openness to others’ opinions, new ideas, new facts
- Analytical ability
- Willingness to question
- Being open with own opinions and ideas
- Willingness to share knowledge and experiences
- Willingness to do market intelligence and learn about trends
Example: Team Plan B's skills
- C#
- IIS
- Epi
- SQL
- Html5, html, Css
- Multiple programming languages
- Web analysis
- Organisational structure
- Solution architecture
- System architecture
- Scrum
- Etc
Evaluation criteria
Which metrics would be in place to evaluate our performance and how do we measure them, i.e. how do we know we are doing a good job? Make a list and prioritise which criteria you want to measure regularly (1-3 metrics is usually enough). Also decide how you want to collect and make sense of the data: surveys, stand-ups, retros, 360s or whichever you think is best.
Examples, evaluation criteria
- EBIT
- Occupancy
- Level of customer satisfaction/NKI/NPS
- Team vibe – how are we feeling
- Turnover
Review dates
Easy peasy: How often and when do we evaluate our performance? Daily, weekly, monthly, quarterly, yearly?
[ IMAGE ]
Final note: Who writes the domain and how is it populated? In an old top-down structure, the domain is created by and populated by management, usually with minimal autonomy for those who end up there. This basically kills motivation and accountability and is something we want to avoid at all cost.
Those who discover a need are the ones who should write the domain to account for the need, usually done by 1-3 people, sometimes with the help of other co-workers or leaders in the organisation. When the domain description is defined, we use invitation and a role selection process, as described below, to populate it with the right people: motivated, skilful and happy.
Organisational Structure - Previous
Organisational Structure
Next - Organisational Structure
Teams and Business Units
Last modified 3yr ago