HackIT Apprenticeships – how’s it going as a line manager?

We’re five months into our first cohort of our digital apprenticeship programme – there are 21 in total, spread over (almost) every team. When we started to plan our apprenticeship programme we knew that getting the right line management support and focus in place would be crucial to its success – and we’ve put high expectations on our line managers to deliver this.

This week we got together as a group to reflect on how it’s going as a manager on the programme: what’s going well, what’s not going so well, what do we think we could do next to improve and iterate our approach?

It’s not often that this group of people gets together to share experiences and reflect as a group so we ran this in a retro format – sharing our thoughts on the wall, then grouping them into themes and encouraging open and honest discussion.

What’s going well?

  • We’re really proud of what our apprentices are doing and learning – and of being a part of that
  • We’re all being asked a lot of questions – and that’s giving the rest of our teams a sense of pride in being able to teach someone what you know
  • There’s a real sense of giving someone an opportunity – our apprentices are all from Hackney or went to a Hackney school, and making a difference for local residents is a big part of our overall goal
  • We’ve noticed a developing sense of camaraderie between the apprentices – working together on projects, supporting each other
  • They’ve hit the ground running – and the speed of learning is impressive
  • It’s made us raise our game – when you have someone learning from you, you’re very aware of demonstrating great professional behaviours and knowledge as a role model
  • The learning goes both ways – we’re getting new ideas, different perspectives, and good questions that make us think

What’s not going so well?

  • Managing the relationship with the training / qualification providers is hard work – and is something we need to keep focussing on so that we’re making sure that our apprentices are getting the right training and support
  • Some of the content of the apprenticeship standard they’re studying doesn’t really fit with how we’re working at Hackney (for instance, there’s a lot of Prince2 content in the L4 Associate Project Manager qualification). Whilst we know that being able to recognise a Gantt chart in the wild is a useful skill, we don’t work that way. And for some there are aspects of their course that aren’t directly related to their role – so they’re having to work on modules that don’t feel very relevant to them. We need to make sure we’re supporting them with this as well
  • Finding time to spend on a one to one basis is a challenge – as is getting open and honest feedback on how it’s going
  • We put a buddying system in place for extra support but we’re not sure it’s really working that well – it’s something for us to look at and improve
  • We didn’t manage to get everyone set up on devices quickly enough – next time we need to plan this better
  • We’re not sure we always recruited the right numbers in the right teams at the right time – the whole programme was part of our overall restructure and for some teams adding apprentices came at the same time as forming a new team. There was honest feedback on how it’s been for teams managing this

So, what are our ideas for improvement?

We’re going to work on some new things:

  • How can we generate more opportunities for apprentices from different teams to work together?
  • Having opportunities for apprentices to work with colleagues in other services on short term assignments has worked very well – how might we create more of these?
  • How can we create space and encouragement for sharing work?
  • How could we redesign our buddying arrangements so that they better meet user needs?
  • How might we form a trailblazer group with other interested people to develop an agile delivery manager apprenticeship?
  • How can we develop our own mentoring skills?

And we will also be continuing to focus on building good relationships with all our providers, setting clear expectations of delivery from them.

What we learnt from prototyping

Hi, I’m David Swainston from the Business Solutions team and I wanted to give a following up on the work we did over the last month to create a prototype for a digital end to end service for Housing.

Here’s what we learnt over the 2 fortnightly ‘sprints’ in which we built Housing Helper – a chatbot for tenants and leaseholders.

  • Be guided by the needs of the end user first: as part of the Agile methodology, this was an opportunity to let our end user needs from the discovery phase inform the basis of our requirements. Traditionally, we would gather a whole raft of requirements from the service area to build a large product that isn’t necessarily tailored towards the needs of the user. It was really interesting to see the relative level of simplicity of end user requirements for a service (i.e. only what users really need), compared to the larger scope and scale of requirements we usually gather and work to. Obviously this can be dependent on the type of service/project being worked on – but we felt this is particularly relevant when it comes to designing public facing digital services
  • Look at existing products and services for design inspiration: as part of the design we looked at various existing consumer based digital services and products currently out there and widely used. These included Banking apps, Messenger interfaces, web chat interfaces and SMS to name a few. We considered the strengths of what these services offered in terms of functionality and user experience and fed this into the design of our prototype
  • Test with end users and let assumptions be challenged: ensure that the service you are prototyping is put in the hands of the users who will be using it. Get their perspective on things such as functionality, design, user experience and also additional user needs that may be identified and incorporated as requirements for future release sprints. Although our brief was to design a service for Housing, we learned from speaking to tenants that the service could be expanded to offer services across the organisation. We gained useful feedback on the certain design aspects, for example allowing spelling mistakes and slang to be recognised within the chatbot prototype and that the interface was easy to use
  • Having the right blend of technical expertise: this was really important when it came to us exploring different platforms that could support the development of the prototype. We benefited from having developers within our team who could identify and configure the cloud platform, the various API’s between different components and coding the chat bot framework. We also had a technical architect who brought the whole platform together and summarised this in a solution design canvas that enabled other members of the team and observers to understand the different components that supported the platform
  • Having a leader in the team/Scrum master: whilst Agile is a methodology to enable quick iteration and change, we soon found out that it is still very much a disciplined approach when it came to working through the design and release phase. It was useful to have a good leader to ensure that everybody within the team is aware of the role they have, and that release sprints are delivered in time to allow for the next iteration to begin. This is something that we can still tighten up on when applying Agile and its various forms for real projects, but as a first attempt away from the traditional Waterfall approach we didn’t do too badly!

Here’s a link to the Google Ventures channel on Youtube. We adopted the sprint methods described by GV in their videos, and the team found it really useful as a framework for our exercise to come up with the final prototype.

If there’s any questions you’d like to ask about the approach or the prototype itself, please drop me an email.