Recently, a page was turned, as one of my first companies closed: 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 have passed through its doors and left their mark on me. Those with whom I have continued to work at Malt. I could spend an inordinate amount of time explaining the workings of this company, with no management, all devs, and which has helped to 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.

No constraints, no alignment

One of LT's objectives was to create a software. Well, to rephrase, one of the objectives of some of the people at LT was to create a software.

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 software. But there was a consensus, discussed and voted on, and we wanted to finance software development by providing 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 that came out. 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 timeoffs and a particular work session.

One of the things we realized at the time was that we had too many side projects. There was more than one side project per company member! If we wanted to go further, we had to manage to get several people working on the same side project.

Everyone came along to present a lean canvas.

It was a really fun, productive day. And do you know what? On the contrary to the plan, new projects sprang up :)

In fact, one thing I realized that day was that, in order to make this famous joint product, we had to be hungry.

In reality, we didn't have the discomfort, the constraints that push us to go further.

LT's financial model redistributed almost all income to the 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 these conditions?

I've got some answers, since I chose to do it for Malt. But it's not that easy to take the plunge. These projects in LT could only remain a game, and a very good way of keeping an eye on things.

In the end, none of these softwares 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 these constraints.

Without constraints, no real innovation

Later, still with LT, I joined a project with a major industrial group. The project was very ambitious, with very substantial finances. 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 elements to be objective.

This project seemed to have no constraints. There was no particular date set, no budgetary limits, no limitations on the scope, and we kept adding to it with ideas that were often quite far-fetched. The company I worked for had even bought out a US startup for the software and content it had produced. In short, plenty of resources were used.

And this project, well, it went nowhere. The U.S. company we bought 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 scattering. A lot of service providers 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 nowhere.

This project had no chance of success.

It was the second time I saw clearly how the absence of constraints can kill a product.

Putting constraints on an engineering organization

Constraints are therefore 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 take 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 generate stress, but it can also lead to the emergence of intelligent solutions 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:

• loss of confidence on behalf of the marketing (and sometimes product) teams, who take complete control over product definition
• loss of confidence on behalf of the company, which prefers to rely on external partners (development agencies)
• lack of investment in tech, which is not seen as serious in its financial management etc...

So, what do I mean by "setting constraints"?

The Tech leader must help clarify constraints and make them visible.
Is there a strong time constraint?
What are the technological constraints? What budget is available?

Clarification also means being able to confront and explain that one constraint is not compatible with another. For example, next month's constraint is not compatible with the requested content and/or the allocated budget.

The tech organization that succeeds in bringing these constraints to light, formalizing and sharing them, is an organization that establishes a relationship of trust and puts itself in the right conditions to create impact.

To conclude, and because I find the link with this post rather 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

Questions

How would you define your organization's constraints? Are they financial, temporal, technical, business or human?

Rather than seeing them as a constraint, when was the last time these constraints forced you to find intelligent solutions?

Resources

• Accept boredom
• Choose your battles vos batailles
• Rework