This is the first in a two part series that looks at how organisations can effect tighter integration across teams without restructuring the organisation. It also discusses how through building these relationships organisations benefit both directly and indirectly.
The Essence of Great Teams
Small teams are great. They take to collaboration really well, they can adapt to change fast, they tend to create a tight bond, they align to common goals reasonably well and they are easy to manage. This creates great harmony and agility which are two key features that lead to success. They are a small community.
In the rapidly changing world of IT all of these characteristics are crucial for success. However, any successful business will grow, and there is natural growth through continued demand for innovative computing.
I so often see a loss of one or more of these characteristics as teams grow and split and grow and split, often creating little silo’s of knowledge, or method, or standard, or all three. The biggest proponent to these silo’s is historical management structures and the natural fiefdoms of control that can occur. Collaboration is one of the hardest things to maintain during organisational growth, yet it is absolutely crucial to be competitive and avoid stagnation.
So how do we grow capability without losing that close knit team spirit all the while maintaining high levels of collaboration? We need to build communities and to do that we can take a leaf out of the Agile playbook.
Why is Community Important?
IT has been built on communities for decades. They have naturally formed amongst people with common interests, passions and skills. They start very simply, typically in a forum where people post questions and members of the “community” answer. The beauty of these communities is there isn’t a membership fee or criteria. If you know the answer, or a good answer or info that will help then you post it in the reply.
I’ve been an SME on a number of subjects through the years, particularly before I transitioned to non technical work; Windows Server, Active Directory, O365 architecture, System Center automation, virtual desktop infrastructure, etc. Throughout most of my career I’ve been the SME rather than part of a team of SME’s. I’ve relied on SME communities for advice, code, examples, tutoring and support. It’s been like having a virtual team globally. The flip side is that as I’ve solved problems I’ve contributed back to the community by sharing what I’ve found, either directly on forum threads or via this blog. In fact some of my early blog posts regarding SCSM and SC Orchestrator still regularly get hits years later.
It’s helped prevent me from feeling isolated, but also been a continuous education through posting my own questions and answering the questions of others. Through this continuous engagement and contribution I have constantly added to my understanding and standards on best practice. This has without a doubt helped me be an expert in my field, which in turn has aided the companies for whom I’ve carried out work.
I would not be where I am today without IT communities.
DevOps isn’t for Everyone
DevOps has exploded in recent years and it seems people are either talking about it, adopting it, or already doing it. “You just started talking about Agile and community, why are you suddenly talking about DevOps”. Bear with me and all will become clear.
For anyone unfamiliar with the concept of DevOps, in a nutshell, it’s people, process and technology combined to deliver software updates and features quickly with little or no downtime (very closely aligned to Cloud Native). A less eloquent version would be, take operations people and developers, place them in the same team, allow them to define process and give them modern tools to use to avoid the “us and them” mentality. DevOps exists specifically to speed up and smooth out software changes through fostering autonomy, innovation, automation and community.
“This sounds awesome, why don’t we convert our IT to DevOps?”
Well, this is where a lot of companies have tried to commercialise DevOps by using it as a handy marketing term, diluting the message and generating confusion. The reality is that it’s simply not suitable for universal application across all IT.
DevOps is appropriate for software development teams to enable them to build better, faster and stronger. However, there are some very attractive principles and working practices that can be adopted and adapted to improve IT efficiency and more appropriately aid in scaling IT teams universally.
Agile is for Everyone
A friend of mine wrote a great post recently that discusses how scalability is achieved across developer teams by expanding on the use of Agile methodology.
This got me thinking about how IT teams in general can take advantage of these principals to bring synchronicity, cohesion and collaboration without breaking the organisational structure apart. I.E. in growing or large organisations, how do we create that little team vibe, or more accurately, a community.
To be frank it doesn’t just need to be IT teams, but as I work in IT and have done for 25 years it’s the example I’m using.
I’m not going to teach the basics of Agile here. There are some great posts and articles out there that do that. For a fantastic introduction to Agile check out Martyn Coupland’s post here.
What I’m going to do is pinch some aspects of Agile and apply them across typically distributed IT teams to demonstrate how greater collaboration and cohesion can be achieved.
First lets talk about some team terminology…
Squads, Tribes, Chapters and Guilds… Umm, Beg Pardon?
This illustration sums it up reasonable well.
This model describes how to build teams for successful software development. This article here by Martyn Coupland (where I pinched the graphic from) does an excellent job of articulating how these different teams work and how it all drives great software development.
In short Squad’s are small teams of developers reporting into a dedicated Product Owner. These teams have the skills and tools they need to do their jobs and are granted the autonomy to decide the working method (SCRUM, Kanban, etc). Most importantly members of a Squad all have a common goal or specific focus such as a specific part of the web user interface for the app they are working on.
Tribe’s are groups of squads. Their commonality is that they collectively work on the same aspect of the product such as the web user interface.
Chapters are groups of people across Squads that have common skills and expertise such as .Net. I.E. you might be the .Net guy in your Squad, but that doesn’t mean you are completely on your own having to bear all that weight. You are backed up by your Chapter, a little like an MSP to the Squads they span. Chapters are designed to create a horizontal community for individuals in different Squads who have a common skillset. You could say that Chapters exist in part to prevent people from feeling isolated.
Here is an interesting quirk. We typically think of organisational structure as a waterfall hierarchy, so in the diagram above it would be natural to think that the Squads are departments headed by someone in that team. Actually, in the Agile structure, the departments are the Chapters with the chapter leader as the manager responsible for 121s, goal setting, salary management, recruitment and other HR/person management activities. This would mean that your physical team, that is the team you sit with, converse with, and work with all day every day are not the team you share a manager with. Also you could have a manager in your squad from another Chapter than the one you belong to.
Guilds are to Tribe’s what Chapters are to Squads. Guilds span Squads and Tribes horizontally and vertically. Squads typically don’t interact with other squads and the same goes for Tribe to Tribe interaction. Remember, the purpose of this structure is to focus in on specific development areas. This is where Guilds come in to be able to bring people together across Tribes.
As Martyn’s post suggests Guilds are communities for sharing knowledge, practices, code, etc. Community is a key word here as this is an essential ingredient to be able to bring cohesion across teams that would otherwise be disparate.
So I’ve talked about DevOps, I’ve talked about Agile and I’ve talked about common team structures. So where am I going?
Chapters and Guilds are where we will focus and what gave me the idea for this post. As Martyn’s article most eloquently puts, they are the glue that hold the collective together. Without Chapters and Guilds you have lots of teams doing their own thing, talking occasionally but no common goals or cohesion.
So, we need to form communities. These communities can then get together to collaborate, share knowledge, provide support for each other and, most importantly provide a single standard across the business, rather than multiple standards vertically in silo’s.
This will also supply reliability and continuity to the business. For example, when SAs, or Security, or TDMs, etc reach out to someone from the community for support, they can get help that the whole community supports. This avoids pools of knowledge forming in individuals that become the go-to people. It also avoids conflict between departments whom, without communities have developed their own individual views and can provide conflicting guidance or advice.
The benefits don’t end there either. As well as direct benefits to the business (avoiding knowledge silo’s, effort duplication, mismatched advice, SPoFs, disperate working practices, team isolation, etc), there are indirect benefits too.
Many businesses, particularly MSPs rarely sell anything physical. They sell services that, through the expertise of people, provide solutions to clients. It’s very easy, even in a large organisation to feel isolated if you are the only one in a team, or one of very few people in a team that have certain expertise. This isolation can chip away at confidence while also pile on pressure.
I’m not going to preach about how the wellbeing of staff directly effects performance, which in turn effects business capability. There are a ton of studies available to reinforce that statement and thankfully its widely accepted. I’m happy to say employers in my experience are always looking for ways to aid the mental health of their staff. Fostering horizontal communities is another good way of reducing or removing isolation.
By borrowing from the Agile handbook we can establish communities horizontally across the business to achieve cohesion across people with common skill sets – Subject Matter Experts (SMEs). This team across teams can then be an authority for setting relevant standards while learning from each other. SMEs are then empowered to provide a consistent message of “why/what/how” both internally to the business and to clients. SMEs within vertical teams feel less isolated and belong to part of a wide community that can cross disciplines and time zones. The company and employees benefit from stronger internal bonds, more harmony, less conflict, and more consistency.
Keep an eye out for Part 2 coming soon where I will discuss how to establish communities, what the right attributes and qualities are and provide some examples of how this can be achieved.