Saturday, 16 July 2022

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.


Wednesday, 29 June 2022

Kind helpfulness

A short muse ... what does kind helpfulness look like? I've been pondering this question as I've been thinking about how to help people develop. When someone is struggling, there is a natural tendency to help shoulder the burden. Sometimes that is the right thing to do, but is often a tactical solution and in the context of work is that helping the individual or myself? It's the shortest route to making the problem go away, and has the highest likelihood of getting the result I want. But there is the cost of the individual losing a learning opportunity, or worse feeling disempowered.

I started consciously thinking about this some time ago when playing some Dark Souls 3 coop with a friend. The Dark Souls games are famously difficult, and are pretty much defined by learning and overcoming challenge. However, someone dropped into our game and ran around killing enemies, pointing out secrets, and generally paving the way to a very easy experience where we were tourists in our own game. He was certainly helpful, but he completely robbed us of challenge, accomplishment and learning our own way through the game.

This comes up all the time in leadership. Someone asks for help with something complex like recruitment, so I step in and then they don't learn for next time. There is a learned helplessness in teaching someone to reach out for the solution instead of working through it and for technologists there is a longer term rot from not letting individuals own (and solve) non-technical problems, as this is where we struggle to get experience in the day to day job which then blocks moving into more senior roles. Very much "teach a man to fish" territory, although of course it needs balancing with not leaving people helpless and floundering.

That said, maybe we should lean into the Ron Swanson method for mentoring? "Don't teach a man to fish, feed yourself. He's a grown man and fishing is not that hard".

Of course not directly, but there is a point in there about being kind along with helpful. Kind helpfulness assists someone overcoming a challenge, but doesn't remove the challenge entirely. And the kind helpful leader makes sure where possible there is space for this process to happen - it takes time and safety for people to learn, after all.

Short post this month. It has been a difficult one.

 

Saturday, 21 May 2022

Fun with email

I have a love / hate relationship with the cliche "work smarter, not harder". On the one hand, as a technologist it forms the core of so much of how I approach problems. "I don't like this weekly task" leads to "how do I standardise this to think less?" then "now it's standard, can I automate it?". Then, much later "how does this script work again?" but I'm going to ignore this last step.

On the other hand, when it's said out loud it tends to be by people who are responsible for pushing too much work on to the individual, then sidestepping said responsibility when it comes time to actually help them out. Often with a side-dose of being too stupid to actually provide the "smarts" to lighten the load.

With this in mind, I want to think a little about collective efficiency, and how we can all help each other out when it comes to email.

When I was a starry-eyed, enthusiastic developer at the bottom of the social totem pole, I learned to hate the "I have a reckon" emails. Typically, someone would dash off a half-thought about some kind of feature development in about 2 minutes and send them over. I would then have to spend half an hour working out what they actually wanted then another couple of hours writing some kind of considered response (usually attempting to shut down this idea). That's the afternoon gone, immediately. Thanks, important person.

Now I'm In Leadership I try very hard to avoid this kind of email. I try to create an environment wherein I can answer my own questions, without bothering people who have better things to do than answer my questions. If I DO need to ask someone something, then I do my best to ask a clear, answerable question to help the victim / recipient spend as little time as possible on me.

So - linking to the original point about working smarter. Everyone knows that at work you aren't working alone, you are part of a team. It is not you that needs to be efficient - it is the ecosystem. If you're highly productive, but you're wasting your colleagues' time, energy or will to live then you are causing a problem for the collective. This is true from large actions (eg how one manages a project) through to the tiny (eg sending terrible email).

But this is more than simply unnecessary email. When one sends an email, the context is all in the head of the author. If the recipient has to spend time actually working out this context, that is time thinking which is going to be far longer than time spent writing. Even worse, if it is forwarding a conversation thread so the recipient also has to read a multi-step conversation between two people with little to no context. Oh, and of course the thread contains 30 page attachment too. Because why not at this point.

So, the original email is "what do you think?" - 20 seconds work on the part of the sender. The recipient can take half an hour or more getting through the information to come to the answer "err ... about what?". Now, consider that the recipient is actually five people. That time multiplies up very quickly.

Imagine instead that the original sender spent a bit more time summarising the content and asking a clear question. Maybe a whole hour? That's a long time to spend on an email, but this is one hour with five two minute responses for a total of 70 minutes from the wider "work ecosystem". In the original example, it's 120 minutes from the ecosystem as well as five rather irritated recipients. This is without mentioning that tying you up for the time you are writing a better initial email prevents you causing damage anywhere else...

So that's email. Now let's talk about booking meetings without causing diary conflicts...

(From Oracle Calendar - screenshot from back in 2011 - apparently I have been irritable for a long time)

"Gosh, that is an inane post" I hear some people crying. Yes and no. While the email example and numbers are clearly fabricated, this is a real problem. I've written before about writing well being a highly important skill and this is a variation of my usual comments, going beyond "clearer communication" into efficiency. As leaders, it's important to consider how much damage our actions can cause without any intent or us even realising. Our role is to empower our people to be the best they can be, and being considerate of their time and helping them be on the front foot is an important part of this.

I believe someone once wrote "do the hard work to make things simple"!

Sunday, 3 April 2022

Speaking the right language

We've been deep in discussion around the way for a technology department to talk to the rest of the organisation - going into enough detail to engage in a conversation, but also keeping it interesting enough that they want to.

We've got a drill, and we think it will help. It's a Bosch, developed to the highest standards of German engineering. It is a hammer/drill with an 18V brushless motor, able to deliver over 110Nm torque with 0 - 31,500bpm and variable speed and power with a precision clutch. Also, good news! It only weighs 1.6kg (without the battery), has KickBack Control and can connect to the Toolbox App for customisation. And our other tools are also made by Bosch, which helps. Actually we have a few drills - we could go into detail about the others too?

Of course what they actually WANT is a hole, measuring 15mm diameter, created on the correct day...

It is no secret that we technologists speak our own language, and people talk about "learning the language" in order to understand the technology department. However, it is really our responsibility as technologists (and especially those in positions of leadership in technology) to solve this problem. We need to go to our colleagues, not expect them to learn our world. In tech, the thing we're delivering is a piece of technology and so when we talk about our work it is easy to end up talking about that thing. But the technology is worthless in a vacuum - we are working on it about it because it solves a problem and it is in that context we should be engaging with others. That is where the common language sits, and we can do the "translation" ourselves. We should talk about what the best hole looks like, rather than how we drill it.

This isn't to say all aspects of technical service providing should be hidden. That approach makes it very hard to talk about the complexities of maintenance or incident management - areas often ignored by the wider organisation. But even in these spaces we can talk about the problem space rather than the solution. We can talk about the desire for uptime, and online engagement patterns as ways to make deployment and incident resolution matter in context. We can talk about the organisation's need to be secure and be able to easily implement new business processes as context for explaining the need for maintenance and upgrade work. Again, stepping into the business context when communicating outside the technology department.

Furthermore, it's important the technical department shows its hand so decisions are made transparently, else the technologists end up hidden away in a shadowy corner making decisions nobody understands. This is not good for trust, as technology becomes something that is done to the wider organisation, rather than part of collaborative problem solving. Building open trust is important, however it can also put technology at a disadvantage - the greater need for transparency can easily end up morphing into a greater need to justify activities compared to other departments.

Discussions about technical decision making should be something that is available for those who want it, rather than the barrier to entry for any engagement with the technology department. There needs to be a clear and positive division between "you need to know this bit" and "you are welcome to engage with this bit if you want". This is especially important in this increasingly digital world where "engaging with the technology department" is analogous to "delivering any major project". It is our responsibility to make sure we are positive partners.

Couple of disclaimers - the drill / hole analogy is not mine, it has been around forever. And I know very little about drills.

Monday, 28 March 2022

Learning at the right time

A few years ago I wrote about practical life lessons learned from playing Dungeons & Dragons. Many roleplaying systems handle the advancement of character skills with a level system. Over time your character gains experience and when you reach a set threshold you gain a "level", which is a collection of abilities and skills. Your choice of character class defines the set of abilities you gain.

So far, so simple. Many years ago, I was playing in a game in which we were forced to enact a dangerous escape in a spaceship. My character was the most competent pilot in the group, which meant he had enough knowledge for the ship to not immediately drop out of the sky. A few very lucky dice rolls, and a suicidal ramming of another ship later and we limped out of the gravity well, escaping to hyperspace in what was left of the ship. Much fun was had, and I gained a level - which I used to improve my piloting skills. Immediately AFTER I needed them.

That scenario never came up again, of course.

In my experience, this is very common in roleplaying games - spend the time learning skills for a scenario that has already occurred. It's also something I see all too often in work. People learning about change management immediately after a change, for instance, or about HR processes immediately after struggling through a difficult piece of casework. In technical delivery, learning how to use a frontend framework properly after releasing an accessibility nightmare onto the public or how to monitor your service on $cloudProvider after implementing their new and shiny features and deploying using it.

I've done this myself many times. So why is it so hard to look forward and learn skills ahead of time? The broad-brush problems should be very predictable. Technical strategy should show which skills are going to be needed in the next six months and longer. Moving into a management role makes change management and some kind of HR process work pretty much guaranteed. For me, there are a couple of problems at play.

Firstly, management work can be far too reactive. More than that - being reactive is actually very seductive as it feels far more productive. It isn't; but the feeling of being needed because you're putting out fires is highly addictive, especially shortly after coming from a discipline with a strong way of defining productivity such as development. I spent most of my early days after moving into leadership trying to force myself onto the front foot so I could actually think ahead instead of running around fixing problems and if I'm honest I didn't really want to make this change.

Secondly, even when there is a chance to look forward we often don't actually have a chance to act on what we see. I know that dedicating hours to studying various aspects of management and reading supporting books will help me, but I certainly don't have the time to do it without making serious compromises in what I have to deliver or just consuming my non-working time. Neither of these solutions are acceptable. Part of this is about having any spare time during the working day, and to study there is a need for some quiet reflective time which is particularly difficult when everyone is trying to reach you for whatever Opinion is needed at that time. But also, I need to give myself permission to study and acknowledge that this is part of the job.

What should we expect from leadership? There are times of difficulties and change, but in general I think it's reasonable for people to expect some form of considered development from their place of work. In these enlightened times, we've moved past "bring them in and use them up" as a management style (insert correct cynicism here) and certainly in a knowledge-based job like development, constantly building skills is essential for an individual's future, as well as of benefit to the organisation. Not to mention retention and in-house skill development is far more cost effective than hiring and firing in this sector. This leads straight to an obvious point - we should be building organisations which value learning, and that means making time and expertise available. For those of us who talk about taking on apprentices and other "learning" roles (which done wrong can destroy someone's career as it starts) the point is that much stronger.

So what is the key thing to learn here? Well, it's important to look forward rather than backwards when deciding what to study. Beyond that, it's a well-rehearsed refrain at this point. Scanning the horizon is fundamental to a successful leadership role. Acting on what one sees there is essential. Both of these require time and carving out time is hard. However there is an extra thought here - giving oneself permission to find and spend time on learning is an important step, and being able to do so is part of the organisation's culture. This is important for anyone, but especially in a position of leadership where one can have a strong voice setting that culture and enabling others to grow.

Sunday, 13 February 2022

Upgrading to Rails 7

I run some simple Rails applications which I keep upgraded. I recently upgraded Ruby and Rails versions and since it's upgrade season, I'm making a note of my experiences ready for the next application I do, and on the off-chance it can help other people get started. And a reminder that I do do technical things occasionally, honest.

To note - this is a very simple Rails application, so only covers the basic gotchas I experienced. It was an app originally written in Ruby 2 / Rails 5 and in this iteration is now being upgraded from Ruby 2.7 / Rails 6 to Ruby 3 / Rails 7. The code is stored in a repository in Github, with CI done both via Github Actions and Codeship and deployment to Heroku.

Ruby upgrade

Good news! The Ruby upgrade (2.7.2 to 3.0.3) caused no problems at all, although I did need to update my Codeship config to remove the explicit installation of Bundler in my setup script.

Rails upgrade

I made use of the Rails upgrade guide - in particular I bounced the version of Rails in my Gemfile from 6 to 7 then ran bundle exec rails app:update which introduced the usual ton of rubocop violations but also created some migrations acting on some tables which didn't actually exist.

These were ActiveStorage tables so I needed to create them with bundle exec rails active_storage:install then rearrange the migrations to get them to work (ie put the creation migration before the modify migrations). I probably could have eliminated the new migrations since I'm not using this function, but it seems there are other references to these tables. It looks like Rails expects these tables to exist, and the lazy option was to create it and be on the standard path. So I was lazy. Those migration do not include timestamps, so I had to add those to appease the linter.

Second show-stopping problem - Rails 7.0.2.1 was a trap. It turns out there was a bug in ActiveSupport which manifested in a variety of different ways. For me, it stopped almost all automated tests working. It was reported and fixed quickly but did manage to cost me a chunk of time trying to figure out what was going on... Anyway, the simple fix is to use Rails 7.0.2.2 instead.

Now fixing some deprecation warnings. action_cable has been renamed to actioncable and this will escalate to a breaking change in Rails 8 so this needs updating in app/assets/javascripts/cable.js.

Also, I was getting references to using older (Rails 5.1) CSRF protection behaviour. There are a load of defaults which are version locked in config/application.rb and these can be upgraded with config.load_defaults 7.0 as per the upgrade guide.

Locally, this was all that was required however when I deployed to production, the heroku build failed at bundle exec rake assets:precompile. Uglifier needed ES6 syntax enabling, with config.assets.js_compressor = Uglifier.new(harmony: true) in config/environments/production.rb.

And that was it! As I said, a very simple application so I'm sure I avoided much of the upgrade pain but I've noted my experiences here to help others get started.

All these changes are captured in a pair of pull requests:

Monday, 31 January 2022

Recovering a sense of wonder

For the last few years I've started the year with a post about how January is bad and I want to reboot the year. This year is going to be different. While I could certainly be having a better time (as could many) I'm facing 2020 round 3 with a sense of cautious optimism.

I spent a lot of time over the Christmas period reflecting on what has changed for me over the last few years and one thing that I think I've lost is my sense of wonder. That childlike sense of feeling the magic in the world, revelling in something small but infinitely complex, and enjoying the feeling that I can explore something and there will always be more to learn.

I say lost - I think I prefer to think "misplaced".

This isn't the kind of thing that I can analyse and come up with a formula for change. It is not something that will come from deliberate action. That said, while there isn't a "solution" here, some deliberate steps can lead in the right direction.

On reflection, what I'm really missing is what comes before - that level of contentment and general feeling of peace when I'm open to the world and new experiences. There are several active things I can work towards, but at the heart of it for me really is personal space. Odd to reflect on after nearly two years of being pretty much entirely alone. That space is better called "free time" - those moments when I don't have some pressure on me to do something. Pressure from real work, volunteer work, paperwork, need to write a blog post, put up pictures, etc. In those free moments I can pick something up (literally or metaphorically), look at it, turn it over and actually experience it. I can engage with something in more than a facile way before rushing off to the next thing, and I can take the opportunity to see the beauty and wonder in it.

So this year, I'm going to invest time carefully. I'm going to try to only do things I actually want to do, minimise the things I have to do and avoid being pushed into doing things I don't want to do. I want to keep my time precious, so I can put more space around the things I enjoy - and by that I mean take the time to enjoy things properly. I'd also like to actually finish some things. While I don't want to be ruled by todo lists, I do actually get something from completing a task and putting a line through it. There are some things on my "want to do" list that have been there waaaay too long and it would be nice to make some progress in the areas I've identified as things I actually want to do.

More than anything, I need to relearn how to Enjoy the Thing. Through that I think I'll start the see the beauty in the world again and that is the route back to wonder I feel.