Category: Weeknotes

I went to the 41st edition Data Bites at the Institute for Government. If this is your first time reading about them, these are monthly events where four speakers present eight (a byte) minute presentations on topics relating to data in government. Then a short, eight-minute-long conversation follows.

They are organised because (from their website)

Better use of data is key to more effective government. Across government, teams are doing fascinating work with data, on everything from policy to public services, to visualisation and ethics.

But that work often doesn’t get the attention it deserves. ‘Data’ means many different things across government and is fragmented across (and within) different organisations, professions, and functions. Those not working directly with data may not understand the benefits better information can bring.

I found the presentation from the Hackney Local Authority the most interesting. Sandrine Balley presented how and why they developed a web map template to open up spatial data on their website. The lack of open data publication platforms motivated them. They wanted to have something simple, so there was no need for great technical skills or expensive commercial products to publish the authority’s geospatial information.

It works, and it solves their problem. However, when asked what they are doing to promote their solutions to other local authorities to share their work, Sandrine admitted that they “could do more”. And, of course, they were at the Data Bites. They are promoting the work. But as often in similar settings, the focus was on “look what we have done!”. It is not about sharing the technology, asking for collaboration to take it to the next step. It is about sharing success stories. Important, but an invitation to cooperation would be more powerful.

Since I joined the Civil Service and its Digital, Data and Technology function, I was inspired by the ambition to work in the open and reuse technology for the public good. And for better value for money. But I am growing more and more disappointed. There are some good examples of this, like for the Design System, but by large, the same problems are solved again and again with code dumped in public github repositories, but never reused.

This is despite the fact that there is a lot of effort to standardise and to enforce encourage compliance with centrally approved standards. I think the “standards” and “central” are parts of the problem in our very federated and rather anarchic organisation. I disagree. I have been talking about the benefits of agreeing on simple protocols over implementing standards whenever I have a chance. And there is plenty of opportunity because there is no shortage of big government projects aiming at standardising, centralising, solving “it” for “all”. I don’t think it will ever work. I think we need to find ways to collaborate without coordination. And protocols like those powering the internet, are good examples on how to do it.

And so I was very happy to come across The Unreasonable Sufficiency of Protocols article earlier this week. It is very long, but worth the time to read text about the benefits of protocols. It also differentiates protocols from related terms like standards, conventions, APIs, and platforms. It explains why protocols are best placed to increase cohesion without decreasing autonomy. This is what we need to collaborate without coordination. Have a read if you can spare the time. I hope I will get to discuss it soon at the 2023 Open Data Camp unconference in Wolverhampton.

There were a few other things this week that would be worth mentioning, but it is already Monday morning, 6 am local time in New York, and in two hours the Knowledge Graph Conference will start. I hope to learn much

A more practical week this time! One when nothing was finished, but quite a few things have been started. 

Contents: 

• The 12in23 is spreading – we learn together
• Practising mob programming – we learn together
• Applying Team Topology – we work together
• Explaining programming to somebody brand new

The 12in23 is spreading!

Outside work, I continue on my #12in23 challenge – completing the first two languages. But that aside, it was great to see that quite a few colleagues joined in on the fun (and learning) after talking to them about it the week before. We are now sharing profiles on Exercism.org and learning together. Where will this lead?

Practising mob programming

Talking about learning, on Friday, I led a small workshop in mob programming with three data engineers using cyber-dojo.org. It went well, and I think we all learnt something. More importantly, we might have addressed some negative feedback from the last half a year of pairing in our data engineering. Drivers were reporting how stressful driving in a pairing session can be. But focusing on the need to share an idea before it is encoded, the fact that it is the navigator who comes up with ideas and the driver just codes it in, solved that problem, I think. 

It was the first such workshop I ran in the department, and it won’t be the last. It’s a natural continuation of discussions about software engineering with my coding colleagues who are not in software engineering professions. 

Applying Team Topologies

But that’s not the limit of last week’s experiments. After some convincing and some negotiating, we have started a very small-scale experiment in Team Topologies in Civil Service applications. We have set up a very small enabling team which will work to support three stream-aligned service and delivery teams.

The team is forming very fast, and I’m really looking forward to what we can do. But the fact that we were able to start is already exciting. Despite all the Government Digital Services talk about modern ways of working in Digital Data and Technology in Civil Service over the last decade, the governance structures don’t support anything but a service team well. 

So we are dipping our toes into something new, and I really want to see where it takes us over the next few months. 

Explaining programming

Talking about things new. I have spent some time in my career explaining software engineering to others. How to explain it to somebody brand new to the subject so they understand? It is not easy. It requires patience and tactfulness. The more you know, the harder it gets, as there are layers upon layers of abstractions and “assumed” understanding you have that a beginner has not. 

I’m starting a new personal challenge next week. My wife, who hasn’t written a line of code before, is thinking of changing her career. What to? That’s to be decided! But she wants to give programming a go to see if that digital thing I’ve been doing for years is something she would enjoy. 

So, here I am at a professional and personal challenge for 2023. How do you explain programming and maintain a personal relationship with somebody new to programming? Wish me luck! And any suggestions will be very much appreciated! 

The week flew by as I had many interesting, in-person interactions this week. I have spent three whole days in our London office. But that also meant I had some time on the trains to read. 

Contents:

• Different ways of data engineering
• The 12in23 challenge
• Cloud repatriation – the new trend?

Trying different ways of data engineering

The week’s culmination was a three-hour meeting on Friday with all Data Engineers in my profession. In August last year, we started experimenting with our ways of working, and it was time we had a retrospective. Over half a year, I have asked them to work in different ways, drawing a lot from software engineering practices, focusing on collaboration, and sharing the burden and knowledge remotely. 

I won’t go into detail here just now. I think it deserves an article of its own, and perhaps to be published somewhere else. Let’s just say, that the results are better than I expected. Working in pairs (not necessarily pairing), dedicated coaching sessions on non-work related mini projects were a success. There are some things to improve, but the ideas are working, and we are improving our mostly remote collaboration. 

The #12in23 challenge

I have been working on my own skills too. At the beginning of the week, I have learnt about the 12in23 challenge organised by exercism.org. It’s about learning a little bit about 12 programming languages in 2023. Obviously, I joined in. I started with COBOL, C, C++ and C#. I have done some C programming, and I’m reasonably proficient in C#, but I haven’t done anything in C++ for some 20 years, and I have never programmed in COBOL. 

Why these four? It happens that these languages have been created more or less 15 years apart. Trying to do simple exercises in all four over the week gave me a new perspective on how technology and programming developed over the last 65 years. 

I do recommend it. It’s good fun 🙂

Is 2023 the year of cloud repatriation?

There appears to be more and more talk online about cloud repatriation. Last week I read quite a few recent articles about it. It looks like many organisations rapidly moved to the cloud during the pandemic. Many must have used the “lift and shift” approach and stopped there. Now, they struggle with the raising costs. According to one of those articles, 93% of companies repatriating (moving back out of the public cloud) are quoting the cost as the main factor. 

I think many of the moves were not thought through, or followed through, and this is just normal correction. I wonder what the year will bring in this regard. 

The fourth weeknote. The new year’s first reflection covers the previous year’s last week. What did I do? I took some days off and didn’t do any work last week. Let’s reflect on that!

It is great to work in a place where I can take some time off without worrying about what I will find coming back. With some strategic reset I was able not to think about the regular work projects. I don’t have to worry about what I will find when I return, and I don’t have any FoMO symptoms either (Fear of Missing Out).

And it’s not that I don’t have anything interesting or important to do there. Quite the opposite. I’m already looking forward to Tuesday when I will re-engage with it all. It’s just that the place is full of great people who will carry on doing great things whether I’m there or not. I’ll try to help a little when I’m back, but I can rest and recharge for now. (Mind you, I’m typing these words after almost two weeks of not checking my office emails, teams or slack messages!)

And recharging I needed. After a few things I have done earlier in the week – I’ll write about them in a moment – we took a four-hour drive Lan i’r Gogs. We stayed in a nice little place with no mobile reception for two nights. The first night I went to bed early and slept for 15 hours straight! 2.5x my norm. The need for that nap sums up the year 2022 for me. 

But it wasn’t all sleep last week. I have done some reading, some thinking, and some writing: 

• I have refreshed and written up an idea stuck in my head for the last year. In short, it’s about digital volunteering and gamifying first aid volunteering experience. Check the links for more detail. I had good feedback and a few offers of help. Thanks! Let’s see what we can do in 2023. 
• I blogged about the connection I made while reading Digital Body Language between how we communicate with each other and how differently we write code. 
• I watched an interesting short video from Cal Newport about the 20% paradox. Is this the solution to my personal productivity goal of 2023? 
• I have spent a lot of time thinking about continuous professional development and how what we do (or don’t do) in the digital space differs from what I do in my volunteering roles. There is so much that should be said, I think, in this subject. And yet I cannot find the right words. I started (for the third time) writing about it this week, but it didn’t go anywhere. 

And the weeknotes? I will continue the experiment for a little while, and we’ll see what happens. 

Happy New Year!

It’s Christmas day. I know. But as I grew up in a culture that does most of the celebration on Christmas Eve, today is just a lazy day. No turkey roast, just time to spend with the family, relax, reflect and write. 

This week I had only three days of work. I took Thursday and Friday off to do some full-time first aid volunteering. This is my way of switching off before a couple weeks of leave. You know, do something different, something very absorbing. 

It’s not the first time I have done it. However, it is the first time I have overcooked it. By 21:00 on Thursday, I was sitting at the side of a road, messaging ambulance control that I could not go to the next job they had assigned me as the previous three were still in my head. I wanted to go home, decompress, and get some sleep. But the Welsh Ambulance Service takes wellbeing seriously. So the next thing I knew, I was in an office with a cup of tea in my hand, chatting to somebody who’s been there before. 

Before you ask, I’m fine. By Friday night, I was out again. But it made me reflect on things I do more than ever before, so this weeknote might be tinted by this experience. Now that I have warned you… Let’s do it. 

Contents:

• Some thoughts on cross-cultural team collaboration.
• What does it mean to be digitally native?
• How autonomous should our teams be?
• Stuff I didn’t have the time to write about.

Cross-cultural team collaboration

Talking is important. Not only for the wellbeing but also to build digitally enhanced services. After all, it is a team sport. Too often, we build teams of walled professionals who attend the same standups and work from the same backlog without collaboration. They just happen to work in parallel for the same master or manager.

Diversity is important too. We know it. We form diverse teams hoping to get the promised benefits. But do we get them in full?

It is the end of my fifteenth year working with digital technology in or from Wales. It has been a decade and a half since I uprooted myself and tried to continue my familiar career in a new context. New culture, new languages (both natural and programming), new norms, and new expectations. I thought it didn’t matter. But it does. 

I still struggle to express myself as well as I would like to. Instead of gaining native fluency in Welsh and English, I have lost it in Polish. All three languages I use every day feel equally awkward. There are things like Christmas jumpers, bingo and crackers, which I lost any hope of understanding. At the same time, the traditions I grew up with appear more and more absurd. I am nowhere-native. But that’s OK. Instead, I have a reasonably good understanding of three perspectives and three languages to think in.

This is my personal model of how diverse, cross-functional teams work. It means giving up on excellence in any individual profession to benefit from a synergy of good enough understanding from many more perspectives. I know it requires daily effort to make it work. But I also know that it is worth it.

Digital natives and adopters

When talking about diversity, we often overlook one dimension. Digital natives and adopters. What it even means? I have just finished reading a book by Erica Dhawan – Digital Body Language. The book covers many challenges of modern, remote, asynchronous communication, but the generational differences are prominent. They are often framed as cultural differences between digital natives and adopters and how the technology we grow up with affects how we express ourselves and how we perceive communications of others. 

The author proposes a test to determine if somebody is a native or an adopter, but it is not such a clear-cut for me. Communication technologies change so quickly that we might all be nowhere-natives in our “office” jobs, as I am nowhere-native geographically and linguistically. 

It can be an opportunity, but as Erica Dhawan explains, this is a huge challenge and a problem if not managed. 

Reflecting on the last week and the previous two years, we have missed a massive opportunity. We are now firmly in the post-CoVID-19 hybrid work world. It was an opportunity to intentionally structure our communications channels and interaction habits, which were already in chaos. We could have used information architecture and re-designed how we work. But we didn’t. Instead, we just assumed things would just somehow work out. 

The autonomous team problem

We want to work in user-centric ways. We tend to agree that to achieve it, we have to be agile and Agile™ comes with the mantra of autonomous teams. Surely, given enough time and retrospectives, the teams will figure it out and optimise their work. And they might, although my experience is full of examples of teams optimising for the wrong things and settling in local minima. But even if they could do it well, the question that bothers me is whether they should. 

A delivery team should focus on value delivery. A data engineering team should focus on building better data engineering platforms. They should spend only a little time thinking about in-team communications. The between-team communication is outside of their influence and scope. Organisations should provide better training and guidance on how to communicate, with whom and most importantly, when not to. 

My thinking on the subject is heavily influenced by Team Topologies by Matthew Skelton and Manuel Pais. At least when it comes to inter-team collaboration. I also agree with Cal Newport when in Deep Work he makes a case for organisations to create constraints within which autonomous teams operate. It goes against the mantra that suggests that autonomous means completely independent. But organisational support is essential to help the teams focus on what is really their domain of expertise. They shouldn’t need to figure out how to communicate across generations nor invent how to incorporate diverse team members and reap the benefits.

Talking is important, and we should talk about it, and teach each other how to do it. 

Things I wish I had time to write about

OK, that Cal Newport reference is not an obvious one. He writes mostly about individual productivity, but he mentions the need for organisational support. In fact, after finishing Deep Work last December I started a year-long experiment in my communication habits. I hope to have some time soon to write about it. And about maximising things not done, too!

Erica Dhawan, in her book, writes about high and low-context cultures and languages. It struck me that we live and collaborate in Engish – a very low-context environment, but we often write code in a high-context way. This can be the reason behind many common problems – a thought I would like to explore more. 

Whenever I get a message starting with “I know you are very busy”, my stomach turns. Why do we do it? How many opportunities to collaborate do we miss because of that? 

Have you ever noticed that some people turn job titles into industries? Why do they do it? How do we stop them and redirect that energy to where it is needed?

I keep thinking about continuous professional development and how little we do it. Weeknotes and TLIr (Today I Learnt) type posts help but are these enough? I bought the Cultivating Communities of Practice book to learn more about the subject.