Expedition Signals: Episode 5
On Shaping Flexible Base Software Architectures for SaaS Products, Learning Web 3, Taming Model Malpractice in Organizations, and the Two Different Top-Down Approaches to Design and Growth.
Welcome to a new issue of Playing the Long Game.
Last week, I got the newsletter back on after a long time on standby. And today, I come to you with a new issue to keep the flow going.
In the last episode, I told you I chose to rebrand this publication. I decided to leave Expedition Signals aside and give birth to Playing the Long Game as the new brand name. I also gave you the reasons behind this choice.
But today, I come with a new twist.
I've decided to recover the Expedition Signals brand.
"What?" Yeah, I know. I created a new brand just to throw it away one week later. But wait.
Don't rush too fast to conclusions.
Playing the Long Game isn't going anywhere. Far from it. It will still be the umbrella under which all the content in this publication will be shared.
No change around that.
But there is something I didn't get right. I understood Playing the Long Game as a direct replacement for the Expedition Signals brand. Yet, there is a different interpretation.
I'm starting to see Playing the Long Game as a broader publication where Expedition Signals can just be a section within a more ample range of content.
For now, Expedition Signals will be the only content within the publication.
But I think that configuration makes more sense and seems more flexible in the long term.
I want to be open with you about changes like this one.
People often convey the false image that they got everything right from the start. They like to appear as if they got the perfect plan on the first try —by the way, we'll also talk about this later. But evolution is an inseparable part of sustainable growth. And that's why I think this change was worth sharing with you. That helps me apply what I preach and lets you see how I do it.
But newsletter changes aside, here is what I have to share with you this week.
Things I'm Thinking About.
How to Shape a Base Software Architecture for Your SaaS as a Beginner Founder to Adapt to Changes Fast (And Without Going Crazy).
"As an early-stage founder, your resources are scarce. And I'm not talking just about money. Your time and energy are even more critical.
But when you build on the wrong foundations, you're putting them at risk.
Like a building on top of muddy ground, your system doesn't hold up. You waste yourself into constant hesitation and technical battles that lead you nowhere. And in the meanwhile, you and your customers suffer."
In a previous article, we saw a high-level process for tackling complexity without prematurely taking on more than necessary.
We looked at three crucial complexity sources in any software project: the logical, the temporal, and the physical architectures. And we saw how different configurations along these dimensions formed a ladder to climb up.
In today's article, we'll dig into the first stage of the ladder. We'll see how to get to a neat logical architecture while keeping the temporal and physical distribution as simple as possible.
Want to grow a base architecture that grows with you without friction? If so, keep reading.
Gems I Found.
How to Learn Web3: Some Useful Steps to Understand the World of Blockchain Better.
I have encountered feelings regarding Web 3.
On the one side, I'm excited to see what it can offer. And on the other, I feel skeptical because of all the hype and blind faith I see around it. Often, what I stumble upon on the Internet almost sounds like a religion.
And that makes me cringe. I don't believe in magical solutions that promise to solve nearly all of humanity's problems.
It sounds like snake oil.
But staying up to date with emergent tech can be game-changing.
What you expose yourself to establishes the range of possible solutions you can think of. And I believe that, far from the extremes, there can be something handy there. We can't obviate it if we want to improve our efforts at enabling sustainable growth.
And that's what this publication is all about.
I've been trading crypto assets, but, technically speaking, I've just scratched the surface of Web 3 so far.
I know the high-level basics. But I still have lots of blind spots. I've got many things to learn about yet.
I want to dig deeper.
I'm in exploratory mode at this point.
I don't intend to go all-in but rather start learning on the topic at my own pace, to see what I find out and see if I discover something valuable with the potential to enable sustainable growth. For now, I'm more interested in the technological fundamentals and how it relates to the world where it is to operate. Not so much in the practical matters of Web 3 development —at least for now. My goal is to get a systemic perspective on its practical uses.
Not wishful thinking but realistic, pragmatic thinking.
Do you want to dig into Web 3? If so, take a look at Francesco's guide here.
And if you've already gotten deeper into Web 3, I'd love to hear your thoughts.
Do you believe it can help entrepreneurs, creators, and innovators grow more sustainably? Do you think it can help them bring sustainable progress to society and our world? If so, how?
Or do you think it's the opposite and believe it's all a bubble?
Whatever the case, I'd love to hear your thoughts.
Taming Model Malpractice.
"Too many models ensure the models are doing specific jobs at the expense of broad understanding. Too few models ensure people use the same language at the expense of doing jobs well."
In this article, John Cutler, Product Evangelist at Amplitud, digs into two common problems in organizations: 1) having too few models or 2) having too many models. The former leads to usefulness problems. The latter leads to collaboration problems.
Want to know his advice on how to address this issue? You can read it here.
A Tale of Two Top-Downs.
Here is a two-part series by Joe Norman.
As with many concepts, the term "top-down" is highly conflated. It's not the first time I've felt confused when someone uses the term. It's not rare to see people conflating top-down and waterfall as the same thing.
But as Joe points out here, there are two types of top-down approaches to design and growth: the blueprint, waterfall top-down, and the coarse-to-fine top-down.
They have nothing to do with each other. The former tries to impose a blueprint onto the world. The latter, however, unfolds and adapts better to the environment's complexity.
This is not a new discovery but a resource I've found myself turning back to over and over. I love how Joe articulates the difference. So I thought you might find it helpful too.
Whether you’ve never heard about the concept, you feel confused about its meaning, or simply find it hard to explain it to others, this is a fantastic source to improve your understanding.
Do you feel intrigued? If so, keep reading here.
"When the oak tree grows, there is no blueprint, no master plan, which tells the twigs and branches where to go.
We know in general that it will have the overall form of an oak, because its growth is guided by the pattern language of an oak tree (its genetic code). But it is unpredictable, in detail, because each small step is shaped by the interaction of this language with external forces and conditions – rain, wind, sunlight, the composition of the earth, position of other trees and bushes, the thickness of the leaves on its own branches.” —Christopher Alexander.
Thanks for reading Playing the Long Game. Did you enjoy it? I hope you did.
Get on board. Was this newsletter forwarded to you? Still not subscribed? Sign up here if you want to receive more issues like this one right in your inbox and support my work.
Say it out loud. Is there anything you disagree with? Anything missing that you'd like to add? I'd love to hear your thoughts, so please leave them in the comments. Or if you prefer more privacy, email me directly at firstname.lastname@example.org.
Share it. Do you think someone you know may enjoy this episode too? If so, please forward it to them.
And that's all for now folks.
Have a creative time.