So, we’re ten days into Difrent being ‘bought’ by The Panoply group; people keeping saying ‘congratulations’, ‘how’s it working for a new boss/ company?’, ‘how do you feel about the buy out?’ So I thought it was a good opportunity to reflect on my thoughts about the acquisition.
And the answer is, I’m feeling pretty good actually. Honestly, so far there hasn’t really been much difference, other than the feeling that we’re part of a larger group of likeminded people.
Difrent is still Difrent, my boss is still my boss, my teams are still my teams and my peers are still my peers. What it does mean is that I now have more peers to talk to, share lessons learned with and bounce ideas off of. It means there are potentially more opportunities for our people to get involved in, bigger communities of practice to be part of and more slack channels to share pictures of my dog on.
Chatting to some of my team yesterday, and the best analogy I could think of about the Panoply group and my understanding of how it works is actually the Civil Service.
Within the Civil Service you ‘belong’ to a certain Government Department, I was at DWP for ten years, and even years after leaving there’s still a part of my brain that think of myself as a DWP person, even though I worked in 5 different departments in my tenure in the public sector. But as a Civil Servant, although I was in DWP, I had opportunities within and across the Civil Service that others outside the Civil Service didn’t. If you were at threat of redundancy in the CS, you got first dibs on other job opportunities, not just in your in department but across the Civil Service and secondments and training opportunities across government departments were possible to further your career development etc.
Within the Group we have the opportunity for our people to go on loan to another company in the group, to further their career development, or because the project they have been working on has ended and we don’t have something else for them to immediately move onto, but someone else in the group does. This is a massive bonus for our people. It gives them so many more opportunities, and takes aware some of the fear you get in agencies about ‘what happens when this contact ends?’ We’re already sorting out access to the communities of practice within the group and discussing opportunities for our people to do secondments in the future/ and vice versa for others in the group to come work with us.
These options to be part of something bigger, to open up and share more opportunities for our people, to work together with likeminded folks was one of the reasons I voted for joining the group when I was asked my opinion. And it certainly doesn’t hurt on a selfish level that so many people I know, have worked with before and respect are also in the group; Within the first 10 days I’ve already had fantastic welcome meetings with so many folks across the whole of the group.
My first ‘catch up/welcome to the party’ call with Ben Holliday was like we were picking up where we were last time we worked together, and Carolyn Manuel-Barkin and I have already put the world to rights and discussed all things Health related; all definitely good signs for me. And being part of the group is already paying off for us, with some joint opportunities with Not Binary and the fantastic folks there already looking very positive (honestly David Carboni has not only the most relaxing voice, but is also really interesting and if you get the chance to hear him talk tech and good team dynamics you should definitely take it). [EDIT: since posting this blog this morning, we have now won our first piece of work with Not Binary!]
Difrent is all about delivering outcomes that matter about adding value and making a difference; and we’ve always been vocal about working better in partnership, both with or clients and other suppliers. Panoply will help us do that.
The frustration of job descriptions and their lack of clarity.
One of the biggest and most regularly occurring complaints about the Civil Service (and public sector as a whole) is their miss-management of commercial contracts.
There are regularly headlines in the papers accusing Government Departments & the Civil Servants working in them of wasting public money, and there has been a drive over the last few years especially to improve commercial experience especially within the Senior Civil Service.
When a few years ago my mentor at the time suggested leaving the public sector for a short while to gain some more commercial experience before going for any Director level roles, this seemed like a very smart idea. I would obviously need to provide evidence of my commercial experience to get any further promotions, and surely managing a couple of 500K, 1M contracts would not be enough, right?
Recently I’ve been working with my new mentor, focusing specially on gaining more commercial knowledge etc. and last month he set me an exercise to look at some Director and above roles within the Digital and Transformation arena to see what level of commercial experience they were asking for, so that I can measure my current levels of experience against what is being asked for.
You can therefor imagine my surprise when this month we got together to compare 4 senior level roles (2 at Director level and 2 Director General) and found that the amount of commercial experience requested in the job descriptions was decidedly woolly.
I really shouldn’t have been surprised, the Civil Service is famous for its woolly language, policy and strategy documents are rarely written in simple English after all.
But rather than job specifications with specific language asking for “experience of managing multiple multi million pound contracts successfully etc”. What is instead called for (if mentioned specially at all) is “commercial acumen” or “a commercial mindset” but no real definition of what level of acumen or experience is needed.
The Digital Infrastructure Director role at DCMS does mention commercial knowledge as part of the person specification, which it defines as “a commercial mindset, with experience in complex programmes and market facing delivery.“
Finally we have the recently published Government CDO role, which clearly mentions commercial responsibilities in the role description, but doesn’t actually demand any commercial experience in the person specification.
At which point, my question is, what level of Commercial acumen or experience do you actually want? What is a commercial mindset and how do you know if you have it? Why are we being so woolly at defining what is a fundamentally critical part of these roles?
Recent DoS framework opportunities we have bid for or considered at Difrent have required suppliers to have have experience of things like “a minimum of 2 two million pound plus level contracts” (as an example) to be able to bid for them.
That’s helpful, as Delivery Director I know exactly how many multimillion pound contracts we’ve delivered successfully and can immediately decide whether as a company it’s worth us putting time or effort into the bid submissions. But as a person, I don’t have the same level of information needed to make a similar decision on a personal level.
The flip side of the argument is that data suggests that women especially won’t apply for roles that are “too specific” or have a long shopping list of demands, because women feel like they need to meet 75% of the person specification to apply. I agree with that wholeheartedly, but there’s a big difference between being far too specific and listing 12+ essential criteria for a role, and being soo unspecific you’ve become decidedly generic.
Especially when, as multiple studies have shown, in the public digital sector Job titles are often meaningless. Very rarely in the public sector does a job actually do what it says on the tin. What a Service Manager is in one Department can be very different in another one.
If I’m applying for an Infrastructure role I would expect the person specification to ask for Infrastructure experience. If I’m applying for a comms role, I expect to be asked for some level of comms experience; and I would expect some hint as too how much experience is enough.
So why when we are looking at Senior/ Director level roles in the Civil Service are we not helping candidates understand what level of commercial experience is ‘enough’? The private sector job adverts for similar level roles tend to be much more specific in terms of the amount of contract level experience/ knowledge needed, so why is the public sector being so woolly in our language?
*If you don’t get the blog title, I’m sorry, it is very geeky. and a terrible Philip K. Dick reference. But it amused me.
While I’m not one to complain about being busy; and given the effect the current pandemic has had on the economy I’m absolutely not going to complain about being busy and having a job.
However, after 6 months of working from home full time, it was pointed out to me politely last week by my other half; how much more work I have been doing recently (I haven’t had time to blog recently!) and that perhaps I needed to take a break.
Doing late nights and the occasional weekend of work is not new for me, that very much goes with the job once you reach senior leadership levels. But over the last few months I’ve been doing that far more often.
My normal way to relax and switch off, LARPing (google it) hasn’t existed this year because of COVID, my family holiday in May was cancelled, and with my partner getting made unexpectedly redundant in June because of the Pandemic, taking time off I didn’t need felt frivolous. So I haven’t taken any time off from work for months.
I haven’t minded, because work takes my mind off the current world events somewhat, and it’s been good to have something to focus on. But with it now being the summer holidays; the fact I’ve not been able to take even a few hours off to go to the beach or a museum (which are still closed because of local lockdowns!) with my family has really hit me; and made me feel somewhat of a failure on the parenting front, and personally just very stressed and like I was trying to do everything.
So, this weekend my partner dragged me out camping, just to get me out of the house and away from my laptop for a few hours; and I honestly hadn’t realised how much I needed to not be looking at a screen for a few hours.
The spot we went to had barely any signal; we deliberately had no way to charge our various devices; and there was nothing around us but the views.
It was bliss.
So, while I normally blog about work; I thought I might not be the only one who could do with a reminder right now that it’s important to take a breath sometimes.
It’s ok to need a break. Yes your work is important, but it doesn’t all sit solely with you; and you need to be able to share that burden and look after yourself too.
So please, even for a few minutes, move away from the computer, and take a deep breath. There is a world out there away from your screen. Make time to go find it.
The Beta Assessment is probably the one I get the most questions about; Primarily, “when do we actually go for our Beta Assessment and what does it involve?”
Firstly what is an Assessment? Why do we assess products and services?
If you’ve never been to a Digital Service Standard Assessment it can be daunting; so I thought it might be useful to pull together some notes from a group of assessors, to show what we are looking for when we assess a service.
Claire Harrison (Chief Architect at Homes England and leading Tech Assessor) and Gavin Elliot (Head of Design at DWP and a leading Design Assessor, you can find his blog here) helped me pull together some thoughts about what a good assessment looks like, and what we are specifically looking for when it comes to a Beta Assessment.
I always describe a good assessment as the team telling the assessment panel a story. So, what we want to hear is:
What was the problem you were trying to solve?
Who are you solving this problem for? (who are your users?)
Why do you think this is a problem that needs solving? (What research have you done? Tell us about the users journey)
How did you decide to solve it and what options did you consider? (What analysis have you done?)
How did you prove the option you chose was the right one? (How did you test this?)
One of the great things about the Service Manual is that it explains what each delivery phase should look like, and what the assessment team are considering at each assessment.
So what are we looking for at a Beta Assessment?
By the time it comes to your Beta Assessment, you should have been running your service for a little while now with a restricted number of users in a Private Beta. You should have real data you’ve gathered from real users who were invited to use your service, and your service should have iterated several times by now given all the things you have learnt.
Before you are ready to move into Public Beta and roll your service out Nationally there are several things we want to check during an assessment.
We don’t want to just hear about the ‘digital’ experience; we want to understand how you have/will provide a consistent and joined up experience across all channels.
Are there any paper or telephony elements to your service? How have you ensured that those users have received a consistent experience?
What changes have you made to the back end processes and how has this changed the user experience for any staff using the service?
Were there any policy or legislative constraints you had to deal with to ensure a joined up experience?
Has the scope of your MVP changed at all so far in Beta given the feedback you have received from users?
Are there any changes you plan to implement in Public Beta?
As a Lead Assessor this is where I always find that teams who have suffered with empowerment or organisational silos may struggle.
If the team are only empowered to look at the Digital service, and have struggled to make any changes to the paper/ telephony or face to face channels due to siloed working in their Department between Digital and Ops (as an example) the Digital product will offer a very different experience to the rest of the service.
As part of that discussion we will also want to understand how you have supported users who need help getting online; and what assisted digital support you are providing.
At previous assessments you should have had a plan for the support you intended to provide, you should now be able to talk though how you are putting that into action. This could be telephony support or a web chat function; but we want to ensure the service being offered is/will be consistent to the wider service experience, and meeting your users needs. We also want to understand how it’s being funded and how you plan to publish your accessibility info on your service.
We also expect by this point that you have run an accessibility audit and have carried out regular accessibility testing. It’s worth noting, if you don’t have anyone in house who is trained in running Accessibility audits (We’re lucky in Difrent as we have a DAC assessor in house), then you will need to have factored in the time it takes to get an audit booked in and run well before you think about your Beta Assessment).
Similarly, by the time you go for your Beta Assessment we would generally expect a Welsh language version of your service available; again, this needs to be planned well in advance as this can take time to get, and is not (or shouldn’t be) a last minute job! Something in my experience a lot of teams forget to prioritise and plan for.
And finally assuming you are planning to put your service on GOV.UK, you’ll need to have agreed the following things with the GOV.UK team at GDS before going into public beta:
Again, while it shouldn’t take long to get these things sorted with the GOV.UK team, they can sometimes have backlogs and as such it’s worth making sure you’ve planned in enough time to get this sorted.
The other things we will want to hear about are how you’ve ensured your service is scalable and secure. How have you dealt with any technical constraints?
The architecture and technology – Claire
From an architecture perspective, at the Beta phases I’m still interested in the design of the service but I also have a focus on it’s implementation, and the provisions in place to support sustainability of the service. My mantra is ‘end-to-end, top-to-bottom service architecture’!
An obvious consideration in both the design and deployment of a service is that of security – how the solution conforms to industry, Government and legal standards, and how security is baked into a good technical design. With data, I want to understand the characteristics and lifecycle of data, are data identifiable, how is it collected, where is it stored, hosted, who has access to it, is it encrypted, if so when, where and how? I find it encouraging that in recent years there has been a shift in thinking not only about how to prevent security breaches but also how to recover from them.
Security is sometimes cited as a reason not to code in the open but in actual fact this is hardly ever the case. As services are assessed on this there needs to be a very good reason why code can’t be open. After all a key principle of GDS is reuse – in both directions – for example making use of common government platforms, and also publishing code for it to be used by others.
Government services such as Pay and Notify can help with some of a Technologist’s decisions and should be used as the default, as should open standards and open source technologies. When this isn’t the case I’m really interested in the selection and evaluation of the tools, systems, products and technologies that form part of the service design. This might include integration and interoperability, constraints in the technology space, vendor lock-in, route to procurement, total cost of ownership, alignment with internal and external skills etc etc.
Some useful advice would be to think about the technology choices as a collective – rather than piecemeal, as and when a particular tool or technology is needed. Yesterday I gave a peer review of a solution under development where one tool had been deployed but in isolation, and not as part of an evaluation of the full technology stack. This meant that there were integration problems as new technologies were added to the stack.
The way that a service evolves is really important too along with the measures in place to support its growth. Cloud based solutions help take care of some of the more traditional scalability and capacity issues and I’m interested in understanding the designs around these, as well as any other mitigations in place to help assure availability of a service. As part of the Beta assessment, the team will need to show the plan to deal with the event of the service being taken temporarily offline – detail such as strategies for dealing with incidents that impact availability, and the strategy to recover from downtime and how these have been tested.
Although a GDS Beta assessment focuses on a specific service, it goes without saying that a good Technologist will be mindful of how the service they’ve architected impacts the enterprise architecture and vice-versa. For example if a new service built with microservices and also introduces an increased volume and velocity of data, does the network need to be strengthened to meet the increase in communications traversing the network?
Legacy technology (as well as legacy ‘Commercials’ and ways of working) is always on my mind. Obviously during an assessment a team can show how they address legacy in the scope of that particular service, be it some form of integration with legacy or applying the strangler pattern, but organisations really need to put the effort into dealing with legacy as much as they focus on new digital services. Furthermore they need to think about how to avoid creating ‘legacy systems of the future’ by ensuring sustainability of their service – be it from a technical, financial and resource perspective. I appreciate this isn’t always easy! However I do believe that GDS should and will put much more scrutiny on organisations’ plans to address legacy issues.
One final point from me is that teams should embrace an assessment. Clearly the focus is on passing an assessment but regardless of the outcome there’s lots of value in gaining that feedback. It’s far better to get constructive feedback during the assessment stages rather than having to deal with disappointed stakeholders further down the line, and probably having to spend more time and money to strengthen or redesign the technical architecture.
How do you decide when to go for your Beta Assessment?
Many services (for both good and bad reasons) have struggled with the MVP concept; and as such the journey to get their MVP rolled out nationally has taken a long time, and contained more features and functionality then teams might have initially imagined.
This can make it very hard to decide when you should go for an Assessment to move from Private to Public Beta. If your service is going to be rolled out to millions of people; or has a large number of user groups with very different needs; it can be hard to decide what functionality is needed in Private Beta vs. Public Beta or what can be saved until Live and rolled out as additional functionality.
The other things to consider is, what does your rollout plan actually look like? Are you able to go national with the service once you’ve tested with a few hundred people from each user group? Or, as is more common with large services like NHS Jobs, where you are replacing an older service, does the service need to be rolled out in a very set way? If so, you might need to keep inviting users in until full rollout is almost complete; making it hard to judge when the right time for your Beta assessment is.
There is no right or wrong answer here, the main thing to consider is that you will need to understand all of the above before you can roll your service out nationally, and be able to tell that story to the panel successfully.
This is because theoretically most of the heavy lifting is done in Private Beta, and once you have rolled out your service into Public Beta, the main things left to test are whether your service scaled and worked as you anticipated. Admittedly this (combined with a confusion about the scope of an MVP) is why most Services never actually bother with their Live Assessment. For most Services, once you’re in Public Beta the hard work has been done; there’s nothing more to do, so why bother with a Live Assessment? But that’s an entirely different blog!
June is Pride Month when members of the LGBTQ+ community and their allies come together in different ways to celebrate, remember and reflect. As such, now June is over, I wanted to reflect on the things I learnt this year.
This June was a Pride Month like no over, because of COVID-19; lockdown meant that the usual pride marches were cancelled and then moved online.
June was also the month that #BlackLivesMatter came to the forefront of Western consensus because of unforgivable killing of George Floyd in the US, amongst sadly so many others around the globe. With marches and rallies both in the US and UK (and elsewhere) to call for the end of police brutality and discrimination against Black people.
And finally, June (yep, still Pride Month) was when JKR yet again decided to use her platform to gatekeep women’s spaces and to decry the acceptance of trans women as women. (I’m not linking to her article, because I won’t give it airspace, but there are MANY fantastic pieces that explain why this stance is harmful, here’s just one. But the Tl:Dr version is, Trans Women are Women.)
As such, this month, more than any other June that we have seen in a long time, has been one in which the conversations about diversity and inclusion have been so important.
I was asked this month, why diversity and inclusion were important to me?
As the very wise Fareeha Usman, founder of Being women, said “Discrimination can only be tackled if we first tackle our own insecurities.”
Working within and alongside the public sector, we develop policies, products and services for the public; for citizens, for society. We can not develop things for people, if we can not empathise with them; if we can not understand where they are coming from and the problems/ barriers they are facing. The people we are building form come from diverse backgrounds. If our teams all look and sound the same, and have the same life experiences, then we will never be able to deliver things that meet the diverse needs of our users.
The Lesbians who tech (and allies) held their annual pride summit from the 22nd to 26th of June, and this year there was a clear focus on #BlackLivesMatter and also #TransWomenAreWomen as well; with a whole host of fantastic speakers discussing actions we can all take to be more inclusive. I was also lucky enough to be asked to speak at a D&I panel* on the 24th held by @SR2 and had the opportunity to attend the Dynamo North East event on the 25th, and to attend several other virtual pride events.
Key things I learned:
Locational geo-clusters can be a blocker to diversity and reinforce racial discrimination – @LorraineBardeen
When attending a meeting/ workshop or invited to sit on a panel, it’s our responsibility to check who else is ‘in the room’ and see if we are needed there, or is there someone else from a different group who’s voice needs amplifying more than ours. – @JasmineMcElry
When awarding contracts we need to look at companies track record on diversity / pay etc. And make sure we are not unconsciously biased against companies that have a makes up that does not match our own. – @SenatorElizabethWarren
It is our job to educate ourselves and not ask anyone else to educate us; as leaders our role is to admit we don’t know everything, that we are still learning, and to actively listen to others – @TiffanyDawnson
COVID-19, if nothing else, has given us the opportunity to think about the society we want to see coming out of this pandemic. We have all embraced things like remote working to help us keep working, now is the time to consider whether these tools can also help us going forward to be more inclusive in our workforce, and our society.
Removing the dependance on geographical hiring would enable us to include people from wider ethnic communities, as well as disabled people who have often found themselves excluded from office jobs by the commute etc; or people with caring responsibilities for who the standard 9-5 office job doesn’t work.
A fantastic session led by Nic Palmarini, Director of NICA, on Agism stated that “We need to reimagine a new society that is more inclusive”. This for me sums up the conversations I have seen, heard and been lucky enough to be part of this month; and I am proud to be part of a company, an industry and a community, that is trying its hardest to do just that.
Before I discuss what (in my view) a Service Owner is, a brief history lesson into the role might be useful.
The role of the ‘Service Manager‘ was seen as critically important to the success of a product, and they were defined as a G6 (Manager) who had responsibility for the end to end service AND the person who led the team through their Service Standard assessments.
Now let’s think about this a bit; Back when the GDS Service Standard and the Service Manual first came into creation, they were specifically created for/with GOV.UK in mind. As such, this definition of the role makes some sense. GOV.UK was (relatively) small and simple; and one person could ‘own’ the end to end service.
The problem came about when the Service Standards were rolled our wider than in GDS itself. DWP is a good example of where this role didn’t work.
The Service Manual describes a service as the holistic experience for a user; so it’s not just a Digital Product, it’s the telephony Service that sits alongside it, the back end systems that support it, the Operational processes that staff use to deliver the service daily, along with the budget that pays for it all. Universal Credit is a service, State Pension is a service; and both of these services are, to put it bluntly, HUGE.
Neil Couling is a lovely bloke, who works really hard, and has the unenviable task of having overarching responsibility for Universal Credit. He’s also, a Director General. While he knows A LOT about the service, it is very unlikely that he would know the full history of every design iteration and user research session the Service went through, or be able to talk in detail about the tech stack and it’s resilience etc; and even if he did, he certainly would be very unlikely to have the 4 hours spare to sit in the various GDS assessments UC went through.
This led to us (in DWP) phasing out the role; and splitting the responsibilities into two, the (newly created role of ) Product Lead and the Service Owner. The Product Lead did most of the work of the Service Manager (in terms of GDS assessments etc), but they didn’t have the responsibility of the end to end service; this sat with the Service Owner. The Service Owner was generally a Director General (and also the SRO), who we clarified the responsibilities of when it came to Digital Services.
A few years ago, Ross (the then Head of Product and Service Management at GDS) and I, along with a few others, had a lot of conversations about the role of the Service Manager; and why in departments like DWP, the role did not work, and what we were doing instead.
At the time there was the agreement in many of the Departments outside of GDS that the Service Manager role wasn’t working how it had been intended, and was instead causing confusion and in some cases, creating additional unnecessary hierarchy. The main problem was, is it was in DWP, the breadth of the role was too big for anyone below SCS, which mean instead we were ending up with Service Managers who were only responsible for the digital elements of the service (and often reported to a Digital Director), with all non digital elements of the service sitting under a Director outside of Digital, which was creating more division and confusion.
As such, the Service Manual and the newly created DDaT framework were changed to incorporate the role of the Service Owner instead of the Service Manager; with the suggestion this role should be an SCS level role. However, because the SCS was outside of the DDaT framework, the amount the role could be defined/ specified was rather limited, and instead became more of a suggestion rather than a clearly defined requirement.
The latest version of the DDaT framework has interestingly removed the suggestions that the role should be an SCS role, and any reference of the cross over with the responsibilities of SRO, and now makes the role sound much more ‘middle management’ again, although it does still specify ownership of the end to end service.
Ok, so what should a Service Owner be?
When we talked about the role a few years ago, the intention was very much to define how the traditional role of the SRO joined up closer to the agile/digital/user centred design world; in order to create holistic joined up services.
Below is (at least my understanding of) what we intended the role to be:
They should have end to end responsibility for the holistic service.
They should understand and have overall responsibility for the scope of all products within the service.
They should have responsibility for agreeing the overall metrics for their service and ensuring they are met.
They should have responsibility for the overall budget for their service (and the products within it).
They should understand the high level needs of their users, and what teams are doing to meet their needs.
They should have an understanding (and have agreed) the high level priorities within the service. ((Which Product needs to be delivered first? Which has the most urgent resource needs etc.))
They should be working with the Product/Delivery/Design leads within their Products as much as the Operational leads etc. to empower them to make decisions, and understanding the decisions that have been made.
They should be encouraging and supporting cross functional working to ensure all elements of a service work together holistically.
They should be fully aware of any political/strategy decisions or issues that may impact their users and the service, and be working with their teams to ensure those are understand to minimise risks.
They should understand how Agile/Waterfall and any other change methodologies work to deliver change. And how to best support their teams no matter which methodology is being used.
In this way the role of the Service Owner would add clear value to the Product teams, without adding in unnecessary hierarchy. They would support and enable the development of a holistic service, bringing together all the functions a service would need to be able to deliver and meet user needs.
Whether they are an SCS person or not is irrelevant, the important thing is that they have the knowledge and ability to make decisions that affect the whole service, that they have overall responsibility for ensuring users needs are met, that they can ensure that all the products within the service work together, and that their teams are empowered, to deliver the right outcomes.
One of the most common questions that comes up in Bid opportunities is usually some variant of “how do you transfer your knowledge to us before you leave?”
This is completely valid question, and really important to both ask, and to understand, but also hard to answer well in 100 words without risking looking like knowledge transfer is only a nice to have!
Having been on the other side of the commercial table, making sure you get a supplier who will want to work with you and up-skill your own people so you are not reliant on the supplier forever is generally vital to both making sure the project is successful, and cost effective.
I’ve written Invitations to Tender that ask for examples of how suppliers would go about transferring knowledge and up-skilling my teams. I’ve sat through bid tender presentations as the buyer and listened to suppliers try to persuade me that they know best, and that they have the expertise my organisation needs to deliver a project or programme.
I was generally able to spot very quickly those organisations that took this more seriously than others, those that would work collaboratively with us vs. those more likely to just come in and do a sales job and leave us none the wiser reliant on their services.
But, if I’m honest, I never really judged that feel on the words they said, but more through the words they didn’t say, and more importantly HOW they said or didn’t say it.
Everyone can say the words ‘show and tell’, but how are you doing them? How are you getting stakeholders engaged? How are you making sure you have the right people turning up to engage with the project?
You can say you use Trello, JIRA, or Confluence etc. to create shared digital spaces to run your backlogs or share information; but how do you make sure the right people have access to them and know how to use them? How do you agree what information is going on there and when? How do you determine what information the team can see vs. your stakeholders, and make sure the information is understandable to everyone who needs it?
As long as suppliers are putting in key buzzwords, that nuance is hard to judge within 100 words, but so key to understand. And it’s not only important for the buying organisation to understand how the supplier would transfer knowledge, but it’s actually really important for the supplier to understand how receptive an organisation is as well.
I always assumed ‘knowledge transfer’ was something that was easy for suppliers to do as long as they put in some effort.
Now I sit on the other side of the table, its something i’ve realised there is a real art too. Not just writing a bid response that gets the message across, but doing it once you hit the ground. I’d always assumed that, as long as the team/ buying organisation was keen and engaged, knowledge transfer would be easy to do.
Eight months later I’ve realised it’s not as easy as it looks, as a supplier there’s a very fine line to walk between supporting an organisation, and looking patronising. Just as every organisation is somewhere different on their agile/digital journey, so is every individual.
A one size fits all approach to transferring knowledge will never work. You can’t assume because an organisation is new to agile or digital, every individual within the organisation is. Some organisations/people want more in the way of ‘coaching and mentoring’ others want less. Some organisations/people will say they are open to changing their ways of working, but will resist anything new; others are champing off your hand for every new tool or technique. Some want walking through everything you are doing so they can learn from it, others want you to just get on and deliver and tell them at the end how you did it.
And as suppliers, there is often as much we have to learn from the organisation as there is to ‘teach’, while we might be the experts in agile or digital or delivering transformation; we need to learn about and understand how their organisation works and why.
There is no ‘one answer’ on how to do knowledge transfer, and it’s not a one way street. It’s how you approach the question that is important. Are you open to working with an organisation (either as the buyer or the supplier) to understand how you can work together and learn from each other? As long as you are open to having those conversations and learning from each other, then the knowledge transfer will happen.
The Agile Prime Directive states“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
This is a wonderful principle to have during Retrospectives, in order to avoid getting stuck in the blame game, and to instead focus on results.
However, lets be very clear, the Agile Prime Directive isn’t an excuse for not delivering. If every sprint you miss your sprint goals, or you’re team constantly suffers from scope creep etc. Then you need to look a bit deeper to understand what is going wrong.
Even if you agree every individual did the best job they could, as a team are you working best together? Are you understanding your teams velocity as best you can? Do you all understand and agree the scope of the project or your sprint goals? Have you got the right mix of individuals and roles in the team to deliver? Is your team and the individuals in it empowered to make decisions?
If the answer to any of these questions is no, this could be impacting your ability to deliver.
The Agile Prime Directive is a good mindset to start conversations in, as we want to create safe and supportive environments for our teams in order to help them achieve their full potential, and recognising that everyone has room to improve is an important part of that. Nowhere in the Agile Prime Directive does it state everyone is perfect, just that they did their best given the skills/ ability and knowledge they had at the time.
However, while it is a good mindset to start with, unfortunately we all know it’s not 100% true. the Agile Prime Directive itself has issues, while it’s a lovely philosophy, and its intent is good; as a manager, and as a human I have to admit even to myself I haven’t ‘done my best’ every single day.
While most of the time we do all try our best and do our best; everyone has bad days. Occasionally on a team there will be someone who isn’t (for whatever reason) doing their best, their focus is elsewhere etc. External life will sometimes effect peoples work, the kids are ill, they have money worries, their relationship has just ended; these things happen. There will be people who don’t work well together, they can be cordial to each other, but don’t deliver their best when working together, personality clash happens. We need to be able to spot and call all out these things, but we obviously need to be able to do so in a positive and supportive way as much as possible.
Open and honest communication is the key to delivery; and having a culture of trust and empowerment is a critical part of that. We need to create environments where people feel supported and able to discuss issues and concerns, and we need to acknowledge that sometimes, for whatever reason, those issues do come down to an individual; and while I’m not suggesting we should ever name and shame in a retrospective, we need to be able to deal with that in an appropriate way.
We need to not only know and understand that even if everyone ‘is doing their best’, they can still do better; but that sometimes we need to be able to recognise and support those individuals and those teams who for whatever reason are not doing or achieving their best.
These issues can’t always just be ‘left to the retro’, while the retro is a great space to start to air and uncover issues, and learn from what has gone well, and what needs to improve; part of leading and managing teams is understanding which conversations need to come out from the retro and be dealt with alongside it.
If we are constantly missing sprint goals or suffering scope creep, we can not simple say ‘but we are all doing our best’, that isn’t good enough. In this instance the participant award is not enough. We are here to deliver outcomes, not just do the best we can.
Changing how we work, to ensure we can still deliver.
One of the big tenants of agile working has always been about the importance of colocation, and there are a million blogs out there on why colocation makes a big difference.
The first value of the Agile Manifesto states: Individuals and Interactions Over Processes and Tools; and one of the 12 principles is to Enable face-to-face interactions; this is because it is generally understood that colocation allows a better ‘osmosis’ of knowledge between the team, allowing better and faster sharing of information and discussions.
But colocation has always had its downsides, the main ones being that constant colocation doesn’t’ allow people time to process information and work without interruption/ distraction. There’s also a large time and cost implication; with team members and especially Subject Matter Experts often having to travel a lot to remain engaged. The most common excuse I have heard from Senior Leaders in organisations on why they can’t attend user research sessions or show and tells etc. is the time and effort it takes not only to attend the event, but to travel to it as well.
As we get better at recognising that not everyone works in the same way; recognising the limits of colocation is also important.
For the last few years, most of the teams I’ve worked on or managed have used a mix of colocation and remote working; usually a minimum of 3 days (ideally 4) in the office working together and only one or two days working from home.
This allows the colocated days to be utilised best for design workshops, user research, sprint ceremonies etc. Days where we can make the most out of being face to face.
That means the ‘remote working’ days could be used to reflect, to review notes, ‘do work’. They were also the days that could be best used for meetings etc.
Obviously COVID-19 threw all of those ways of working on their head; with everything that could be done remotely, moving to be fully remote. Within Difrent in that time we have on-boarded new staff, stood up brand new teams, completed Discoveries, delivered critical services to help with the nations response to the pandemic etc. Now as we consider how we move to a world post pandemic is the time to pause and consider whether we need to (or even want to) return to old ways of working.
A conversation at the virtual #OneTeamGov breakfast meet last week highlighted that Lockdown has meant we have all had to find more inclusive ways of working. It used to be the case that people ‘in the office’ would often make most of the decisions, and then replay those decisions to us few remote workers. Nowadays, with no one in the office, it forces us all to think about who needs to be involved in conversations and decisions. It might take a bit more planning, but it allows us to be more considerate of people’s time and involvement.
Within Difrent we have recognised that a return back to full colocation is actually not necessary in order for us to keep delivering services that matter. Working remotely has not impacted our ability to deliver at all. Rather than having remote working be the exception, we are now planning how we can make that the norm.
Thinking about how we put people before processes; we are ensuring we use the days where we will all get together face to face to their best advantage, making sure we get value from peoples time and the effort they have put in to travel and that we are adding value to them (and the project) in return.
The discussions we had at the time focused on “how do we actually define the role? And what makes a good product manager?” And there have been plenty of blogs written on those questions over the years. It definitely feels like the role has matured and progressed over the last few years, and now is generally pretty well recognised.
However yesterday chatting to Si Wilson about SME’s and Product Managers, and why they were different roles, I realised this may be one area not touched on much, and actually a pretty key difference it’s important to understand.
In the private sector, the Product Manager is often “the voice of the business”, they are equally seen as the “voice of the customer” but when developing products to take to market and make a profit, it’s less about what the users need, and what the business can sell to them.
In the Public Sector, the role of the Product Manager is a bit different. The Product Manager is NOT the voice of the business, instead they are the voice of the vision. The Product Manager is responsible for ‘what could be’ they ensure the team are delivering quality and value, weighing up the evidence from everyone else in the team and making the decisions on where to focus next in order to meet the desired outcomes.
This slight change in focus is where the role of the Subject Matter Expert (SME) comes in. The Scrum Dictionary states the SME is the person with specialised knowledge; in my experience the SME provide’s the voice of the business; and what ‘is’ rather than what will be. They understand the in’s and out’s of an existing product, service or any sacred cows that need to be avoided (or understood) within an organisation. They usually work closely with the Business Analyst to map out business processes and User Researchers to understand staff experiences.
Back when we merry band of Head’s of Product were trying to understand the role, the decision to not have Product Managers ‘be the voice of the business’ was a very deliberate move as we felt it hampered the move to User Centred design, as it felt it was hard to step back and be agnostic about the solution if you’ve had years in the business and know every pain point and workaround going etc.
Some of the dangers of having a Product Manager who is also an SME are:
They feel they know everything already because of their experience, so feel that user research or testing is a waste of time.
They become a single point of failure for both knowledge and decision making, with too many people needing their attention at the same time
They can get lost in the weeds of details, which can lead to micromanaging or a lack of pace
That is not at all to say that Product Managers can’t ‘come from the business’ because obviously having some knowledge about the organisation and the service is helpful. But equally, having a clear delineation between the roles of the Product Manager and the SME is important; so if you do have someone covering both roles, it’s important to understand which hat is being worn when decisions are made; and for that individual to be able to draw a line between when they are acting as the PM and when they are the SME.
As a Product person, a good SME is worth their weight in gold. good ones bring loads of speed and stretching thinking — and even packaging thinking. They can help identify pain points, and help user researchers and business analysts find the right people to talk to when asking questions about processes’ etc. They give the Product Manager room to manoeuvre, and make sure things are moving on. Equally the best SME’s can be pragmatic, they understand that what the business wants doesn’t always match what users want, and work with the team to find the best way forward.
Where the role of the SME hasn’t worked well, in my experience, it tends to be because the individual hasn’t been properly empowered to make decisions by their organisation or line manager; or don’t actually have the knowledge required, and are instead their to capture questions or decisions and feed them back to their team/manager. Another common issues is that the SME can’t be pragmatic or understand the difference between user needs and business needs; and won’t get involved in user research or understand its importance. Rather than helping the team move work forward, they slow things down; wanting every decision justified to their satisfaction; wanting to make decisions themselves rather than working with the Product Manager.
Rarely have I found SME”s that could be dedicated full time to one project, they tend to be Policy or Ops experts etc. and so there are a lot of demands on their time. I suspect this is one of the reasons the role of the SME and Product Manager if sometimes blended together. However, while they ‘can’ be filled by the same person, in my experience having those roles filled by separate people does work much better, and allow the team to deliver value quicker.