There is no development in the food company. And also – a lot of overtime and lack of motivation. All these statements are real myths, which we have taken the courage to refute. Read an extensive breakdown of the most common stereotypes about product IT companies, conducted by our blog editors together with the CTO of the company Universe from the Genesis ecosystem.
MYTH №1
Startups chase hype technologies, and developed products chase features. In both cases, quality has to be compromised.
The most important thing that all technical teams should be chasing is certain business goals. Stakeholders are pushed away from this when making any decision. If there is a need to get a round of investment thanks to a hyped technology or to increase the number of users thanks to a new feature, those are business goals to achieve. The fate of the company depends on them: if there is no financing, the business will not survive. If you don’t “roll out” new features, you will fall behind the competition, and as a result, your product metrics will fall, revenues will decrease, and as a result, the business will not survive. Therefore, statistically, this myth can be confirmed. But with regard to concessions in quality, one can argue.
First, it is worth defining: what is quality? Technical experts often refer to “quality” as purely technical metrics—for example, Code Coverage—that are difficult to explain to stakeholders. Therefore, for them, three hours of refactoring per week is a compromise in terms of quality.
If “quality” is defined as a solution without which 10% of users and 5% of revenue will “fall off”, problems with scaling or security will arise, then no product team will make such compromises.
MYTH №2
In the product, the technology stack lags behind, developers do not have the opportunity to experiment, so they develop more slowly.
Let’s simulate the situation. The technical team can choose a solution on the hype stack. Or on an old one (at the same time NOT outdated), which can be quickly implemented, and it will work stably. There is a very high probability that the product team will say, “Why take the risk? Let’s just make it work reliably.”
It doesn’t matter to the end user whether you have plain Java or blockchain under the hood, as long as the product covers their needs. This hurts developers, because everyone strives for self-improvement, to be relevant in the market, to experiment. But this is not a reason to put technology first, and business needs second. If you have a finished product, users, metrics, etc., you have a lot to lose. You won’t rush to a new technology because you’ve heard something about it. One of the things that separates a middling from a senior is understanding that you’re not writing code for technology, but to cover business needs. This school works best in food companies. If you’re not learning a new technology every month, that doesn’t mean you’re standing still. You develop other skills.
However, there are tasks where new technologies are really needed. And here the developer will need soft skills: the ability to explain and argue why it is important for business. If the technology really solves a certain problem, and is not just “cool”, then it is highly likely to be implemented without hesitation.
MYTH #3
The developer has the opportunity to influence the product only during the launch, in the future it is mostly support and monotonous work.
The truth of this myth depends on the stage at which the product is. When a complete “feature freeze” has occurred, there is no development, only support — effectively a stagnation stage in which the developer cannot really influence the product. In all other cases, the influence is quite powerful.
In addition to the main flagship products, companies often develop additional areas, study new niches and launch mini-products in them, which may also become flagships over time. This is a fairly common practice for food businesses all over the world and in Ukraine. For example, Universe has a “utility” direction, which was launched back in 2018, and it continues to develop and is constantly supplemented with new functionality. And there is R&D, in which the team experiments with technologies, niches, and is now working on a product that did not exist even a year ago. The environment in product IT is constantly changing, so this work for developers is quite dynamic and dynamic.
MYTH №4
The role of the developer is less important. All decisions are dictated by numbers in analytics (users, marketing), etc.
This is true, but it applies to any IT company, not just a food company. There is hardly a team in which a developer can single-handedly make contradictory decisions with the argument: “I’m an artist, this is how I see it.”
Every IT company has developers responsible for the code. And there are managers who are responsible for meeting the requirements of the customer (in outsourcing) or the user (in the product). If a developer in a product company wants more control over the process, there are many related positions, such as Technical Product Manager. Or you can shine as a product manager.
Also, this does not mean that developers are not listened to, but simply given tasks. Proactive specialists who take the initiative, argue and prove their opinion will always be heard. Developers often see how to improve a process or product from the inside, and they always have the opportunity to suggest an idea during, say, a grooming or other team meeting.
MYTH №5
There is a lot of overtime and uneven workload in food companies.
The presence of overtime does not depend on the type of company, but on the construction of processes. Usually there are more of them in startups – because the survival of the business depends on it. Also, overtime often happens in small service companies that are afraid of losing customers – even inadequate ones that change the concept at the last moment and ask to redo everything.
Each overtime is the use of a future resource. From a management perspective, this hurts the team, especially if they don’t understand the ultimate goal. If a manager drives a team just because he wants to, he will quickly lose it.
In order to avoid overtime, large companies (both food and outsourcing) spend a lot of time planning for the quarter, episode, year, drawing up roadmaps, team goals.
MYTH №6
Most of the team is made up of non-technical specialists, so the developer has no one to share expertise with.
Product companies are different. Genesis is a large ecosystem, which consists of companies, within which there can be various projects. When the processes are properly built in the structure of such scales, it is easy to develop networking: you can always find a contact of a colleague from another project and ask to share experience.
Genesis has built a system of specialized communities in which you can exchange expertise, cases, conduct workshops, meetups, and discussions. Or just meet for coffee and chat. There are five communities for technical specialists: backend, frontend, QA, DevOps and gamedev.
MYTH №7
Employees sit in one place for too long, lose motivation, so projects lack fresh ideas.
In the IT industry, there is a conventional rule that a specialist should change position / project / company every few years. Otherwise, motivation and involvement are lost, tasks seem monotonous and uninteresting. “Life cycle of an employee” is a concept that shows how much time a specialist will spend in a project. Product companies carefully monitor this metric and try to optimize. As the team strives to improve the user experience in the product, so the company is interested in helping employees grow rapidly and achieve shared goals.
How can a business motivate employees other than financially?
1. Stimulate professional development, help master new skills.
Someone needs a mentor, someone wants to master a new technology, and someone has accumulated expertise and wants to share it. There are many educational formats in the ecosystem (both internal and external). If specialists practice continuous learning, they will have no shortage of fresh ideas and approaches.
2. Help in career growth.
If a technical specialist has a desire to lead a team, a new project, or move into a related field, the company should support his initiative. If management skills are lacking, there are schools of management and leadership (both in the ecosystem in general and in individual companies). For example, over the past six months, QA engineer and IOS Engineer at Universe have grown to QA Lead and IOS Lead, respectively. They took internal management courses and also had specific tasks for the quarter that had to be completed by delegation to the team.
3. Strong corporate culture.
Engagement is a powerful motivational tool. The developer should feel his role is not at the level of “I wrote the code and did the push”, but at the level of “I did the push, the code was deployed, followed by production, so the users saw the feature, so the LTV increased by 2%.” And all this is thanks to me!”.