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.

Friday, 31 December 2021

The year that was, 2021

Good grief. Astonishingly, 2021 was a year that happened. Even better, it ended. As I start writing this post, I am honestly struggling to think of anything I've done this year however long-term readers will know that that is exactly the point of this annual post. I also don't write about work (until I do) which is going to be a big deal this year. So, with that in mind, what HAVE I done this year that isn't all Deep Rock Galactic and Dark Souls 3?

  • 13 posts on this blog (14 including this one) - seventh consecutive year of a post per month
  • another year of the Year in Pictures site - this is the seventh year and we're up to 33 photographers
  • 264 contributions on Github - down on last year, but better than I expected
  • started writing a new D&D setting
  • got back into gaming (including finally understanding the appeal of and completing Dark Souls 3)
  • made a point to read a lot more than 2020 - important since I've lost my train journey reading time
  • did a lot more cooking - both learning and keeping it regular
  • attended a cooking class (and learned about sauces)
  • learned a bit more video editing - made a birthday video for Matt and a tour of my Valheim home
  • increased exercise and felt it actually start to do something
  • made a colour changing potion
  • learned how to use a multimeter
  • bought some lightsabers!
  • finally started building some LEGO
  • upgraded my home network with a UniFi Dream Machine
  • made a book
  • extensive Instagramming
  • loads of photos on my Flickr stream

Resolution count - 6.5/10. It's getting better, but I'm aware I made them easier this year as I was expecting a tough year...

Looking over these, I am once again pretty amazed I got anything done. However I notice most of these kicked in towards the end of the year, when Significant Events happened (more on that later). This could be classic memory bias, but I've spent some time thinking about it and this does seem to be a fair reflection of the year. I really did very little other than work for the first seven or eight months of the year.

So, speaking of work... Every year I say some variation of "this year has been too much about work but next year will change" and every year it gets worse. This year has been no exception - work has been all-consuming in a whole variety of different ways. However, this year I can genuinely say I've made a change. I left my job in the Civil Service. I've written about it before, and I'm sure I will do again so for now I'll note that it was a tremendously emotional decision and I have since realised quite how burnt out I really was. Since then, I've also set up a company (Third Way Digital) for all your digital leadership consulting and engineering needs and have taken my first steps working with a few different places.

And now for 2022. I'll say again (again) that next year will not be all about work. However, if I'm honest, I just don't know. Self-employed consultancy is a whole new game for me and maybe I'll be working really hard all year? Maybe I'll have nothing but time? I'm not sure which I'm hoping for, but a balance would be nice.

Other than work, I think it's time for some changes. We've all been stuck inside, looking inwards and not engaging with each other enough for nearly two years and for me that needs to change. I want to be looking outward this coming year. Whether it's in person, or via video call, I want to be more involved with other people in a healthy and constructive way. If you know me, expect a call.

I also want to be more creative. The last few months of 2021 saw me recovering and starting to indulge in creative projects. I want to keep that going and increase it significantly. I used to do a lot of making and I want to find that space again. I was set a challenge:
"I dreamt that you had built a mechanical light up version of the old school Channel 4 logo, which was on display somewhere, but as I was looking at it and going "omg Tom made this why didn't he tell us?!" a curator knocked it over and it smashed."
Good idea dream-me. However you're making me look bad, so you're going down.

My new year resolutions support these, however more than anything I want to find and restore my sense of wonder. I am naturally a pragmatic cynic, however until this year I've also retained a sense of wonder for the world. This year I think I lost it - or at least misplaced it. However what was lost can be found. That's 2022. From that restores an interest, and a general zest for life.

Let's do this.