Holding a great show and tell

We’ve been running show and tells for nearly a year, and in that time we’ve run 57 by my count, across 7 different services. That’s enough to have a model about what makes a great show and tell. Here’s what we’ve learnt:

1. Names don’t matter
Some people read ‘show and tell’ in their diary and don’t know what it is and assume it can’t be important. We put people first, so if ‘show and tell’ doesn’t work, we can call it ‘project update’ or ‘workshop’, ‘knowledge share’ or even ‘project board’.

2. Timing does
The optimal show and tell lasts half an hour. If attendees want it to last longer, it can continue. But we should prepare about 15 minutes content.

3. Venue
Make it easy for people to get there. Ideally, allow people to find out about it as it starts. Make it inclusive. Show and tells in meeting rooms don’t get noticed.

4. How to begin
The beginning of the event needs four things:
A welcome – it’s just polite
Thank you for coming – a show and tell is only valuable if people turn-up
The vision for the project – show and tells grow so often people are hearing it for the first time. Remind people what we’re trying to achieve.
The purpose of the event – a good show and tell will repeat back to people what they already know. You need to explain that’s for them to check we’ve listened and learnt, and identify any outliers or gaps.

5. The structure
There are two main parts to a show and tell: what we’ve done, what we will do. For some groups, we will need to create a third for their questions – but ideally the feedback has already started.

6. The presentation
Everyone has a role. A good show and tell is a team presenting its work. Everyone should have a role in explaining part of the story.

Show the product, don’t talk about the process.

Less jargon. Do people really need to hear ‘sprint’ rather than ‘fortnight’?

Remember to talk about us, our, we and team. Colleagues aren’t ‘them’, ‘the users’ or ‘officers’.

7. The message
Most listeners will remember 2-3 key points, and little more. Know what you want to say before you write a word on a slide. Have prompts ready to stimulate discussion, should you not get much feedback.

8. The deck
A slide deck is useful for people who couldn’t attend, and starts to collect valuable assets for your Service Standard assessments (screen grabs, personas).

Most rooms have a screen big enough for 10 words or part of a screen. Prepare lots of slides rather than one slide with lots of content.

9. Preparation
A show and tell is an important presentation, often to senior leaders. Practice – at least once, preferably as a team. Get a second pair of eyes on your presentation. Know how the projector works.

Prepare your attendees. Email them to remind them that you’re looking forward to seeing them. Explain that you’ll start on time because there’s a lot to cover. Remind them their input is important. Tell them biscuits (fruit?) will be provided

10. Plan B
Presentations go wrong. Plan B might be huddling around an iPad. Maybe the attendees get out their phones and open a URL. Don’t spend their time waiting for you to make the computer work.

11. Feedback
Capture feedback – ideally visibly. Write it on a post-it and put it on the wall. Don’t just nod. Get people to write their own thoughts – for example, annotate drawings. Feedback matters – so show it.

12. Thank you
Thank people for coming. Remind them that their input will make a better product. Remind them you’ll be back in a fortnight.

13. Learn
Retrospectives are for another blogpost, but should always happen after a show and tell. Reflect on what you’ve done and what you’ve learnt. Re-plan what needs to happen next. If the next fortnight looks as you anticipated the previous fortnight, you haven’t learnt enough.

By the end the year we’ll have passed 100 show and tells, and will have a more developed model. But in the meantime, if you follow this, you’ll learn more.

Working with suppliers to develop better digital services

Some of the best work we’ve done in the last year has been in partnership with our suppliers. In Hackney we’re particularly fortunate to have some of the world’s best digital agencies on our doorstep, many of whom have been helping us explore opportunities to redesign the Council’s services.

Whilst there’s an expectation that suppliers will work hard to fit in with our needs, we can produce better work at lower cost if we’re good to work with. We’ve been advertising tenders for individual pieces of work on the government’s Digital Marketplace which is a transparent and fair process, through which it now takes a couple of weeks to purchase a service, rather than traditional procurement exercises that run for months.

We invited a group, comprising leaders of agencies with which we’ve worked, to help us explore five questions. How might we:

  • Reveal our core challenges / opportunities and digital pipeline so that agencies can identify emerging opportunities to do business with Hackney?
  • Procure for user needs whilst enabling suppliers to build capacity to support us and plan resourcing?
  • Work in collaboration with agencies to get the most out of the skills they have to offer?
  • Ensure we develop long term expertise amongst colleagues, whilst remain focused on immediate delivery?
  • Identify emerging opportunities that we don’t yet know we need?

We learned four key things that can help us work better:

Think aloud

It’s important for us to think aloud, at an early stage of our thought process, so that suppliers can understand the aims for a Council service, and therefore how an individual piece of work contributes to those aims. Thinking aloud is more transparent and efficient for all (avoiding lots of individual conversations) but it also offers the prospect to approach something differently – whether in partnership with others or building on other work.

Planning ahead

We’ve been purchasing in an ‘Agile’ way. We advertise an opportunity as soon as we’re ready to start (ie once we have the need, people and budget aligned) and aim to complete the buying process in a couple of weeks for a job that is likely to take less than three months. Agencies find out about the opportunity when it’s posted. But running any profitable client services business means staff will be deployed on fee-paying work around 85% of the time. So whether or not an agency has the capacity immediately to Hackney, or put its best team on the job, is down to chance. We need to signpost earlier, without losing our agility.

Categorising opportunities

One of the key things suppliers want to know, is why we’re looking for support. Is it a non-core job that we want to get out of the way, something of strategic significance, or a small but innovative exploration? And it would also be useful for them to know how confident we are in the work. Have we set our technology direction, or are we open to new ideas? Are the people they’ll be working with seasoned digital practitioners, or are they still learning how to work in new ways? This will help them understand what resources to invest and what we’re trying to achieve.

Sizing jobs

We’ve been advertising for individual phases of work (typically, discovery, building a prototype, expanding into beta, then building a live service). These jobs are relatively small, especially at the discovery and prototype stages, and the costs of bidding are relatively high. Stuff that’s been working in the initial stages then has to stop mid-flight for procurement. We need to look at how we might tender for bigger opportunities so that we get a more seamless delivery, but we also need to make sure that we don’t make our projects so big they exclude smaller vendors or lose the ability to ‘fail fast’ where that’s the right thing to do.

Conclusion

Our goal is to work with high quality suppliers through which we support local businesses and residents in employment, to build better services for residents. We’ve made a good start, and listening to our suppliers’ perspectives has helped to give us a clear focus for where we should focus to improve further. Over the next couple of months we’ll be experimenting with different approaches to address these issues and then making the ideas that work, core to our approach.

Developing digital services for all

We’ve been working hard over the last few months to understand how to accelerate our delivery of digital services that are so good, people prefer to use them. It’s not a controversial idea, but we’ve got a lot of hard work to achieve it.

The starting point is our HackIT manifesto which explains how we want to work and what’s important to us. We’ve produced this because we wanted to set out a clear and easily understood set of principles that we can use to make sure we’re all taking a consistent approach to delivering digital change at Hackney. The manifesto gives us a lens through which to examine everything we do.

We are committing to the Local Government Digital Service Standard (the manifesto reminds us we’re part of a wider community working to deliver excellent digital local services). Everything we buy, commission or build will be assessed according to whether it meets the Standard. Important services will be assessed by external reviewers with expertise in digital services. This will help us make sure that our digital services put people first. If you are able to help as a reviewer, please get in touch.

Next, we’re going to deliver our work using the Hackney Agile Lifecycle. This owes a huge debt to the UK Government Service Design Manual and similar approaches in the US and Australia. However, it’s rooted in the Design Council’s double diamond model of delivery. Anyone who’s working with us (Council officers, partners, other agencies) can understand our process. The job of creating digital services isn’t just an ICT thing- it’s a globally-recognised design challenge and we need to stand on the shoulders of giants.

We’re opening up. We’re starting to publish our code on GitHub. We’re blogging about our work and what we learn and we’re spending time with residents to learn what they really need – and then making sure our services meet those needs. This will help us make decisions together. Our Tactics Manual brings together techniques from Google Ventures, 18F as well as our own experiences to help any team work collaboratively to tackle a problem at pace. Everything we’re producing is shared openly on GitHub and we’re really keen to hear from. others who want to copy, edit or propose improvements.

Designing a new digital service is just the first step and the work mustn’t stop there. Typically it’s much easier to do a project well than it is to continuously improve a service. The fourth stage of our design lifecycle is: improve. It sets an expectation that once it’s fully operational a service will need continued leadership, review and focus to meet people’s changing expectations.

Finally, we’re trying to move from mandating a way of doing something, towards finding many routes to high quality outcomes. We trust the team to find their preferred way of doing something – provided it meets users needs.

This is the start of our journey. We’re fortunate that we can learn from the hard work of so many colleagues and share ideas for ways we can make public services better. We can play our part in designing digital services for everyone.

Understanding user need for technology in housing

We are working with our colleagues in housing and FutureGov to understand what our tenants and leaseholders need from the Council’s housing service, and look at how technology can support those needs.

The work has identified that too often many of our existing processes and systems are too complex for most residents. And because these have developed organically over time, it can often be hard for the service to be confident it has the information it needs to make the right decisions about how to handle problems and where to invest. That’s the starting point for a new piece of work to decide on what technology is needed – including whether the ‘one system’ approach is actually the right one, or whether we should move towards a more ‘loosely coupled’ approach.

One of the most powerful findings of our research has been that the services and processes which support our tenants and leaseholders share many of the same characteristics as the services and processes needed for many other transactional services that the Council provides for our citizens. Reporting a blocked drain isn’t so very different from reporting a broken streetlight – or at least, it shouldn’t be.

Happily, this work fits very neatly with three other workstreams in our programme to deliver digital change for everyone:

  1. our review of our CRM platform
  2. the need to renew our master data solution
  3. work to understand how we accelerate the delivery of services through Hackney’s One Account

This is a great opportunity for us to think much more broadly about the underlying technology we use, and how we can build on it to make sure that we support successful, cost-effective customer journeys based on a single view of our customers and assets (homes, buildings etc).

We are now assembling the team needed to make this happen. The team will comprise user research, service design and development skills, overseen by a Product Owner empowered to make decisions about the design of the service. We will reduce the risk of this complex project by working to Agile principles: breaking down the requirement into individual user stories, delivering them in fortnightly batches (or sprints) with the priority of testing working code directly with residents in weeks and using their feedback to drive our direction.

So, rather than just buying a new housing solution, we’re planning to look at how far we can go by using generic solutions which we can use as a platform to build the end-to-end digital services that our residents need. Throughout the project we’ll be working openly. Nothing we do is likely to be unique to Hackney. If other local authorities, housing associations, or innovative software companies have part of the solution already, or want to work with us to fill a gap in user needs, we’d love to look at the potential to work together and share our learning.

This project will be our next major step towards the ICT service that the Council wants, and our residents need. We’ll be consolidating the ideas we have already been working with: user-centred design, Agile, open source development and working to the local government digital service standard.

This isn’t ICT-led or technology-led change. We want it to be genuine service transformation facilitated by the vision of the senior leadership of the organisation. We’re fortunate to work in such circumstances, which makes it all the more important that we deliver the right solutions for our tenants and leaseholders.

Setting a team up to fail

No one likes to fail. Many do, but few set out to. Failure is particularly problematic in the public sector, because it can lead to fears that hardworking taxpayers’ money is being wasted.

Despite knowing all that, I set a small team up to fail this week. Their brief is to spend a month creating a prototype. The team will succeed if:

  1. The service is digital end to end and delivers a viable business process
  2. The service is so good that people prefer to use it
  3. The service supports our other projects, but is distinct from it
  4. The service, if developed further, would reduce dependence on our existing systems
  5. We learn more about what our customers need from a CRM and customer portal and the time it takes us to build a service

That’s a big ask from a small team, and with just a month to do it. That’s important. We can’t set up a whole service to fail – that would be irresponsible. But a small team working for just a month can learn, and then teach, much more than a larger team working for longer. And at lower cost and lower risk.

I told the team I expected them not to achieve all of those things. They asked if I was managing expectations. I wasn’t. In fact, it’s particularly important to me that they don’t get it all right first time. I want the team to be bold. They need to aim high and make mistakes. It’s only by learning what’s wrong, that they’ll find what’s right.

The team asked me what we’ll do with the prototype. I said we’d likely put it in the bin. Whilst my fee as a motivational speaker may have fallen significantly, it was another risk worth taking. The team has spent years working to produce ‘finished products’. We previously had a simple choice between meeting deadlines and suggesting it was good enough or missing them and waiting until the product was ‘done’. That is precisely the approach that we need to change if we are to be better able to meet the needs of our residents and the aspirations of our colleagues.

The team will be able to draw on the tactics manual that we’ve pulled together, based on the experiences of Government Digital Service, 18F and Google Ventures, amongst others. And it’s work will help us understand a user-centred, Agile methodology. So the act of doing the work will be successful, regardless of the product we create, and will teach us far more in the long run than training courses. In fact, we will win whatever the outcome.
So whilst I’ll be willing them on, mostly I’m crossing my fingers and giving them the space to try their best, be bold enough to get things wrong and brave enough to learn that, done right, an Agile approach can deliver enough failures to produce a more successful outcome.

Why we’re thinking about design principles

One of the most exciting things about joining the team in Hackney has been hearing colleagues express their interest and enthusiasm for working in new ways. We’ve got lots of ideas of what can change and how we can improve things. But as we embark on this journey, it’s important to understand why we’re doing things.

Russell Davies, the former strategy director of the Government Digital Service came to Hackney this week to talk to us about the GDS design principles. These emerged as the team started to develop its ways of working. He described them as a formulation of a culture and attitude that was already emerging, but also how they served as ‘super rules’ which weren’t “owned” by any particular department but which still required compliance (the service standard and control of the gov.uk domain were other key parts of the jigsaw).

Intriguingly, Russell also urged us to not necessarily adopt design principles, but to consider our manifesto, playbook, or new form of statement. He also regretted that they hadn’t iterated the principles after adoption.

We had a brief set of discussions at tables during the event. Whilst it would have been great to talk for longer, the time-limit perhaps created the sense that we were starting a conversation. As we are on multiple sites, we’re doing that virtually, in the first instance – for all I’d prefer to be able to visualise it in a common space, it does at least mean that you can follow our thinking.

The work will need to grow organically – but as Russell said, we also need to make sure the end product is high quality. ‘Use a designer and a copy editor’, he urged. Watch this space!

 

Becoming HackIT

I was super-excited when I arrived in Hackney. But I was also conscious that I knew relatively little about the ICT service. In the first few weeks I met lots of colleagues who were also excited to work in ICT for the council – but few people outside who knew much about what we were doing.

In my last job, in Buckinghamshire, I blogged about our work, and ran a weekly email newsletter to talk about what we did that week and what we would do the following week. But in a bigger service, and with high profile leaders like Rob Miller, I wanted to be part of a wider conversation. If we all talked about our work, we’d capture that excitement and potentially showcase the service better as a place to work.

If we called the blog ‘digital’, it may have seemed like it was just for some parts of the team. That would’ve been a mistake: the work of the infrastructure team, for example, is critical to changing our service – making it more flexible and responsive.

We canvassed ideas for a name from the team, and then put a shortlist to our Cabinet portfolio holder: Mayor Glanville. He chose HackIT – Digital change for everyone. It was great to choose a name that captured the mentality that we’re developing (Hacktivism as a force for good) but also made a clear commitment that this isn’t technological change for the sake of it, or the responsibility of a single team, but a collective effort to deliver change for everyone.

Here we are!