Author: Michał Poręba

A year review (2022)

For me, relaxing is the most stressful thing. Time passes, and nothing gets done. With an attitude like that, you probably wouldn’t be surprised to learn that I’m interested in personal productivity. Well… I have some data inclinations too, and some charts to show you.

The above is my first full year (January to December) as a civil servant. I started in the bottom left corner on week one and some tasks in my backlog and progressed steadily through the year to the top right corner in week 51. Of course, there are some variations from week to week, but the thicker lines show that things are surprisingly constant on (six week) average.

It also shows me there is a limit of things I can do per week. In weeks 1-13 and 19-26, I managed ten tasks a week. In April, week 14, I tried harder, got up to seventeen, but that fizzled out by mid-May, week 19.

Looking at this graph before my first job anniversary in July, I realised the blue and green lines were pretty straight and divergent. It meant I was always putting more on my backlog than I could accomplish, so that was not sustainable. So I decided to try harder. Once more, I reached deep into my bag of personal productivity hacks to up my performance.

You can see that from July, I managed sixteen tasks per day, 160% of my earlier norm, but still, it wasn’t enough to match the demand, and so in mid-August, I started being more selective in the commitments I took on. Finally, the blue and green gap started to narrow down and things were going well until December!

Why is it so hard?

Ultimately, my commitment to commit to less work made a real difference to the length of my backlog. It was obvious, and yet it was the last thing I tried. Why?

I find it difficult to say no to opportunities to help others or to collaborate. Believe it or not (and I know with my occasionally blunt demeanour, it might take a leap of faith), I get out of bed to make a difference. And the only way to do it at scale is by collaborating and helping each other. And so I say, “yes, I will help” you more often than I should.

But despite that, the second list of the most stressful things people say to me, just after “relax”, is starting conversations with “I know you are very busy, but…”. How many opportunities to collaborate have I lost, because people think I’m too busy to talk? Too busy, or worse, too important, to see if their problem is something I can help with or not? Every communication that starts with “I know you are very busy” reminds me of all forever-lost opportunities to collaborate. And so I respond, as calmly as I can, that I will always find the time for a chat, even if I cannot help.

I’ll have to do something about it next year, but first, let’s go back to the data to see what else we can learn. My ambition for 2023 is to bend that green line up a bit more and find a way to do even more.

More Charts

The view above – weekly snapshots – shows more clearly that last summer’s effort to reduce the number of new commitments was working well until the beginning of December. What happened there? We had our internal conference. I had three days of in-person meetings that inspired me to take on ridiculous amounts of new things.

What the two views we looked at so far don’t show well is what really matters: how many things I can do a week, and how many things I start but cannot complete – the Waiting category. Those are the things I start, but hit a wall. I have to meet with somebody, get somebody’s opinion, get approval and so on. Every item like that means context switching and so lost effort and time.

Now, after excluding the things that are in the backlog, the picture is more compelling. We can clearly see the two weeks when I decided to do more. In April, week 14, it lasted a few weeks.

During Weeks 22-23, I was off and then, after coming back, had a lot of requests to do things which I tried to start as quickly as possible. This resulted in a lot of tasks in progress and a lot of waiting, but not much was done. That is what led to frustration and yet another attempt to increase productivity in June – weeks 27 and 28.

I worked hard on reducing the work in progress and the tasks in waiting. Still, I managed the reasonably constant level of tasks completed. But then, in the fourth quarter, I tried to do even more, but the only thing I achieved was the waiting queue going past sixty.

Sixty tasks I have started but cannot complete. I’m waiting for somebody else, but still, they are my responsibility. They still take my time, even if just to check if I can progress them or not!

It’s an unbelievable waste of time.

My plan for 2023? To change it and do even more with less effort. Achieve more with less strain.

But first a couple of days in the mountains to… relax! Scary! Although, I’m sure I’ll find something to do, not to relax properly. That would be too stressful. I’ll do some reading, some thinking, and hopefully something to find the much-needed new energy for civil servicing in 2023 at never before seen levels of productivity.

Happy New Year!

Digital volunteering, anyone?

I am a civil servant. I work with data and technology in digital services. But what got me there, after many years in the private sector, was the time spent volunteering in various first aid organisations.

I enjoy doing first aid at events and responding to 999 calls either as an ambulance crew or community first responder. But sometimes, I think I could help more volunteering with my professional expertise (software, not pre-hospital medicine) rather than just my time.

Our National Health Services use many digital services and systems. That kind of services are what really matters. This is where we should see the latest in software engineering and user-centric design thinking, but from my experience… we are far from it. I want to do something about it.

The last three years have shown that there is a lot of will and determination in people to make things work and to help each other. And so here I am trying to find out if there are people who would like to volunteer some time and their digital skills to save lives (not directly, but still).

It won’t be easy, I imagine. The systems running our health services are not open and not publicly accessible. The data they process is sensitive. But if a group of us is willing to help, we will find a way. I’m sure.

Interested? Get in touch! Let’s talk about it. Do you have a better idea? Then definitely, let’s talk. I want to know about it!

Or have a look at the idea or code on GitHub, something relatively simple to start with, with less red tape to get through. A project to help with first-aid volunteering. Have a look. Let me know what you think.

Low and high context mismatch

In her Digital Body Language, Erica Dhawan writes about low and high-context languages. We need a detailed understanding of the culture to process a message in a high-context language. The message has to be interpreted in its social context to be understood. When we communicate, certain things are not said because they are apparent, even if not explicit.

English language and the cultures associated with it are low-context. It doesn’t mean we always say what we mean, but we are used to having things spelt out.

Which one is better? I am not planning on settling this argument here. In the book, the debate is not settled either. Instead, the author offers practical tips on communicating online with people from different backgrounds. However, the distinction could help us understand why we struggle to read and work with “legacy” code.

And yes, I mean “legacy”, not as an obsolete code written in long-forgotten, unsupported technology. That would be legacy code. I mean the code written a couple of months earlier by me, which I cannot read or comprehend anymore. We call it “legacy”, a “tech debt”, and argue for rewrites or at least very extensive refactoring “tickets” to be put on the product backlogs… don’t we?

Refactoring, rewrites and sacrificial architecture.

Rewriting your code can be an essential part of software engineering. This sacrificial approach to software architecture worked well for many. For example, an ex-eBay Chief Engineer and Distinguished Architect, Randy Shoup, often says that if you are not rewriting from time to time, you are over-engineering. But it should not be done because we don’t understand the code or the problems. There are plenty of examples. Last week this showed up in my feed – an excellent and high-profile example of when not to do it.

If you don’t understand the problem how can you be sure that you won’t replicate it when starting from scratch?

So, how about refactoring? For me it’s part of coding. It’s something that should be done all the time as a standard way of working with code. If we practice Test Driven Development (TDD), it happens in every mini cycle red-green-refactor. I often do it when reading code too. When things are not obvious, I refactor to help me and those coming to the code behind me understand the code better. I use refactoring to help me understand things. Unlike rewrites, I think it should be used to help us understand. But it shouldn’t be on backlogs!

Coding is communicating.

And this brings us back to low and high-context languages. When we write computer programmes, we codify our solution to a problem. In some languages, we focus on the shape of the solution – that’s the declarative approach. In imperative languages, we focus on the steps to get us to the solution. What we omit, almost always, is the description of the problem. We forget that the code is not only something machines will execute. We will eventually have to read and try to understand it too.

We code as if programming languages were high-context. At the time, we don’t have to express the problem, the reasons, or the technical and business constraints behind our decisions. They are obvious. We have had to understand them to shape the solution we are crafting. But that high-context communication style works only if the person receiving our message also has access to the context in which it was created.

Digital Body Language explains how it is reasonable to expect others who live in the same culture to have that context. Communications can be very effective even if it appears to us low-contexted English speakers that some things are missing. But in programming, the context is often gone forever. Even if we go back to our own code, we look at it thinking, “what was I thinking?”

Is it engineering or archaeology?

I used to think that we struggled to read other people’s code because we didn’t practice it enough. Programming courses (universities, boot camps, online tutorials, they all) focus on writing code rather than reading it. But it could be because writing code is Software Engineering, and reading it is Software Archaeology. (check the episode of Software Engineering Radio with Dave Thomas on the subject). It is an apt description but only because we create artefacts devoid of context. Our digital products might as well have been created thousands of years ago by unknown cultures. We know what tools they have produced. But why? And why didn’t they do something else?

So perhaps the lack of practice is not the issue here. We struggle to understand what we build because we live in a low-context culture, speak in a low-context language, and yet build our digital services as if we operated in a high-context environment.

What can we do about it?

Should we comment on our code more? Should we document our solutions more? I don’t think so! Instead, we should have a screaming architecture that doesn’t need additional comments or documentation of the solution.

But we should document the problem better!

We can do it with refactoring. We can use design patterns – not as part of solutions but as a common language to hint at how we see the problem we are trying to solve. If working in the open, we can write, blog or create video walkthroughs about the situation we faced and solutions we have chosen not to apply. We need to capture not what is already in the code but what is not there and why it is not there.

Software archaeology problem affects the whole of digital products.

The problem is wider than just code. It affects digitally enhanced services as a whole. We build roadmaps to meet the needs of our users. We prioritise our backlogs by choosing and recording what we will do. But we don’t often record what we decide not to do and why. Our roadmaps look into the future showing us where we want to get to, but they rarely show where we are, what our surroundings are, and how we got here in the first place. Without all of that, our roadmaps look more like marching orders. Without it all, our products, as our code, need archaeologists to unpick the past before every next step we take.

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.