Machine Learning, Software Development

Analyzing a WhatsApp group chat with Seaborn, NetworkX and Transformers

We had a company shutdown recently. Simfoni operates ‘Anytime Anywhere’, which means that anyone can work whatever hours they feel are appropriate from wherever they want to. Every quarter we mandate a full company shutdown over a long weekend to make sure that we all take time away from work at the same time and come back to a clear inbox.

For me this meant a bunch of playing with my kids and hanging out in the garden.

But it also meant playing with some fun tech courtesy of a brief challenge I was set: what insights could I generate quickly from a WhatsApp chat list.

I had a go using some of my favourite tools: Seaborn for easy data visualization; Huggingface Transformers for ML insights and Networkx for graph analysis.

You can find the repo here: https://github.com/alanbuxton/whatsapp-analysis

Business

Remote working works

The UK press has recently seen senior politicians criticising remote working. They are misguided.

I’ve worked in remote and hybrid environments for well over a decade. Remote work, when done well, works excellently. One example from my own experience: the ability to employ stay-at-home mums who balance employment around childcare commitments has been a game-changer for businesses that I’ve been in.

You cannot turn back the clock.

For sure, I’m one of the laptop class who can easily work from pretty much anywhere. I have a young family in a nice house and a decent home office setup. My commute to Central London and back is about 2.5-3 hours per day. I have a lot more productive time available to me in a remote-first environment than in an office-based environment. And I get to spend more time with my kids. It’s a true win-win.

This is not to say that it’s easy to make the most of remote working. There are challenges to getting remote working right. The best thing to do is to face up to these challenges and figure out how to solve them.

Here are examples of the sorts of person or organisation that struggle with the transition to more remote working:

  1. Commercial landlords. In the short term demand for offices in central locations goes down as remote working goes up. Though in the longer term we will see offices being recreated as hybrid living/working spaces. The city centres that are dead at the weekend will change for the better.
  2. Managers who don’t have the skills to connect with staff remotely. It’s one thing to be in an office watching people, picking up on body language cues and grabbing people when you need to talk to them. This can’t simply be replicated on video calls.
  3. People without a decent work-from-home setup. If you’re in a small flat then spending too long in there will drive you crazy. If you can’t get good broadband at home then you will struggle to work remotely.
  4. Companies who can’t provide a decent remote-first infrastructure. Computer systems need to be accessible securely and quickly over the internet, not just from inside the office.
  5. Companies who support office workers. For example the lunch stops and the flower seller who saw his business collapse 50% even before London’s official lockdown started.
  6. People who are most comfortable with face-to-face networking. In the olden days (1990’s) the place to be was the smoking room in which everyone was an equal irrespective of rank. Then the place to be to pick up on tidbits of career-enhancing information would have been in the coffee area or the pub at lunch/after work.
  7. Organisations who haven’t figured out how to do training remotely. The nature of training and developing junior staff has changed. You can’t provide shadowing or guidance as easily remotely as when you are sitting next to each other.
  8. Organisations which have a culture which encourages ‘out of sight out of mind’. If 80% of staff are in the office and 20% are dialling into calls then the 20% will quickly become second class citizens.
  9. People who struggle to set boundaries between work and personal lives.

It looks like a pretty long list but the underlying themes are pretty clear:

  • Investments in infrastructure are needed (better broadband, better IT setups).
  • Support for small local businesses as they transition to the new more remote world is needed.
  • Managers need help to adapt to remote work. The book Remote is a great place to start for organisations trying to figure out how to adapt to a remote world.
  • A face-to-face element is still needed, whether through shared working spaces or other ways of getting people together every now and again.

Anyone who makes broad-brush statements that “you can’t collaborate in remote work” or “you can’t work efficiently remotely” is telling you about their difficulty in adapting to this new reality. Not about the nature of remote work. Plenty of people are making great strides in making the most of the opportunities of remote work while addressing the downsides. With the right level of will and vision we can adapt to increasingly remote work and, indeed, thrive in it.

Oh and a couple of final requests. Please can people start saying:

Working remotely instead of Working from home

and

Going to an office instead of Going to work

Product Management, Software Development

The Now/Next/Later Roadmap changed my life

I love ideas that seem so obvious in retrospect. The Now/Next/Later roadmap is one of those: https://www.prodpad.com/blog/how-to-build-a-product-roadmap-everyone-understands/

The traditional roadmap is a group of chevrons or bars set out in quarters one or two years into the future. It says that: In Q1 we will deliver features A and B, in Q2 features C and D etc. Something like the following:

If you can plan this far ahead then, fantastic. But many of us need to be more nimble and to adjust priorities in the face of changing needs and opportunities in the marketplace. For us, this kind of roadmap is too rigid of a way to communicate future product development plans.

Its problems stem from the way it combines prioritisation and timelines into one view. It allows different stakeholders to have very different interpretations of what done looks like for any of these future developments. And it obscures whether we need to do any work now for something that it planned for 3 quarters away.

Now/Next/Later fixes an important part of this by separating out relative priorities from timelines. At Simfoni, implementing Now/Next/Later has helped me have these sorts of conversations:

  1. Which of the items in now is genuinely something we should be working on now in support of company OKRs? And is everything in now really well-defined enough for us to be working on it right now?
  2. For the stuff that isn’t in now, which pieces should be in next and which pieces should be in later?
  3. What requirements/analysis/user testing do we need to do now on items that are in next and later so that we can be ready to build them when the time comes?

I even love the language of Now/Next/Later. Now clearly means something we should be working on right now. The less you have in now the more focussed you can be and the sooner you can get something properly done. Next means we need to get ready for something that we will be working on shortly, so we better firm up exactly what we need to do. And later is altogether more speculative and might need some early stage proof of concept work but it’s not something we should be spending much time discussing at the moment.

How to then apply timelines to the results of the now/next/later work is another topic. But so far I am finding that it helps to make the problem space smaller: we should be able to have pretty firm time-boxed estimates for work in now, and then things will get less precise as we move out into next and later.

All credit to Janna Bastow who invented it, see https://www.prodpad.com/blog/the-birth-of-the-modern-roadmap/ for the history.