Week 34, 2020
On life
Watch this: Kelechi Okafor on why violence is in fact the answer.
On writing
Dave Perell has become a frequent source of writing tips and tricks for me. Like his pinned tweet, which is an excellent starting point:
Business writing 101.
— David Perell (@david_perell) April 26, 2020
∙ Shorten your sentences.
∙ Make your point fast.
∙ Shorten the introduction.
∙ Use simple words.
∙ Add graphs and statistics.
∙ No buzzwords.
∙ Use more periods, fewer commas.
∙ Write for skimming, not deep reading.
∙ Bold the main takeaways.
It's important to remember not to follow advice verbatim. Listen, but remember to follow your instincts and find your own style.
On Timo
Timo is moving into an exciting place next week. Now we’re happy enough with what we have, we will open the gates and start inviting people from our email list to try the latest and greatest.
The list itself is a decent starting point. It’s organically grown to around 80 people over the course of about two months. Here’s hoping that our eventual subscriptions can grow in the same way too!
We're using Notion for public facing pages that we don’t want to spend time building just yet. We’ve just added the MVP of our Changelog as one of these pages.
We have also started looking into how we can utilise Twitter better as a promotional tool. Research on similar staged companies is quite difficult. If you find a twitter account at the same place then it’s too early to be able to tell if what they’re doing is working well. If you find an account further along, with good engagement levels, then you lack the context of what they did at your size. Twitter is only a snapshot of the now.
To assess accounts which have been through the same stage already, you’d need to be able to see how many followers they had during that period. You need the context to learn anything useful.
Luckily, the Wayback machine is a thing. With some good luck, they might have taken a snapshot of what you’re interested in.
With a stroke of bad luck, and they might have snapshotted your fresh out of University profile, complete with awful profile picture.
On TransferWise
At TransferWise, we follow a similar organisational structure as Spotify. I’m part of the frontend (or web) guild. As part of the frontend guild, we maintain the libraries that power our micro-frontends.
One such library is CRAB, or “Create react apps better”. It’s a wrapper around nextjs which provides a bunch of middleware and other goodies for authentication, localisation and experimentation to name a few things.
I mention this, as we’re currently going through a process of maturing how we work as a guild.
While internal and closed source (there wouldn’t really be any value in open sourcing it), the organisational structure of TransferWise makes CRAB analogous to an open source project. Many potential stakeholders, with infinite different use cases.
As such, I’m thinking about how it is probably a good idea to adopt an open source model, and the processes to match. We’ve started forming the idea of working groups. Who, like core maintainers of an OSS project, would be responsible for the direction and roadmap of a library. Web Standards come to mind too.
They wouldn’t necessarily be the ones doing the implementation. Rather, they’re aware of the bigger picture and can guide the project to the best solution for everyone. They’ll do the research to understand the use case and have opinions on implementation, but not the final solution. Working groups would do the same for a given project. They would still allow for individuals and teams to contribute as they see fit. Just like open source.
Better yet, this pattern is familiar to the engineering community, and there are plenty of successful examples of how to run this. Look at any major open source project in recent years, and there are a host of reference points to look at.