Business vs Technology

Jese Leos

Founder @ Zencal.io

Many, if not most, businesses today are closely, more-or-less linked to technology. Willingly or unwillingly, software can streamline many company processes. The problem arises when technology starts to constrain the business. In this article, I would like to share my thoughts on the constraints that the business (Product Owner, Business Owner, Business Owner, etc.) may face. Owner etc.) if the technology is not properly optimised.

TL;DR

5 highlights from this article:

  • 👉 Simplifying technology is not a bad thing, in fact it should be a goal that safeguards the business from changing direction at a rapid pace.
  • 👉 It doesn't matter if you are creating a small startup or a large corporation. Agility and the ability to make bold decisions should not be delayed because of poor or inadequately executed technology.
  • 👉 Business processes should be reflected in the core software. Therefore, it is important that business and technology play to the same goal. Disagreement can lead to large financial losses.
  • 👉 Sometimes less is more. Chasing product development can be disastrous if not enough time is spent taking care of the current form of the product. It is better to deliver a smaller increment of the product, but polished in every respect.
  • 👉 Increasing the efficiency of development teams should be a business priority. In many cases, the problem is not the number of people in the team, but the quality of the working time.

Business and technology

At the outset, a small clarification. Throughout this article, when I use the word 'business' I mean people. Product owners, Project managers, Business owners etc. Whenever I use the word 'technology' I mean people. Programmers, testers, UX designers etc.

As you read this article you may be looking at it from the business or technology side. However, if you want to or are already creating a startup, then you need to combine both points of view into one.

Now that we are clear about the importance of business and technology, we can boldly start with a bold but in my opinion true statement: There is no business without technology, no technology without business.

If you work or run a business where this is clear to everyone on the business and technology side you can confidently finish reading this article at this point. However, if you have at least 1% doubt I think it is worth staying.

Being a programmer, running a startup on a small scale, we gain a completely different perspective on the reality around us. Many things that sometimes seemed incomprehensible to us (maybe also illogical) make sense. This is because suddenly we go from being a programmer who develops code to also being a salesman, a marketer, a support person. You could say that we are a whole company in one person. I think that anyone who wants to work with technology close to the business should go on such an adventure.

You very quickly come to the conclusion that we should all play to the same goal. After all, we have a common goal - to deliver value to our customers/users. Why is this not so obvious in some cases? What is blocking us? After all, we all have good intentions and want to do our job as well as possible.

Purpose

First of all, we need to have a clearly defined goal. Everyone in the company should know where we are going. It needs to be clear to everyone, as well as understandable and achievable within a certain timeframe. Why is this so important?

From a business perspective, it is easier to think about the product. About what it should be, what functionalities it should deliver, what problems it should solve.

From a technology perspective, it is easier to plan the architecture, choose the technologies. We can also arrange the processes in the product accordingly, which is also very important in terms of the competences we need to have in the team.

All this will ultimately translate into adequate agility in the team. If the technology is not overly intricate, it allows us to adapt quickly to changing business realities and requirements.

Simplification

Simplifying technology should be one of the common goals between business and technology. If our technology is simple, the threshold for new employees to enter the project is low. Consequently, if we have a need to scale teams we can do so much faster. You're probably asking yourself where the business is in all this, after all architecture is a matter for the teams that develop it. Yes, but if the business doesn't give enough space (time and money) to simplify, sooner or later the technology becomes hard to maintain.

As a rule of thumb, it is the case that we want to deliver value (read fucktivity) to the customer as quickly as possible. We want to be competitive, better. Let the first one to throw a stone be the programmer who did not do an unnecessary if to prove the project to the end. In my opinion, there is nothing wrong with that. Provided that as soon as you release the functionality you go back to that code and refactor it to make the code maintainable.

The simpler the better. Better for the technology, better for the business and, in the end, also better for the customer.

Less is more

In a world of global competition, in many situations it seems that first come, first served. If your competitors are delivering more functionality in less time, you are probably doing something wrong. Is this really the case?

What if your competitors deliver 30 functionalities, but you find business-critical bugs in 20% that render the product useless? It turns out that the company that delivers only this 20%, but with refined, key features becomes better. I hear very often that technology is unreliable. I even say it myself sometimes. The question is, however, why is that?

My theory is that we want to do too much, too fast. Sometimes it's better to slow down and work out all the pieces by delivering a solution that we are confident in. There is nothing worse than a business shining its eyes for mistakes in the code. But on the other hand, if it's the business forcing an unbearable pace then the fault, as always, is in the middle. The worst thing in all this is that by creating a startup at the very beginning we impose on ourselves a bluntness that makes our solution less stable.

Efficiency

How often do you think about your work system? Do you have such a thing as a working system? Even if your answer right now is 'no', I'll surprise you - we all have a system. Most of us (myself included) make one basic mistake - we don't think about our work in terms of a system.

What is a system? It is simply a set of activities that each of us performs in our daily work. If your answer to the first question was 'no' then you have probably never had the time to analyse how you work. I started doing this relatively recently, and I can already say that it is having a huge effect on me.

How often do you find yourself thinking - I don't have time, this will take me ages? For the most part, this is the result of not breaking down larger tasks into smaller ones, not looking for simplifications, not shortcutting your way to your goal. Many of the things we do in our daily work can be simplified or automated. However, this requires the initial effort of analysing what we do and taking a bird's eye view of our work. Personally, I like to draw out the flow of my work so that I can easily track the elements that I often repeat.

The other side of the coin, which is equally important, is focus. Programmers sometimes refer to this as the 'flow state', but this is nothing more than focusing on the task at hand. Does your working environment enable you to do something like this? How many meetings a day do you organise? How many do you attend? How many of them could be emails?

Businesses like to meet, that's their role, building relationships is key. Technology requires focus, a clear mind and no constant change of thinking context. Some time ago I performed an experiment on myself. I decided to do the most reliable task evaluation I could imagine. I set a completion time of 40h (a week of time). The task took 3 weeks from the moment the status changed to in-progress. Reported completion time? 40h

It turns out that my estimate turned out to be accurate, but why am I writing about it? Because the experiment was to see exactly how much time I was spending on things unrelated to the task. It shows how much stuff happens in the so-called in-between time. Of course, these were also important things, but not directly translating into value for the user.

Question for you

The power of business is in technology, and the power of technology drives business. Do you have the pleasure of working in an environment of understanding between technology, business?