On the day-to-day work of running systems, hackathons and coaching new coders.
We have moved nearly all our activities off our on-premises finance and workforce systems onto our new cloud service. There are a couple of small projects to complete, such as archiving and shutting down the old systems, but most of the work is now tinkering and tweaking to keep things running well and add improvements. That’s what I have been spending most of my time on.
Some of the tweaks involve cables and computers, some involve software and databases, but quite a lot involves teams and processes. Some examples of things that fall into this latter category include:
- picking up issues and routing them to the right people
- getting a small group of busy specialists together to resolve specific issues or questions
- adapting how permanent teams are working in response to what we learn.
Highlights for the next week or so are:
- getting ready for the new agile coaches who will join us later in November
- helping some teams to adjust to the new project priorities in our portfolio, particularly where the things they have been working on have dropped to a lower priority
- creating plans to renew or replace some product and service contracts which are due early next year.
I’ve not been closely involved this time but I have been watching our teams take part in a kind of hackathon over the last few weeks. This is an internal experiment to see if we can find more direct routes to choose between alternative ways of tackling user requirements. Often, these choices are made using desktop assessments which involve a lot of risky assumptions. The style of a hackathon is to get teams to roll up their sleeves and build a partial or prototype system. Although this can produce a more well informed decision, it is hard to organise and feels out of control. I’m wondering how else we can blend the competitive,creative, productive energy of hackathons with the calm, confident and steady processes we normally use.
It is great to see our web team adopting leading practices in developing our new council website. User needs and accessibility1 are at the heart of it. Like many organisations our capacity to do this sort of work is limited and, quite rightly, externally facing systems get priority attention. Unfortunately, that means some of our internal websites and systems can fall short, sometimes quite a long way short, of current best practice. I’m going to dig back into my notes from working in Central Government, and hopefully find a better way to meet internal needs without draining away the scarce skills from customer-facing work.
I haven’t been a professional software developer for decades, but I can still get things done with the technology used to run today’s websites. Codebar2 have a waiting list because there are not enough coaches, so I have been working through the course material to check I know enough to help a beginner. Next challenge is to get over my imposter syndrome and sign up to help someone at the next event.
In some ways we are playing catch up with the rest of the public sector here. User needs and accessibility have been a core part of the UK Service Standard since the Government Digital Service started. ↩