EN 49: Energising work and collaboration

I didn’t pay attention when it stopped happening. It is what it is, I thought, but when it occurred, the feeling was like a drug, a rush of energy and satisfaction. I’m talking about collaboration, not “collaboration” but real collaboration, building in community, as a team.

The Product Manager had questions about the feature, we were writing back and forth in the chat. Sensing that the conversation was not going anywhere, we jumped to a call. I shared my screen, and started to show the code that described the business logic we’ve been discussing. Luckily, the code was legible and self-descriptive, anybody could understand that part of the business flow. While we were going over the code, we discovered we weren’t on the same page on small but critical issues. Even thought we were saying similar words, what each of us had in our minds was slightly different. As we compared the code and our ideas, we created a shared understanding and changed the code based on that understanding. We were building together.

On another occasion, I was working on the UI and having the designers close by, I showed them the interface I was working on. It was a short conversation, they gave me some feedback, I got answers to my questions.

Another time, I was working with an exec to update the wording on some pages. Rather than getting a ticket or an email with all the copy changes and me applying them on my own, we sat side by side and I plugged the laptop to a big screen. On my laptop I had the editor, on the big screen I had the app running locally. As I changed the copy, immediate feedback was shown on the big screen, they could see what the app looked like with the updates. You could say that it was a waste of time, they could've sent me the list, so I could do it on my own time. But here’s the magic, there was a list, but the wording from the list changed as they saw the changes “live” and realised that some didn’t feel right. If I had worked solo, the next day I would’ve had to make changes again and maybe get more suggestions. The feedback loop working together was seconds and minutes, working solo would’ve increased the loop to hours or days. Moreover, I was involved in the process, we were co-creating.

Take these situations and consider what it would be like if we could do this more often, if we could start together and finish together. There’s no product on one side, designers on another and developers in the corner (or backend devs in one corner and frontend devs in the other), we are one, the team is the atomic unit of work. Take the situation with the exec and replace the exec with a customer, isn’t it preferable to have a shorter feedback loop and know earlier what works and what doesn’t?

These situations, and many like them in the past, make me feel energised and think that this is what the work is about. If I could choose, I wouldn’t have it any other way, unfortunately I can’t always choose.

From the first anecdote, something else stands out: knowledge work is messy and uncertain. We have a hard time acknowledging that fact, and instead fight to compartmentalise it to attempt to bring order to chaos. “Talking to people is inefficient, we need fewer meetings and get our heads down into the deep work!”. The reality is that even if the messiness is somewhat contained, it spills through the cracks. One of my core beliefs about knowledge work is that it is (or should be) inherently collaborative, that “the only work that matters in a knowledge economy happens when we are together”, as Elizabeth Ayer puts it in her terrific post: Meetings are the work. We start to embrace the messiness and uncertainty of the work when our ways of being and working get, among other things, more collaborative, more communal.

Things don’t have to be perfectly defined, we don’t have to have a perfect and efficient process. As Woody Zuill says:

It is in the doing of the work that we discover the work that we must do. Doing exposes reality.

Doing the work following the idea of software teaming (also known as mob or ensemble programming) is as close as it gets to working together.

Even if we don’t do software teaming, we should start together and finish together, having the team discovering and delivering together, co-creating with users.

It would be better if everyone worked together as a system, with the aim for everybody to win.

W. Edwards Deming
  • Building in Community. In this post, Bukky Adebayo writes about the idea that individual work doesn’t work, everyone expects to work in silos and pass down their artefacts, a lot is lost in translation. The alternative is to work collectively: “we create insights together. And when we learn something that invalidates our previous beliefs, we process this discovery together. We ideate as a team. We ultimately create better solutions”.

  • We need to talk about testing. Insightful article by Dan North about what testing is and what isn’t and why techniques like TDD and BDD are only tangential to testing and don’t replace it.

  • Earth to Media: Try to Get It—Nice, Ordinary People Can Be Fascists

Join the conversation

or to participate.