Mathias Askholm co-leads HK Lab, an ambitious innovation project at Denmark’s HK union that is helping the union and its members adapt to the implications of technological change. He joined us for a seminar at the TUC to talk about union innovation – this blog is a summary of the presentation he gave.
HK is the second largest union in Denmark, with 180,000 members in mainly administrative roles across the public and private sector, including 621 collective agreements.
Unions in Denmark have a higher membership density than the UK, with around 67% of workers in a union. There’s a big incentive for workers to join as unions administer much of the social security system, and whilst this has been liberalised in more recent years, union membership also bring with it a good deal in social insurance. That also means it’s more expensive, costing around £110 a month, including the A-Kasse, which gives unions a solid income stream and capacity for running major services to members.
The impetus for HK’s new innovation Lab, came about from concerns on how the union adapts to technological change, and the changes in society that will cause. Technology will affect not only what the union does and what it can do, but also members’ workplaces and the content and futures of their jobs.
HK have form in dealing with these questions. Looking back to the 1980s, when computers came into workplace, their largely secretarial workforce faced a huge change in their roles. Office support roles changed, and many traditional administrators risked redundancy as tasks like filing and typing became part of other staff roles.
HK responded by devising an “IT Driving License” course, and trained 120,000 members to help them prepare and move into the new and developing administrative roles that the technology made possible. Their aim was not to fight technology, but to interact with it early and make sure that their members were fit for the future labour market.
As we go through the 4th industrial revolution, HK started tracking developments for their members and the world of work that might be caused by a wide range of technologies:
- Big data
- Artificial Intelligence and machine learning
- Quantum computing
- 3d printing
- Virtual Reality
- The Internet of Things
- Driverless vehicles
Originally, they thought that all they would need is a new style of ‘80s IT Driving Licence, but it soon became apparent that this was much more complex. These technologies worked in combination with each other, and the effects were far from clear. Many of them would not just be new tools for specific roles, but could fundamentally change the nature of work for everyone.
They designated 2016 to be a year of questions, and ran a large research project to understand what might happen across all their industries.
One of the first things they discovered was that it was much easier to find new questions than to find answers. It’s far from decided yet how each of these tech trends will affect an industry. There are political choices and societal factors that could impact on them, and with much still experimental, many outcomes are currently possible.
The approach they hit on was that if they entered early and experimented themselves, they could be a part of whatever future they faced. The result was the establishment of HK Lab, a team dedicated to understanding members’ problems and experimenting to find solutions.
HK Lab is situated on the edge of HK, adjacent to the union rather than internal. The team are based in a co-working space, away from union headquarters, where they interact with other startups on a day to day basis.
They were given the security of a three year budget (around £1.8m), and a high degree of freedom. They report to HM management, but can pick their own projects to work on without seeking approval.
They’re also outside of many of the union’s restrictive rules, such as only working with companies that recognise their union. This has often been critical in finding commercial partners for projects. For a chatbot project, the firms with the experience they needed, and that were focused on short and cheap experiments, weren’t ones which recognised the union yet (though the company has recognised them since the project – a nice organising result!).
Their relatively fluid team structure for each project features internal staff, embedded consultants, external partners, and problem-owner colleagues from across HK’s functions. External collaborators bring technical knowledge to projects, whilst union colleagues bring domain knowledge and user knowledge. The Lab becomes the matchmaker between union people with problems and people who can help find solutions.
HK Lab has 2 programme leaders, who were both drawn from different roles in the union. This gives them an understanding of HK, but also means they’re known and trusted better than they might be as technical experts with no prior HK connection.
3 more Lab team members have been recruited from outside the union, bringing in specialist skills in product design and anthropology.
The team also involve HK staff on each project – bringing in a role as “problem owner”. For example when they developed an advice chatbot, they involved call centre staff. Doing that avoided resistance that could have occurred had staff thought innovation could remove their own jobs. Instead it got them thinking about how their own jobs could make more value, and hence more jobs in their area. The chatbot would remove more mundane enquiries and let them focus on expanding the difficult problems they could solve, and give them a greater role in organising.
The lab has two core focuses:
- Designing future jobs for HK’s members
- Developing new products and business models for HK
For example, in exploring chatbots, they’re looking at both use cases for the union and potential impact, with learning from each side complementing the other.
They experimented with a chatbot to help members and their families access advice – a kind of rep in your pocket with a direct benefit to the union. But they also realised that as chatbots become a bit part of the future of retail, by engaging earlier with the technology, they have a chance to help their members in retail customer service transition into the advanced chatbot users their companies they will need, rather than being made redundant when their current roles change?
HK Lab only work to the pilot stage. They take a problem through to a minimum viable product, rather than a fully working solution. They then hand over the prototype and test results to HK, for them to decide and scale.
They also don’t work on automating and improving existing processes inside HK. There’s huge potential for doing that, but the union already has a strategic IT team with developers who can work on those kind of problems. Instead the lab is focused only on creating new value for the union or members
The Lab have 10 to 12 projects on the go at a time, ranging across all their project stages, from understanding initial questions through to building and evaluating prototypes.
Despite having a healthy budget, the Lab have a rule to keep projects small. A limit of £20,000 per project helps stop things getting too big before they’ve been proven. The Lab celebrates failure if used as a learning point, but seeks to reduce the risk of any costly failures.
Lab projects follow a broad pattern:
- Identify a trend or possibility (the “what if” phase?), and research it.
- Understand the need (talk to members about their experience of the problem. What is that they really need to solve?)
- Prototype a solution and test the idea. This is a cycle that repeats as the project grows in depth or functionality.
- Refine the business model. Test assumptions on how the project might be sustained.
- Run a pilot, evaluate and share the results.
- Scale the pilot.
- Implement the new service within HK.
The first 5 steps are done by the HK Lab, before a hand over to the problem owner and IT team within HK. The last two steps will be taken by HK’s internal developers, who need the skills and systems that will help an idea fit within the organisation.
Projects are chosen by how well they fit against three criteria.
- Is it desirable? (will users want it?)
- Is is feasible? (can it technically be done?)
- Is it viable? (does it fit HK’s goals and capacity?)
If something is going to count as genuine innovation for HK, it needs to be relevant against all of these criteria. This helps keep HK Lab on track to use their particular skills and focus most effectively, without being drawn into projects that would be less of a fit for innovation work.
The Lab have big goals but only work in iterative steps towards them. This means making the smallest possible demonstration of each new development, and testing it to validate their assumptions.
Too often we design and build a complete solution for a problem without testing it until it’s ready to run. By that time though, we could have wasted a lot of work, when earlier testing could have identified a major change early on that would give it a better chance of working.
Building it out in minimum viable products (often just a paper prototype or a shell service to get users talking about the idea) can help avoid wrong assumptions that cost us heavily in time and resources.
Rather than making a big bet on a project, the Lab chooses to make loads of small bets. There’s less to lose at any one point, and they know they’re on track through the whole process.
In many cases, a project carries a lot of risk that the Lab don’t want to expose members or the union to. Testing small helps get around this too.
One of their projects is a Freelance support service. They found many members who wanted to go freelance, but then found it difficult to run a self employed business. They prototyped an advice service for the self employed, including a collective fund for freelancers. It would pay savings for unemployment and sick insurance, financed by the collective group, out of a small fee paid on each contract.
To test out whether members would want these services and advice from a union they had to actually provide some of them. This was a very different thing for the union to do, which could have been controversial. But launching with a small target group rather than a public project, they were able to find out what people wanted. It also helped them find out what kinds of activity might cause issues for the union, rather than causing any issues only once they were at scale.
Coupled to small iterations is a heavy focus on user testing. Too many projects will brainstorm and vote on ideas internally. This can get a wide range of ideas quickly, but it can suffer from our internal biases. The main opinion that matters is that of the eventual user of the product, and the Lab seek to test new ideas as soon as possible with users to see if they are realistic.
For HK, this has meant talking to members as well as reps. It’s often easiest to plan work with the reps who are closest to the union. They have great understanding of the situation in their workplaces, but that often means they unconsciously have a different perspective to their members. Members don’t talk about “stress” at work for example, they talk about change or efficiencies. Reps and those closer to the union will identify the underlying stress in a workplace, but talking about this risks being ignored by the members, even though it’s the root of the problem that they think of by a different name.
And sometimes everyone’s assumptions are slightly wrong. With their advice chatbot project, the first big question everybody asked during a hot simmer was “how hot can it legally be at work?”, but the team hadn’t anticipated that. Making a quick correction from the test helped make the first interaction much more convincing for many subsequent test users.
Test faster and wider
HK Lab like to test a wide range of options quickly, working out from each result whether to drop it or to build on. This also helps you work out where to stop, as Only by going too far sometimes can we work out where enough was.
Mathias likens this approach to the difference between playing Minesweeper and Battleship. In Minesweeper, you clear the board laboriously, a tile at a time. You make bets, but only when you have to, as the risk is greater that you’ll lose the whole game.
Battleships is about casting your net wider and accepting that more of your shots will fail before you get a hit. In Battleship, the more you do, the more you’re likely to hit more targets, which you can then refine, then shoot widely again.
Documenting success is crucial as it gives the team licence to do more. When the chatbot project was demonstrated to be a success, many other people around HK had a tangible example of how the innovation process worked. Telling the story as widely as possible increased trust in the team, and also helped other colleagues understand where they might have problems the Lab could work on.