Mike is a new delivery manager, joining the team that look after Check if you can get legal aid, the related call centre software and backend systems. We chatted about bureaucracy in different orgs, his preferred style of delivery, our shared ideal of dynamic reteaming and Mike's experience of the GDS way where "people express preferences to move product areas using a survey" every quarter. I think there a few blockers to working in this way at LAA Digital but would be great to get there.
Brlliant chat with René who has worn a few hats in the digital space before getting into product by building Gapelist. And he learnt a bunch of technical stuff to make this possible, e.g. getting certified in AWS Cloud as a practioner and working towards Solutions Architectc certification. Amazing! So beneficial!
Met Daniel properly this week. Talked about his way into digital ways of working at various different employers and learnt that he ran street food stall in London selling shakshuka. Talked about pschological safety with a passing reference to Project Aristostle, and briefly touch on importance of measurements to understand the flow of value, e.g. value stream mapping and applying theory of constraints. Continuous delivery can get super geeky if you're into that sort of thing.
I also briefly met Adam, another new delivery manager, but this was part of another meeting, so no opportunity to get to know each other. And met Faith and Jake too in a meeting. There's a theme here. Good work is enabled by good relationships so should catch-up with them properly too! So much of this would have been done in the pub pre-Covid. Find myself needing to be way more intentional about this these days as Zoom meetings require organising.
Sometimes it's hard to attract a strong and diverse field of applicants for permanent roles. The recruitment principles help here as I initially thought we might be blocked by bureauratic rules:
The media chosen to publicise appointment opportunities and the time allowed for advertising must be suitable for attracting a sufficiently strong and diverse field of applicants, taking account of the nature of the role and the relevant job market.
Also, should we switch from passive to active recruitment for permanent roles which nearly always result in little to no applicants. I'm looking at you Technical Architects. Active recruitment is outsourced for contractors via Public Sector Resourcing. This could be an answer to the question posed to the recruitment panel Chair in the aforementioned principles:
Before a competition may proceed to advertising, the Chair must therefore approve the selection criteria, role description, panel membership, process to be followed, timetable, remuneration and other terms, and the advertising strategy, including how best to attract a strong and diverse field of applicants.
Despite this, we have been lucky enough to drastically improve our gender diversity, going from 3 to 9 women working as software developers by the time everyone lands! That will be 25 / 75 split women to men. So still a way to go on this front.
Who else did you talk to?
Spoke to Heidar and Oli about making it easier for people, particularly developers, to contribute to architecture as code repo, which generates these diagrams. Incidentally, this is brilliant work! We've got to understand the current state before we head off in a future direction. We've had 2 developers contribute so far. Without explicitly saying the term OKR, we kind of agreed on one which was "diversify contributions to Architecture-as-code repo" with key result of "at least 1 developer per team making a contribution". Making it easy to contribute will help achieve this I'm sure.
We also discussed accessing a budget ring-fenced for risk/debt work and appropriate candidates. Luke confirmed there was and the money hadn't all been spent! We're in the process of working out how to spend this wisely. I think this budget might have been rejected by teams a while back before we're trying to fund teams, not specific projects, and work sustainably. Now teams have matured, we're in a better place to work with this funding model, but ideally we could get to a place where funding didn't happen like this. But government funding has a way to go before it gets there, although need for risk/debt budgets will reduce over time as teams get better at software maintenance vs new work, plus better at having a sustainable portfolio of things. It's pretty clear to me now that a major reason why people have felt burnt out and it's been almost impossible to transform services is because project after project resulted in increasing number of systems, with a static headcount, thus risk/debt goes up. Only in the past year has started to be addressed, thus we've grown by 30+ people, although I still think we're thin on the ground in certain areas.
Had a brilliant chat with Rich and Laurence about the challenges of being two people working on key systems that underpin LAA Digital (example of above paragraph playing out). They feel like one of them is unofficially on-call out of hours because they feel so much responsibility and care for their users. They are migrating the remaining systems from a traditional data centre to AWS, recently upgraded to the latest version of Oracle DB (version 19), whilst resisting the urge to modernise some legacy tech, e.g. Pro*C is in use in some places!
Asrar was chuffed with the progress towards continuous delivery, zero down time deployments for parts of CCMS. The team's hard work continues to pay off. Lots of stuff containerised, which will reap dividends once migrated to AWS where sane pipelines can be put in place.
Spoke to Mark and Said separately about the value of doing our take on crowdsourcing technology governance. They have a plan to write some uncontentious guidance that can act as an example of how guidance should be written, plus ideas for categories that will be make for a diverse discussion between developers. Imagined future workflow is (1) anybody can raise an issue on Github either asking for missing guidance or changing existing guidance (2) person who raised issue, along with moderators encourage async debate on the issue (ideally debate doesn't happen in Slack or verbally because of ephemeral nature and lack of inclusion / visibility) (3) ideally healthy debate happens between developers of all levels and technical architects (4) pull request created where guidance is written up and follows some kind of approval process (5) guidance is published when PR is merged into main branch. Some potential categories are: collaboration tools, application frameworks, caching, data stores, API gateways, CI/CD, Cloud and Compute, Containers, Developer Tools, Logging, Monitoring, Address/Postcode Lookup Services; basically recommendations on things to use and, importantly, not to be confused with coding standards, although specifying tools for enforcing standards, measuring code complexity, etc makes sense. We have already have code standards but they definitely need a refresh.
Had a chat in SMT about how external stakeholders understand the roles within a typical digital team. When teams go from forming to high performing, boundaries between the roles and their responsibilities become fuzzy because silos between disciplines are broken down, people emerge into different roles as need dictates, with people swapping hats intentionally sometimes. This blurring of responsibilities is an awesome sign of high cohesion. However, from the outside, stakeholders might not appreciate this and get confused with who they should be talking to. Ideally, a business stakeholder would become part of the team so they could intimately understand this and do some hat-swapping themselves. Probably a while more until this happens but necessary if we're to meet the vision of one team. One day we'll stop saying things like "the business".
I had a few regular 1:1s too. A few interesting things: some people will work despite not feeling well and encouraged to take time off; enthusiasm and motivation will often solve a gnarly technical problem - a pair of devs are working on a side project in 10% time to scratch their developer itch without asking for permission to do so or understanding the true value, sometimes you just have to trust your instincts; "really busy, but not productive" someone said and helped them work through this common feeling when helping others instead of doing the work yourself:
A lot of effective leadership is about growing the potential in others. It’s about the move away from ‘maker mode’, where you’re focused on what you produce, to ‘multiplier mode’, where you’re focused on helping others bring out their potential. In software teams, there are always opportunities to multiply others to help and support other people’s growth.
Michael and I dug deep into two things that were discussed in the people manager meeting, a manager's round table of sorts. I don't attend this at the moment, freeing up time for other things. I checked that this was still okay. Yes, there was value in me not attending! A rubber-ducking of sorts happens. Peer support is better by removing me, the notional principal in the group. Only when the group of managers need my support will someone talk me through the problem and recommendations. At my layer of the onion, I can influence structural change and organise things. And on that note, the two topics were (1) moving the protected 10% L&D time from profession level (every Tuesday afternoon atm) to the team level (2) written guidance for professional objectives at the Developer level. I really appreciated Michael sparing his time to reflect on topics that impact our whole profession!
Quotable Slack messages
...the lack of bounded context between “ERP concepts” and “LAA concepts” creates this spaghetti mess.
- Adrian
Did you watch / listen / read anything helpful?
Yeap, I've been attending LeadDev Together sessions when I can. I'm a few weeks behind. I watched a talk called "Difficult listening and having difficult conversations" by David Yee. Here are my notes.
Abu left on Monday. He described the change he has seen whilst at LAA Digital for 18 months as "going from black and white to technicolour". One his best times was throwing sweets around a function room in the basement of the Home Office building in Marsham Street. Somehow related to team building activities from memory. He's off to work at HMRC, maybe to kill off IR35 from within 🤣.
What was your meeting of the week?
⭐️⭐️⭐️⭐️⭐️ goes to CIS/CWA/MI Apps & CCMS Migration Planning for outstanding facilitation by Simon.
The tail end of my week off went well. Spent a few days in Pagham. And finished the weekend off on Sunday night with a semi-regular video with friend group. We call ourselves the miserable bastards. We finished the 2 hour catch-up by completing the guardian crossword together, nice sense of achievement. So started the working week off feeling refreshed, plus got a visit into the gym on Monday morning at 8am, partly motivated by the impending lockdown v2.
Vision / strategy session
It's always helpful to have the time and space to talk vision and strategy. It gives a chance to course correct, align and build a shared understanding of our direction as new information appears. We were lucky enough to have Matthew Davies from Madetech to guide us through:
Why are we doing what we're doing
vision for the future (think 5 to 7 years)
think about objectives to iteratively get us closer to vision
ran out of time for the futurespective
We were all aligned on why we need strategy 😀, coming up with themes as broad as culture, comms, technology, digital practices, user needs, access to justice and helping legal aid providers. The vision piece resulted in affinity groups digital first, one team, sustainable services, collaborative culture, data-led, delivery excellence, API-first culture, influencing policy, excellent supplier partnerships, ...
I found the objectives session a bit harder. I try to adhere to the lessons from Good Strategy, Bad Strategy, and resist objectives until we diagnose the problems and get a collective view on what's most important to work on. Blue sky objectives are helpful to some extent as it's a signal to where the group align or don't align based on everyone's perpsective. The things we were going to delve into and work out how to measure were Products Are Based Around User Journeys, Not Systems and Continuous Delivery Pipelines For All Software We Build. Brilliant! We ran out of time but really got into the nitty gritty of the first objective. We delved into some of the topics talked about in the Team Topologies book, e.g. teams built around cognitive load, autonomy, an appreciation of Conway's law. Structuring teams around user journeys or segments of user journeys is one aspect of organising products but not the only one. I'd like to continue to focus on this topic, including many voices, before we settle on anything.
Did you meet anyone new?
Yes, I met new developers and delivery managers.
Eloise has started as a developer. We had quite an unstructured chat, covering lots of things. Learning styles. Tried my best not to overwhelm her with too many L&D options. Her time teaching at a bootcamp and prior careeer as a tech recruiter. Plus her tendency to try to learn all the things. I pointed her to Julia Evans website as a resource for visual learning. We also talked about women in tech. By the end of this year, we will have 8 female software developers, up from 3 just a week ago!
Rose has joined us as a developer with a specialism in front end, but very keen to continue full stack. Fascinating how she got into software development. Whilst studying philosophy at uni, she did a module on logic and computing, masters in cognitive science, and discoverd she really enjoyed working in computing. I love hearing how people view computing and how their interest drives them to explore new domains. If you're curious, love learning and solving problems, working with computers will never be boring. Talking to Rose made me think about my own experiences and reminded me of all the things I know little about but would love to and the considerations of going deep vs seeking breadth of experience.
Alice joined 3 months ago as a delivery manager and it's my bad for not meeting her sooner. We spoke about her career path too, plus I gave talked about the evolution of LAA Digital, the challenges ahead, shared a few reading recommendations, e.g. Dave Roger's series on toxic technology and a recent series on sooner, safer, happier delivery by Jonathan Smart. Dave's series talks describes the reason behind some of our technology estate and Jonathan's writing gives ideas about how we forward.
I also briefly met Daniel Susser, another new delivery manager, but this was part of another meeting, so no opportunity to get to know each other.
Who else did you talk to?
I haven't spoken to Dave for ages so I called him up. Besides the usual chat, he told me about the amazing progress with containerisation of SOA compositites, one by one migration to AWS and building up a SOAP UI tests as they go. This is some of the hard work of bringing us closer to continuous delivery for bits of the monolithic ERP I mentioned above.
Met with two developers who do contract work for LAA Digital. With Giuseppe, spoke about his excitement about learning Rust. With Atri, reflected on our modern work culture compared to his last place - QAs outnumbered developers vs build quality in approach; flexible collaborative ways of working plus mentioned how I'd love to see a team try mob programming for a week, including non-devs too.
Caught up with Abdul about his work introducing practices that will help with the migration of a key LAA system.
Caught up with Lesley, our amazing recruiter, a few times this week. Still seems to be confusion about how to apply new salary framework. Hope to get to the bottom of it soon.
We have some Java recruitment going on. Caught up with the team running the campaign, reflected on the criteria we assess against in the interview process and determined we need to tighten it up a bit. Really good to see that we have been constantly iterating and improving the whole recruitment process over the last few months, from better job adverts, assessment critiera, different styles of questions. One big area to improve on is marketing our job adverts. At the mo, I don't think we're placing ads in some of the typical places developers look for jobs.
Had a great chat with Fleur. She commented at the end that it felt like therapy, in a good way I think. Chatting through things, getting different perspectives on things, listening and connecting is simple yet underrated and often doesn't happen enough. I'm actively trying to chat to more people to make up for all of the incidental, unplanned corridor chats that used to happen. These glue conversations were so important looking back.
Lovely to speak to Nabeeha. It's been a while. She works in another part of MoJ, and is currently trying to bring Service Now development in-house. She needs help with recruitment. Service Now is used for IT Service Management. I know nothing about Service Now. Appears to be going through some of the same challenges as we have in LAA. Customisations galore has meant change is difficult, so the strategy is to strip away all customisations and get back to basics. Hope to help her where I can. From first glance, it looks like Service Now is a low-code solution.
What did you read this week?
It's Time for... ERP Disruption
We have a two installations of Oracle E-Business Suite and they display a lot of the symptoms of toxic technology. The teams working on these systems everyday have embraced the challenges and are working to create the conditions to ultimately break apart the monolith.
I read It's Time For... ERP Disruption (Applying Wardley Mapping and DevOps Techniques To The ERP Ecosystem), a chapter from Dev Ops Enterprise Journal, Fall 2020, nodding along, increasing my empathy levels for those doing the hard work of disruption.
It's the first time I've come across a piece of writing that sums up the rise, the subsequent industry of customisations to make up for the mismatch between business need and out of the box features, with every step taking us further towards maximum complexity and away from simple, reliable way of making software.
Because these systems were relatively new and only contained basic functionality, enterprises often needed to build other homegrown systems to augment the functionality contained in the MRP or ERP. Building adjacent systems was both a blessing and a curse.
The chapter proposes a bunch of recommendations, some of which I believe the teams are working towards. I think we need to develop a clearer understanding of where enterprise COTS (who wants to build there own accounting system) and where it isn't appropriate, by learning from within, reading things like "Fake COTS" and the one day rule, understanding the SaaS marketplace, appreciating the difference between UI-first SaaS and API-first Saas (think Stripe and Twilio) and understand core vs context, i.e. what to build internally and what services to rely on via third-party services or suppliers.
Not yet read the other pieces but the Dev Ops Enterprise Journal, Fall 2020 looks like an awesome read.
What have you added to your reading/watching list?
Came across a link to an MIT Press Journal issue on The Rise Of Legal Design whilst emptying the inbox. This looks like it'll help me understand more about the legal system, in an interesting way. Unfortunately it's a paid for journal. Need to check with the work library to see if I can get access.
How to get better at building on platform infrastructure
Over the past few weeks have been thinking about how platform teams innovate whilst at the same time provide a stable offering for applications to be hosted on. Concepts like error-budgets, an appreciation of SLOs, and effective communication between platform and product teams. One thing to try is to introduce a semi-regular retro with users and the providers of the platform. Not sure how this will work in practice but keen to see if it's a useful ceremony to tick off user research, engagement and forum to impact the platform roadmap.
Preparing for new developers joining
Met with teams who have new developers joining. Reflecting on what good onboarding looks like, should we be moving people management closer to team boundaries, what does good people management look like, what can developers do to support each other within teams vs outsource to a people manager, a general awareness of Tuckman's phases of team development. Some really good things have come out of these sessions:
Reach out to new starter before they start. One practical reason is because the formal letter from SSCL still says to turn up at the building in Petty France. We all work from home nowadays.
Understand how to get equipment
Improve team's ownboarding checklist
Have a few different people ready for new starter: mentor (less frequently, talk about career progression), buddy (same level, informal, no question is stupid), people manager (wellbeing, look after the formal stuff like holiday, sickness, performance/conduct, career conversations, coaching). There's quite a divide on who should/shouldn't be a people manager, what good looks like, whether formal line management should be within or outside team. As we get to 40 developers, thinking about a structure to suit and one that works for the majority. There's no perfect model, people need different things at different times, and the org has needs to. Lots of thinking still to be done and maybe some trial and error.
Other notable things
found out the Scottish Government might be working on a "payment out" platform. Wondering if it's be the answer to my question.
Attending weekly senior management team meeting. Learnt the delivery profession are looking at plandek to help measure and visualise metrics. A quick scan through the web page puts me off almost completely. Scaled Agile, run away! I'd opt for understanding what you want to measure and why, then start small and get good at measuring manually. Only then, bring in technology to reduce the manual, but valuable work. Basically an agile approach. Been bitten by off the shelf software too many times (this is becoming a theme in these weeknotes 😂)
HMCTS are starting to bring product delivery in-house. They're looking for resources to help with recruitment drive. Will try to help out where I can whilst being aware not to say no so I can also focus on my main area.
