7 Rules For Building A Technology Leaders Community

There are many technology communities around us. Many of these are public communities — open source, local meet-up or technology conference communities that form around a common interest. I don’t want to talk about these. Instead I want to describe growing a technology leaders community inside an organisation.

Within organisations there is a strong need for communities to bring together people of similar interests to share and grow their collective understanding. With active communities an organisation will be actively improving at scale. For software companies Spotify have made this popular with their Chapters and Guilds that formalise the community of interests across their Squads (teams) and Tribes (squads who work on same product). I want to focus on a specific type of community: the technology leaders.

Technology leaders are a difficult bunch. They display the following characteristics strongly,

• they are very busy
• they are exceptionally opinionated
• they are typically cynical because of their experience
• they are interested in new and shiny things
• they are influential across their teams

So yes they are a difficult bunch to corral. But there is significant power that can be encapsulated when a group of technology leaders agree on things. This is especially true if this community is focused on change. Having an active technology leaders community is vital to all organisations that understand software is eating the world. This cannot be optional because software is eating everything else including other software: staying still or moving slowly is accepting decline.

Technology leaders at Kainos

Within the digital group at Kainos we have been building a tech leadership group for the past 2 years. This is a group that has grown over time to almost 20 people. It is an active and successful group. And it is full of people with the characteristics described above.

The digital technology leaders group is working to some extent but of course it can and is being improved as we go — continuous improvement is expected, it’s not some binary switch that is either failure or success.

Perhaps the best way to describe the group is to explain the rules the group has adopted. We have only recently written these rules down, instead they have formed over time from the behaviours of the group. There wasn’t any up-front design.

1. The goal is improvement

The reason why we have a technology leaders group is to improve. It is so important to continually remind oneself of this. Otherwise it can easily because focused on shiny technology or similar cool stuff.

Improving the way in which we think about development or testing or operations is the goal we are fixed on. This will of course include considering new technologies that may promote this improvement — but will also include better design, better processes and better communication.

For example in 2015 Irek Pastusiak and Steven Limmer introduced the need to change our thinking on testing to move to an explicit shared responsibility with QA model. This was hotly debated and it was agreed to roll this out to an agile project to better understand its impact on developers and testers. This has resulted in a new way Kainos approaches testing for its teams working on digital services. Irek has added to this by describing his experiences as a QA lead in agile teams.

2. Improvement is better if there is consensus

Debate is healthy within the group. And of course there will be disagreement and differing opinions, that is fine. But I find that if we can bring this debate to a broad consensus then the action or change agreed will become more readily adopted.

For example to have all your technology leaders agreeing to a common format for design proposals that is lightweight, open, conversational means that it has much better chance of adoption. Rory introduced Open Design Proposals (ODP) last year and has described the aims, process and template to make it easy for anyone to adopt.

3. Membership is restricted but content is open

Everyone in Kainos cannot join the tech leaders group, otherwise it wouldn’t be a leaders group. It is intended for those with the most experience, who are doing a technical role and have plenty to contribute across all our software disciplines — development, architecture, testing, webops. This typically aligns with those who have senior roles though this is not part of the criteria for us.

Even though membership is restricted, I would like it to be a glass box not a black box. The things we discuss and agree and change need to be visible to everyone in our organisation. Admittedly this is something we haven’t been particularly good at, it is too easy to get drawn in to a club membership mentality. But we are improving this weakness by publishing a digest of content from meetings and we will also re-run the most popular presentations from our face-to-face meetings for a wider audience.

4. Meetings are for decisions, slack is for information sharing

The tech leaders group meets face-to-face for an away day every 3 months. Face-to-face is important because we are a distributed organisation with projects and locations stretched across multiple countries. I find it is also important to facilitate productive collaboration and debate.

Face-to-face meetings are a big event. They are a whole day event where the goal is to make decisions about change we need to make. I invite one topic to be submitted from everyone in the group — and it could be a presentation, a discussion or a survey. Recently we have been adopting a theme for the away day, the last theme for example was innovation: this helps focus the submissions.

But meetings are not enough on their own. So we have a slack channel for day-to-day discussion and comms. This is very active private channel though again its easy to fall into a club membership mindset so one to remind everyone if the discussion should instead be on an open channel.

5. If you are in you must participate

It’s really important to have an active group. So we insist that everyone in the group participates — especially in the face-to-face meetings. After all, if you are not contributing then maybe you don’t need to be in the group.

6. There are no remote joiners or observers for meetings

We’ve tried lone individuals skyping in or dialing in. This doesn’t work with today’s commodity technology. Perhaps in the future this will be better but in order to facilitate productive meetings we adopt a strict rule on no remote joiners.

We also have a no observer rule for meetings. This is because meetings are for participation. If we manage to successfully publish content from meetings then everyone who is interested can catch up without needing to be a silent observer.

7. There are no walls inside

Within the group we have no walls between roles or disciplines. The group is currently a mix of developer-architects, QA, webops and Russell who leads the government digital business. No topic is off limits and we actively try to promote cross-discipline debate. This helps senior technologists be aware of and conversant with design, development, security, test, devops and what is important across our business.

The future

What we’re doing next with the digital technology leaders group is to grow this beyond just one business unit. We have just this month joined the digital technology leaders across government and enterprise business units because of the shared benefit. We suspect that the same active improvement on agile-security-development-architecture-test-data-webops will apply across organisational boundaries so it makes good sense to break through these and collaborate.

Another future aim is to blend data science more naturally into the group as this capability grows to match our technology capability. We will also be trying to figure out to share benefit with a closer join-up with nascent Delivery Manager and Product communities.

If you examine the photo above you’ll also notice that we have a diverse bunch of people — from different countries, disciplines and generations. We also have good representation from the ginger community. One diversity area we do need to improve is more female representation though this is sadly representative of the dearth of female developers and architects across our industry.

We’re on the look out for great developers, architects, webops and testers who want to work with us to build great software that meets user needs.

If you want to find out what kind of person we’re looking for read about how we hire software architects.