I think this is a struggle for many of us.
Not only to re-organise existing teams but also positioning teams in a larger organisation.
What team composition works for your cases?
What roles are filled within a software development team, and what roles run across teams?
What kind of teams are there?
I've applied teamtopologies and unfix
to help communicate about our team structures, but I'm curious about what problems people encounter and what solutions you've discovered.
Form a starting team based on skill sets and let them do the rest. Give them a project and they will tell you what they need if they feel assured that you have the capability and will to help them. You want the team to cater to the product, not to the manager because manager satisfaction does not bring value to the organization or the customer. You only need to manage more closely if for some reason you were only able to gather junior devs.
I feel trying to structure everything "perfectly" is just micro-management and is never going to be close to "perfect" for the usual reasons top-down everything never is. My general thoughts are:
Employees should feel they are achieving autonomy, mastery and purpose. They'll work out all the details themselves if they're motivated and empowered to do so.
To that effect teams should be able to do their end-to-end work without being blocked by/dependent on other teams 80% of the time. Not for 80% of each piece of work but 80% of pieces of work they put into production.
The vision of the company/department and what rough path is being taken towards that vision (metrics, projects, goals, etc.) should be crystal clear to everyone.
Incentives (promotions, yearly reviews, bonuses, etc.) at a corporate level should correlate with driving forward business value versus bureaucratic box checking.
The price of perfection is infinite. It's not about structuring everything, and it doesn't have to be top-down. But, at some point, a team grows to more than ten people, and it's not enough to self-structure. At some point, you must agree on who is responsible for what instead of everyone being accountable for everything.
I agree with you on all points as to desired outcomes. I think it is particularly interesting that you emphasize how important vision is. I have found it difficult enough to have a medium-sized organization even come up with a vision, let alone effectively communicate long-term, medium and short-term plans to engineering teams.
Aligning projects with goals and setting milestones is a great way to communicate a vision. I've found it tricky to use metrics to track progress or performance. Do you have any ideas about how to use metrics to help align with a vision?
For context, my answers are in regards to growing companies versus those past that stage that now get more value from focusing on pure optimizations. I've found that approaches which work for the latter actually hurts growing companies and vice versa.
At some point, you must agree on who is responsible for what instead of everyone being accountable for everything.
In my experience splitting into teams of 6-8 people and then assigning focus areas to teams works fairly well. Assuming you split in a way where teams are not blocking each other the vast majority of the time.
Do you have any ideas about how to use metrics to help align with a vision?
I was thinking more of business metrics which may or may not tie into vision. What metrics does the business care about (customers, revenue per customer, customer sentiment, fraud reports, etc.) and why do you think each team helps those metrics? A team may be supporting other teams but otherwise they should be pushing forward some business metric you care about and are measuring. If you're not measuring it then how do you know the business is actually doing better or worse in an area (or that a team is helping)?
At sub-100 developers, what I have seen work is to align dev teams based on company organization structure, so that each part of the company has a dev team to support the internal products they need and can develop expertise to help when coordination across teams is necessary.
The size of these teams is commensurate with the priority of the function and its internal products.
Like any organizational method, you need a strong vision from the top, clear priorities, and a product roadmap that makes sense.
That's interesting. One of the problem for onboarding new engineers is they miss any domain knowledge of our product and building that end-user sensitivity is difficult. Embedding devs with sales,support etc does address this.
What are some problems you've experienced with this approach?
The downsides is when you need to do something cross-functional it requires a different approach. What I have seen work is that you spin up a temporary team to own the delivery of the cross-functional project then have VP/CTO give all teams priority about helping the cross-functional team, e.g. the x-func team will say "I need support from finance and marketing" and those teams would agree to help out via 1 dev for 2 quarters (or whatever).
It requires a lot of clarity from management and agency from the cross-functional team.