Several years ago, I was running a humble adtech company. As a non-technical founder, I was quickly facing my limits in managing the dev process. I wanted it all of course: not expensive, fast and great quality; the impossible triangle. The technical people I worked with somehow seemed to have enough confidence to promise it all and what followed is predictable.
First issues and finger-pointing
The first issues started with quality. A lot of users and a lot of bugs. If you have 100 users and 10% experience bugs, you’ll have 10 conversations to maintain. If you have several 1000’s of users… When the market buys and the users use, you have a good reason to be confident about your business model. The frustration of not being able to deliver accordingly grows quickly.
I pointed fingers at ‘incompetent’ devs. They pointed fingers at every person who had been working on the code before them and left it like a spaghetti plate. I understood them. I had been a cheap-skate at the offset to first validate the business model and it is normal that you can get away with this only temporarily. You can guess what happened; a re-write. This time it was a costly one. Not just costly when agreeing on the cooperation, but even more costly when fully delivered because of several surprises in the dev process. I remember being happy with the result but being shocked by how rigid/expensive the new thing was to change. We finally had something nice, but we were kind of stuck with it for a while now. In a fast-changing context, especially as a startup, you want to be able to A/B test, to pivot, to try out this and that, but if your code does not allow you to, your competitive advantage of being small and flexible kind of disappears. That change would be so important, was not something that I had mentioned explicitly to the devs.
A lesson in communication
For a long time, my simple conclusion was that good devs are scarce. That’s a claim you will hear from many non-technical managers. Luckily, the company survived the difficult encounter between tech and non-tech, and I like sharing this experience to help others being quicker in identifying and cutting short issues like the ones I had. After all, the real lesson was not that good devs are hard to find as much as it was a lesson in communication.
On my side, I was judging an outcome of a process that I did not understand. The issue was to be found within that process of course. What was I expecting in the short run and in the long run? Did I really communicate that well? Did I even question myself enough on it? Did I sufficiently made clear that quick pivots, A/B testing, etc.. would be a must? Did I make a realistic request in the sense that a good MVP was more useful than a buggy full-feature? If I am honest with myself, then I have to confess a good portion of naivety on my end. I simply did not know what to ask for or how to express it because I did not know which trade-offs are at play at the dev side. I didn’t know that flexibility and architecture are linked for example. And that is just one example.
On the dev side, some elements are worth mentioning as well though. I was given what I asked. I was never questioned on what I did not ask. I did not ask for well-structured code or compliance in naming conventions or anything like that. I asked a result that should work starting from a certain day in time. I was never really confronted with the trade-off between flexibility/quality, price and time. I simply didn’t know it existed or mattered. Software architecture and the meaning of code quality were too far from my world. My lack of interest for the job of the developer was probably my biggest mistake and I think it was the developers’ biggest mistake to not have much interest for the true needs of my company in short ànd mid-term.
Genuine mutual interest
One can expect a founder to not be naïve as one can expect a developer to know how to deliver. But in many cases, both are working based upon assumptions; the assumption that you know what the other wants or needs without genuine interest in each other’s challenges. If I asked for quick and cheap, I did not know how that would come back at me and how expensive the cost of change would be.
I did get everything delivered my way at first: fast, ready to use and inexpensive. And I paid it heavily with the never-ending refactoring. This refactoring comes not only with a financial cost but also with time; valuable time if you are learning fast and not able to steer quickly. It paralyzes your ambitions as a founder. And it paralyzes your entire team if you depend on unpredictable delivery cycles. If I had known that code quality and software architecture determine your code’s tolerance to change, I would have made that a KPI.
For a long time, I thought my naivety was mostly to do with the fact that I started my business while graduating and not having worked in bigger companies yet. However, in the last couple of years I was a business coach for more than 70 startup companies at incubator Start it @KBC in Belgium and I was surprised to see that people with +20 years of career experience make the same mistakes more than often. I recently met a successful serial entrepreneur who was clearly opinionated about the topic and said “Oh, I have had big fights with all my CTO’s”. It turns out that even many established companies and enterprises have poor understanding between technical staff and non-technical management.
Conclusion
To conclude, when you are non-technical and you expect a good cooperation with technical people, you need to have a genuine interest in how they will go about it and you should only work with people who have genuine interest in what you really need, not just in what you think you need. You want to know the challenges and the trade-offs a dev team is facing. What is the goal of the code? A quick MVP to test the market or a full version that needs 2, 3, maybe 4 years of product lifetime? How much will flexibility cost and what is your definition of flexible? Which KPI’s will you use to quantify and evaluate expectations? Are these KPI’s indeed telling you the essence of what you are doing and are you sure that some of them are not vanity metrics? Which tools will you use to track, manage and improve?
I am writing this as a founder of bismuthlabs.io. For existing code, Bismuth tells companies what is worth fixing. For new code Bismuth safeguards architectural compliance, hence protecting the code’s tolerance to change. The goal is to have more tolerance to change, leading to less refactoring, better refactoring where necessary and more predictable delivery cycles. As an interesting by-product some companies look at us for junior training.
Needless to say from the above that when I met my cofounders, I immediately understood the value of the customer pain they are addressing.
How is your cooperation tech – non-tech going? Similar misunderstandings going on? Did I indicate the right spots to pay attention to? Interested to learn from other experiences.
Top comments (0)