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.


The Power Of Team Dashboards

Using metrics and dashboards is a well-understood tool when monitoring the health and performance of software, or your profitability or other key business metrics. What is less common is using the same tools and techniques to monitor the health and performance of the team behind the software. I’m not suggesting using dashboards to report on individual developers, but as a tool to help the team focus on improving their own processes, it can be very useful, provide it’s handled carefully.

My own journey started when I was promoted from a team leader to an engineering manager, responsible for five teams. The change in level resulted in a significantly different view, but also great difficulty in knowing where to focus my efforts. When you’re a team leader you are so close to the team that you hear and feel every change in mood, and have intimate knowledge of all projects and their current state. Suddenly being responsible for five teams gives you a great view to take advantage of areas of collaboration between teams, and removes you from the noise of day to day life so you can focus on the biggest issues. However, it also removes you from the firehose of raw information so it can be hard to know where you should spend your time to get the best return on your energy.