I Left my previous job to Work on nzyme Full Time

Today, I am incredibly excited to announce that I left my previous job to work on nzyme full-time. Working as founder and CTO for almost ten years and helping it grow to more than 125 full-time employees, I have learned a lot that I can now put to work again. (I will stay on as an advisor and in contact with all my friends there, who continue to do great work.)

People around me notice that I am the happiest and most energetic after a day of creating something. I love to make things I can be proud of, and that bring others joy. Life is too valuable not to take bold steps to achieve happiness when you are privileged enough to be able to do so.

My goal for nzyme is to create sustainable growth: no shortcuts and no compromises when it comes to quality and user experience. A big part of that is to grow slower and bootstrap the business. Nothing wrong with taking investor money, but you have to understand what expectations that sets.

What Is Good Software?

Good software solves people’s needs without portraying itself as more than what it is. It can be clear about what it does and what it does not do. It brings genuine joy to the people who use it and makes the people who built it proud. Not just proud of a particularly brilliant piece of architecture but proud of the product as a whole. Proud of what they give into people’s hands.

However, to achieve this, a few conditions have to be met:

No Unrealistic Short-Term Growth Goals

An expectation of growing revenue by 100% or 200% yearly will make you chase one unfinished feature after another. There is never time to finish anything, and the last mile, the essential details, are left out in the never-ending pursuit of new functionality. This pressure leads to shortcuts, a bad user experience, and a bad time for everyone involved, including the user.

To make things worse, all that product debt you took on will eventually catch up with you, leaving you in a spot where you lose unhappy users and have to crank out even more unfinished features to keep up with expectations.

If everyone involved is on board with slower but sustainable growth, you can build software that people will love and continue to use. Additionally, you, as the author, will probably enjoy your work more again.

Complete Features

Proper planning and project management are important, but you’ll often get it wrong. Humans are generally bad at estimating effort. In that case, you must either delay the release or move an unfinished feature to the next release. Never release incomplete changes just so you can say you hit a release date or have an imaginary feature now, even though it will never satisfy your users’ needs. A realistic approach to planning and executing projects also always leaves the possibility of canceling a feature altogether when circumstances change, or a hypothesis is incorrect.

Deciding to delay without fear or pressure is possible in a sustainable growth environment.

I will not have roadmaps for nzyme. Roadmaps imply promises and create expectations. If a user hears from me that version X, released on date Y, will include a specific feature, they should, of course, expect that to happen. Considering how bad humans are at estimating, this adds another layer of conflict when the release date comes closer, and we need to delay. Canceling a feature is almost impossible in that situation, and changing plans after learning new things during the development process is also challenging. All this leads to bad products.

So, why are so many companies building those kinds of roadmaps that look so far into the future? They are often used to pre-sell features to customers. “We don’t have this yet, but it’s on the roadmap and will be released in July!”. This is another form of debt. This often happens under the veil of product planning. Development teams, however, rarely need to work with exact plans for so many months ahead.

A good reason is to inform your users and customers about how your product will change. Internally, it has to be clear what the product strategy is.

For that reason, nzyme is publishing priorities instead of a roadmap. Users should base their decision to use nzyme on the current state of it instead of future changes. We do this to avoid pressuring ourselves into horrible product decisions caused by often wrong human estimations. Not promising the future is possible in a sustainable growth environment.

The following two cycles (8 weeks) of development are always carefully planned, with more uncertainty further down the road and a constant adjustment of details as we learn.

Listening to the Practitioners

The voice of the practitioner is what matters. The people who spend their time looking at your web interface might not have the relevant budget, but how they feel about the product drives long-term, sustainable success. Build what makes their life easier. Build what makes a difference to them. Too many have lost this perspective in all the shortcuts they are taking to save another quarter’s revenue numbers instead of thinking long-term.

Of course, the person with the budget must agree that the product does what they want. They need a clear overview of what the product does and does not do. However, overpromising and overhyping in these documents and sales processes does not lead to sustainable success.

I believe this industry needs more honesty, and I hope to do my part.

The future of nzyme

Currently, nzyme is in the middle of a massive rewrite for v2.0. Not only am I adding multi-node support and a full authentication model, but I am also extending it to support Ethernet data. The GitHub project for v2.0 gives you an impression of the extent of this whole operation.

Please read the official nzyme blog post and priorities to learn more about where we are going.

Please consider subscribing to my blog if you want to stay in the loop with things happening around nzyme.