Hugo
Recently, a chapter closed, as one of my first companies shut down: Lateral-Thoughts, or LT for those in the know, a small company I helped found in 2011 and which was a catalyst for me.
I could mention the many people who passed through its doors and left their mark on me. Those with whom I continued to work at Malt. I could spend an inordinate amount of time explaining how this company worked, with no management, all devs, and which helped lay the foundations for a new relationship with work.
But for this post, I want to talk about one lesson, among many, that I learned from LT when I was there: the importance of constraints.
One of LT's goals was to build a product. Well, to rephrase, one of the goals of some of the people at LT was to build a product.
It was a collaborative company based on the principles of sociocracy. So there wasn't one big boss saying that LT had to create a product. But there was a consensus, discussed and voted on: we wanted to finance product development through consulting services.
So we set aside money to finance internal projects.
And several came out, some more like side projects than real products, but there were some great ideas. One of those side projects was Malt. But that's another story.
Still, LT didn't become Atlassian or Basecamp. But why not?
I still remember the incredibly productive off-sites, and one work session in particular.
One of the things we realized at the time was that we had too many side projects. There was more than one per company member! If we wanted to go further, we had to get several people working on the same one.
Everyone came along to present a lean canvas.
It was a really fun, productive day. And do you know what? Contrary to the plan, new projects sprang up :)
In fact, one thing I realized that day was that, in order to build this joint product, we had to be hungry.
In reality, we didn't have the discomfort, the constraints that push you to go further.
LT's financial model redistributed almost all income to its members, so if you take an average daily rate between 500 and 1000 euros for most people, everyone was doing very well.
At what point, when you're earning between 5 and 10k euros a month net, do you say to yourself that you're going to take a risk on a side project?
Why put yourself in an uncomfortable situation under those conditions?
I have some answers, since I chose to do it for Malt. But it's not that easy to take the plunge. Those projects at LT could only remain a game, and a good way to stay sharp.
In the end, none of these products saw the light of day within LT. Products were born with LT members, but outside.
So this was the first time I saw the importance of constraints.
Later, still with LT, I joined a project with a major industrial group. The project was very ambitious, with substantial funding. It brought together multiple companies within a conglomerate, academics, etc.
Here, I'm going to give one person's point of view among hundreds of others, so I'm probably missing a lot of context to be objective.
This project seemed to have no constraints. There was no particular deadline, no budget limits, no limitations on scope, and we kept adding to it with ideas that were often quite far-fetched. The company I worked for had even acquired a US startup for its software and content. In short, they threw significant resources at it.
And this project? It went nowhere. The US company we acquired didn't add any value, and the product was killed. Several of the conglomerate's partners gradually withdrew.
The main problem, at least as perceived by the teams, was a totally unclear direction. Because where there were no constraints, there was no focus. A lot of contractors came and went, and we worked on very complex problems that didn't actually exist, because in order to move forward we had to set ourselves constraints, completely out of thin air.
This project had no chance of success.
It was the second time I clearly saw how the absence of constraints can kill a product.
Constraints are beneficial. They force us to make choices, to define where we invest or don't invest. If you don't make any choices, if you don't set any limits, you're guaranteed to waste energy.
If I bring this back to software development, it's crucial to set constraints. A date is a constraint, a scope is a constraint, a quality level is a constraint, a quantified business objective is a constraint.
This can be stressful, but it can also lead to intelligent solutions emerging to cope with constraints.
But, in reality, except in exceptional cases, every organization already has constraints. The role of tech leaders is to bring them out into the open. It's precisely because some tech organizations are unaware of them that they end up failing.
They're not aware of financial constraints, user expectations, or marketing expectations. And all this systematically leads to a disastrous situation whose symptoms look more or less like this:
So, what do I mean by "setting constraints"?
The tech leader must help clarify constraints and make them visible. Is there a hard deadline? What are the technological constraints? What budget is available?
Clarification also means being able to push back and explain that one constraint is not compatible with another. For example, next month's deadline is not compatible with the requested scope and/or the allocated budget.
The tech organization that succeeds in surfacing these constraints, formalizing and sharing them, is an organization that builds trust and positions itself to make an impact.
To conclude, and because I find the connection with this post quite relevant, I'm going to quote a paragraph from the book "Rework":
Send people home at 5
When people have something to do at home, they get down to business. They get their work done at the office because they have somewhere else to be. They find ways to be more efficient because they have to. They need to pick up the kids or get to choir practice. So they use their time wisely.
How would you define your organization's constraints? Are they financial, temporal, technical, business-related, or human?
Rather than seeing them as limitations, when was the last time these constraints forced you to find smart solutions?
No comments yet. Be the first to comment!