Key focus: the product, not the tasks. Key resources: people and time.
Now in more detail…
What do our customers need? What are they willing to pay for? These questions are the foundation of an iterative approach in conditions of extreme uncertainty. The team is searching for its product-market fit, and the entire focus is on delivering end-user value.
4 basic functions of management—planning, organization, motivation, control—work poorly in startup because there are no processes yet. Processes themselves are the formalization of good practices, of what has proven effective for a specific team after gentle trials. Therefore, before implementing rigid processes and rules, a company must first understand if it even has enough resources and whether it has accumulated enough experience.
Time – is an extremely limited resource.
Alternative – what exactly is worth spending time on right now?
In a startup environment, rigid rules restrict a team’s flexibility and speed, simply because people now have to perform additional actions and switch their mental context to something other than product value and customer needs. One might object, saying there should be a common understanding and adherence to best practices to ensure work moves in the right direction. As usual, the devil is in the details.
A startup, by definition, presupposes a high level of competence among its participants. This is precisely why finding the right people is so crucial in the early stages, as each individual’s contribution is critical. Competence-knowing what is a right way, what is a wrong way, and why, in a given situation. This means that people don’t need as much control or formal task planning (and if they do, the startup probably won’t take off), because the participants understand why they are here and where they are going. If they don’t create a great product quickly, there will be no one and nowhere to follow processes. Quality assurance should, by default, be guaranteed by the competence level of the people, not by imposed rules. It won’t be perfect, but it will be “good enough” for the current conditions. For example, I am a perfectionist by nature, but I understand that in the real world, there are constraints and competing priorities. Therefore, one must proceed from the available resources and control the desire to endlessly improve details—you need to know when to stop, not just follow textbook dogmas or your own ideals.
It’s a classic management principle: to get people to work at their full potential, find unconventional approaches, and make reasonable decisions, you must give them freedom, and therefore, responsibility. Yes, there will be mistakes, but this is a normal part of the work process and of accumulating experience—we learn from mistakes, which is why practices like post-mortem analysis of incidents exist.
In an established company with its own product niche, there is already a proven business model and a cash flow. This means there is accumulated experience of what has worked, and it makes sense to stick to it, at least until the contrary is proven (adaptability). There are additional people to whom the workload and responsibility are redistributed, so time appears for discussing rules and onboarding new team members accordingly without breaking a functioning business model and product.
So, where established companies have business analysts, project managers, release cycles, and task planning aligned with strategic priorities, a startup has constant communication. Priorities can change several times a week (or even a day), new hypotheses must be tested, and there’s no point in polishing a solution that might be thrown out in a week—it’s all about maximum speed and constant change. As little friction as possible. I believe this is especially relevant today for startups in the field of AI.
In such an environment, there is simply no place for rigid rules—you either lose speed, or people, or your place in the market—in that exact order.
Therefore, the focus is on flexibility for the team, discussing customer needs instead of tasks on a board, and exploring options to improve the product. But this raises the question of quality—without it, no one will pay for the product. How do you find the line between ensuring quality and fostering innovation within a limited resources?
There is hardly a single answer here. In my view, as soon as the radical pivots end and you manage to sell the product, obligations arise. Depending on the industry, these can be informal or in the form of an SLA. It is at this stage that the implementation of quality assurance practices begins-Shift-Left Testing in SDLC, for example-but gently, with the team’s consent and discussion. Either there is a common understanding, or the time has not yet come—perhaps there are not enough resources to continue developing rapidly while guaranteeing maximum quality. Yes, sometimes you have to make trade-offs and accumulate a technical debt, but there must be clearly defined boundaries for when we stop fixing and start engineering. Otherwise, the moment to implement quality improvement practices will never arrive, and the company will cross a complexity threshold where no one but the original employees can support and develop the product—there’s just too much context, nuance, and bugs.
Let’s go further…
Product quality is the result of concrete actions to improve it. From a business perspective, there is another alternative here: not time, but money. What exactly am I paying these people for? Are they, for example, improving the architecture and refactoring code that will ease maintenance, speed up bug-finding, and facilitate adding new functionality in the future? Or am I adding a new feature right now that might attract more customers? In an established business, these questions don’t pop-up that often.
Another problem for a startup is too much work and too few people. That’s why you need teammates with broad competencies—so called a “T-shaped” specialist, or someone with a deep primary specialization (the vertical bar) and many additional skills (the horizontal bar). This means they can handle issues in different parts of the business or technical system. But it’s important to understand—the person must genuinely possess these competencies or, at the very least, have a strong desire to acquire them through practice. Otherwise, assigning a person to non-core work will create unnecessary stress for them and result in low-quality solutions. This isn’t resource reallocation; it’s incompetent resource utilization.
I may elaborate on this topic a little later, but as an interim conclusion: different amounts of resources dictate very different approaches, and it is difficult to find the right moment for transition here — this is one of the challenges of management in a startup. But since people are the main driving force behind an idea, any changes, no matter how good they may sound in theory, must be implemented with the consent of the team.
Another interesting thing is that today even large companies, trying to keep up with digital transformation, are creating separate startups outside their existing processes to test new technologies and ideas in a fast, flexible and independent environment, but with the support of their parent company.