Office Based Osmosis

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 about it.

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.


Ownership and High Performing Teams

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 managers.

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 code change.

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 of way.

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.


Anti-Consumer Electric Car Charging

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 report 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 an investigation 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.


Deriving From Untypable Classes

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 Renovate for Google’s BigQuery Python API library. The failure was in 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.


Writing A DevOps Vision

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.