Our farm was run by a very small team. Mainly my Uncle Rick and my father, but my Uncle Steve helped on the weekends. This allowed my dad and his brother, Rick, to get one night and one day off every other weekend, and a three day weekend once a year. Talk about a strong vacation package! With us kids helping (more likely getting in the way until we were older) we got through the day to day but it was always those two guys. It started with their father before them, and they’ve enjoyed sharing fun times with their grandkids, too.
The deep trust they have in each other, and the lifetime of experience and skills they had acquired, allowed them to be very successful. So how can a small team like that be so successful without modern day planning tools, forecasts, etc.? Farming is a complicated business that requires deep knowledge across multiple areas. The answer is you don’t need to be complicated with the right team in place.
We haven’t always worked like that in technology and there are still many companies that don’t put enough thought into their team and communication structures.. We know now that small, cross-functional, long lived teams build trust and working relationships that surpass any other. Ownership of software from requirements to production instills quality and speed if we enable focus, flow, and joy. This is the core of DevOps with team first topologies in mind.
If we maintain small teams (5-9 cross-functional team members) with a solid value stream that they own end to end, they will surpass any other structure you can come up with. Keeping them together will allow them to learn from each other, trust each other, and improve the unit as a whole. You will have to manage communication structures between teams and keep the architecture of the system in mind at all times. It isn’t a one-time exercise and leaders must be looking for triggers to re-evaluate the structures.
Conway’s Law requires us to have a team first architecture that we strive to build our software against. As the author’s of my favorite books from IT Revolution state, if you don’t have the architects involved in defining team topologies, then you have non-technical people deciding the architecture of your software. Like software systems, the organization must be re-factored over time as well. We can’t all be lucky like my dad and his brothers to be partners for life so we must do the best we can as leaders to get the most from our teams.
There are many team structures and communication issues that need to be addressed to be successful at different organizational sizes and leaders owe it to their teams to study and learn systems thinking and apply it.
About David “Nick” Pazzaglia
Good reads Nick…hope you’re doing well!
Thanks for any other fantastic article. Where else could anyone get that type of information in such an ideal means of writing?
I’ve a presentation subsequent week, and I’m at the search for such
information.
IT Revolution is my favorite collection of books and articles. I’d recommend checking them out.