Technology for a use-case, or use-case for a technology?
The evolution of a startup company looks like this:
— someone is struggling with a task, or feels the need of a product that would help him/her in some way, but it does not exist yet
— verifying that the need is real: there is a strong demand from other people as well
— the product idea is converted into a set of use-cases
— the product idea is implemented, covering the top use-cases
— end-users are happy, profit
The evolution of a project in a corporate environment looks like this:
— someone has an in-house technology — eg. a repository solution or a framework
— the technology is being advertised across the organization
— reaching out to development teams, trying to convince them to use the technology
— some development teams are adopting the technology for an imaginary use-case
As you can see, startup companies are trying to solve a business related problems, and they are picking and using technology to reach their goal. This mechanism allows small organizations to use lightweight solutions, as they are focusing more on the “what”, instead of the “how”. If the implementation can be done in 5 weeks in Java, but only 2 weeks in NodeJS, they would pick NodeJS. Reaching a business goal — eg. implementing use-cases — is more important than spending weeks on building complex solutions.
The situation is different in larger organizations: when the company has stable funds, it is no longer a strong need to find quick and lightweight solutions. Developers are allowed to discover new technologies in depth, and integrate them into the company’s ecosystem. If we all know Java, and we are experienced in NodeJS as well, why dont we just check out .NET Core as well? Of course, the company will not go bankrupt while we are doing our spikes for weeks. Not cost effective, but seems to be normal. After all, it is good for the developers, they keep themselves motivated.
Fast-forward to large companies, the situation is totally different. Imagine a tech company that acquired several companies in different sizes, inheriting all of the technologies they had. Aside of the inherited in-house technologies, there are inherited people as well. Some of them were at very high position before the acquisition. If you are a CTO in a company of 50 employees, you will only be Director of Engineering once the big fish (eg. company of 3k employees) eats your small company. That is natural, but this leads to a challenging situation: you had been the big boss with high influence level, but now you are only one of the directors. How would you restore your position? In my opinion, there is basically nothing to be restored, as this is just a natural flow. Former CTOs need to accept the fact that they can not continue their career as CTO in the 3k organization. It sounds reasonable, isn’t it? I have seen several situations like that, and most of the cases former high level leaders were totally pissed. Some of them disappeared for several months. Another guy was yelling with the CEO over the phone, claiming his position. One thing is common: once they settle, they either leave the company, or select their new strategy.
As a betrayed former high level leader, there is one thing that you can definietly do in this shitty situation: make the best out of it, by occupying as much space in the organization as possible. The large company acquired your small company for a reason. They like your product. Now it is your time to spread your technology across the large organization, no matter what. If your product is a Big Data stuff, then all teams must use your Big Data solution, even if they have small MySQL databases with 5GB space, and there is absolutely no need to change to Big Data. If your company is an AI company, you need to make sure that the CEO understands that AI is the future, and, in order to survive on the market, all products within the company must adopt your AI solutions, as soon as possible. Product and development teams might not like the idea that they need to adopt technologies for no reason, but they will not go against the direction that is declared from high level. Teams should show their Enabler attitude: they need to find an imaginary use-case that they can present to higher level management. CEO will be happy, as he/she would get confirmation from most development teams that the direction is good, and everyone joined the party. Investors are also happy, as they see (via PR, articles and corporate communications) that acquiring the small company was a strategic decision.
End result:
- end-users did not get any extra feature
- development teams got engaged with dummy projects for several months (3–6, usually)
- one guy made his/her position stronger
