Weeknote 6

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

Contents: 

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! 

Weeknote 5

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:

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. 

Weeknote 3

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!

Weeknote 2

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:

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.

Weeknote 1

It’s time to continue what I started last week – an experiment with “readerless” weeknote blogging. I know it has been done before. But will it work for me? 

TL;DR:

The full version:

I published the first ever weeknote on Sunday late afternoon. On Monday morning, I walked into the office and got instant, in-person feedback (thanks!). What have I done? Aren’t weeknotes readerless? Have I broken the system already?

Luckily in the office was Mr Civil Service Weeknote himself. We talked for a while. He told me about the history of weeknotes, the Government Digital Service, and digital services in the Civil Service. I couldn’t share what I learned in that conversation in a single post, even if I tried. But that’s beside the point. It was the first indication that writing reflections in public as if nobody will ever read them can spark unplanned but valuable interactions. 

That chat, thank you, Mr Weeknote, was what we are yet to replace in the new “hybrid” and “remote” world. Of course, we can schedule calls and virtual meetings, but how do we create opportunities for such spontaneous exchanges of ideas. Writing weeknotes is probably not the answer I’m looking for, but it could help. 

Enough of this meta-writing. Let’s start weeknote 1 proper… 

How much should we listen to the user “needs”?

Last week I missed a few things in my first weeknote as I decided to go and do some community first responding for a few hours. I published what I had and booked on just after 20:00. I wanted to be home by midnight as I had to be in the office early in the morning. It wasn’t to be. As soon as I logged into the system, I was sent to a 90-year-old male who’s fallen and couldn’t get up. He’s been waiting for help since 15:00. The plan (or hope) was to get him up and into his bed. One less patient for the ambulance proper. Not this time! He couldn’t be safely lifted or left as he was, so I kept an eye on him until a professional crew relieved me just after 03:00.

What has it got to do with users and their needs? The initial hour of a response can be busy. There are checks to make, techniques to perform, and things to discuss. But once that is all done, then there is the wait. Then, there is time to think, interrupted by more and more impatient questions, “how long until the ambulance arrives?” 

My “users” want to know when an ambulance will arrive. That’s their “need”. They and their families want to know how long the wait will be here and then at the emergency department. And I must admit, by 01:00, I was with them on that! I had been there already for four hours, and now I had only 5 hours left until my alarm clock went off. Unlike them, I knew nobody was coming just yet. And so a thought was born. Couldn’t we build a digital service that shows current ambulance waits? Couldn’t we apply some machine learning doodah to predict the delay? Couldn’t we show the patient and their family exactly how hopeless their situation is? 

Of course, we could! But should we? Our users want this. We could confirm this with user research, but I was in the field listening to the question for six hours. I felt the urge too. By 03:00 I was half asleep, but my head was full of ideas about how such a system could be built. And then it dawned on me! We all want to know when the help will come, not because it is important to us or it matters in any real sense. We just want the help to be there now. Wouldn’t it be better to fix the service, so the ambulance arrived before this question crossed anybody’s mind? 

I know. I’m opening myself up for criticism that I don’t understand the User Centric Design gospel. A good User Researcher would realise that the need is superficial and uncover the actual “ask”. We could address it with a beautifully designed service by a skilled Service Designer… and so on. But before you get on your high horse, can you honestly say that things like that never happened? How many services are there to address symptoms of some form of pathology? How many digital services have been built to plaster over a gaping hole, lack of this or failure of that? Why?

Things I will not write about

So… yes, I do think about user-centric design and delivery of digital services when treating patients in my volunteering roles. But I also think about the very agile and cross-functional ways of working I see in emergency services when I’m back in my day role. I find it beneficial and inspiring. I have been thinking about ways to write about it for quite some time. I still haven’t figured out how to do it, but I hope to write about it one day. 

It’s just that it takes time. It is Tuesday night, and I’m trying to finish last week’s weeknote! I will stop here, but I wanted to list things I thought a lot about last week which I won’t write about just yet. 

  • Cross-governmental communities of practice and how anaemic, frail and small they tend to be despite people who are assigned “leads”. It is a real problem for me as I’m thinking of starting such a community myself and the only thing that stops me is this image of… I don’t even know what to call it. 
  • The “Future Ways of Working” and how much more we have to figure out there. And that the communication has to be bi-directional. And that wellbeing is essential to consider. 
  • Throughout the week, I also considered and discussed the need for CPD. Why don’t we do it in our professions? Should this be done in the open?
  • I missed my graduation and failed to pick up some award.
  • I remembered the Jolie language and how it could revolutionise how we build our applications. I’d like to try it again soon.
  • We had a Christmas party, dinner and associated meetings, something we hadn’t done in a few years.
  • I have also learnt about the Law of Stretched (cognitive) systems.
  • I have watched an interesting “intellectual riffing” between Matthew Skelton (Team Topologies) and Dave Farley (Continues Delivery). 
  • I have read a fascinating article by Robin Sloan – A Year of New Avenues
  • And the Agile Baristas slowly start to be helpful, perhaps going back to the original point about writing things out in the open.