03 Dec 2021
Recently my collegue Chris Sheldon posted an article titled
“Under Pressure”. It’s excellent so please take a few minutes
to have a read of it.
Ok, are you back? Great. Chris talks in part about feeling like he misses absorbing knowledge through osmosis in an office.
Osmosis, in case you’ve forgotten your biology lessons, is the spontaneous passage of something through a semipermeable
membrane. In this case, we’re talking about knowledge entering your head without you needing to consciously do anything
Working from home can indeed be an isolating time. In my experience, short term productivity
and intra-team relationships are (in general) not affected by working from home. The biggest impact is on inter-team
relationships and a lot of that is down to the osmotic acquisition of knowledge that Chris was talking about.
Back in the distant past (e.g. 2019) when you were sat near another team you would overhear discussions about what
they were working on. Whether consciously or not, this would lead to you instinctively knowing when there was overlap, or
when there were opportunities for collaboration. It would also lead to a feeling of working for a larger group than
just your team, and this would result in a closer connection to those in other teams.
If you miss out on this knowledge then it can result in duplicated work or conflicting solutions to the same problem.
So, what can you do to improve things?
If you aren’t going to acquire knowledge spontaneously, then you need to be more intentional about both obtaining and
sharing knowledge. The key point here is that you must be more deliberate about acquiring knowledge, but it’s also important
to be deliberate about sharing knowledge so others can benefit too.
In the office, you might have a network of people that you bump into and then go for coffee or a lunch with. These conversations
are goldmines of unintentional knowledge transfer. When working remotely, whether that’s full time or even part-time, these
networks take more effort to maintain and build, but it’s effort that’s well worth spending.
Schedule regular catch-ups with people, just half an hour is plenty of time to keep the relationship alive and gain a
nugget of useful information. As well as catching up with people you already know, ask them explicitly who else they
think you should talk to? You’re not going to bump into people randomly in a Zoom call, so be more intentional about
expanding your network.
If you have information that might be useful to others, then share it. Similar to what I was talking about above,
look for others that you can catch up with and give them information. Also in a world full of cross-continent collaboration
and multiple timezones written sharing of information is more valuable than ever. If you’re feeling fancy then putting
together a newsletter for your department is a great way to spread the word about what you’re working on.
I’m a big fan of the 5/15 update, which is probably a topic for a future post.
The summary however is that each week you spend 15 minutes writing a summary of what you’ve been working on, aiming for it to take
five minutes for someone to read. I post mine in a slack channel, but you could share it over email or wherever fits with your
company culture. This has benefits to me as it lets me look back over what I’ve achieved in the last year, it helps me organise
my thoughts on what’s happened in the last week, and I try to commit myself to goals for the following week. It is also useful to
others because they can see what I’m working on, what I’m thinking about and generally what is going on in my world - exactly
what you might get from a chat over coffee or sitting near me in an office.
Of course, you could argue that intentionality comes with a cost (usually time), and if the pandemic is over why don’t we all just
go back to the office where we get this for free?
At the time of writing the pandemic is very much not over, and the Omicron variant is rearing its ugly head, so returning to
the office is not desirable for everyone. But probably more importantly, it’s pretty clear that hybrid or even fully remote,
teams are going to the default in the future, rather than the exception. Whether it’s just someone who works in another country
or the whole team who are remote there is likely to be some degree of remote working, and for a hybrid team, the lack of
office-based osmosis is more of a risk than for fully remote teams.
With a fully remote team, everyone is in the same boat. No one is getting the in-person benefits, so everyone needs to make an
effort to compensate. With a hybrid team, some people will be benefiting so it’s easy for them to forget that remote workers
are missing out. In a hybrid team, it’s crucial that everyone makes an effort to include all team members in discussions and
knowledge sharing. While the team lead can share information, that should be a last resort and it’s the whole team’s
responsibility to ensure that everyone is included.
Despite some of the challenges of remote working, and remote leadership, this is now my preferred way of working. It’s certainly
been a steep learning curve, but with some focus and effort I feel it’s possible to get the best of both worlds. Do you have any
tips for sharing knowledge while working remotely? Let me know in the comments below.
05 Nov 2021
Imagine you’re making a change to a codebase you don’t like. Testing is difficult and you don’t have a
good understanding of how all the parts of the system fit together. It’s tempting to just do a bit
of cursory testing, deploy it to production and keep your fingers crossed. This is not a pleasant
situation to be in, and will inevitably lead to production incidents, sad developers and cross
As a manager, if you encounter a situation like this you’ve got a choice to make about how to fix it.
Instinctively you might want to put more processes in place around deployment and testing. Maybe kick
off a project to refactor the code base and make testing easier.
Maybe you can reduce failed deployments, but at what cost? Slower development caused by extra
bureaucracy and more policies to follow is going increase friction, delay releases and
eventually lead to an unhappier team.
The underlying problem is that the team feels disconnected from their software. They might own it
according to your org chart, but they don’t feel ownership of it. This lack of ownership can
manifest itself in many ways, but principally it results in a “good enough” attitude and a lack of
interest in the negative effects that a deployment might cause, or future issues caused by the
So, rather than adding more policies how do you encourage the team to feel more like the owners
of the software they are responsible for? There’s no one answer to this, but you can start
by looking at how detailed their future technical plans for the software are. A team that feels
a high degree of ownership will likely know exactly what technical changes they want to make over
the coming months or years. A team that doesn’t will be content with just tinkering around the edges,
or maybe they have some plans but talk about them in a jokey, “we’ll never get around to this” kind
If the team doesn’t know what they want to do with their software then you as a leader can help by taking
them through a process of working out what changes they do want to make. These need to be practical
and realistic, this is no time for pie-in-the-sky “let’s just start from scratch” ideas. If the team
is already in difficultly then you need to start small, and incrementally make improvements.
Begin by assessing where the biggest pain points are. Once you’ve identified the area come up with some
easy wins, and create time for the team to work on them. By starting small and getting something
done you can help the team feel a sense of achievement. It won’t happen overnight, but once the team
feels like they are making progress they will start to feel a sense of ownership.
Another aspect of feeling ownership is a connection to your clients. How easy this depends strongly
on what type of business you’re in, but it’s worth fostering this connection if you can. Maybe people
can spend a day shadowing a client? If you run user experience research then developers sitting in on
a few sessions will help build that connection. Developers don’t need to build as complete a picture as a
product manager or UX researcher needs to, but if you’re building something that it’s not possible to
dog food then gaining some first-hand connection with a subset of users will help people to think about
them in less abstract terms.
To try and build an understanding of your clients you might be able to get one to attend a town hall
or other meeting and talk about what impact your changes have had on them, what their priorities are,
or a recent success that your software has enabled. Hearing directly from a client, and putting a face
and a voice to them is hard to beat as a way to build empathy and understanding of your users.
If you’ve been successful you should start to notice a change in the behaviour of the team. They might be more proactive
about suggesting improvement projects and be keener to iteratively improve on what will still be a
“bad” codebase. Hopefully, you’ll notice a keenness to resolve issues more quickly, and more attention to
detail when preparing and executing changes in production. If a company’s users become the team’s users
then they will feel a personal responsibility for their experience, and for the success of your product
that can only be a good thing.
14 Oct 2021
Recently I went on holiday to the island of Jersey in the Channel Islands. As an electric car owner this
currently requires more planning than I would like. Inevitably, running an electric car on holiday is not
quite as convenient as being able to charge your car up at home, or being able to pop into a petrol station
and fill up in a couple of minutes. There are three 50kw chargers on the island, which can get me from
20% to 90%+ in just under an hour. Given the size of the island a full battery will last for five or six
days, so we expected this to be ok.
Although we’ve owned a Tesla for around nine months at this point our only drive longer than the range of
the car was to Northern Ireland and back, which necessitated a single stop in each direction at a Tesla
Supercharger and was quick and easy, exactly what you’d hope for. While we were there we were able to charge
using a three-pin plug where we were staying, so charge was not an issue. Unfortunately, the rented accommodation
we were staying in on Jersey didn’t have a plug near the car park, so charging overnight was not an option.
On our first day we happened to park in a car park with some 7kw chargers. We thought why not get a top-up while
we buy some food, so we plugged in and tried to work out how to start a charge. Most chargers on
the island are run by Charge Your Car so I had already downloaded the app.
First impressions of the app are not good - it hasn’t even been updated to support a modern iPhone’s aspect
ratio. Still, it was fairly easy to navigate to the right charge point on the map and click the “start charge”
button. This then directed us to add a card to the app so we could pay. The first stage worked fine, but then you
need to add the CVV number and the app returned a 404 Not Found error and that was it - there was no way to start
the charge. After 20 minutes on hold to their helpline, we gave up and left.
The next day I went to the nearest 50kw charger which while also run by Charge Your Car supported contactless
payment. It worked perfectly, so I could focus on my holiday.
After running the car down to about 15% I went back to the charger, only this time it refused to detect that
our car was connected. While I was on hold to the helpline a nice man from Jersey Electric happened to be
passing and he tried to help. He wasn’t able to fix the fast charger so he directed me to a nearby 22kw AC charger.
Sadly this was limited to 11kw due to the Model 3’s onboard charger. It was also managed by Charge Your Car so
the helpful Jersey Electric man lent me his RFID card to so I could top up. After waiting an hour (which at 11kw
only gained me 18%) I decided to risk a different 50kw charger.
After some difficultly finding and then parking at the charger as it was in a very tight hotel car park I was eventually
able to connect and set about trying to work out how to start the charge. This charger didn’t support contactless and was
run by BP Pulse. Downloading the app and registering was reasonably straightforward,
but instead of registering my card, I needed to top up a minimum of £10. Once this was done the charge started and I
sat back to enjoy my book. Unfortunately, after less than 10 minutes the charger crashed and rebooted. When it came back
it refused to start the charge again. Having wasted most of my morning and now on 50% charge, I headed off to enjoy
the rest of my holiday.
Fortunately, for the other two times I used the Charge Your Car rapid charger it worked flawlessly and as expected
the Tesla Supercharger on the return journey was perfect. Sadly this experience added more stress than I would like
to an otherwise enjoyable holiday. The UK is definitely not ready for the EV revolution, unless you are able to
charge at home, or only travel within the Tesla network’s range.
What suprised me most was just how anticonsumer the two charging companies I had to use were. Charge Your Car appears
to have been abandoned - an app that’s only had two minor updates in two years, and currently fails in its primary
purposed - to let you start a charge at their charge points. We also spent over two hours on hold, and the phone
was never picked up. BP Pulse was better, but only marginally. I did manage to start a charge, but the unreliability
of the charge prevented it from successfully completing. They also required me to top up a minimum of £10, so I now
have over £8 trapped in their app with no obvious way of getting a refund.
Can you imagine if petrol stations worked this way? You needed to download an app for each brand of station, and they
forced you to top a minimum of £100 before you could fill up. Half way through filling up it gives up and refuses to
add any more petrol. Cars would never have taken off and we’d still be using horse and carts.
As a smug Telsa driver with access to the Supercharger network it would be easy to think that I’m ok. That’s only
the case when a Supercharge is en-route though, and while widespread there aren’t charges everywhere and enivatably
I’ll need to use third party chargers occasionally.
The UK government seems to be aware of these issues, which is a nice change. They recently published a
which among other things highlights the reliability issues, and the consumer unfriendlyness of requiring app downloads
or subscriptions to be able to charge.
In a related move the Competitions and Markets Authority have opened
into a couple of charging companies who have signed exclusive deals with the main providers of motorway service stations.
They don’t mention Tesla, but given the exclusivity of the Super Charger network it wouldn’t surprise if they
were forced to open it to other users. This is something that has been rumoured for a while, but might be taken out of Tesla’s hands.
In general being an electric car owner is great, but I hope the market and governments pressure charging companies
to stop being so anti-consumer, or it really will set the revolution back by years.
06 Aug 2021
There’s going to be a bit of a change of pace this week, compared to my more recent posts. This time we’re
going to be getting deep into the weeds of Python typing.
One of the biggest recent changes to Python has been the introduction of type annotations. Back in the dim and
distant past I did my third-year university project on type inference in Python, around the time of Python
2.3. Now though, it’s a much more mainstream part of the Python ecosystem. Alongside tools like
black and pylint, the type
checker mypy is a core part of my standard Python set-up.
Adding type annotations to your code, and integrating a type checker into your CI pipeline gives you many
of the benefits of a statically typed language, while retaining most the speed of development that
is associated with Python. The dynamic nature of Python, and the fact that type annotations haven’t been widely
adopted by libraries that you might depend on, means that type checking has its limitations and sadly this means
it might not be obvious when the type checker has exceeded its abilities to detect errors.
Recently I was investigating a CI pipeline failure for a merge request opened by
Google’s BigQuery Python API library. The failure
pylint, saying that a type didn’t have the attribute name we were using. At first, this seemed
like a simple failure, but after more investigation, I noticed something odd about it.
09 Jul 2021
DevOps as a concept has been around since around 2010, but implementing the ideas behind it,
particularly when you’re in a team that is supporting old monolithic codebases is challenging.
For several years we had engineers fulfilling the role of a “DevOps Engineer”. However, we
always knew that having a specific person working on DevOps is a bit antithetical to the
DevOps concept - it’s supposed to be a state of mind and a set of practices rather than a job role.
The aim was always to have that engineer act as a source of expert knowledge and an enabler. Teams
were still supposed to own their code, processes and deployments, but in reality, DevOps related
work was often thrown over the wall to that engineer with the expectation that it was their
problem, and not the team’s problem.
We ended up in a situation where we had to make a choice - hire a new engineer into the same role,
or attempt to spread the work across all engineers. We chose the second option, but that then poses
the question of how to change team culture across a department, so that DevOps becomes a standard part
of the team’s process, much like Kanban, Scrum or any of the other ways the team organises themselves.