From developer to team lead to company co-founder — throughout my journey in IT, I've had an inside look at how very different teams operate. Whether in tiny three-to-five-person startups or sluggish enterprises, the same systemic mistake keeps repeating: management completely ignores the basic psychology of engineers.
Not long ago, I discovered the SCARF model (developed by David Rock). It's grounded in neuroscience: our brain perceives social threats in the workplace — such as criticism or micromanagement — in exactly the same way it perceives a physical threat to survival. The fight-or-flight response kicks in, and cognitive abilities plummet. Conversely, in a safe and respectful environment, an engineer's brain operates at its peak. That's precisely where unconventional architectural solutions and breakthrough ideas are born.
Let's break down the five elements of the SCARF model using real-world examples from IT practice: how we kill team motivation with our own hands — and how to fix it.
Status — A Sense of Professional Significance
In IT, status is rarely measured by the size of your office or a fancy job title. For an engineer, status is first and foremost the recognition of their technical expertise, their colleagues' respect for their code, and the ability to influence architectural decisions. Every specialist wants to feel their professional worth. When management or peers question that expertise, dismiss ideas, or criticize publicly, the brain perceives it as a direct threat. Even a minor but public humiliation or dismissal can instantly crush the motivation of even the strongest senior engineer, driving them into a defensive shell.
What destroys it:
- Code reviews turned into a competition of "who can humiliate whom more elegantly."
- Micromanagement and architectural decisions handed down from above with no room for discussion.
- Feigned attention: an engineer's idea is formally heard but effectively ignored.
What helps:
- Constructive code reviews: discuss the logic and the code, not the person. Focus on why it can be done better.
- Consistently involving the team in product and technical decision-making.
- Public recognition of each person's real contribution to the product's success.
Certainty — Predictability of the Future
Our brain expends an enormous amount of energy processing uncertainty, and for engineers — who are accustomed to thinking in structured ways — this is especially acute. The most vivid example of violating this principle is "Brownian motion," commonly seen in startups or under weak project management. Today we're sprinting in one direction, tomorrow we do a full 180-degree pivot, and everything "needed to be done yesterday." Living in a perpetual firefighting mode with no clear direction strips people of the ability to properly design solutions, creates chronic anxiety, and leads to burnout faster than any amount of overtime.
What destroys it:
- Vague, contradictory, and constantly shifting requirements.
- Sudden priority changes with no explanation from the business side.
- Tasks in the vein of "just do it" — stripped of context and end goals.
What helps:
- Measurable goals and a transparent roadmap for a foreseeable period.
- Honest communication around changes. If uncertainty is unavoidable, give the team as much information as possible about why it's happening.
- Understanding of business value: the team should always know why a specific task is being done.
Autonomy — Control Over One's Own Work
This is perhaps my "favorite" point, because this is where most managers break down. There is no better way to destroy initiative than to hire expensive, smart experts — only to then control their every step as if they were in kindergarten. Engineering is a creative problem-solving process that requires freedom of thought. When leadership doesn't trust the team, dictates not only what to do but how to do it, imposes tools, and demands reports for every little thing — employees simply disengage. They turn into obedient "task instruction executors," shifting all responsibility for outcomes onto the person who handed down those instructions.
What destroys it:
- Micromanagement. If you think you're just "keeping your finger on the pulse" — chances are you're already suffocating your team.
- Total control that kills any freedom in organizing the workday or choosing approaches.
What helps:
- Freedom to choose tools and technical solutions within reasonable boundaries.
- Proper task-setting: focus on the outcome ("what needs to be achieved"), not the process ("how exactly you should do it").
- Basic managerial trust in your people — the hardest thing to give, but the most important.
Relatedness — Psychological Safety
The idea that engineers want to sit in a dark corner and not talk to anyone is a myth. We are all social beings who need a sense of belonging. This isn't about becoming best friends outside of work, and certainly not about the toxic mantra of "we're a family" (families, as we know, don't lay people off). It's about basic psychological safety — creating a work environment free of any form of bullying or pressure. Where a person isn't afraid to ask a question. Where they can honestly say, "I made a mistake, production is down, I need help" — knowing that what follows will be a collaborative effort to fix the problem, not a public flogging.
What destroys it:
- A callous corporate environment, blame culture, and punishment for bugs.
- Detached leadership, condemnation of mistakes, and disregard for the human factor.
- A complete absence of supportive informal communication within the team.
What helps:
- Normalizing mistakes. A mistake is part of the learning process and an opportunity to improve the system — not grounds for a penalty.
- Empathetic and open informal communication.
- A culture of mutual support, where asking for help isn't shameful — and receiving it is normal.
Fairness — Fair Rules of the Game
Engineering culture is deeply rooted in logic and cause-and-effect, which is why engineers have an exceptionally keen sense of fairness. The most dangerous thing here is that they rarely come to make a scene: if their sense of fairness is violated, they simply go quiet, lose motivation, and start quietly looking for another job. Lack of transparency in promoting certain employees, a clear mismatch between effort invested and reward received, broken verbal agreements — all of this acts like poison. Even if the company's processes look great on paper, hidden unfairness completely destroys trust.
What destroys it:
- An opaque system for making management decisions (including promotions).
- Different rules of the game for "favorites" versus everyone else.
- Management breaking previously reached agreements.
What helps:
- Clear, open, and documented decision-making rules.
- Uniform standards for everyone — no exceptions for "stars" or leadership.
- Strict and honest adherence to all agreements made.
Conclusion: The Cost of Management Mistakes
To wrap up, I'd like to share one observation from practice.
When a company hits a crisis, management often instinctively shifts into total-control mode. Micromanagement begins, developers become scapegoats, and management's own failures are completely ignored.
What happens to engineers' brains according to the SCARF model? They switch to "defense mode." The team stops proposing creative ways out of the crisis, because any initiative becomes unsafe. The situation only gets worse.
To sum it up: an engineer working in a safe and mutually respectful environment is capable of working wonders for the business — or at the very least will give it everything they've got. An engineer squeezed in the vice grip of micromanagement and anxiety won't produce anything good. Someone else will have to work the miracles and save the company.
How does your company handle autonomy and predictability? Which of the five SCARF elements is most commonly violated in the teams you've worked with? Share your thoughts in the comments.