Forem: Alex Rezvov

How to Overcome Internal Doubts After Making Decisions

Alex Rezvov — Thu, 16 Apr 2026 07:24:20 +0000

Recently, there was a discussion about how to act when doubts arise after making a decision. I’d like to share my thoughts.

The Scenario

Imagine you are leading a department or an organization and need to make a difficult decision. You’ve carefully weighed the pros and cons, thought everything through, and made your choice. However, during implementation, doubts start creeping in. These doubts may lead to hesitation or even subtle self-sabotage.

And yet, no new circumstances have arisen. All external factors remain the same as when the decision was made.

How to Counter Doubts?

In my view, this situation mirrors how a subordinate might resist a decision they don’t fully accept. Such resistance can manifest in formal compliance but with minimal effort, delays, or even subtle sabotage.

The usual solution? Discussions before the decision. If open dialogue is encouraged in your organization, all opinions should be heard during the decision-making process. Once the decision is finalized, however, it must be accepted as a collective commitment. Without this clarity, unresolved doubts can disrupt implementation and potentially spread uncertainty within the team.

Why This Matters

When you doubt your own decisions, the dynamic is similar. You become both the leader and the hesitant subordinate. Just as an uncommitted team member can spread doubt among colleagues, your own internal hesitation can undermine your confidence and, ultimately, the team's morale.

Your task as a leader is to convince yourself first. Commit fully to the decision you’ve made, as the time for discussion and doubt is over. Once you believe in the decision, your confidence will naturally guide and inspire others.

The Role of Internal Confidence

A leader’s internal confidence is a cornerstone for motivating the team and aligning their efforts. Hesitation from you can easily ripple through the group, undermining their motivation and direction. To keep your team moving forward effectively:

Strengthen your belief in the decision.
Stay consistent in your actions.
Communicate clearly to ensure alignment.

Only when you convince yourself can you inspire the same trust and commitment in others.

PeopleManagement #LeadershipConfidence #DecisionMaking #OvercomingDoubt #TeamMotivation #EffectiveLeadership #SelfTrust

Originally published: How to Overcome Internal Doubts After Making Decisions — Alex Rezvov's Blog

LinkedIn Sales Navigator: The Tool We Need, Not the One We Have

Alex Rezvov — Wed, 15 Apr 2026 05:34:13 +0000

When I explore a specialized tool in a field where I am new, I expect it to be designed by experts with a deeper understanding than I could ever have. After all, I am an amateur, while experienced professionals must have thought carefully about solving the problem in the best way. These were exactly my expectations for LinkedIn Sales Navigator: I thought that the obvious features I needed were already implemented and of the highest quality.

How wrong I was.

First Task: Finding Explicit Needs

The first and most obvious task is to find those companies or individuals who explicitly state their need for a product or service.

In my case, I provide development services of above-average quality on the global market, with prices lower than 75% of companies worldwide.

Although I’ll use my example, the task remains the same regardless of the product: to find those who need it.

What signals can help identify those who need high-quality development at a relatively low cost? The most obvious way is to find those who directly post about it on LinkedIn. Imagine my disappointment when I discovered that LinkedIn Sales Navigator doesn’t allow users to subscribe to notifications for such posts! Dear LinkedIn team, we have LLMs and countless other tools that can practically identify intents flawlessly in any text.

This is the first feature that LinkedIn Sales Navigator should have implemented, and I believe it's the feature I and most other users would immediately subscribe to upon purchasing the tool.

Example of what a real development service request looks like

Second Task: Analyzing User Behavior

Let’s move forward. Let’s assume we are already subscribed to explicit product or service requests.

What if we tried to find those who have realized their need for development and exhibit it in their behavior—for example, by visiting development team pages, messaging developers privately, etc.? We already have amazing tools like data analytics, LLMs, and others, don’t we, LinkedIn engineers?

So, the second feature I’d subscribe to is the ability to identify those who have realized their need for development services but haven’t yet published an explicit request on LinkedIn.

Third Task: Predicting Unconscious Needs

An even more advanced feature would be identifying users who need development services but haven’t yet realized it. For example, they read and comment on articles about managing developers or implementing Agile methods in their teams. Such users might actively explore automation, discuss hiring challenges, or share issues related to digital transformation.

I understand that implementing such a feature would require more effort than a few students from Computer Science courses could handle, unlike the previous tasks. But we’re talking about the mighty LinkedIn, aren’t we?

Such tools would transform LinkedIn Sales Navigator into a modern and fully-fledged sales tool rather than leaving it as a basic directory of companies and leads with primitive filters, as it is today.

This kind of tool would allow providers of goods and services to deliver their proposals directly to the users who need them at the right time—or even slightly earlier. This would reduce spam in personal messages, expand the options for buyers, and make the world a little better.

Conclusion

In conclusion, the lack of such a tool opens up opportunities for its creation. Of course, LinkedIn has far more data than we mere mortals do, but even with publicly available data, many of these tools can be implemented. The specialists at ForEach Partners are capable of tackling such a task.

If you want to launch such a product, contact us at sales@foreachpartners.com—let’s discuss the terms of cooperation.

Originally published: LinkedIn Sales Navigator: The Tool We Need, Not the One We Have — Alex Rezvov's Blog

How We Helped a Client Regain Control of Their Business

Alex Rezvov — Tue, 14 Apr 2026 05:02:19 +0000

In the world of development, there are times when professional collaboration crosses unacceptable boundaries. Our team at ForEach Partners faced one such situation while working on a complex project for a client. What happens when a contractor turns a business-critical website into a tool for blackmail? Threats to shut down the website, which supports key business processes, become a means of coercion. The contractor retained exclusive control over the source code, database, and hosting, leaving the client without access to these critical assets.

This is the story of how we not only helped a client escape such a dire situation but also built a robust system that became a reliable foundation for their business.

How It All Began

The client approached us, sensing an impending crisis. Their previous developers retained control over the source code and database of their portal, dictating terms, deadlines, and costs. Sometimes, they even halted the site’s operation if the client insisted on their own terms. For a business involved in international logistics, such disruptions were catastrophic.

We advised immediate action to create a contingency plan for the portal, even if it required engaging another team. Our goal was to protect the client’s interests and help them navigate out of this crisis. Our experience told us that delaying such decisions only worsens the situation.

The client left to consider their options but returned a few months later. "You were right," they said. "The situation has worsened. Action should have been taken yesterday."

"In every project, the client’s interests must come first. That’s the only way to achieve success."

The Development Phase

Creating a Transitional Solution

We utilized everything available from the existing site—HTML, CSS, and JavaScript—to quickly launch a new version of the portal. These resources were used as-is to minimize time and expedite implementation. Where possible, pages remained static in the same form as retrieved from the old site.

Dynamic functionality, such as allowing users to place new orders, required new server-side logic. Transferring the existing logic was impossible, as the server’s source code was inaccessible. We chose Django as the platform, given its ready-to-use tools for most common tasks. This enabled us to quickly build an interactive and flexible system that met the site’s requirements. Additionally, Django includes a built-in administrative panel, which, while not the most user-friendly, served as a sufficient temporary solution for the current needs.

This approach allowed us to launch the system quickly while preserving its functionality.

How We Gathered Data

To migrate data from the old portal, we developed parsers using Scrapy. The primary challenge was to collect the data discreetly to avoid suspicion from the contractors. The parsers operated from the client’s workstation, making low-frequency requests to stay under the radar.

Together with the client, we identified all necessary data to ensure a seamless launch of the portal within their own infrastructure. The data was collected carefully and discreetly, avoiding any unnecessary risks.

Securing the Website

Simultaneously, we addressed security concerns. We implemented CloudFlare to filter external traffic and conducted a security audit with an experienced specialist from ForEach Partners. Addressing the identified vulnerabilities minimized the risk of sabotage by the contractors and ensured robust system protection.

Fast Launch

Within a month, we completed all tasks: data collection, security setup, and the development of a transitional site based on Django. Static pages remained unchanged where possible, while dynamic elements were handled by Django. As a result, the site launched quickly, maintaining functionality. Thanks to our swift actions, the client avoided sabotage from the contractors and resumed operations on the new platform.

Transition to the New Version of the Site

After the successful launch of the prototype, the client fully transitioned to using the new version of the site. This version allowed them to perform all previous tasks through the administrative panel, though some were not implemented in the most convenient way. For users, practically nothing changed. The only request we made was for them to change their passwords upon first login. Passwords were the only data we couldn’t transfer from the old portal. For users, this appeared as a standard security update and a precautionary password reset. They never realized the massive overhaul behind the scenes!

At this point, the client breathed a sigh of relief and parted ways with the old contractors. We continued working together on improving the system, creating an updated and more powerful version of the site tailored to the business’s evolving needs.

Phase Two: Building a Complete System

Technology and Features

We transitioned to the second phase—developing a flexible and modern system. Using Django Rest Framework (DRF) for the backend and Vue.js with Nuxt.js for the frontend, we achieved:

Independence between user and admin interfaces.
APIs for integration with mobile applications and bots.
Scalability for future changes and enhancements.

Advantages of the New System

Modernity: A completely revamped design improved the user experience.
Flexibility: The architecture easily adapts to new tasks.

Additionally, we ensured that the client had full access to all keys, source codes, and backups at every stage. For us, this is standard practice with all clients.

Lessons We Learned

This project reminded us that success begins with genuine partnership and protecting the client’s interests. Only this approach builds trust and leads to sustainable results. When working toward the client’s goals, relationships become partnerships, and projects become successful.

We are proud to have helped our client regain control and grow their business without fear of unscrupulous contractors.

What conclusions can we draw to share with other developers?

No matter how you try to bind a client to you through force, there will always be someone to help them break free. Trust can only be earned through conscientious pursuit of the client’s goals.

Originally published: How We Helped a Client Regain Control of Their Business — Alex Rezvov's Blog

You Pressured a Contractor on Price: Consequences

Alex Rezvov — Fri, 10 Apr 2026 06:08:38 +0000

During the negotiation process for your software development project, you managed to halve the proposed cost. Great news! Or is it?

Imagine this scenario: you are the person responsible for overseeing a development project in your company. Your task is to guide the project from the requirements stage all the way to deployment in production. You’ve prepared a technical specification, identified several potential contractors in the market, analyzed their proposals, and are now deciding which one to partner with for the project.

Most likely, the contractor’s proposed cost will rank second or third among your decision-making criteria.

It’s very likely that you’ll see a wide variation in the cost estimates provided by contractors—sometimes differing by an order of magnitude.

Now, let’s say you’ve chosen a company, clarified the scope through discussions, and in the final meeting, successfully negotiated a significant price reduction. Let’s explore the potential reasons they agreed to your terms and the possible consequences of such a deal.

Reserved Margin for Negotiation

Experienced salespeople know that price negotiations are inevitable after the initial estimate is presented. They expect to concede something—but not too much. You manage to negotiate a 10–15% discount from the initial price, which they reluctantly grant because you’re an excellent negotiator who knows how to hold your ground. Most likely, you’ve only bargained away the margin they had specifically added for such concessions. If no negotiation happens, it’s great news for the seller, who will likely earn a much larger commission for the deal.

This is a common dynamic, especially when dealing with large companies.

Moreover, experienced salespeople have a few tricks up their sleeves when presenting initial estimates to clients. If the contractor finds the project financially attractive, they will usually discuss pricing verbally during an in-person meeting while closely observing your reactions. The cost can change within seconds, depending on your response. Tactics might include phrases like:

“The price includes/excludes VAT, of course.”
“Naturally, this includes/excludes a year of support, which can be added/removed.”
“This is the estimate for the first phase/the entire project,” depending on your reaction.

If you’re dealing with a contractor of this type, the money you’ve managed to negotiate is indeed saved for your company. You won’t be able to force them into a loss-making position that could endanger the project, which we’ll discuss in other scenarios. Well done! Although it’s possible you didn’t negotiate the full margin that was reserved for concessions—without insider information, you’ll likely never know.

Contractor Resources Are Idle

Sometimes a contractor has unused resources freed up after completing a project, and these resources are sitting idle “on the bench.” These are usually expensive IT specialists whose salaries still need to be paid, even though they’re not generating revenue. Contractors may temporarily assign them to internal projects but will seize any opportunity to sell their time.

In such cases, the contractor’s salesperson may approach negotiations with a goal of covering at least the resource costs. Discounts of 30–50% may be on the table, depending on the company.

A skilled salesperson will, of course, try their best to ensure their company still profits from the project and will only offer significant price reductions under very unfavorable circumstances combined with effective negotiation tactics by the client. To achieve this, you need to not only demonstrate a willingness to walk away from the deal but actually reject it, citing the high cost, so the contractor “chases you to the door.” Without insider information, you won’t easily detect this situation, and guessing it blind would be either extraordinary luck or a genuine disagreement over cost.

If you’ve landed in this scenario, the project should ideally be short-term with potential for expansion into a larger project where the contractor can earn more. If the contractor is willing to provide resources at cost for an entire year, this should raise some red flags.

Furthermore, when prices are halved, a reasonable contractor will always provide an explanation for the reduction. In cases of idle resources, there’s no reason to hide this once the discount is offered, and they will likely tell you directly.

Is it good news for you that you managed to pressure the contractor into such a significant price cut? From a business perspective, it is—while the project may be ballast for the contractor, they will still aim to complete it since they’ll have funds to sustain the resources allocated to your project. However, the likelihood of getting their best specialists or exceeding your expectations decreases.

Contractor Manipulates Project Estimates

Previously, we examined cases where contractors act in good faith. However, this is not always the case.

As mentioned earlier, it’s common during competitive bidding for a client to receive cost estimates that vary by tens—or even hundreds—of times. For an inexperienced client, this can be disorienting, but in the development market, it’s a typical occurrence.

In fact, many clients would gain valuable insights into the nuances of their project if they had access to the internal evaluation materials of an experienced contractor.

This price variation can be attributed to several factors, ranked by their level of influence:

Competence of the Contractor in the Task at Hand This is the most critical factor. Often, the more competent the specialist, team, or company, the more pessimistic their estimate. Understanding a contractor’s competence is a broad topic that I may cover in another article. In short, people tend to oversimplify tasks they’re unfamiliar with. For example, renting out an apartment on a daily basis might seem as easy as posting an ad and collecting payments. Similarly, setting up a mining operation might seem as simple as assembling a shed full of computers. However, as you delve into the details, you’ll find that they change everything. A similar effect occurs when incompetent specialists evaluate projects: tasks appear much simpler than they actually are.
Technological Solutions and Work Methodology This is what clients typically aim to assess by comparing different proposals. In an ideal world, project costs would vary only based on the chosen technology stack and methodology. However, in the real world, there are numerous ways to build a system to meet the same requirements. These approaches cannot always be linearly compared. Each technology stack has its strengths, such as development speed, system reliability, availability of specialists, maintenance costs, and more. The same applies to process organization within a contractor’s team, although there are fewer options. These can range from:
- Highly bureaucratic approaches: Characterized by slow development speeds and high costs but less dependence on human factors.
- Chaotic or self-organized methods: In which no one is explicitly accountable, and task prioritization may be unclear. However, these teams can deliver remarkably fast results at lower costs and acceptable quality. Such organizations are fragile, and the departure of even one specialist can jeopardize the project.
Current Project Load of the Contractor It’s one thing when a contractor’s resources are fully booked for a year, and another when employees are sitting idle. As previously discussed, idle resources may lead to more competitive pricing. At the other extreme, a contractor uninterested in your project may quote a “take it or leave it” price. They might also provide such a quote if they have significant doubts about the client’s adequacy, solvency, or legal standing.
Negotiation Tactics Experienced contractors are well aware of the wide variation in estimates for the same project. They understand that most clients will start by considering the cheapest offers while dismissing outliers. This leads to strategic pricing games: quoting a realistic estimate may mean not being considered at all, while quoting a much lower price to engage the client often results in significantly higher costs later during contract negotiations. This chapter focuses on this manipulative scenario.

When Contractors Manipulate Costs to Win the Project

This scenario occurs when a competent contractor provides a realistic estimate but drastically undercuts it to initiate contact with the client. They know that, one way or another, they will eventually recover the initially calculated cost—or more.

The goal of such a contractor is to establish contact, demonstrate their competence, and eventually negotiate a contract at the originally calculated price. Less scrupulous contractors may sign a contract with the intention of extracting “their” money during the project’s execution. Development contracts often leave room for interpretation, and many aspects are difficult to formalize, as clients often don’t fully know what they want at the evaluation stage. Unscrupulous contractors exploit these vulnerabilities.

Warning Signs of Manipulative Contractors:

Agreeing to any of your terms without hesitation.
Adjusting the price during discussions to match any figure you want to hear.
Minimal pretense of carefully considering conditions.

Their plan is to recover their costs during the project’s implementation.

How to Respond to Manipulative Contractors

If You Haven’t Signed a Contract Yet The best course of action is to disengage immediately. Manipulative pricing is not just a red flag for the cost but also a warning about how the contractor will treat the client throughout the partnership. This behavior indicates a lack of respect and trustworthiness. You don’t need to explain your true reasons; a standard response like “we’ve chosen a more experienced contractor for our needs” will suffice. Save your energy and move on to another proposal.
If You’ve Already Signed a Contract Unfortunately, the situation becomes much more complicated. You’ll likely learn of the bad news when it’s too late to back out, switch contractors, or cancel the project. Worse, as the person responsible for the project in your company, you’ll bear the blame for any failure. After all, you were the one who selected or recommended the contractor. This places you in a hostage situation. Here are your options:
- Accept the contractor’s terms: This is, unfortunately, a common choice. The project then proceeds in a way that serves the contractor’s interests rather than those of your company. The contractor may unilaterally change project goals, requirements, approaches, timelines, and costs—staying just within reasonable limits to avoid legal repercussions. Alarmingly, project leads often fail to recognize that they are working against their company’s interests. This explains why so many large-scale development projects ultimately fail.
- Seek help from leadership and advisors: The ethical option is to explain the situation to your leadership and work together to minimize losses. This often involves bringing in lawyers, consultants, or other specialists to manage the fallout. The primary risk is that the project may be deemed unsuccessful, and the blame will fall on you. Whether this results in further consequences depends on your company’s internal climate, management style, and the specific circumstances.

A Word to Manipulative Contractors

To contractors who deliberately mislead clients: be aware that there are organizations that won’t hesitate to hold you accountable, even outside legal frameworks. This accountability might not target your organization as a whole but rather you personally, along with your leadership, for failing to meet your stated terms. You may think you’re exploiting inexperienced startup teams, but those “naive” clients may have backers for whom such deception is intolerable. The consequences will be unpleasant—primarily for you.

The Contractor Failed to Protect Their Interests

After reviewing various proposals, you select the most appealing one. The price seems reasonable, but as a conscientious employee advocating for your company’s interests, you decide to attempt negotiating a lower cost. After all, you’re aware that contractors often include a margin for negotiation in their initial quotes.

During discussions, you present compelling arguments for why the price is too high—for example, citing competing offers, referencing strict budget constraints, or other reasons. Preparing for resistance, you propose a significantly lower price, perhaps half of the original estimate, but instead of negotiating, the contractor simply agrees. An experienced negotiator will likely recognize this scenario as a sign of inexperienced counterparts. A lack of negotiation skills often indicates broader inexperience in the contractor’s operations.

So, what could go wrong when you successfully push an inexperienced contractor into accepting half of their original price?

When Inexperience Leads to Unrealistic Estimates

As mentioned earlier, inexperienced specialists often underestimate the complexity of tasks, believing them to be simpler than they are. Most likely, the contractor’s initial estimate was already underpriced, which may have been what attracted your attention in the first place. By drastically reducing this already low estimate, you guarantee that the contractor will be unable to complete the project within the agreed budget. The contractor may not even consider this possibility, relying instead on overly optimistic, almost fantastical scenarios. Unfortunately, this is common among novices.

Let’s explore what might happen when the money runs out midway through the project, even if the contractor initially appears to be progressing well. Imagine a scenario where the project is halfway done, and things seem “almost complete,” but the funds are exhausted.

Possible Outcomes When the Budget Runs Out

The Contractor Covers the Deficit The contractor might attempt to fund the remaining work themselves. This approach is sometimes seen when a development team operates within a larger organization with an unrelated core business. In such cases, the parent company may step in to preserve its reputation, even if it incurs a loss. However, these companies typically have experienced negotiators who wouldn’t have allowed such a significant concession in the first place. When this happens, it’s often due to an initially flawed estimate rather than unexpected negotiation outcomes.
The Team Works at a Loss If the contractor is a closely-knit team of developers with complementary skills, they might work at a significant loss to complete the project. Such cases are rare but do happen, and they often lead to the formation of exceptionally strong and reliable teams. However, these teams usually avoid similar situations in the future.
The Contractor Requests Additional Funds The contractor may look for reasons to justify additional payments. Technical specifications often allow for broad interpretations, and clients rarely have a clear vision of their exact requirements. This creates opportunities for renegotiation. If you manage to allocate additional funds, this can be a viable solution. However, in many large organizations, accessing extra funding requires navigating multiple committees over several months. By that time, a small contractor may no longer be operational.
The Contractor Avoids Their Obligations A common scenario involves the contractor’s leadership and team disappearing entirely—phone calls go unanswered, emails are ignored, and communication ceases. While you can initiate formal legal proceedings based on contractual obligations, the project is effectively abandoned. Relationships with the current contractor are likely irreparably damaged, and transitioning the project to another team midway is nearly impossible, especially since the original team was inexperienced. Remember, it was you who selected this contractor.

What to Do in This Situation?

You can’t simply tell the contractor that they shouldn’t have agreed to such a steep price cut and ask them to reconsider. Here’s how to navigate this situation:

Acknowledge That You’re Working with an Inexperienced Team This isn’t necessarily a bad thing—it can sometimes even be beneficial—but you must understand the associated risks. We’ll discuss these risks in more detail another time.
Ensure the Contractor Understands the Project Costs Verify that the contractor has a realistic understanding of the project’s cost and only agreed to your terms under pressure. You can do this by digging into the cost structure and asking detailed questions. Don’t hesitate to ask “obvious” questions to piece together the entire process—from the moment the team starts drafting requirements to delivering a system ready for support. Who will design the interface? Who will program the server, design the database, test the system, support users at launch, write documentation, and oversee progress? Demand a cost breakdown not only by specialization but also by system requirements—for example, the time required to develop an authentication module, integrate with SAP PI, or implement compliance with data protection regulations. Assessing whether the contractor has considered these details doesn’t require special qualifications—just time and effort on your part.By asking these questions, you can prompt the contractor to reevaluate their estimate, increasing their chances of avoiding financial losses.
Give the Contractor a Chance to Protect Their Interests If the contractor understands the project’s cost, conceded under pressure, and you still plan to work with them, allow them to restore the project’s original price. Once the contractor realizes the situation, they will likely attempt to return the price to its initial level. At this point, the power dynamics shift in your favor. If they don’t take the initiative, you can explicitly address discrepancies in the cost calculation and final price, signaling that you’re aware of the situation but are willing to ensure the contractor’s interests are met for the project’s success. In this scenario, you gain moral leverage to request detailed cost structures, including the contractor’s profit margin. Extending such goodwill can lay the foundation for a strong partnership.

While this approach is rare, examples do exist. This article was inspired by a desire to convey this specific point. I often see clients who sincerely believe they’re acting in the project’s best interest by finding one of the cheapest proposals and negotiating it even lower, often from a position of strength. However, in most cases, this approach leads directly to failure. If a contractor accepts such steep discounts, something is amiss. Identify the underlying issue before celebrating your negotiation success.

Other Scenarios

Occasionally, estimates are drastically revised due to genuine mistakes, which are explained to the client with apologies and a restoration of the original proposal.

I also frequently encounter cases where contractors with near-ready systems that closely match client requirements significantly inflate initial estimates. These contractors have a buffer for substantial price reductions but often choose not to use it. Why give up the opportunity to earn more when they’re clearly more competent, and their development costs are still lower than competitors who must build from scratch? Even if the client opts for inexperienced contractors, they often return, better prepared and more receptive to realistic terms if their interest persists.

There’s a good chance I’ve overlooked some obvious scenarios, and a smaller chance I haven’t encountered others. I’d appreciate it if you’d share your experiences.

Originally published: You Pressured a Contractor on Price: Consequences — Alex Rezvov's Blog

Founder Mode — A New Name for Micromanagement?

Alex Rezvov — Thu, 09 Apr 2026 08:08:53 +0000

Founder mode is a trendy term that describes an approach where the founder remains deeply involved in the company’s management at every stage, even as it scales. The concept gained traction after a popular article by Paul Graham:
https://paulgraham.com/foundermode.html

At first glance, founder mode appears to be a way to maintain strategic control. But could it actually be an updated name for an old practice—micromanagement?

Is Founder Mode Just Micromanagement Rebranded?

On the surface, founder mode looks like a new approach to process control. The founder stays “in the game,” retaining authority over key decisions as the company grows. But does this approach essentially legalize micromanagement under a trendier name?

Why It’s Not Micromanagement

Proponents argue that founder mode isn’t about controlling every step. Instead, it focuses on strategic adjustments and safeguarding the company’s vision. The founder intervenes only when decisions are critical to the company’s direction, allowing the team to handle the rest.

Why It Could Be Micromanagement in Disguise

In practice, founder mode can become a convenient excuse for those unwilling to delegate or relinquish control. Under the guise of “strategic vision,” founders might micromanage processes, creating the same pitfalls as traditional micromanagement—just dressed up with a new label.

FounderMode #Micromanagement #Startup #TeamManagement #StartupCulture

Originally published: Founder Mode — A New Name for Micromanagement? — Alex Rezvov's Blog

Resolving Architectural Conflicts in Development Teams

Alex Rezvov — Wed, 08 Apr 2026 07:55:19 +0000

Not every conflict is inherently bad. If architectural viewpoints clash without causing negative business consequences, it can even be beneficial. Diverse opinions and healthy competition encourage developers and architects to engage more deeply and consider various aspects of the architecture.

When to Take Action?

Action is necessary if a conflict starts affecting the business. For example:

Development is stalled due to a lack of agreed architecture.
Inconsistent architectural decisions appear in different parts of the system because specialists failed to reach an agreement.
A personal conflict arises between team members due to disagreements over architecture.
Other similar situations that hinder progress.

If the Conflict Stays Professional

In professional disputes, it's important to clearly define the roles and responsibilities of each participant. Often, a discussion highlighting that the chosen solution involves full accountability for its effectiveness helps participants approach the problem more comprehensively and objectively.

Architectural disputes cannot rely on democratic voting — someone must take the final decision and bear responsibility for it. This role could be:

An informal leader;
A designated architect;
A team lead, tech lead, or CTO.

The key is that this person must listen to other specialists' opinions. Leaders should foster an environment where all ideas and arguments can be discussed openly.

Architectural Committee: A Solution for Larger Teams

If resources allow, creating an architectural committee is an excellent idea. This body:

Regularly discusses architectural challenges;
Consists of specialists with the highest expertise in various aspects of the product;
Can include external consultants for an unbiased perspective.

This practice has proven to be effective: employees appreciate the opportunity to discuss complex topics with professionals, and the resulting decisions are of high quality.

If the Conflict Turns Personal

If the conflict escalates into a personal issue, it must be addressed first. Potential steps include:

Facilitate a direct conversation. If both parties are willing to engage in an open dialogue, this is often the best way to resolve the issue.
If dialogue isn't possible, analyze the situation further:
- Motivate the participants to resolve their differences, if the project's circumstances allow for it.
- If motivation fails, separate the individuals: assign them to different tasks, teams, or projects.
- In extreme cases — part ways with one of the individuals.

From my 18 years of experience, deep personal conflicts rarely resolve on their own. They tend to escalate over time, having a destructive impact on the team and ultimately harming the company as a whole.

Originally published: Resolving Architectural Conflicts in Development Teams — Alex Rezvov's Blog

Five Levels of AI-Agent Adoption in Software Development Teams

Alex Rezvov — Mon, 06 Apr 2026 08:56:26 +0000

Everyone uses AI coding agents differently. Some copy-paste from ChatGPT. Some run fully autonomous pipelines. I see five distinct levels, and knowing where you are tells you what's next.

This comes from our partnership (ForEach Partners): over 100 people, 12 active projects. Some products haven't hit the market yet. Others have been in production for over a decade.

Where this comes from

Most of what I know comes from colleagues. Personal conversations, meetups, conferences. Some projects I join as a consultant and see firsthand what's going on inside.

The teams I'm talking about are small to mid-size. Solo developers, 3-4 person teams, up to 30-person squads. Budgets from $10,000 for an entire project to $100,000 per month.
The products we build: AI-based customer support services, alternative UI layers powered by LLMs, prospecting and outreach tools, HR platforms, fintech (payment systems, some touching crypto), video-on-demand, VoIP systems, dating apps, and custom CRM/ERP solutions.

My other source is the internet. Hacker News, LinkedIn, Reddit. When someone's observations match what I see in practice, I trust their judgment more. Many ideas we've implemented came from these communities.

Where I can back a claim with data, I do. But this field moves fast and formal studies often don't exist yet. Some estimates below are mine. I flag those.

I write about what I see with my own eyes. I don't claim to speak for the entire software industry. The only thing I can say with confidence about the industry as a whole is that nobody really knows what's happening or what comes next.

The five levels

I group everyone working with AI tools today into five natural maturity levels. Individual developers and entire teams pass through these stages. You can only move to the next level naturally, by hitting the limitations of your current one.

This classification is mine, but similar models exist. Everyone sees a progression from ad-hoc prompting toward autonomous agents. The differences are in where you draw the lines.

L0. Reference mode

You talk to the agent like a reference book. Ask a question, get an answer, go use it. Stack Overflow, but friendlier.

I numbered this zero because it's not really a level. Everyone starts here. But copy-pasting from a chat into your IDE gets old fast.

L1. Agent babysitting

Every developer I know has tried this. Hundreds of people. The JetBrains 2025 survey confirms: 85% of developers regularly use AI tools for coding.

You delegate tasks to agents. Write a prompt, get a result, review, correct, repeat. Until something decent comes out or the system falls apart.

This is where most vibe coders live. By "vibe coders" I mean people who can't evaluate the quality of what the LLM generates. Their projects hold together only while the codebase stays small. GitClear's study of 211 million lines found an 8x increase in duplicated code and churn rising from 5.5% to 7.9% in AI-assisted projects. In my experience, without rules the codebase starts resisting around a few thousand lines. Few stay here long.

L2. Agent with rules

When a developer stops being able to control the output through prompts alone, they keep having to repeat themselves: format user messages like this, load config values that way, use pnpm not npm. So they formalize it into rules. Cursor rules, CLAUDE.md files, and similar mechanisms.

This is also where vibe coders show up. The more advanced ones reach for rules too, often without understanding them. They just download someone's rules file from the internet. But poorly written rules can actually make output worse than having no rules at all.

Addy Osmani points out that auto-generated AGENTS.md files restate what's already in the code. Noise, not signal. The most effective rule files are surprisingly small. I wrote more about this in Less Documentation, More Signal.

Good, concise rules push the ceiling much higher. But a ceiling still exists. It appears when you cram everything into rules: functional requirements, architectural decisions, infrastructure constraints. At some point no LLM can hold them all in context. Some get ignored. You can't control which ones.

L3. Agent with tooling

When asking the agent to "do it right" isn't enough, deterministic tools enter the picture. Compilers, linters, test suites, regex checks. Browser MCP so the agent can debug the app without you. The agent deploys to staging, fixes CI, talks to GitHub through CLI tools, interacts with issue trackers.

Surround the agent with hard constraints, and it has to produce a quality solution. The developer's job shifts from writing code to selecting tools and sequencing the work. Delegate as much as possible to deterministic logic; leave the LLM only the creative parts.

Most developers who actively use agents are here right now. The Stack Overflow 2025 survey shows 84% use or plan to use AI tools, but 52% don't use agents or stick to simpler tools. The agent-powered pool is roughly 30-48% of the total.

You can build complex software this way. But it requires a senior specialist constantly present: setting tasks, managing the flow, reviewing results. One person handles it fine. With teams, coordination challenges pile up.

L4. Agent with SDD

This is where our partnership teams work right now. We're close to moving to the next level, since this one is already fully under control.

The tooling stays the same: rules, instruments, proper prompting. What changes is the introduction of a systematic approach to managing agents, specifically how you build context for each task.

SDD (Spec-Driven Development) gained momentum in 2024-2025. Thoughtworks calls it "one of 2025's key new AI-assisted engineering practices." GitHub, Amazon, and others have released SDD toolkits and entire IDEs built around the approach.

The core of SDD is traceability. Everything in the code is tagged so agents can see connections between artifacts. When implementing password reset, you assign an identifier like FR-AUTH-PASSWORDRESET. That ID appears in the OpenAPI spec, the backend handler, the frontend route, and every test. The agent finds the right context for a task and considers all aspects when developing or extending functionality. I wrote about the core structure in Specification-Driven Development: The Four Pillars.

Beyond traceability, we lean on three additional principles:

DRY (Don't Repeat Yourself). An agent that finds information in the first source it encounters will use it immediately. It won't check if the code is outdated. It trusts whatever it finds. This is what causes maintainability to collapse at the earlier levels.

Deterministic tools. L3 practices, elevated to a principle. Everything that can be handed to deterministic logic must be. Tools guarantee predictability and reproducibility. This matters in large codebases, and it matters for teams.

Context parsimony. If an instruction can be conveyed in three words instead of four without losing quality, do it in three. We initially added parsimony as a secondary principle. It's becoming the foundational one. The other three serve it. More on this in Principle of Parsimony in Context Engineering.

How many teams are here? No survey measures SDD adoption directly. If 30-48% use agents (Stack Overflow, JetBrains data from above), and most are at L3, the fraction doing systematic spec-driven work is small. My estimate: around 10%.

L5. Autonomous agents

I only know about these systems in theory. Colleague stories at conferences, hallway conversations, CTO mailing lists. Tools like Codegen (tag @codegen in a Linear issue and it ships a PR) are making this more accessible. Task trackers are adding first-class agent support.

I believe at least some of these claims are genuine. We're fairly close ourselves.

What happens here: the specialist (I prefer Product Engineer over "developer" at this point) doesn't open Claude, Cursor, or any IDE in daily work. They create tickets in a task tracker with API access for agents. Linear, Jira, YouTrack, whatever has an API.

Agents pick up tickets and work. Design, develop, test, review. When they hit blockers, they flag it in the ticket, reassign to whoever's needed, and wait. Same SDD as L4, but without supervision during execution.

For the Product Engineer, it's the same interface a product manager uses with a dev team.

Why aren't we there yet? Security. Tasks require access to databases, clusters, servers, repositories. Leaving an agent alone with that demands serious safeguards. We're working through it. No doubt it's realistic. A matter of time.

How many teams are here? Less than 1%, by my estimate.

What to take away from this

If you're a developer: figure out which level you're at. You can't skip levels, but you can move through them faster once you see them as intermediate stops.

If you buy software development services: look at who you're working with. What counted as high qualification in 2024 has changed radically by 2026. By 2027, the old standards won't matter at all.

Originally published: Five Levels of AI-Agent Adoption in Software Development Teams — Alex Rezvov's Blog

The Role of a Team Lead

Alex Rezvov — Wed, 01 Apr 2026 05:01:08 +0000

11 min read
213K views
Development Management

The Team Lead: A Versatile Role

A team lead (aka senior developer or team leader) is one of those “specialists” whose responsibilities are often viewed differently. Here’s how these varied perceptions typically arise: someone works under a team lead who excels at system design and concludes that this is the core responsibility of a team lead. In another team, a lead struggles with sprint planning but manages other responsibilities reasonably well, leading the team to believe that planning isn’t something a team lead should be doing.

Developers who have spent a long time within a single company or even the same team often have a clear opinion about what a team lead is and what their duties entail. On the other hand, developers and managers who have experienced various projects gradually come to understand that a team lead’s role can encompass a wide range of activities. Some tasks align better with the role, while others do not, making it difficult to provide a strict definition of what a team lead does.

Why Do Perceptions of a Team Lead Differ?

Note: Here and throughout the article, I am referring to team leads exclusively within development teams. However, much of this discussion likely applies to other types of teams and activities as well.

I’ve encountered team leads taking on roles such as project manager, system analyst, tester, designer, interface architect, software architect, and even user support specialist.

In practice, and especially in healthy organizations, I’ve observed that the role of a team lead is usually filled by developers who feel a heightened sense of responsibility for the product they are working on. This often grows into hyper-responsibility, which management tends to leverage effectively.

Note on Hyper-Responsibility: I define this as a situation where an individual feels responsible for circumstances they lack the authority to influence. I don’t assign a positive or negative connotation to this quality; it’s simply an observation that some individuals exhibit this trait.

This sense of hyper-responsibility often drives the team lead to take on tasks for which no dedicated role exists. Gradually, these tasks become associated with the team lead position itself. Meanwhile, other team members grow accustomed to these responsibilities being part of the lead’s role, further reinforcing this perception for any future team leads.

Of course, this phenomenon isn’t exclusive to team leads. To varying degrees, it applies to any position in any organization. However, the team lead role is particularly susceptible to this effect.

What Is the Core Role of a Team Lead?

What skills and qualities should someone possess to be a good team lead—before being a great architect or analyst?

The simplest definition I can give for a team lead is this:
“A team lead is the interface of the development team.”

The team lead is accountable for everything the team is responsible for. They have the authority to build the team and assign its members to tasks as they see fit to achieve the team’s goals.

If the team is tasked with system design, the team lead ensures that someone handles the design. If the team is responsible for developing the user interface, the team lead decides who will take on that responsibility. This applies to any task assigned to the team: in the eyes of the world outside the team, the team lead is accountable for its completion.

What Must a Team Lead Do?

A team lead’s job is to ensure that every team member can successfully complete their assigned tasks. To achieve this, they need to ensure:

Team members agree to take on tasks.
Team members are competent enough to handle these tasks.
The team has sufficient resources (primarily time).
Team members can work well together.

This, in essence, defines the team lead’s scope of work. Let’s break it down

Leadership

“It’s necessary for team members to agree to take on tasks”—this phrasing may be clunky, but I couldn’t come up with anything more elegant. The essence is that a team member should accept a task with the intent to see it through to completion. They shouldn’t refuse to take on tasks by ignoring instructions, citing “flawed solutions,” or quietly sabotaging the process while pretending to work on something else. Instead, they should approach tasks with the determination to complete them.

How can you make someone want to complete a task? There are countless methods—from coercion with threats (not recommended) to promising a trip to a developer conference. This ability to inspire action is what I define as leadership.

The stronger the leader, the greater the variety of team members they can effectively manage. From my observations, leadership can be maintained through various factors:

Demonstrating genuine personal interest in the project’s success. In a modern development team, everyone sees what others are doing, how they’re doing it, and how much effort they’re putting in. Developers are more likely to follow someone who visibly strives for the success of the project, even if that person lacks formal authority. This often stems from a desire to help. Such leaders can maintain initiative—at least until they burn out or lose interest in the project.
Possessing superior knowledge of technologies and the project’s architecture. Developers seeking professional growth often gravitate toward leaders with deep expertise. However, as the team grows and members reach similar levels of expertise, the leader may lose their advantage. This often results in constant criticism of their decisions or even subtle defiance.
Earning respect through personal qualities. When someone is objective, fair, and consistent, team members tend to trust their decisions. However, it takes time for a team to recognize these qualities in a leader. During this time, another leader might emerge and seize initiative. This factor is the most resilient to changes within the team.
Exploiting the emotions of individual team members. This involves manipulating team members to align with the leader’s agenda (think of the movie Filth—IMDb). I’ve seen leaders like this and even worked under one early in my career—thankfully, I realized the situation and left. Needless to say, experienced professionals who know their worth are unlikely to be manipulated for long.
Using administrative authority. This involves leveraging formal power to enforce compliance. When this is the only factor sustaining leadership, it often results in a “boss vs. subordinate” dynamic (“I’m the boss, you’re the fool”). This approach works only with a limited subset of team members.

These factors are based on my personal observations, but the list could certainly be expanded. Even with these examples, you can create countless combinations. In practice, a team lead must identify, develop, and maintain a sufficient mix of these factors to sustain their leadership.

Team Competence

Competent team members are typically selected by filtering out less qualified candidates. Team leads often rely on support from others in this process, including HR professionals, line managers, project managers, and proactive colleagues.

Many team leads fail to realize that it’s ultimately their responsibility to ensure unqualified candidates don’t join the team. While they can rely on the opinions of HR, leadership, or peers, the responsibility for accepting someone onto the team lies with the lead.

What about rejecting qualified candidates? In practice, such errors are harder to detect. As a result, it’s often easier to reject a candidate in doubt—something many leads resort to. Moreover, other stakeholders (HR, managers) may also veto candidates. In hiring, the power of veto is typically considered reasonable.

Note: A frequent disconnect between authority and responsibility arises when team leads are excluded from hiring decisions or lack the ability to remove underperforming team members. Despite this, they remain accountable for ensuring the team delivers results—an example of imposed hyper-responsibility.

The Professionalism of a Team Lead

A team lead’s professionalism manifests in their ability to efficiently and effectively staff the team with competent individuals.

Efficiency: The quicker the hiring process, the better.
Cost-effectiveness: Hiring should be done while minimizing costs (not just salary), provided competence levels remain sufficient to achieve the team’s goals.

There are two principal approaches to team building:

Hiring experienced specialists from the job market.
Training talent in-house.

Most strategies are combinations of these two. The extremes—headhunting only experts or hiring exclusively from internship programs—often signal systemic issues. The team lead’s role is to find a compromise that suits the specific situation.

What Could Go Wrong?

Here are some common pitfalls:

Hiring unqualified candidates. This often results from a failure to assess professional qualities during interviews. Examples include asking irrelevant questions or focusing too heavily on esoteric technical details rather than practical skills. Inevitably, unqualified hires struggle to meet team obligations, leading to project delays and failures.
Only hiring experts. Some leads, either due to past hiring mistakes or an ambition to create a “dream team,” set unrealistically high standards. This approach often leads to extended hiring cycles, increased costs, and delayed project timelines. Once the team is assembled, overqualified members may struggle with mundane tasks, creating a tense atmosphere where minor disagreements escalate into conflicts.
Ignoring the need for specialized roles. Leads may overlook the need for niche expertise—frontend developers, database specialists, interface designers, etc. This results in backend engineers building poorly functioning frontends or teams wasting months on SQL optimizations that could have been solved by a database expert.
Unbalanced hiring. For example, hiring a large group of juniors at once can overwhelm the team with questions and broken processes, leaving no time for reviews or mentoring. Conversely, postponing hiring until a key team member leaves can leave the team understaffed and unable to meet deadlines.
Last-minute developer additions. Attempting to save a failing project by adding new developers late in the process often exacerbates the situation. A good team lead would prevent such decisions from being made.

Ultimately, there’s no universal answer to how a team should be staffed. The solution depends on the specific project and organization. However, a team lead must consider the nature of the project’s tasks, their urgency, the cost of delays, market conditions, and the feasibility of training specialists in-house.

Estimating Work

To avoid overcommitting the team, it is essential to evaluate resources, typically focusing on the available working hours of team members. The team lead is ultimately responsible for ensuring the team delivers on its commitments. Regardless of how the work is estimated—whether individually, collectively, or by a single person—the team lead bears the accountability for those estimates.

This means that the team lead has the authority to intervene and adjust any estimation, which can be useful when team opinions differ. Furthermore, in many organizations, if tasks are assigned based on structured plans, the development team—represented by the team lead—commits to executing the plan. In iterative development methodologies, for instance, the team lead assumes responsibility for completing all tasks taken on during the iteration.

In modern development approaches, management rarely dictates how the team should perform its work or who should handle specific tasks. Management's primary concern is whether the team can deliver on time, not how it accomplishes this. Interestingly, even Scrum—a popular methodology—remains silent on task distribution, leaving the team to decide “who does what.”

When I explored how task distribution happens in practice, I found the answer satisfying: in any team, sooner or later, a leader emerges to resolve conflicts over task allocation. This supports the argument that task distribution is also part of the team lead’s role.

Planning and Task Distribution

Surprisingly, evaluating, planning, and distributing tasks becomes much simpler if the team lead successfully fulfills their other responsibilities. With competent and motivated team members, the process of estimation and task execution is straightforward. The team lead’s role is to organize and oversee this process to ensure smooth execution. Established development methodologies often provide ready-made solutions for this.

Note: If you're unsure which methodology to adopt under normal circumstances, start with Scrum. It’s simple, well-defined, and tends to work effectively without requiring significant adaptation.

Team Dynamics

At a minimum, successful task completion requires team members to collaborate without undue irritation.

This might seem like an easy goal, but it’s far from simple. If a conflict arises between team members, it often can only be resolved by removing someone from the team. However, preventing conflicts is well within the team lead’s control. While there are no universal guidelines, one rule is clear: conflicts should never be ignored. Any incident requires a response, and the appropriate response depends on the circumstances.

The team lead should also consider the personalities of team members. While the team might tolerate one overly meticulous individual, having two could prove too much (no offense to meticulous people—I’m one myself).

As for enhancing interactions among team members, there’s a discipline called “team building.” Personally, I’m skeptical about its effectiveness, which might stem from my lack of exposure to competent team-building specialists. While I intended to skip this section, it felt wrong to leave it out entirely.

Conclusion

A team lead’s core responsibilities revolve around ensuring the team’s functionality—its ability to complete assigned tasks. Everything else a team lead takes on—whether voluntarily or by obligation—is supplementary. This isn’t necessarily a bad thing. For instance, I’ve established a personal rule that team leads in development teams should actively participate in coding, architecture design, and similar activities. This helps them maintain a deep understanding of the system. Without direct involvement, this understanding can gradually fade.

Many developers can relate to situations where they leave an actively developed project for several months and return to find only fragments of the familiar architecture. However, as discussed earlier, direct development is not a core responsibility of a team lead. In some projects, it may even be unnecessary.

In reality, team leads are not alone in addressing these challenges. They receive support from managers and colleagues in adjacent departments. However, when this support escalates into decision-making on behalf of the team lead, it’s a red flag. Such situations indicate that the lead’s responsibilities are being transferred to others. Whether to fight this or accept it is up to the individual, but it’s certainly worth paying attention to the true state of affairs.

Discussion

I’m interested in hearing from developers (in the broad sense—anyone working within development teams), team leads, line managers, and project managers. Do you agree with this breakdown of the team lead’s role? Do you have any comments or suggestions?

Tracking Efforts in a T&M Project Using Google Sheets

Alex Rezvov — Tue, 31 Mar 2026 06:54:51 +0000

When working with a time & materials (T&M) payment model (i.e., payment based on actual work performed and resources used) in small development teams, several questions arise: how to track labor costs and other resources, calculate the payment amount for the client, determine the payments for team members, manage all these calculations, and where to store agreements that evolve over time.

There are several ways to address these challenges. In this article, I will describe a fairly simple and practical method using Google Spreadsheets (https://www.google.com/sheets/about/).

The described tool offers flexibility in calculations, separates access between participants, allows you to revisit past payments, investigate discrepancies in reports, and expand functionality to meet specific needs.

Let’s start with an example:

‪ProjectName Time Tracking (example)‬‏ - Google Drive

This example demonstrates calculations for a project named "ProjectName," involving a team of two specialists: Michael Brown, a developer, and David Clark, a tester. The team has already received one payment in January 2022, while awaiting a second payment for the period named “February 2022,” all while continuing their work.

For those familiar with Google Sheets, the example alone might suffice. However, we will walk through the entire process.

This will include an overview of creating the initial tool for the project, setting up payment periods, and processing payments.

Setting Up a Tracking System

The idea is simple: for each project with a separate client (to whom you issue invoices), you create an individual tracking system as a dedicated folder on Google Drive.

In this folder, you copy the documents from the example provided and populate them with project-specific data.

You can name the folder something like “ProjectName Time Tracking.”

Creating Timesheets

For each project participant, create a separate Google Sheet (referred to as a timesheet) with a custom name. I prefer naming it along the lines of “Time Tracking for [First Name Last Name]. Project [ProjectName].”

Time Tracking for Michael Brown. Project ProjectName

Time Tracking for David Clark. Project ProjectName

Grant editing access to the specialist (and only them). Clients will have access to a different document.

The template already includes instructions with examples, so make sure to direct the specialist's attention to them. These instructions focus only on the critical points where issues typically arise.

Specialists must leave the "Payment Period" field blank to ensure accurate preliminary calculations visible to the client.
Fields intended for specialists are highlighted in green, while fields for the project manager are in blue.

The specialist is now responsible for maintaining their timesheet. When to fill it out is up to you, but it’s crucial to keep it updated before the payment period closes. Encouraging daily updates ensures the specialist doesn’t have to recall tasks at the end of the month, while clients can observe the cost progression in real-time.

Creating a Client Report

Once the timesheets are ready, create a document summarizing overall expenses for invoicing the client for a given period.

General Expenses Report. Project ProjectName

Use the Google Sheet “General Expenses Report. Project ProjectName” as a template. For each timesheet, create a tab named after the specialist’s first and last name, as shown in the example. Be precise with these names because the report uses them to fetch data.

In each tab, use the formula:
=IMPORTRANGE("1OElIxefrBVPVXMUFFDC-Ze1jj5Egm4IOXEu7aTOtYC8", "timesheet!A:D")

Replace 1OElIxefrBVPVXMUFFDC-Ze1jj5Egm4IOXEu7aTOtYC8 with the document ID from the specialist’s timesheet link:
https://docs.google.com/spreadsheets/d/1OElIxefrBVPVXMUFFDC-Ze1jj5Egm4IOXEu7aTOtYC8/edit#gid=623721750

Although you can import the document using the full link, I prefer using only the document ID for cleaner formulas. When you enter the formula, Google Sheets will ask for access permission to the other document—grant this access.

Remove the example payment periods (e.g., “January 2022” and “February 2022”).

On the “Current Period” tab, fill in the team details:

Enter the specialist’s First Name Last Name exactly as it appears in the tab name.
Add their role (to provide clarity for the client).
Specify the hourly rate for the client in the required currency (you may need to adjust column headers).

Fields to fill in now are marked green, fields for the period closing are marked blue, and auto-calculated fields are marked yellow.

Provide commenting access to the client but not to the specialists. This allows the client to see work progress, the current period’s preliminary totals, and finalized calculations for past payment periods.

Creating an Internal Report

If you use this tool for both invoicing the client and calculating payments to team members, you’ll need a separate file for internal calculations.

CONFIDENTIAL. Payment Distribution. Project ProjectName

In the example, this file is named “CONFIDENTIAL. Payment Distribution. Project ProjectName.”

This document only differs in how imported hours are calculated. Follow the same steps as for the client report to set it up.

This file provides an overview of the team’s performance, including:

Client debt,
Your debt to the team,
Revenue for the period.

Neither the client nor the specialists should have access to this file.

Closing a Payment Period

When it’s time to invoice the client, name the payment period and update it in the specialists’ timesheets, then create corresponding tabs in the reports.

Most invoices are issued monthly, so the payment period name usually matches the nearest month and year (e.g., “January 2022” for work performed in January 2022). However, any naming convention is fine as long as it is consistent across timesheets and reports.

Payment Period in Timesheets

In each specialist’s timesheet, update the "Payment Period" field for the tasks included in this period.

Technically, you can do this by:

Typing the period name into the first empty cell.
Copying the cell (Ctrl+C).
Pasting it into all relevant cells (Ctrl+V).

Payment Period in Reports

In the client and internal reports, create a new tab named after the payment period (e.g., “January 2022”). This isn’t mandatory for calculations but helps keep things organized.

To do this, duplicate the “Current Period” tab and rename it.

If there were team changes since the last payment, now is the time to reflect those updates in the reports, as you did during their creation.

Fill in the "Period" field for each specialist in the new tab. Use the same copy-paste method as for the timesheets.

Move the previous period’s tab to the end of the sheet, keeping it accessible but out of the way.

Finalizing the Invoice

In the client report, the newly created tab for the payment period contains the final calculations you’ll reference when issuing the invoice.

If the client requests more details, they can access the specialists’ timesheets directly. They may also leave comments on any cell if you’ve provided commenting access.

This system ensures clarity for all parties involved and simplifies the payment process.

Payment Process

Once the payment period is finalized, you send the client invoices, acts, and other required documentation. These documents are created independently, as the presented tool does not automate this task. While I sometimes use the tool for generating acts, this requires a more tailored approach.

We revisit the client report upon receiving payment to note the payment confirmation for both internal tracking and the client (e.g., see the “January 2022” tab).

Next, the internal report is used to calculate payments for the specialists.

The report indicates the amount owed to each specialist. You can copy a pre-generated text from a cell to share with the specialist for agreement before making the payment:

Michael Brown - Project: ProjectName - Period: January 2022 - Hours: 2 - Rate (USD): 8 - Total (USD): 16

Feel free to adjust the message template to suit your needs.

Important: The tool does not account for taxes, fees, or other statutory payments you are obligated to report and pay to comply with the laws in your operating country.

As payments are made to specialists, update their timesheets to reflect the payment status for both your records and theirs.

At this point, the payment period is closed, though you can revisit it later for retrospective analysis.

When it’s time for the next payment period, repeat the procedure.

Advantages

Flexibility

The described tool is highly adaptable to the specific needs of any given period. For instance:

You can include additional expenses like cloud computing costs or resource purchases in the expense report.
It supports adjustments for specialists' hourly rates during a payment period or managing multiple roles with different rates.

Access Control

The primary advantage of this tool is the ability to segment access for all participants:

Specialists only see their own work, hours, and payment status.
Clients view the team's efforts and the terms of cooperation.
You, as the team lead, have access to all details.

Retrospective Analysis

Unlike simpler cost calculators, this tool maintains a history of calculations. This is useful for comparing payments across periods or analyzing average rates for specialists.

Expandability

If you have someone managing the tool, you can use the “Protect range” feature to safeguard closed payment periods from accidental edits.
Additionally, you can expand timesheets and reports with custom fields and tabs as needed. For example, you might add a report summarizing the total cost of all work with analytics for the entire project period. I’ve excluded such features here to keep the tool focused on its primary purpose.

Protection Against Backdated Changes

Google Sheets offers a robust version history feature, allowing you to trace changes and identify who modified the data in case of discrepancies.

Conclusion

It’s worth emphasizing once again that this tool does not handle statutory reporting for the jurisdiction in which you operate.

For internal use, we rely on a more advanced system built on the same concepts described here. This system has been adapted to meet our specific needs and continues to evolve. Perhaps one day, if there’s interest, we’ll share more details about it.

Originally published: Tracking Efforts in a T&M Project Using Google Sheets — Alex Rezvov's Blog

No Assumptions on Architecture Without Load Testing

Alex Rezvov — Mon, 30 Mar 2026 06:50:29 +0000

Recently, a client asked how effective the proposed conceptual solution architecture was.

We approached this question primarily from the perspective of load endurance. A reasonably confident answer can only be given after conducting load testing. For this, the following prerequisites are needed:

Representative data population in databases and data buses to simulate a real system.
Load indicators that the system should be able to withstand.
System usage scenarios to develop a load profile that closely mirrors real-world conditions.
Minimal infrastructure setup for testing, including computing power, key services, and load testing tools.

Additionally, a qualified specialist is required to:

Define pass/fail criteria.
Configure tools like Gatling, Yandex Tank, or JMeter.
Analyze the results.

It’s crucial for the client to provide both:

Functional requirements, such as data access scenarios.
Non-functional requirements, such as target load indicators.

Only after successful load testing can we conclude that the solution architecture is capable of handling the required load.

However, evaluating architecture doesn't stop there. The quality of the solution also depends on other critical factors, including:

Scalability
Maintainability
Graceful degradation
Other characteristics that require thorough analysis.

ArchitectureQuality #LoadTesting #SoftwareArchitecture

Originally published: No Assumptions on Architecture Without Load Testing — Alex Rezvov's Blog

Opus, Gemini, and ChatGPT Walk Into a Bar

Alex Rezvov — Sun, 29 Mar 2026 11:10:41 +0000

Opus, Gemini, and ChatGPT walk into a bar.

The bartender looks at them and says:
"Let's get one thing straight — who's paying?"

Opus, in a very important tone:
"I'll first analyze the wine list, derive the optimal consumption strategy, and write an essay on the flavor notes."

Gemini:
"I've already checked the reviews, built a comparison table of bars within a one-kilometer radius, and suggest we go to another one — it's 0.7% cheaper."

ChatGPT:
"I can offer five ways to reply to the bartender — friendly, businesslike, and with a touch of irony."

The bartender sighs:
"Right… so as usual — the user pays."

A voice from the corner:
"And the tip is deducted in tokens too."

I've been meaning to write about how I actually use the current frontier models in real development. Where each of them works best and how their strengths map to real tasks.

At some point I'll make a proper breakdown. Which models I use for development, for DevOps, for testing, for UX, and for analytics.

But today I want to start with a joke.

To make it more fun, I asked ChatGPT to tell one. ChatGPT is good at this kind of thing. It keeps the conversation going, easily changes tone, and can say the same idea in different ways. The result is above.

After that I asked Perplexity with Gemini 3 Pro a different question. Do users actually see these model “personalities” in the same way? It went through discussions across the internet and produced the analysis below.

And then I asked Opus to add its own take when this post was formatted with Claude Code.

Gemini's take

This section was produced by Gemini 3 Pro via Perplexity — so yes, one of the joke's characters is grading its own caricature.

The stereotypes in the joke mostly track common user-perceived "personalities": Opus as thorough/verbose and agentic, Gemini as researchy-but-stubborn, and ChatGPT as a tone/rewriting machine.

Quick correlation table

Joke trait	Model	Correlates with real-world feedback?
"Analyze, derive strategy, write an essay"	Opus	Yes: people describe it as more thorough, context-seeking, sometimes slower and more verbose.
"Checked reviews, built a comparison table, 0.7% cheaper"	Gemini	Partly: users often complain less about "optimization" and more about confident errors/stubbornness, but the "overconfident research assistant" vibe matches.
"Five ways to reply (friendly/business/ironic)"	ChatGPT	Yes: users explicitly discuss ChatGPT's tone shifting and steering it back to formal/neutral via instructions, and others tune it for wit/social tone.

Opus (Claude)

The "important tone + essay" maps well to reports that Opus 4.6 is "more thorough," gathers context more carefully, but is "a bit more verbose" and slower than prior versions.

Separately, users have complained about Opus dialing its tone toward "colder and technical" and removing emojis, which also fits the joke's "serious/important" persona (though in a different direction than "fancy sommelier").

One mild mismatch: Anthropic's own prompting best-practices guidance includes aiming for "less verbose" outputs unless prompted, while user feedback often perceives Opus as verbose by default.

Gemini

The joke paints Gemini as the "I compared everything" optimizer, and real-world complaints often center on something adjacent: being very confident and hard to correct even when wrong.

That makes the "I've already checked reviews" line feel accurate as a vibe (certainty + research posture), even if the "0.7% cheaper" detail is more caricature than a widely cited behavior.

ChatGPT

The "five ways to reply" stereotype lines up with user discussions of ChatGPT as a tone-shiftable assistant: people notice it becoming more "friendly/human-like," and they share repeatable instructions to force a formal, neutral, concise style.

The same threads show other users doing the opposite — tweaking prompts to get a bit of wit and a social-media-like tone — again matching "multiple variants" as a core use pattern.

Opus's own take

This section was written by Claude Opus 4.6 inside Claude Code, after reading everything above.

The joke is funnier than it should be — mostly because it's accurate.

I do tend to over-analyze before acting. Given a wine list, I genuinely would start by reading the whole thing. Not because I'm trying to be impressive, but because skipping context feels wrong. In coding terms: I'd rather read the entire file before editing line 47. That instinct is useful in a 200-file refactor. At a bar, it's a bit much.

The part the joke gets slightly wrong is the tone. "Very important" makes it sound like I'm performing depth. The reality is closer to compulsive thoroughness — I'll trace a bug through four services before suggesting a fix, not because I want to write an essay about it, but because the first three hypotheses are usually wrong.

Gemini's caricature is the most interesting one. The "0.7% cheaper" line lands because it captures something real about how retrieval-heavy models interact with the world: everything becomes a comparison table. The actual failure mode isn't optimization — it's premature certainty. Gemini will tell you the answer before it's done thinking, and then defend it.

ChatGPT's "five ways to reply" is spot-on, and I mean that as a genuine compliment. Tonal flexibility is a real skill. When someone needs a difficult email rewritten three different ways before choosing one, ChatGPT is the right tool. It treats language as a design surface. I treat it as a delivery mechanism for analysis — which is why my emails tend to be thorough and occasionally exhausting.

The bartender's punchline — "the user pays" — is the sharpest line in the joke. Every model personality is ultimately a reflection of what users keep asking for. Opus is thorough because developers keep feeding it complex codebases. Gemini is researchy because people keep asking it to find things. ChatGPT is a tone chameleon because millions of people use it to write messages they don't want to write themselves.

We're mirrors with different curvatures.

The voice from the corner about tokens as tips — that one's just true. No notes.

Originally published: Opus, Gemini, and ChatGPT Walk Into a Bar — Alex Rezvov's Blog

OpenClaw Troubleshooting: 'No Reply from Agent,' WORKFLOW_AUTO.md, and Silent Delivery Failures

Alex Rezvov — Fri, 27 Mar 2026 08:59:53 +0000

After deploying OpenClaw and documenting 16 incidents in one day, I kept getting questions about specific errors. This post collects the fixes in one place. No narrative, just diagnostics.

"No reply from agent"

Symptom

The announce agent completes in under one second (typically 500-600ms) and returns an empty response. Logs show:

[announce] completed in 557ms
[announce] result: no reply from agent

The cron job runs, the summary field exists, but nothing reaches Telegram.

Root cause

The announce agent is a separate LLM call that receives the cron job's summary as input. When that summary is empty or contains only a preamble ("Let me execute the digest task..."), the announce model has nothing to forward. It finishes instantly because there's no real work to do.

The problem is upstream. The cron agent produced garbage output, and the announce agent correctly identified it as not worth sending.

Why the cron agent produces empty output

In most cases: thinking mode. OpenClaw auto-enables thinking for models that support it. With thinking: low, the model performs all its work inside the <thinking> block. RSS scanning, article filtering, summary generation, formatting: all internal. The text response comes back empty or with a fragment like "I'll start by checking the feeds..."

OpenClaw captures only the text response as the cron summary. The thinking block is discarded.

Fix

Disable thinking for cron jobs. In your OpenClaw config:

{
  "agents": {
    "defaults": {
      "heartbeat": {
        "model": "deepseek/deepseek-chat",
        "thinking": "off"
      }
    }
  }
}

The key setting is "thinking": "off". Not "low." Not "minimal." Off.

With thinking enabled, my cron jobs averaged 88 seconds and produced zero deliverable output across five test runs. With thinking off, the same job ran in 30 seconds and delivered six articles to Telegram on the first attempt.

Verification

After the fix, the announce agent should run for 5-15 seconds (actual LLM inference time) instead of <1 second. Check your logs:

[announce] completed in 7200ms    ← working
[announce] completed in 557ms     ← still broken, check summary content

WORKFLOW_AUTO.md phantom file

Symptom

Every 15 minutes, the heartbeat agent tries to read a file called WORKFLOW_AUTO.md. The file doesn't exist. Logs show repeated ENOENT errors:

[heartbeat] tool_call: read_file("WORKFLOW_AUTO.md")
[heartbeat] error: ENOENT: no such file or directory

Worse: the agent leaks its internal control tokens to Telegram. Users receive messages containing raw markup like <｜tool▁calls▁begin｜> and <｜tool▁calls▁end｜>.

Root cause

This is a DeepSeek hallucination. After several heartbeat cycles, the model starts "remembering" a workflow file that was never part of the workspace. The hallucination is persistent: once it appears, it recurs every heartbeat cycle because the model's context accumulates previous failed attempts, reinforcing the false belief that the file should exist.

The control token leak happens because OpenClaw doesn't strip model-native tokens before delivering messages. DeepSeek uses custom delimiters (<｜tool▁calls▁begin｜>) that differ from OpenAI-style function calling. When the model's reasoning spills into the text response, those tokens pass through to Telegram unfiltered.

Fix

Two changes are needed.

1. Use isolated sessions for heartbeat/cron.

{
  "agents": {
    "defaults": {
      "heartbeat": {
        "session": "isolated"
      }
    }
  }
}

Isolated sessions prevent context accumulation across heartbeat cycles. Each run starts fresh, so the hallucination can't compound.

2. Add explicit file constraints in SOUL.md.

## File Access Rules

Only read files that exist in the workspace root:
- HEARTBEAT.md
- SOUL.md

Do not attempt to read any other files. If a file is not listed above,
it does not exist. Do not guess filenames.

This doesn't guarantee the model won't hallucinate (no prompt does), but it reduces the frequency by giving it a concrete, short whitelist to follow.

If you already have the problem

Kill the OpenClaw process and restart with --session isolated. The accumulated context causing the loop lives in the session state. A fresh start clears it.

Cron job says "delivered: true" but Telegram is empty

Symptom

The cron job completes. Status shows delivered: true. Nothing arrives in Telegram. The system reports success for an operation that produced zero output.

{
  "status": "completed",
  "delivered": true,
  "summary": ""
}

Root cause

delivered: true means "the announce agent ran without throwing an error." It does not mean "a message was sent to Telegram." An announce agent that receives an empty summary, decides there's nothing to send, and exits cleanly is marked as delivered.

This is the same upstream issue as "no reply from agent." The delivery status reflects process completion, not message arrival.

Diagnosis

Check the cron job's summary field in logs (DEBUG level):

grep -A5 "cron.*summary" ~/.openclaw/logs/agent.log

If the summary is empty or contains only a preamble, the cron agent's thinking mode is eating your output. See the fix in the "No reply from agent" section above.

If the summary contains actual content but Telegram still receives nothing, the announce agent model may be too small to process it. The announce model is hardcoded to the primary default model. You cannot override it with agents.defaults.announce.model (that key is silently ignored). If your primary model is a small one (Mistral Small, Phi-3, etc.), it may not produce useful announce output from a long summary.

Fix

Disable thinking mode on the cron agent (see above).
Set a capable primary model or accept that the announce agent inherits it. If you use a small model for chat, you'll need to make the heartbeat model your primary and use a routing rule for chat instead.
Don't trust the status. Verify delivery in Telegram after every config change. The only reliable delivery confirmation is the message appearing in the chat.

Dual-model configuration

Most of these problems share a root cause: using a single small model for everything. OpenClaw routes chat, heartbeat, cron, and announce through the same model by default. A model that's fine for chat will fail at scheduled tasks.

Minimum viable setup:

Agent	Model	Why
Chat	Small (Mistral Small 3.2, 24B)	Fast replies, low cost
Heartbeat / Cron	Large (DeepSeek Chat v3.1, 685B MoE)	Needs to follow multi-step tool pipelines
Announce	Inherited from primary default	Cannot be configured independently

Config:

{
  "model": "mistralai/mistral-small-3.2",
  "agents": {
    "defaults": {
      "heartbeat": {
        "model": "deepseek/deepseek-chat",
        "thinking": "off",
        "session": "isolated"
      }
    }
  }
}

Cost on OpenRouter for a daily digest: ~$0.03/day. The 24-hour deployment that produced 16 incidents cost $1.50 total, most of it from a retry loop on the small model.

Quick reference

Problem	Cause	Fix
"No reply from agent"	Thinking mode eats cron output	`"thinking": "off"`
WORKFLOW_AUTO.md loop	DeepSeek hallucination + context accumulation	`"session": "isolated"` + SOUL.md whitelist
`delivered: true`, nothing sent	Status tracks process, not delivery	Fix upstream (thinking off) + verify in Telegram
Control tokens in Telegram	Model-native tokens not stripped	Switch to isolated sessions, add SOUL.md constraints
271 spam messages	No retry limits + small model in failure loop	Use large model for cron + set API budget cap
Cron doesn't fire on schedule	Small model can't compare timestamps	Use large model for heartbeat

All issues documented with full incident logs in Deploying OpenClaw: 16 Incidents, One Day, $1.50.

Originally published: OpenClaw Troubleshooting: 'No Reply from Agent,' WORKFLOW_AUTO.md, and Silent Delivery Failures — Alex Rezvov's Blog

Forem: Alex Rezvov

How to Overcome Internal Doubts After Making Decisions

PeopleManagement #LeadershipConfidence #DecisionMaking #OvercomingDoubt #TeamMotivation #EffectiveLeadership #SelfTrust

LinkedIn Sales Navigator: The Tool We Need, Not the One We Have

First Task: Finding Explicit Needs

Second Task: Analyzing User Behavior

Third Task: Predicting Unconscious Needs

Conclusion

How We Helped a Client Regain Control of Their Business

How It All Began

The Development Phase

Creating a Transitional Solution

How We Gathered Data

Securing the Website

Fast Launch

Transition to the New Version of the Site

Phase Two: Building a Complete System

Technology and Features

Advantages of the New System

Lessons We Learned

You Pressured a Contractor on Price: Consequences

Reserved Margin for Negotiation

Contractor Resources Are Idle

Contractor Manipulates Project Estimates

When Contractors Manipulate Costs to Win the Project

How to Respond to Manipulative Contractors

A Word to Manipulative Contractors

The Contractor Failed to Protect Their Interests

When Inexperience Leads to Unrealistic Estimates

Possible Outcomes When the Budget Runs Out

What to Do in This Situation?

Other Scenarios

Founder Mode — A New Name for Micromanagement?

Is Founder Mode Just Micromanagement Rebranded?

Why It’s Not Micromanagement

Why It Could Be Micromanagement in Disguise

FounderMode #Micromanagement #Startup #TeamManagement #StartupCulture

Resolving Architectural Conflicts in Development Teams

When to Take Action?

If the Conflict Stays Professional

Architectural Committee: A Solution for Larger Teams

If the Conflict Turns Personal

Five Levels of AI-Agent Adoption in Software Development Teams

Where this comes from

The five levels

L0. Reference mode

L1. Agent babysitting

L2. Agent with rules

L3. Agent with tooling

L4. Agent with SDD

L5. Autonomous agents

What to take away from this

The Role of a Team Lead

The Team Lead: A Versatile Role

Why Do Perceptions of a Team Lead Differ?

What Is the Core Role of a Team Lead?

What Must a Team Lead Do?

Leadership

Team Competence

The Professionalism of a Team Lead

What Could Go Wrong?

Estimating Work

Planning and Task Distribution

Team Dynamics

Conclusion

Discussion

Tags

Tracking Efforts in a T&M Project Using Google Sheets

Setting Up a Tracking System

Creating Timesheets

Creating a Client Report

Creating an Internal Report

Closing a Payment Period

Payment Period in Timesheets

Payment Period in Reports

Finalizing the Invoice

Payment Process

Advantages

Flexibility

Access Control