Why startup and corparate environments are desperate for a mindset shift

Why am I writing about this on a warm evening on my day off?

As I talk with my friends in the industry about our work, why we are satisfied or why not, there is a common particular pattern I see amongst most colleagues of mine. This started feeling like a pattern when I started noticing that colleagues from the biggest corporates and startups, not on the same level but eventually, have the same concern and that is “at some point we started selling rather than building”. And what do I mean by this? I mean that we are more focused on launching new features in a rapid pace rather than building sustainable code bases, reliable products, and trust with users through security and data safety.

Many of our startups/corporates nowadays earn revenue from technical aspects. They are not selling any particular products rather they are selling technical services. So why is the technical aspect of the project always neglected? In this post, I want to talk about the current situation, how we got here, why this is not sustainable, and finally what should be done, at least in my humble opinion.

How did we get here (And why people from product teams are doing the right thing)

In most organizations, the hierarchy itself is creating this imbalance. At the very top are the shareholders, executives, and CEOs whose primary responsibility is to make money and market relevance. Their focus becomes product teams’ focus. Thus, leading us to where we are.

To be fair, product teams are not wrong in what they do. In fact, they are doing exactly what they are supposed to do: push for growth, increase user numbers and numbers in general, and respond ASAP to the market. In an environment where competition is unbelievable, moving fast with new features often feels like the safest, and sometimes the only, way to survive.

However, as my friends and I tend to say, everything has a price, nothing is free. There is a hidden price for every shortcut taken to release faster. A hidden debt that the team will eventually have to pay back. Every time security, performance, or maintainability is delayed in favor of speed, the long-term health of the product is quietly weakened.

So we need to be on the same page that this is NOT a post about why technical teams are right and product teams are wrong. In fact, this is a post about why we should work together to find a middle ground that satisfies both ends. To put it in terms of car manufacturing (even though I vividly know these brands since I am not a car enthusiast), I am not pitching the idea that we all must be McLarens and Lamborghinis. But I think being a Saipa is not what we should be proud of, nor pushing for either.

Why this is not sustainable

At first we are moving fast, I mean very very fast. However, this illusion of progress is not going to last long. Teams are celabrating fast releases but eventually, system becomes harder and harder to maintain. Bugs become harder to fix and scaling becomes a dream that most probably will never become true. You might say, “Okay Mateen! we get it!! but at at least we have a lot of users and making a ton of money, right?”. Well, yes. We do have a lot of users now but

With great power, comes great responsibility. - Uncle Ben from Spider-Man

Now that we have a lot of users, we have many pairs of eyes looking at checkin out our products on daily basis. For users, this situation of ours, eventually shows itself in form of unreliability: apps that crash, services that slow down under load, data that isn’t handled with the safety it deserves. And in today’s world, trust is the real currency. Losing user trust through instability or insecurity is far more costly than any short-term gain from a new feature.

This is insanely ironic. The same energy that made us to grow faster can end up slowing everything down. Engineering teams burn out fixing issues instead of building new capabilities. Product teams face frustrated users instead of loyal ones. Companies spend more energy patching holes than charting the future.

We cannot build a sustainable ecosystem if technology is something we think about later down on the road.

What should be done?

If we agree that we have this imbalance, we need to rethink our view of technology in the companies. Here are some steps I personally think can be great to start:

• Leaderships and board members need to understand that technical health is business health. It is not a “nice to have” but rather a “must have.”
• Like most problems in our universe, this can be bettered with communication. Product and tech teams need to work less like two opposing forces and see themselves as part of the flow. Product ensures the company grows, while tech ensures it survives.
• Finally, engineers themselves must learn to understand business terms. This is a skill that I myself have recently started working more on thanks to a team lead of mine giving me this feedback. When you put yourself in other colleagues shoes, you will be more understanding. So my fellow engineers, this is not a one-sided road.

At the end of the day, sustainable success comes from building, not just selling. Launching new features might win the moment, but building reliable, trustworthy, and scalable technology wins the future. That’s all I had to say. Hope you have a nice evening.