A mesh team is a small cross-functional unit that caters to a specific domain. It is important to know not just about the people individually but how they come together to fit into the team.
Team Structure
Spotify's Model For Scaling. One of the best models for organizing teams properly. The team structures I’ve been a part of have less groupings — squads, tribes and guilds. I guess we actually have the others, just not having the same formal names. It’s a matter of learning from others’ experiences and taking what fits your needs.
A simplistic view of a team with squads handling their own focus area:
Self-sustainability
We already know the work we need to do. We met the people. Can this team work autonomously?
What is the structure of the team?
Is it a part of a bigger group?
What does the organization tree look like?
How many squads?
Are there horizontal leads? (e.g. subject matter expert for quality engineering, working across squads making sure the work quality is aligned)
Do we have sufficient headcount?
Positions and roles of the people
Are all of the members <junior>-level?
Do we need up-skilling?
Meeting Product, Business and other stakeholders
Within the mesh, Tech works alongside Business and Product. The Business and Product Leads strategize and create the requirements to meet the business goals. Their teams include Business Analysts, Product Owners, and UX/UI designers and researchers.
The team will work with other mesh teams, data teams, marketing, operations, and other departments. As more features, more products are created so will the team meet more people. Maintain healthy relationships with everyone.
Learnings
Not having sufficient headcount. Mismatched profiles.
Example: The team has applications with frontend features, but they have no frontend engineers. These features then get handed off to another team who can support the development needed.
There are many reasons why this can happen (e.g. no budget for new headcount, cost-cutting, re-organization).
The team is not the full owner of their features and are dependent on others to get some things done. The other team receiving this extra work will need to trade off their own priorities. Now this can be handled in a matter of proper prioritization with all parties involved.
Sometimes there’s not much you can do if the budget is tight. Still making a request does not hurt. Maybe next year’s budget can cover this? How about an internal hire instead?
This goes beyond the Tech part.
- We used to have no designers and no product owners working in our department. At first it looked like a dream, working on purely tech initiatives, etc. But the truth is that is was difficult. We missed a lot of requirements/features needed by the stakeholders. I had to do both the UX/UI design and the frontend development. When we finally got support from the design and product teams, we were able to focus on the actual implementation instead.
Building positive, healthy connections that extend outside of the mesh team makes for a more enjoyable work environment.
My ex team mate shared that he liked being in the team because even if there were a looot of things going on and it seemed like the issues were endless.. we could make it through because we were together. And we did things together with jokes and smiles and dark jokes and smiles again. 🤣 It’s the same when you have friends in other teams. ♥️
Anyway, in our experience, teams help each other out. Especially tech teams lol They band together, you know. Like how about we all say no? Jk 😆