Can we actually do sustainable working?

Ok, time for another rambling post about mental health.

Over August I took a week away from work, and I came back feeling so much better. I was away from Bath for a few days, and the change of pace and change of environment was incredibly refreshing. I felt ready to face some of the challenges that only a week before were making me want to hide, and for the first time in ages I didn't feel a sense of gnawing dread at having to face work again.

This is all great, and we all know about the healing power of a break from work - and why it is so important that the break is a proper, clean separation and not just answering emails in a less convenient way. A break always make me feel better, helping me recharge my batteries and replenishing energy to face the next days. However, this time, the change was dramatic enough to remark on it, which doesn't seem right. We talk a lot about sustainable working being an important part of a caring workplace culture but a properly sustainable working life should not really require holidays to recharge. Holidays should be a positive extra, enabling new experiences and life learning, not just a break between work-marathons to collapse and pull oneself together.

I've had seen this fatigue growing in me over the preceding months, and I can see it trying to grow again now I'm back. I am paid to work a certain number of hours a day, and (accepting that my role will require some flex in this) I should be able to enjoy the other hours in the day. However, if I am getting to the end of the day knackered and just looking to crawl onto a sofa and close my eyes that is not giving me any sense of life outside of work (and if it gets worse, it can knock on to bad behaviours like takeaway food replacing cooking, etc). This, for me, is where "sustainable" really kicks in.

Of course work is going to be stressful at times - that is pretty much a given. Also, I am certainly not currently in a strong mental state. I am very definitely still recovering from burnout and this has made me more vulnerable to mental exhaustion and less able to shrug off personal slights that wouldn't have phased me in better days. However, these things are amplifying existing problems, not creating new ones. Things that have been draining me for the last few months would also have done so previously, just less so. 

So what can be done? While I believe in trying to create a sustainable work environment, I also believe that many places of work are more about talk than delivery, and are unwilling to get under the hood of the problems. Often this is because it is the leaders who are talking about better working conditions, while creating the unsustainable environment. Where I am now, the leaders do indeed talk about sustainable working and energy ladders aaaand I'm one of the more senior leaders in my department. Damn. Better do something of that "modelling behaviour" thing.

There are infinite variations on a sustainable working environment, but they must address two core points. First, the number of hours worked. People working long days and weekends are not working sustainably and the obvious question is why is this needed? Are they under pressure from the organisation? I know I do not deliberately push anyone to working antisocial patterns (quite the opposite, actually) but do I create an environment where they have to?

This is a more difficult question. I know I work long hours at times (with no good consequences - see all the above) which sets a bad precedent. I know I need to model the behaviours I want to see from those for whom I have responsibility. I also know they have far too much to do, as do I - I don't work long hours for fun. So the problem is volume of work against capacity? At least partly - and for this we need to aggressively take an axe to the department "to do" list. We've already pledged to do this, and the hardest part will be gathering the information required to enable the conversation properly. This is, of course, more work...

The second point is the activity during those working hours. My current boss likes to talk about energy ladders and energy drains (disappointingly, not energy snakes). To put it another way - things that make us interested / excited / give us an energy boost vs things that sap our will to live. There will always be things to do on both sides, but the balance is very important. For me, I'm realising that my balance has been horribly off for quite some time. I'm also finding that things I've previously found ok are more draining at the moment.

So I need to cut back on the things that make me miserable, whilst maximising the happy. Fortunately, my job is supposed to be all about strategy and future horizon scanning. I enjoy this. Unfortunately, we've been mired in tactical decisions and putting in the foundations to enable The Future. I usually don't mind this, but at the moment a typical working day is emails, then unbroken meetings for 6 hours, then more emails asking why I haven't answered the first emails. No matter how interesting the meetings (and some are great ... some) I find remote meetings exhausting and full days of the things are lethal. I can feel this affecting me. So I've decided to make some changes. I've blocked out a lot of my diary to get things done. Now people are complaining they can't get hold of me, but it's better than complaining I haven't done something.

So will this help? Can I make my own working life sustainable, let alone help anyone else? That remains to be seen, but I am sure that pushing away from "survivable" is the right thing to do.

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.

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.

 

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"!

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.

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.

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:

• https://github.com/tomnatt/year-in-pictures-rails-helper/pull/88
• https://github.com/tomnatt/year-in-pictures-rails-helper/pull/89