Performative dev teams are blamed for slow delivery when the actual cause is an intake process with no ranking, no governance and no defense of the technical risk. The developer who says no is answering a question leadership never asked.
What Are Performative Dev Teams and Why Do They Get Blamed?
Performative dev teams are engineering groups blamed for slow delivery when the real cause is unstructured intake and weak governance between sales and technology. The label appears when a company treats any developer who asks for sequencing or risk assessment as an obstacle, and then measures that caution as obstruction.
The argument surfaced in a widely shared TikTok clip that the Mano Rage Show, a Brazilian weekly tech livestream, discussed in an August 2026 episode. The clip claimed the biggest enemy inside a company can be the IT department. The show's host and his commenters pushed back, and one comment drew the sharper line: calling IT the main enemy is a dangerous simplification, and the real problem is missing governance and communication between technology and strategy.
That distinction matters because the two complaints point at different owners. A developer who blocks every request is a personnel problem with a manager. A company that never ranks requests has a leadership problem that a developer cannot fix from inside a sprint.
The August 2026 episode framed this as gossip rather than reporting, so treat the clip itself as a talking point, not a study. The useful part is the mechanism it exposes: unranked ideas arriving at people whose professional duty is to keep production stable.
Why IT Becomes the Enemy in Sales-Led Companies
IT becomes the designated enemy when a company's headcount is weighted toward sales and outreach while the people responsible for shipping and support stay a small fraction of the team. In that structure every new idea outpaces the delivery capacity, and the developer who cannot fit it into the current sprint is the visible face of the gap.
The episode's host described a recurring shape: a boss has an idea in the shower, calls a meeting, and brings a request that is often poorly formed. Meanwhile the backlog already holds committed work. Research on interruption and task switching has long shown that context switching carries a real cost to focused work; the deeper problem is that the request was never ranked against existing work. See the American Psychological Association's overview of multitasking research for how switching between tasks affects attention and performance.
The episode's broader point is that the stakeholder rarely turns that anger on the situation. It lands on the messenger. A developer who explains that the request cannot be absorbed becomes the person who is 'blocking progress', even though no one has decided which committed work should be dropped.
A sales-led structure is not automatically broken. The risk is a company that measures its culture by visible energy: bells, stories, recordings, and meetings, while the operational team stays understaffed.
The Three Signals That Tell You It Is Theater, Not Delivery
Three observable signals separate a company with a delivery problem from one performing delivery: a sales team larger than the operating team, no owned tooling or onboarding function, and spending on AI tokens treated as a status symbol rather than a cost line with an owner.
The first signal is the ratio. The episode described a company with roughly 100 people selling and fewer than ten doing everything else. That is not proof of bad engineering. It is a warning that delivery capacity has no political weight inside the company, so its constraints get ignored.
The second signal is ownership of the basics. When no one owns onboarding, internal tooling, or the integration layer, those tasks land on whoever has time. Problems then surface as individual failures instead of system failures.
The third signal is status spending on AI. The episode mocked founders who brag about token bills as a badge of ambition. A token budget is a cost line. Bragging about it without measuring what it produced is the same behavior as bragging about a busy calendar.
How to Answer the 'IT Is the Enemy' Claim With Evidence
Answer the claim with evidence from your own systems: feature usage data, incident history, and a ranked request queue. The episode's host described using product events to show whether a feature someone championed was ever used, which turns a status dispute into a measurable question.
The sequence works in practice:
- Before the meeting, confirm whether the request already exists in the product. Several requests are re-proposals of shipped features no one remembers.
- Check whether the existing feature has usage events. A shipped feature with no recorded usage is a stronger answer than an argument.
- If the request is genuinely new, show the current sprint and ask which committed item should move. The decision belongs to the person requesting.
- Log the request with its expected outcome so the next meeting starts from a record, not from memory.
- Escalate only the prioritization conflict, never the personality.
None of those steps require a developer to win a debate. Each one moves the question from who is obstructive to what the company has decided.
There is a fair counterpoint, and the episode's commenters raised it. A developer can become a genuine obstacle by vetoing ideas out of stubbornness or by demanding process with no justification. The test is simple: can the developer explain the risk in terms a business person can act on? If not, the objection is friction, and it deserves to be treated as one.
Governance Is the Missing Layer Between Agile Rituals and Real Risk
Governance is the layer that decides which requests get funded, which risks get accepted, and who signs off, and it is the layer that most Agile ceremonies do not supply. Without it, sprints become a queue that anyone can bypass by asking loudly enough.
The episode spent time on a separate clip in which a bank executive complained that Agile methodology had been reduced to theater, complete with rigid 15-minute dailies and compulsory story points. That criticism deserves care. Agile and Scrum are not the same thing, and the failure described is a rollout problem rather than proof that iterative delivery cannot work. The Agile Alliance glossary defines the terms separately for anyone who needs the distinction in writing.
What the ritual critique actually points at is the same gap: ceremony without decision rights. A daily standup cannot resolve a conflict about whether the company should absorb a new request this week. Only a named owner, a documented risk acceptance, and a visible queue can do that.
Teams that lack that layer run on escalation, and escalation rewards whoever is loudest. The engineering group then looks like the department that says no, because saying no is the only control it has.
Where Gustavo Dev Doido and Crazystack Fit for Developers Building Real Skills
Brazilian developers who want delivery skills rather than ceremony can look to resources such as Gustavo Dev Doido, whose channel covers backend and TypeScript material, and the Crazystack program, which lists full-stack TypeScript training. Neither fixes a governance problem, but both build the kind of grounded technical judgment that makes a developer's objection defensible.
Technical depth changes how the 'IT is the enemy' conversation ends. A developer who can point to a concrete integration constraint, a security requirement, or a usage query is offering information. A developer who only says the request feels risky is offering a feeling, and feelings lose to a confident founder in any meeting.
The same logic applies to how training is packaged. A bootcamp or a structured cohort such as the Bootcamp do Dev Doido works when it produces artifacts a developer can carry into that conversation. A certificate alone does not.
One caution belongs here. Environment discussions can bleed into regulated deployments quickly. Local tooling, allowlists, and private infrastructure can support an air-gapped setup, but none of them alone establishes compliance with banking, health, or data protection rules. A bank is a security problem, not a methodology problem. Separating the two keeps an engineering discussion honest.
What to Do When Your Team Resembles the Warning Signs
If your team resembles the warning signs, the first move is to make the request queue visible and the second is to get a named owner for prioritization; without both, no amount of tooling will change the outcome. Changes you can start this week:
- Publish the committed queue. If everything is visible, a new request becomes a comparison rather than an interruption.
- Require a written request with an expected result. The episode's host put it plainly: formalize it in writing, then join the queue.
- Attach usage data to shipped features. A feature nobody uses answers future requests on its own.
- Name the risk owner in writing. If a stakeholder wants to accept a risk, the acceptance should have a name and a date.
- Track AI and infrastructure spend against outcomes. Cost without a measured result is a budget line, not a strategy.
None of these steps require the company to hire more people first. They change what information is available when the next unplanned idea arrives.
Progress on these points is uneven and slow in most organizations. A team that gets one of them working has more leverage than a team that argues about all of them at once.
FAQ
- What does 'performative dev team' actually mean? It describes an engineering group whose value is judged by visible activity rather than delivered outcomes. The label is usually applied by outsiders, and it often says more about a company's lack of governance than about the developers themselves.
- Is the claim that IT is the biggest enemy of a company supported by evidence? No. The claim circulated in a 2026 TikTok clip and represents one person's opinion. Commenters noted the more defensible diagnosis is weak governance and poor alignment between technology and business strategy.
- Does this mean developers are never wrong? No. A developer who blocks requests without a technical justification is creating friction, and the episode acknowledged that pattern directly. The useful distinction is whether the objection comes with a defensible reason the business can evaluate.
- Why do sales-led digital companies show this pattern more often? Companies built around courses, infoproducts and high-volume outreach tend to weight headcount toward sales, leaving engineering and operations understaffed. Developers in those companies face more unranked requests than their capacity can absorb.
- Can better Agile practice solve it? Only partly. Scrum and Agile define cadence, not decision rights. A fifteen-minute daily standup cannot decide which committed work gets dropped, so the prioritization conflict needs an owner above the team level.
- What is the single fastest change a team can make? Publish the committed queue and require written requests. A visible queue turns a confrontational request into a comparison between two pieces of work, which is a conversation the team can actually win.
- Where does this conflict with regulated-industry requirements? Financial and healthcare environments add security and audit obligations that no delivery method overrides. A bank release still needs risk acceptance and review, so speed claims in those settings have to be scoped to the controls in place.
- How does this relate to the training resources mentioned above? Resources like Crazystack and the Bootcamp do Dev Doido build technical depth that makes a developer's objection specific. They do not change a company's governance, and no course can substitute for a named decision-maker.
- Should developers always avoid being the blocker? No. Developers are accountable for production stability. The skill is blocking with evidence and offering an alternative, not avoiding the block entirely.
Turning Recorded Conversations Into Written Analysis
The night of the livestream, the argument about IT as the enemy and the counterargument about governance would each need their own meeting to replay. Writing them down is how they stay available.
If you have recorded discussions, interviews, or explanations that carry this kind of operational knowledge, you can run them through Skala Blog: paste a YouTube URL, transcribe the video, and generate a draft article you can edit and publish. The unfinished argument about who owns delivery risk becomes a document the company can actually use.
Skala Blog starts with your existing video. The finished article is still yours to review, correct and publish.