Based on the original article by Olga Kulapina

Micromanagement is usually associated with a lack of trust, constant check-ins, and managers who want to control every move their employees make. But during a project crisis, close oversight can serve a different purpose: it can help a team make decisions faster, resolve blockers, and keep moving toward a difficult deadline. At Red Collar, this approach helped save a digital product that was still far from ready just three months before its scheduled launch.

A Project in Trouble

In 2021, a client approached Red Collar to build a digital platform for buying, selling, and delivering crushed stone. The idea was to replace scattered calls and messages with a transparent digital process. At first, even the format of the product was unclear. It could have become a marketplace, a tender platform, or something else entirely.

As a product analyst, Olga Kulapina conducted research, developed hypotheses, assessed risks, worked on the monetization model, and proposed a hybrid concept – a kind of "Tinder for gravel" where buyers, quarries, and brokers could find one another.

The initial research was completed, the MVP was defined, and the project moved into development. The release was scheduled for April to coincide with an industry conference where the service's brand and exhibition booth would also be presented. Olga then moved on to other projects.

By January, with about three and a half months left before launch, the team had a name, visual identity, and promotional materials. The service itself, however, was still a prototype. The team recognized that an April launch was no longer realistic and moved the release to another industry conference in August.

By February, the backend architecture was complete, but the backend developers had nothing else to work on. Design was behind schedule, frontend development was idle, the scope remained unclear, and changes had become constant. Everyone believed that an August launch was impossible.

In May, with three months remaining, the project was handed back to Olga – not as an analyst, but as its project manager. It was a difficult but logical decision: she already knew the product, had a good relationship with the client, and had experience managing large projects. The instruction was simple: the service had to launch.

Cut First, Accelerate Second

The first response to a delayed project is often to add more people, but team growth does not create a proportional increase in speed. More people also mean more meetings, messages, and coordination. Junior employees need help from experienced colleagues, which affects the productivity of the people mentoring them. That is why the first step was not hiring. It was a deep project audit.

The audit showed that the designer, working without analytics support, had repeatedly accepted new client ideas and added features. As a result, the product had moved far away from its original vision and become overloaded. Olga compared it to "a plane with a pool on board": impressive in theory, but still unable to fly.

The team prioritized the functionality by dividing features into three groups: "not necessarily MVP," "maybe we cut this," and "definitely cut." Each feature was evaluated against the client's business goals, and the team continued reducing the scope until an August launch appeared possible, at least on paper.

The next step was to negotiate the reduced MVP with the client. The argument that helped move the conversation forward was simple: a flying plane is better than one with a pool. The first can fly; the second only looks impressive. The client agreed to focus on the core functionality and remove the rest.

Only after prioritizing the product did Red Collar expand the team. New frontend developers, QA engineers, DevOps specialists, and analysts joined the project, bringing the number of people involved to around 30 at its peak. Expanding the team introduced additional communication and coordination, but the team accepted the risk because some increase in speed was better than none.

A tight deadline does not automatically mean a simple result. In another Red Collar project, the team created the Starfall Arena landing page for potential investors attending the Solana conference in Lisbon. The team had only three weeks to complete and polish the MVP before the event.

What Micromanagement Looked Like

Two-week and even one-week sprints were no longer fast enough. A delay in one task could block several others, so the team switched to a much shorter management cycle. They held daily check-ins and closely tracked blockers. Whenever a blocker appeared, everyone involved was brought together to resolve it that same day.

The team was ready to rebuild processes and adjust plans immediately to maintain momentum. Designers, frontend developers, and backend developers worked in parallel streams so that one group would not have to wait for another. The focus was on keeping tasks moving: blockers were addressed every day, the right people were brought together quickly, and plans could change whenever the situation required it.

Overtime also became part of the temporary crisis mode, but everyone knew it would not continue indefinitely. Team members received clear instructions for work they could complete independently in the evenings or on weekends, and weekend plans were discussed in advance during daily meetings.

In one example, the team spent a week creating a flow that allowed users to submit a request from a quarry map. The documentation, designs, backend, and frontend were ready by Friday. A similar flow had to be implemented in the user account the following Monday, but it depended on the first version being tested. QA tested the flow on Saturday, while one frontend and one backend developer were available on Sunday to fix any problems.

Why the Team Did Not Rebel

Daily oversight alone does not create motivation. The manager's behavior was what made the difference. First, the team needed confidence that the project could succeed. Olga compared the project manager to air traffic control: if the person directing the work panics, the planes crash. She made a point of not panicking.

Olga described her approach as shoulder-to-shoulder leadership. The manager had to be part of the team rather than standing above it. Instead of asking, "How could you mess this up?" she asked, "We have a problem. Let's fix it. What's the plan?" Her role included trusting the team, asking questions, rearranging tasks, bringing in additional support, and doing whatever she could to help.

The management style was also adjusted to individual team members. Some people responded better to private praise, while others valued public recognition. Some needed an opportunity to talk through their frustrations. The point was not to create a detailed psychological profile of every employee, but to pay attention to what made each person comfortable and create an environment where the team – not the manager – was the focus.

Fairness mattered as well. If someone had worked late, they were not criticized for missing a morning call. If the manager had promised not to contact someone during a weekend away, that promise was kept. If overtime pay had been promised, the commitment had to be honored. The team was solving difficult problems, and its talent and effort had to be recognized.

Weekly demos gave everyone a sense of progress and pride. Team members working from the office shared a dedicated room, meme chats became active, and some employees voluntarily met in Figma voice chats at night. When the team became stuck, brainstorming sessions were open to everyone. The project began to feel like a game in which the team was working together to defeat a difficult boss and reach the next level.

Want to hear more from the author of the original article? Short videos featuring Olga Kulapina's talks are available on Red Collar's Instagram.

Why the Client Did Not Rebel

The same principle of transparency applied to the client. Risks were communicated early instead of being hidden in the hope that they would go unnoticed. Even relatively small problems were raised, considered, and discussed with the client together with possible solutions.

The team also held weekly demonstrations of completed work. Sometimes the result was a map with filters; sometimes it was only a new response flow. These demos helped the team track its own progress while showing the client that the project was moving forward.

The Result

The service launched on time. The MVP had been reduced, but it was fully functional. The Red Collar team helped the client prepare for the exhibition, present the service, and onboard its first 120 users. Over the following two months, the team stabilized the product, fixed minor bugs, improved the documentation, and added usability features.

According to Olga, micromanagement worked for two main reasons. First, it was about speed rather than control. The team understood that the goal was to launch the product successfully and that problems had to be solved in hours rather than days. Micromanagement served that goal rather than creating an illusion of control.

Second, it was about people rather than exploitation. Everyone knew that the intense working mode was temporary and that the manager was working alongside the team.

After the launch, half of the team took a break, and some people eventually left the company. But years later, former team members still wrote that they missed the intensity of the experience. A difficult race can be exciting when everyone is in the same boat, rowing toward the same goal – not chained to the oars below deck.