Working in partnership with suppliers

We hosted a small, open breakfast event for suppliers as part of the Hackney fringe for London Tech Week to discover how we can make HackIT a great place to do business. Hackney Council has a clear commitment to in-sourcing and it’s important we get value for money from commercial organisations and have clear accountability in contracts. So why the breakfast?

We can make things better for residents if we do the best possible work in the most efficient way. We’ve put a strong emphasis on partnering with small businesses to help us learn new skills and adopt new ways of working. Working with a range of businesses gives us access to the best talent and a diversity of experiences and skills. Many of these businesses are local and we can use procurement to encourage them to provide job and training opportunities for our local residents. If we make it more costly to do business in Hackney, then ultimately that cost will be passed on to residents.

Today’s breakfast was targeted at businesses we’ve not yet worked with, or not worked with as often. We want to ensure that the best people want to work with us and show that working with Hackney Council could be rewarding. But we also wanted to test our thinking so that we avoid unintentionally excluding some suppliers from our procurements. Sometimes it can be more efficient to have a standard way of doing things but if you are too specific, you increase the barriers to working with new suppliers which narrows the advice you receive.

We focused the discussion on two topics: How we buy things, and How we create opportunities. It was reassuring to hear that attendees felt that we are right to use the government’s Digital Marketplace by default. It is cheap for suppliers to participate and the marketplace is refreshed frequently.

Our standards

We had a useful discussion about how we see Service Standard assessments. It’s a key frame of reference for the ability of the supplier and event in our project lifecycle. We could do more to show that we’re aligning to the government Service Standard and that they aren’t conducted as a confrontational gateway but as an honest assessment of what’s been done and what needs to be done next.

We’ll consider how we can provide reassurance to suppliers about how and why we conduct Service Standard Assessments. We’ll also explore how we might engage our supplier community more broadly in assessments

Skills

We discussed the balance between user research and service design, and development. Our experience has been that an agency tends to be better at one than the other but both are key enablers of delivering the right solution for residents. But we’re also interested in how behavioural science, ethnography, data science and devops can add new disciplines and perspectives on our challenges.

We’ll consider how we can reflect when we believe a team needs a blend of skills or when a task is better-suited to a stronger design or development skillset.

Focus

We had feedback from a couple of agencies that had worked with us that we face challenges ensuring that our own staff are sufficiently focused on the project. We know this is an important issue for the team, too. We explored how agencies manage these tensions – and we could learn more still rom software suppliers who manage bugs and incidents alongside software improvements.

We’ll explore how we can ensure we’re providing the right team with sufficient time to make projects successful.

Early thinking

We then explored how we create opportunities, shared our current approach and discussed what more we could do. We built our projects pipeline in the open in response to a previous supplier event so we wanted to know whether we’d made progress. The reassuring news was that nobody else was doing it better. But it was evident that we could be more open in order to learn more from suppliers. We explored whether an ideas wall would help suppliers spot forthcoming plans and whether service mapping would help suppliers tell us about components that might accelerate our plans.

We’ll experiment with different ways to share early-stage ideas so that suppliers can plan for forthcoming procurements and share what they know.

The breakfast was a sufficiently useful event that it re-doubled our commitment to holding these more frequently. We’ve got bold aspirations and sometimes we’ll fall short, so it’s important to be challenged by suppliers in a non-competitive environment. We’ve made some good progress, and helped demonstrate that Hackney is a rewarding place to do business. But there’s more to be done.

When HackIT met the venture capitalists

I’m participating in a programme to explore the concept of responsible leadership – simply, helping people and their organisations make decisions which take account of the interests of all stakeholders. One of the ways the programme does this is by connecting you to people and environments that are unlike your own.

I had a conversation with the partner of a venture capital firm exploring what might a local authority IT team (us) learn from the way that they analyse investment opportunities? And what might our thinking help them understand the diversity of the needs and abilities of people they don’t normally meet.

On Thursday, five of our projects presented to a panel of people from Hambro Perks, a venture capital firm that specialises in growing technology businesses – including brands that we’re familiar with – Laundrapp and What Three Words.

We chose projects that represented larger and smaller investments for us, and products that were already achieving a return on investment and those that were early prototypes. Each team explained the problem to be solved, their vision, the current stage of development, what was already available on the market and what investment they needed next and what they’d seek to achieve with it. They were then subject to (the nicest) challenging questions about the market, the strengths and weaknesses of the product and the potential roadmap.

Across the five presentations, there were some key themes that we need to consider:

  • Are we really understanding and solving problems, or are we just improving existing services? We need to do both. But it’s easy to start with a problem / opportunity and then rapidly find yourself iterating to a point that’s an improvement on today but doesn’t make a
  • Have we understood our users well enough – in particular, using quantitative as well as qualitative techniques to understand the size of the ‘addressable market’, likely digital uptake and how we support digitally excluded people.
  • Do we understand the ‘competitor set’ well enough? This matters in terms of other software that already performs a task but also entrepreneurs, social enterprises, charities who are trying to solve the same problem. Discoveries don’t typically begin with analysis of think tank reports, but perhaps some should.
  • How are we marketing the product or service? We’ve had some tangible benefits of ‘organic’ uptake of some of our products and for others, we’ve got a captive audience. But our marketing ideas could do with further work.

All of these are questions of responsible leadership: do we understand our context, situation and system well-enough to know whether we’re doing the right things in the right way.

The teams found the exercise sufficiently useful that we’re now experimenting with how we might re-create it to inform the way that we initiate new projects. Our next Dragon’s Den event will be in mid-June.  It will be important not to create governance processes that work in parallel to our existing forums, but it was sufficiently worthwhile to give it a go.

Importantly for me, the exercise gave me a real energy boost. I felt significant pride in hearing Andrew; Soraya and Guy; Philippa and Richard; Rashmi, Selwyn and Mirela; Daro and Anna present confidently and clearly about our work, handle the challenge well and to see that our work stood-up to external scrutiny.

How we’re iterating towards our API competition

Today, we launched a competition for people to build services using our APIs. You can enter our API competition here. The competition is a chance for us to:

  1. Find out if our APIs are sufficiently well-engineered and clearly documented that third parties can access the API without needing help
  2. Identify new APIs that would help us develop our services further
  3. Generate new ideas for online services
  4. Identify new partners we can work with

But some of the details are still to be sorted out. Here’s why.

It seemed like a good idea to find out whether our APIs were so good that people could use them first time, unaided (as per the Service Standard). That meant working with people who haven’t been involved in their creation.

But we didn’t know:

  • Whether anyone would want to enter,
  • What prize / incentives we should offer
  • Whether people would want to develop a simple prototype or build a whole service
  • We wanted to protect the privacy of the data behind the APIs but ensure that it was a genuine test of the APIs that had been built

We began by posting the idea to Twitter in a Google Doc for people to share and discuss. The Twitter activity reached over 15,000 people, which was a good indication that there would be some interest in the competition. Lots of people that we don’t know talked about it – although we probably haven’t yet reached enough local people. People suggested a range of prizes, which meant that we didn’t have to dictate how developed the prototype needed to be.

Then on Friday, I spoke at a UK Authority roundtable following their report: ‘APIs for the Public Good’, sponsored by Cognizant. It was a great opportunity to talk about the competition and to get advice from the other panellists on its design.

Today we’ve launched the competition in two phases, beginning with a call for ideas. Depending on the entries, we’ll then explore the opportunities and timeframes. This may be dependent on our ability to ensure the APIs meet the needs of the best ideas, the way in which we’ll provide secure access to the APIs and the feasibility of the services. But we’ll determine these once we’ve seen the range of ideas.

It’s not a traditional way of running a competition. But by opening up our thinking, the idea is already getting better.

Developing our API strategy

TL;DR

One of the decisions at last week’s ICT management meeting was to confirm our commitment to an API strategy:

  • Ensuring that all of our key datasets are available via a REST API so good, that people prefer to use it
  • Replacing existing connects with REST APIs that can be used independently of each other
  • Developing our skills to ensure we can use the modern programming languages, development techniques, tools and services necessary to deliver high quality services
  • Developing our cloud-first approach, ensuring we’ve got a sustainable digital architecture that supports continuous deployment and continuous integration
  • Ensuring our code remains secure but is open source

Background

Last year, we were considering options for renewing our CRM. We reviewed the CRM market and also experimented with lowcode and, in particular, Outsystems which seemed to be the best on the market. We built Pay My Rent in just 12 weeks using Outsystems, connected to data in Dynamics, and it’s been working well ever since.

However, when we began developing the housing repairs service, we found that lowcode was a barrier to working with suppliers. They would have to spend time learning lowcode. Most of our suppliers were expert in Ruby on Rails, a modern, lightweight programming language – but not one we knew. We also learnt that whilst lowcode helped us develop apps quickly, we were still reliant on data in legacy systems for managing the end-to-end journey.

We also learnt that if we connected new services to legacy systems using the integrations we used to write (SOAP webservices and direct database connections) then we would have to re-write them when we were ready to migrate from Universal Housing. So we experimented with developing a REST API to support online repairs. Previously we would have built an integration that put data directly into the database, which:

  • Would be hosted on-premise (for security) so unusable to anyone outside Hackney
  • Was impossible to monitor availability in realtime – so we’d have found out it was broken when part of the service failed
  • Could not be re-used, and would have had to have been re-written if either the application or the database changed

We called this work a ‘prototype’ because there were a number of questions we couldn’t yet answer:

  • Did we have sufficient skills in the team to write REST APIs?
  • What were the benefits of writing REST APIs?
  • Could our existing technology support an API-driven approach?
  • Could we get the best from existing software (lowcode, CRM) whilst increasing our capacity by working with local agencies?

Over the last six months we have been trying to answer these questions.

Work to date

We deployed the ‘Hackney API’ that enabled repairs, and started adding more data to it. It was underpinned by a draft set of standards so that we could develop future APIs to a consistent format.

The API was hosted on-premise as a short-term workaround, and the code was on a private repository of GitHub initially. We then re-wrote (‘refactored’ in the jargon) the API to individual APIs that work independently of each other. That means changes to code won’t create problems in other parts of the API and enable us to continuously develop the services.  

The development team has made a strong start in developing their skills. We began by co-locating our developers with partners in agencies. We got some great feedback from our agencies about the speed with which our devs learnt.

The NHO team adopted the API-based approach and began developing a more flexible approach so that they could better meet user needs. The team, and the income collection team were both able to benefit from the API built for Pay My Rent, because they’re using the same data. So they developed the idea of a suite of APIs that could be used by any team.

Our emerging standards were adopted by the Business Index team.

We’ve also shown that we can build APIs on our own. Sachin, Sandrine and Tapan, working with Tejus developed a suite of APIs to support the LLPG.

What we’ve learnt

Writing great APIs demands we use a range of techniques to improve the way we write code. Pair programming, test-driven development and coding in the open are all important attributes of writing great code and therefore making our APIs reusable outside Hackney.

Our developers are learning a lot, but need help, support and time to increase their skills. There are too many demands on their time, so we need to get better at prioritising what they do.

You can’t just deploy cloud-based applications which seamlessly connected to on-premise, legacy systems. And you can’t publish open source code that’s reusable if you haven’t got the security sorted out.

There are lots of tools that can help us – from Platform as a Service such as Heroku to software tools such as Swagger, for documenting APIs, and TeamCity/Circle CI for continuous integration. However, none of these are shortcuts to writing good code.

We need to be able to continuously deploy code, ensuring it works and connects seamlessly to our systems and infrastructure. Our change control process enables this, but we’ve got more to do to support reliable, secure access between cloud software and our legacy applications.

 

What we will do now

We’re making a clear commitment to an API-based approach. We believe it will:

  • Enable us to re-use data and connections as we develop more digital services
  • Provide the potential for third party applications to connect to our data and (potentially) us to use more third party apps and services
  • Reduce our dependency on large systems and reduce the risks of switching between applications
  • Increase the visibility of integrations between systems, reducing the costs of support and maintenance
  • Improve the security of our systems by having a secure OAUTH system in place

However, we recognise that this won’t be straightforward. We’ll need to:

  • Work closer together, ensuring our digital design team, developers, architects, infrastructure and data teams can all contribute to the approach
  • Support colleagues in their continued learning and development
  • Learn from experts to ensure that our API products are high quality
  • Track our capacity to ensure that new services are improved continuously but that our legacy applications continue to be well-supported
  • Track the cost and benefits of this approach to ensure it delivers a better IT service for residents, businesses and colleagues

We’re already working with MadeTech to provide support and challenge for our API strategy. We’ll now be drawing on a range of experts to support the whole team in understanding best practice. We want to increase the number of opportunities available for people to learn coding – whether through our new learning platform, secondments into the team or secondments into projects to develop new services. And we need to work harder to open up our work, so that we:

  • gain from other people’s wisdom (their input can help improve the quality of our code) either indirectly, or through recruitment
  • make a valuable contribution across local government by helping other authorities who are starting out on a similar journey / don’t have the resources that we do play a part in resetting the local government digital landscape, helping the sector to unlock itself from the traditional oligopoly

There’s a lot to do – but the opportunity has never been greater. We’re in a unique position in Hackney to make this work.

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.