Why hire a Head of Community?

One of the hats I have worn during my career is "Head of Community" for Software Engineering. A few years ago, these were rare roles but these days we're seeing them pop up more often. Since we at Macmillan are currently recruiting for one, I thought I'd write a bit about why they are a Good Thing, despite the rather strange mix of requirements. This post is not sponsored!

So, you have a Software Engineering group. Why should you hire a Head of Community? 

If you've hired developers and other technologists, you know they are hard to bring in and retain. A typical developer role last to about three years before they move on and when they do, they not only take their professional expertise they also take all the knowledge of the organisation's technical estate and business problems that has accumulated in their heads. This is expensive for a variety of reasons and surely we can do better? 

Your organisation has almost certainly been describing itself as proudly investing in its people (everyone does, whether it's true or not). If we care about people, why are any initiatives done as extra work by people who have a heart for that kind of thing? Why are these extras the first thing to go when time is squeezed? Why is there not someone with clear space to think strategically and holistically about essential problems like careers, recruitment, support, mentoring, and so on? These often are shunted off to organisation-wide initiatives, which is good as far as they go, but these areas require specialist knowledge born of experience to be credible.

A Head of Community role brings together professional expertise (and another senior technologist never hurts) with the mandate to improve the lives of the technologists in their community. Happy people are less likely to leave, which obviously is a good thing for retention. They can devote time to finding diverse sources of recruitment and reaching people who might otherwise be overlooked. Furthermore, getting the basics in place across the whole organisation saves considerable effort in recruitment and performance management and enables a consistent experience for all those working there.

Fundamentally, Head of Community roles are about putting our money where our mouth is when we talk about valuing people.

Ok - you're a lead developer, or an engineering manager or some other technical leader. Why should you consider being a Head of Community?

Personally, I see it partly as giving back. Everyone with experience in technology has had to gain that experience somehow. We've all had our first job, made our junior mistakes, and so on. This is not an easy process for most. Technology is a famously hostile and toxic field, and some have it far worse than others. And yet, technology underpins most of the modern world. There is no shortage of work - there is enough of a shortfall in people to do the work that the government set up the Institute of Code to look at the problem. But Computer Science graduates struggle to find work. Why is this? Why can't people get into an industry crying out for workers? 

As an industry, we can do better. We must be thinking about the next generations of technologists. It's as important to the sustainability of the industry as making sure our code is well written and understandable in the future. Roles such as the Head of Community roles are created to give space to enable specifically this - to grapple with problems like "how do we recruit juniors in a safe way?" or "how do our people grow?".

Maybe this isn't enough - you'd rather be writing code. Understandable, but what about in five years? Ten? Do you want to be hands-on your entire career? If not, what is next? If you want to progress into senior leadership you need experiences beyond the hard technical. People-oriented roles such as a Head of Community enable broader learning, dealing with HR challenges and issues, line management and operating at a wider scale through people. However there is still a requirement for technical understanding, so do not require stepping entirely into a different career. For someone who wants to be a Director or CTO, this kind of experience can be extremely valuable.

If all this sounds interesting, a reminder that we're currently hiring a Head of Technical Community at Macmillan.

Surviving the world of post-technical

Back in the olden times, when I used to do a real job, I spent my time writing code and making awesome things. Nowadays I am post-technical which means I mostly talk to people, sit in meetings and play with spreadsheets. Making the jump from operational work to a leadership position is not easy, so I thought I'd write about some of my experiences in the hope it'll help someone making a similar journey.

One of the hardest parts I found of moving to management is understanding what a good and productive day looks like. A reason people find programming so compelling is the process of breaking down problems into small, achievable chunks then completing them in a short period of time. At the end of the day you can look at your work and say "I had a good day - I made that". This is a tight emotional feedback loop which triggers positive emotions and makes us happy.

Moving into management breaks this loop as, initially at least, much of the work is variations on supporting the people making things. It's important, but not as immediately rewarding - especially since most of it is never really "done", it's forever maintaining things. It's very important to learn how to limit maintenance and support work or it can easily become all-consuming - especially since if you know what you're doing everyone will want your involvement. Taking on too much is particularly tempting early on as, if you're anything like me, you'll want to do something concrete and maintenance work looks like a short-term deliverable that will help justify your existence. This can easily fill your time and you'll be unable to do anything else - anyone who has suffered under a reactive, passive manager will know where this road leads. One of the most important questions I (accidentally) asked early on was "how do I stop being so reactive and start taking control of my work?" The answer was long and difficult in practice, but the theory was simple - be discerning about what ended up on my plate.

In the early days of management I was given things to change, handed down from On High. They appeared in the form of business needs, which needed translating and socialising before anything could be done. The basic but important questions to get through this were: Why is this change important? What (hopefully positive) effect will it have on the people I'm looking after? Why do the operational people want or need to care? It's very important be able  to champion whatever is going on and there were definitely times I found myself unable to express clearly the case for change so I spent long hours talking to people and going back through decisions to regain that context. "Why" is a very important question - you're going to be asked it a lot, so you really need an answer ready.

When it comes to communicating change, the key tips are to keep the message simple, keep saying it and listen to feedback at least twice as much as you talk. In fact, "listen a lot" is my strongest single piece of advice for making moving into management or indeed any leadership role. As a rule of thumb, the more authority you have, the less you should be talking.

These basic experiences about managing change have come up again and again, however the steps take a long time and frequently loop around while appearing to go nowhere. This brings us back to the original question on how to get some sense of accomplishment from management work. Fortunately, for me the answer was also the answer to the questions "how do I effectively deliver anything?" and "how do I show the organisation I'm doing something useful?" and comes in the form of work objectives. Everywhere I've worked has required objectives written in the SMART format. As a manager thinking about these in detail suddenly becomes very useful as they force a scoped deliverable in a known timebox and defines a "done" state, which lets me know when I can stop thinking about something for a time. This isn't particularly insightful, but it's easy to skip over when the pressure is on. I've made that mistake several times, but taking proper time to think and plan deliverables and end states has never been time wasted.

Much of the above is about scoping management work in completable chunks, and therefore bringing it back to the more familiar patterns of product delivery. At the same time, I did have to get used to the new cadence of work. Plans and changes can take a long time to seed and grow and I frequently have periods when it feels like everything is just a slow grind. Then every so often the work comes to fruition and several things bloom at once. The feeling is different from cracking a difficult technical challenge, but no less powerful. However it is far less frequent.

There are other fundamental changes to watch out for when making this switch in role. It's important to get used to making decisions. In a leadership or management role you can't hide at the back, or as a voice in the crowd. In order to be comfortable making decisions, I had to learn the detail of how I make a decision (how much information I need, etc) so I could justify it to others if the need arose. Learning how to make a decision is an art, and a very important one when taking up a role where making decisions is basically the job.

Part of that is understanding the limitations on the decisions you can make. What are the limits of your authority? When do you need to escalate and (just as important) when do you not need to? What does and doesn't the organisation let you do? This last is worth gently pushing and questioning as I've found the organisation will be used to giving you the same authority as your predecessor took and that is not necessarily the same as the answer to the first question about limits.

To frame it differently, I see learning what I can and can't do as learning the rules of the game. I don't have to use everything, but it's helpful to know where I can reach out and when I'm in danger of doing something wrong. It also helps me take ownership of the things I'm doing. A manager who doesn't do this and passes on messages from their superiors just looks weak and ineffective and that is awful for the morale of those who depend on them.

Final tip for now - it's important to find a team of people you can trust. Everyone needs support but you can't sit in a pub grouching in the same way you used to. Finding a leadership team is very important for getting things done, but you do need to be open to this team changing. There is a very real danger of building a clique and alienating people, denying development opportunities to new and growing people and causing problems via your own biases (both conscious and unconscious). At the same time, those kept close need to be able to grow and sometimes that means them moving on into their own space.

So, the summary. It's a mental shift going away from technical work and something not to everyone's taste. If it's happening to you, I hope something here has been of use.

Why I do this job

My life has changed quite a bit this year. I started out as a Lead Developer working on our new reliability engineering programme then our Head of Software Engineering moved on to pastures new and against all sense They saw fit to put me in charge of over a hundred technical people, including their hopes, dreams and careers.

The handover was a bit of a whirlwind, but I distinctly remember standing in our foyer as I was leaving on the handover day, thinking "shit, I'm Head of Software Engineering here".



Yeah, the imposter syndrome was very real.

So anyway, there are highs and lows in any job and when those lows come around it's important to remember why one does the role. In my case, I laid it out the other day in a brief presentation to the department about the software engineering community. Community is defined as a group which has the same attitudes or interests in common - by that definition, the software engineering community is a loose collection of people who happen to do the same job. For me, that misses a great deal - people don't spend their lives seeking out community because they want to share a label.

Community means connection, safety and support. It means being able to grow, safe in the knowledge that others around you acknowledge your strengths and weaknesses, where you are on your journey and are willing to give of themselves to help you come along. It means being able to reach out to people around you when you're in need of help and be confident you'll find a supportive response. It means an environment you can be the best version of yourself that you want to be, whatever that might mean.

This doesn't happen by accident. It is all driven by connections between people and these take time to grow and need space in which to thrive. At work, this means many things but I think they can be boiled down to two axioms: enabling a safe environment for people to talk and creating the space for them to do so.

Community leadership has a responsibility to create the space for community to flourish. At GDS one thing we have is a monthly community hour which brings technologists from across the organisation together. We have various activities which are carefully considered to encourage participation by our very own liberating structures expert, David Heath. However, no matter how much work he puts in the gatherings are only successful because the community turns up and engages. Because everyone shows willing, barriers are broken down and slowly people get to know each other.



This is just one example. I've written before about Show & Tell, and I'm also looking at different ways of helping everyone have a voice. But I'm also challenging people with the response "so what are you going to do to help?" - a question which not only helps increase the possibilities of the community, but also gives important opportunities for growth to the individual. All of this needs to be carefully balanced against delivery of course, so putting in place sustainable events is very important as it's all too easy for any kind of community to vanish when the crunch comes and people turn inwards.

I'm deliberately not writing about diversity in this post, but clearly implementation of anything here needs to be considered from a variety of different angles and this brings me back to that presentation and the real reason I do this job. We can discuss groups of people and even do some good things to help them, but that lays down a wide path that goes from A to B when it's too easy to forget that that group is made up of individuals. Every single one a different person, with different hopes, dreams and needs. Each is coming from a different place, with a different collection of experiences and each is going to a different place. In short, they are different.

This isn't to say that broad-brush improvements aren't important - they are vital for raising the base level for everyone. But they should be viewed through the lens of "this will affect X individuals" rather than "this group behaves like this". It's essential to remember the individual, even though in a position of leadership it's often impossible to know everyone. That doesn't mean we shouldn't do what we can.

If I vanished tomorrow, those who remembered me wouldn't remember the hours of meetings I attended or the improvements to our governance structures I've implemented. They'd remember how I touched their individual lives - the battles I fought for them, the time I spent with them talking through their hopes and fears, and the ways I have helped them move forward in their lives and careers.

This is why I do what I do. Because day by day I like to think that my efforts are helping to improve the lives of the people around me who are doing such good work - not as a group, but as a collection of individuals.

It's inevitable we're going to end on the parable of the starfish:

A man was walking along a deserted beach at sunset. As he walked he could see a young boy in the distance, as he drew nearer he noticed that the boy kept bending down, picking something up and throwing it into the water. Time and again he kept hurling things into the ocean. As the man approached even closer, he was able to see that the boy was picking up starfish that had been washed up on the beach and, one at a time he was throwing them back into the water. The man asked the boy what he was doing, the boy replied, "I am throwing these washed up starfish back into the ocean, or else they will die through lack of oxygen."

"But", said the man, "You can't possibly save them all, there are thousands on this beach, and this must be happening on hundreds of beaches along the coast. You can't possibly make a difference."

The boy smiled, bent down and picked up another starfish, and as he threw it back into the sea, he replied "Made a difference to that one".

There are various ways to read this - it's supposed to highlight the power we have as individuals to change lives, and doing something is better than nothing. It's not supposed to dismiss the need to ask wider strategic questions like "why are they on the beach in the first place?" or "can we stop this happening again?". However it does contain a warning against asking those questions, while forgetting that all the while there are thousands of individuals dying on the beach.



Also, starfish are weird.