Diego's Manifesto

Why this manifesto

I wrote this manifesto to bring together how I think teams should work inside a company. I mainly have engineering teams in mind, because those are the ones I know best, but I think most of what is here applies to any team where several people have to coordinate.

Some of what I write comes from things I have seen go wrong. To me, they were mistakes, though I understand other people may see them as just a different way of managing a team. This is not a description of a perfect company. It is a set of principles that I believe help teams stay healthy over time.

It also has a practical purpose: I want anyone reading it to understand how I think about leadership, collaboration, and work culture, so both sides can honestly judge whether there is a real fit before committing. These are ideas I have carried with me for years, and experience has only reinforced them.

1. Respect #

Respect is probably the most important point in this manifesto. Almost everyone agrees with it in theory, but in practice respect gets broken in many ways. You do not need to insult someone to disrespect them. More often, respect breaks down through smaller, more frequent gestures, especially under tension.

Mistakes I have seen

Complaining about a decision without offering real arguments. Throwing out negative comments that do not help solve anything. Walking away from a conversation once someone pushes back, as if it is no longer worth closing properly.

Giving harsh criticism in public instead of speaking in private. Dismissing someone's work with a label instead of useful critique. Turning experience into a permanent position of superiority. If someone says something you did bothered them, ignoring it or refusing to apologize.

The consequences

Each of these things may seem small on its own. But when they accumulate, they erode trust and create an environment where people stop engaging honestly. People become defensive, fewer ideas get shared, and conflict stops being resolved and starts simply being avoided.

Over time, the person on the receiving end starts justifying every decision before anyone asks. They stop experimenting, stop taking healthy risks, and get stuck in a cycle of criticism and self-protection that drains both sides.

How I think it should work

Respect also means repair. If someone tells you that something you did bothered them, acknowledge it and apologize. You do not need to agree with their full interpretation to understand that the damage is real, and that ignoring it makes the relationship worse.

Respect also means staying engaged in disagreement honestly. If you disagree with a decision, explain why with real arguments. If someone pushes back on your idea, do not disappear. Reply, reconsider, or refine your position. If someone repeatedly drops out halfway through an important discussion, that can be experienced as disrespect or disinterest, even if bad intent is not always the explanation.

And when tension is high, pause before you answer. Respect is easiest to break right when it matters most.

2. Freedom to speak up #

Everyone on a team should feel free to share an opinion, question a decision, or suggest a different way forward, without their title or level turning them into a spectator.

Mistakes I have seen

I have worked in places where people who tried to improve something were shut down immediately. They were told "that is not your business", "we do it this way because I said so", or simply "we are not doing that, end of discussion". No explanation, no context, no room for dialogue. Just authority used as an argument.

The consequences

When people learn that speaking up only leads to being dismissed or put back in their place, they stop trying. The team loses ideas, loses honesty, and starts operating in silence. Decisions get worse because nobody challenges them anymore. The people with the most to contribute either disengage or leave.

How I think it should work

When someone says "I think we could do this another way", they deserve more than a flat no. If the idea does not work, explain why. If they are missing context, share it. And if they still believe their approach is better, ask them to turn it into a short proposal with pros and cons and review it properly. People do not need to win every argument, but they do deserve a real answer.

3. Safe channels for speaking up #

In any team, some conversations only happen if there is a safe place for them. Salary concerns, friction with a colleague, disagreement with a decision, or concerns about how someone behaves do not usually come up naturally in a group meeting or a Slack channel. If there is no clear place for them, they either stay unsaid or come out when it is already too late.

Mistakes I have seen

Teams with no 1:1s, no retrospectives, and no anonymous way to raise concerns. Everything was supposed to flow through informal conversations, but sensitive topics rarely surface that way. People accumulated frustration until they exploded or simply left.

I have also seen the opposite problem: spaces that exist on the calendar but not in reality. 1:1s where the leader is rushed, cuts you off, does not let you fully explain yourself, or even talks to you while driving with the call on speakerphone. Formally there is a channel. In practice, there is no listening.

The consequences

When there are no safe channels, or when those channels exist only on the surface, problems grow in silence. People stop raising concerns because they do not know where or how, or because they sense that nobody actually wants to hear them. By the time someone finally speaks, the damage is already done: someone has burned out, a relationship is broken, or a bad decision has gone too far to reverse easily.

How I think it should work

Teams need real, structured spaces for honest communication. Anonymous channels so people can talk about decisions, team dynamics, or leadership without fear. Regular 1:1s to talk calmly about growth, compensation, concerns, and friction. Retrospectives to review what worked and what did not.

Not everything has to be anonymous, but it does need to be safe. If speaking up could cost you standing, peace of mind, or your relationship with your manager, it is not really safe. And if the other person is not giving you real attention, it is not safe either. The point of these spaces is to give people somewhere to say hard things before they resign themselves, explode, or leave.

These are not extras. They are the minimum infrastructure of a team that takes communication seriously. Without them, you are not making important things sayable. You are just hoping they come up on their own.

4. Shared responsibility for alignment #

It is impossible for everyone to agree on every decision. That is normal. The problem is not occasional disagreement. The problem is turning disagreement into the team's default state. There is a big difference between disagreeing on a minor decision and having half the team pushing against decisions that really matter.

Mistakes I have seen

I have worked in teams where more than half the engineers were not aligned with the decisions being made by the person responsible. Leaders who say "I have more context" without actually sharing that context. Leaders who decide in isolation and expect the team to follow without asking questions.

I have also seen decisions made from above that had a direct impact on people's work or day-to-day reality without involving them beforehand. They were executed first and, at best, explained later, once there was no real room left to influence them.

The consequences

Having people row in a direction they do not believe in creates a lot of friction. It leads to tension with the decision-maker, demotivation, and eventually exhaustion. Teams that are pushed without understanding become dependent. They stop thinking for themselves and start asking permission for everything.

People stop pushing back not because they agree, but because they assume it is pointless. And when that happens, the team stops being a group that thinks and becomes a group that complies. On top of that, when people are only involved at execution time, they start to feel they are not really part of decisions that directly shape their own work.

How I think it should work

Alignment does not mean everyone gets the option they wanted. It means people understand the decision well enough to support it honestly, even if they would have chosen something else.

The person making the decision has a responsibility to build that alignment, and the team has a responsibility to help make it possible. There may be cases where alignment is not fully reached, but that should be exceptional, not the normal way of working.

If a decision is going to directly affect a team's work, timelines, or day-to-day reality, it is worth listening to the people affected before making it. Listening does not mean giving up the decision. It means giving people a real chance to provide context, point out risks, and surface effects that may not be visible from above.

Leaders should avoid deciding in isolation whenever possible. I have changed my mind completely more than once after listening to other people, and I see that as a strength, not a weakness. There is almost always someone you can use as a sounding board: another engineer, another leader, someone from another team, or simply someone who helps you see the blind spots in your reasoning.

Sometimes the best move is to widen the conversation. You have to communicate what matters more than once, assume other people do not have your context, and avoid assuming bad intent when confusion is a much more likely explanation. Without that context, alignment is impossible.

5. Honesty in leadership #

A leader does not need to have every answer, but they do need to avoid lying. If they do not know something, they should say they do not know. If they cannot promise something, they should not promise it. Honesty is not optional. It is one of the foundations of trust.

Mistakes I have seen

I have seen people say things that were simply not true just to close an uncomfortable conversation or buy time. Things like presenting equity, compensation, or future changes as if they were already secured when they simply were not. I have also seen commitments made around salary or promotion that did not actually depend on the person making them.

Sometimes the lie is less direct, but close enough: selling certainty where there is none, letting someone walk away believing something you know is unlikely to happen, or using a half-truth to avoid a difficult conversation.

The consequences

When someone discovers they have been lied to, it is not only that conversation that breaks. The credibility of the leader breaks with it. From that point on, every explanation is heard with suspicion, every promise gets discounted, and the team starts interpreting far more than it hears.

That creates cynicism, distance, and disengagement. It is especially damaging when it affects sensitive matters, because people feel their trust has been used against them in decisions that shape important parts of their professional lives.

How I think it should work

If you do not know something, say you do not know. If you cannot share something yet, say you cannot share it yet. If something depends on someone else or on a decision you do not control, explain it that way. An uncomfortable or incomplete truth is better than a reassuring answer you made up.

A leader should only commit to things they can genuinely stand behind. And if they make a mistake or gave someone the wrong impression, they should correct it quickly and own it clearly. People tolerate an honest limitation much better than false certainty.

6. Clear priorities and planning ahead #

A meaningful part of team exhaustion does not come only from workload. It also comes from working without a clear direction. Not knowing what matters now, what the product will need in a few months, or which problems are quietly growing creates a constant feeling of being late.

Mistakes I have seen

I have seen teams stuck in constant reactive mode, responding only to whatever feels urgent and just trying to survive the week. Engineers who did not know what the real priority was, what they would be building in the coming months, or where the team was heading.

I have also seen obvious problems left to grow for too long: parts of the product that would scale badly, fragile dependencies, accumulated technical debt, or processes that were already showing signs of getting stuck. Because they were not exploding today, they were left for later.

The consequences

When a team works like that, it enters a constant reactive cycle. It applies more and more patches, understands less and less of the purpose behind the work, and lives with the feeling that nothing ever gets properly sorted out.

Problems also get more expensive the longer they are postponed. What could have been solved with attention and some breathing room ends up demanding much more energy, more rush, and more compromise. That leaves the team even more overwhelmed when it comes to anticipating the next thing.

How I think it should work

A team needs to know what matters now, but also what comes next. People should understand the current priorities, the direction of the next few months, and the reasons behind both. That kind of clarity creates focus and also calm.

Planning ahead is part of the work too. You need to look closely at which current problems are growing, which needs are likely to appear soon, and which parts of the system or the product may break if they keep being ignored. Not to become obsessed with the future, but to stop arriving late all the time.

That requires reserving some capacity for prevention, preparation, and cleanup, not just for reacting. When leadership, product, and engineering do this well, the team stops living in firefighting mode and can start building with more judgment and less wear.

7. Look for causes, not culprits #

In companies, problems are rarely the fault of one person alone. When someone immediately starts looking for a culprit, that should raise alarms.

Mistakes I have seen

Pointing at one person instead of looking at the real cause. Sometimes there is individual responsibility, of course. But most of the time the underlying issue is also a weak process, missing safeguards, unclear context, weak review, bad communication, or a system that made the failure too easy to reach.

The consequences

At best, blaming gives someone a place to dump frustration. At worst, it creates a chain of damage. The underlying problem remains, so the same failure is likely to happen again to someone else. The person who was blamed ends up working from fear, and that fear spreads quickly through the rest of the team.

People who make decisions out of fear stop taking healthy risks, stop asking questions, hide uncertainty, and start acting to protect themselves instead of improving the work. That is how teams become slower, less honest, and more fragile.

How I think it should work

Teams should focus on process and learning. Postmortems matter. Looking at systemic causes does not remove individual responsibility. It means responsibility should be examined with context, not used as a shortcut to end the conversation.

The useful first question is not "who failed?" but "what conditions made this failure likely, and what are we going to change so the next one is less likely and less costly?" Failures are natural. The naive part is expecting a system where they never happen.

8. Early detection of team strain #

Safe channels are not enough on their own. Leadership and HR also need signals that help them detect strain before the team reaches its limit. I do not mean spying on people. I mean getting there early enough to help.

Mistakes I have seen

I have worked in startups where there were no 1:1s, no useful reviews, no satisfaction surveys, and no mechanisms for HR to see what was happening. Some leaders were doing a poor job, some teammates were already burned out, and the company still failed to notice.

Another common failure is saving important feedback for formal reviews. If someone hears an important criticism or an important piece of recognition for the first time during a review, the system has already failed.

The consequences

When a company only reacts once someone is already at their limit or already thinking about leaving, it is already late. By then motivation, knowledge, and time have already been lost, and the problem usually affects more than one person.

How I think it should work

I believe in combining voluntary channels with structured signals: regular 1:1s, reviews that actually help, satisfaction surveys, anonymous feedback, and leaders who pay attention to changes in energy, tone, or motivation. The goal is not to bureaucratize follow-up. It is to make problems visible while there is still time to correct them.

But collecting signals is not enough. You also need to read them and act. If an anonymous survey shows repeated strain, if several people describe the same problem, or if a team's tone shifts in a sustained way, leadership and HR should know quickly and move.

9. Timely recognition and compensation #

Recognition matters, but a pat on the back does not go very far. Saying "good job" is the first step, not the last.

Mistakes I have seen

Waiting for someone to ask for a raise is already too late. By then they have probably been thinking about it for months, and may already be looking elsewhere. The same applies to overtime: waiting until the hours are already done and people start complaining before deciding how to compensate them.

Some leaders try to save five or ten thousand by keeping pay just low enough that the person hesitates before leaving. I have even seen raises renegotiated downward just to make the budget work. That kind of move destroys trust faster than almost anything else.

The consequences

When recognition arrives too late, people have already made up their mind. They have spent months feeling undervalued, and by the time the company reacts, loyalty is already broken. They start looking elsewhere, and the best people leave first because they have the most options.

How I think it should work

A leader who is paying attention can get ahead of it. They can say: "I can see the effort you are putting in. I believe you have earned a raise, and when this is over I am going to make that case clearly." Hearing that before having to ask changes the relationship with the company completely. The key is anticipation.

If a major delivery is coming and extra hours will be needed, say it beforehand. Explain what is expected, how long it will last, and how it will be compensated. Asking for exceptional effort without being clear about the return is a fast way to burn people out.

Not everyone wants to engage in the same way, and that is perfectly legitimate. But when someone carries more responsibility, pushes harder, or takes care of the team beyond what is required, it is worth recognizing it early and visibly, not months later and reluctantly.

10. Salary transparency #

Salary is one of the easiest places to hide arbitrary decisions. It is also one of the clearest ways a company can show whether it genuinely values someone. That is why silence almost never protects anything. It only postpones a conversation that will happen anyway.

Mistakes I have seen

Many companies do not want employees talking openly about pay. I understand why they think it might create tension, but many times what they are really trying to avoid is having to explain why one person earns more than another. The same applies to new hires: if someone joins with a much higher salary, there should be a clear and explainable reason.

The consequences

Telling people not to talk about salary does not solve anything. Sooner or later people talk anyway. When that happens in private, they find differences without the context behind them. Confusion and frustration grow, leaders often do not see the damage early enough, and the team fills the gap with assumptions.

That gap easily turns into distrust, resentment, and exhaustion. And once the team starts reading the numbers as arbitrary or driven by favoritism, rebuilding credibility becomes very difficult.

How I think it should work

I am not saying every person's exact salary has to be public. But I do believe people should have a clear idea of the salary bands for each role and the criteria that allow movement within them. That feels like a reasonable middle ground.

If the company is in a healthy financial position, it should pay its people in a clearly competitive way, and above market when it can genuinely sustain it. People who are already inside have something an external candidate does not: deep knowledge of the codebase, the product, the team, and how the company works. That matters too. The clearest way to show an employee that you value them is to pay them in a way that reflects what they contribute.

Talking about salary should not be taboo. It helps people understand where they stand, how far they can go, and what it takes to get there. It gives perspective, lowers anxiety, and stops everyone from having to guess the rules of the game.

Instead of forcing people to guess, talk about it directly. Share market data, explain why a given offer or raise has a given number, and let people say what level of pay would make them feel comfortable. Salary, role, and performance should not be managed as separate systems. When they are, people fill the gaps with assumptions, and that is where distrust starts.

11. Freedom with responsibility, not control #

I believe people should have real room to organize their work and decide when to do it in the way that lets them perform best. Freedom is not disorder. Freedom requires responsibility, especially because in engineering your work often has a direct impact on other people's work.

Mistakes I have seen

Controlling schedules, presence, or ways of working as if that guaranteed productivity. Expecting everyone to function well under the same pattern instead of assuming that different people do their best work at different times and need some room to organize themselves.

I have also seen the opposite error: using freedom as an excuse not to think about other people's time. For example, handing a task to someone at the end of the day when you could have given it to them first thing in the morning. Formally you did your part, but in practice you shaped someone else's day for no good reason.

The consequences

Control solves very little. What it usually does is push people into working in an environment where they are uncomfortable, where they spend energy fitting the rule instead of doing strong work. That creates discomfort, worse motivation, and less real productivity.

And when freedom is exercised without considering its impact on the rest of the team, coordination deteriorates. People start blocking each other, flow gets worse, and friction appears that often has less to do with the work itself than with not respecting other people's time properly.

How I think it should work

The healthy version is real autonomy to organize the work, as long as there is responsibility, visibility, and good coordination. If someone is tired, it is often better for them to rest, even sleep for a while, and come back later with more clarity and energy. Forcing someone to stay visibly present when they are not in good shape does not improve the work. It usually makes both the experience and the outcome worse.

But that freedom comes with a clear condition: think about the impact on others. If your work unblocks someone else, deliver it as early as you reasonably can. If you know someone depends on something from you, give them context, notice, and room to plan. It is not only about organizing yourself well. It is also about not organizing yourself at the expense of other people's time.

That is also a form of respect. The virtue is not in controlling people, and it is not in doing whatever you feel like without looking around. It is in having the freedom to work in the way that suits you best while still protecting the rhythm and time of the people around you.

12. Learning is part of the job #

Professional curiosity is not a nice-to-have. In engineering, it is part of doing the job well. Staying current, exploring new ideas, or building side projects is not separate from the value a person brings. It is often part of that value.

Engineering changes constantly, and the rise of AI has accelerated that pace dramatically. Technologies that looked stable a year ago may already be outdated. In that context, making time to learn and explore is not a luxury. It is a necessity.

Mistakes I have seen

I have worked in companies where the only thing that mattered was output. No time for learning, no budget for growth, no room to experiment. Everything was urgent all the time.

The consequences

When everything is urgent all the time, people stop improving. Their standards drop, they focus only on surviving the week, and they lose the space needed to learn, experiment, and think carefully about the work. That may produce output for a while, but it does not build strong engineers or strong teams in the long run.

How I think it should work

Good companies should protect that curiosity instead of squeezing it out of people. That means budget for certifications, time to investigate technical options, room to try new tools, workshops, and real knowledge sharing inside the team.

A strong engineering culture also shows up in daily habits: tests are part of the work, technical debt is made visible, code review is treated as a conversation, and knowledge is shared instead of hoarded.

Learning should not depend only on what people do at night or on weekends. A healthy company makes room for it inside the work itself.

13. What works can still be improved #

One of the easiest traps for a team is confusing "it works" with "it no longer deserves to be questioned." If something works, that is a good starting point, but not the end of the conversation. Teams that keep improving their systems, processes, and habits tend to stay sharper, move faster, and arrive better prepared when pressure appears.

Mistakes I have seen

I have met many people who reacted to any proposed change with "but it already works, why touch it?" as if revisiting a process, a tool, or a way of working were unnecessary risk instead of normal engineering hygiene.

Many times it really did work, but in a clumsy, slow, or fragile way. It could have been simpler, cheaper, clearer, or more scalable. The problem was not that improvement was impossible. The problem was not wanting to question the current state.

The consequences

When a team falls into that mindset, it becomes less adaptable over time. Friction gets normalized, inefficiencies settle in, and obvious opportunities to improve are left alone until the pain becomes too big to ignore.

That also leaves teams less prepared. If you only revisit something when it is already failing, every change arrives late and under pressure. Improvement stops being preventive and becomes reactive.

How I think it should work

Teams should review how they work with some regularity: processes, tools, rituals, handoffs, and technical decisions. Not everything has to change, but everything should remain open to being questioned.

The goal is not to touch things for the sake of touching them. The goal is to keep asking whether the current way is still the best trade-off. If something is already working well, great, keep it. But if it can become meaningfully simpler, faster, clearer, or more resilient, it is worth discussing.

That improvement mindset compounds over time. Teams that examine their habits without ego usually become more efficient, more prepared, and less likely to be surprised by problems that other teams only notice once they are already blocked by them.

14. Pragmatism over dogma #

Best practices matter. They usually exist for a good reason, and many of them prevent very real mistakes. The problem starts when they stop being seen as tools and start being treated as rules that must always be applied, regardless of context. At that point, the practice stops being good and becomes dogma.

Mistakes I have seen

I have seen people apply best practices automatically, as if departing from them were always a sign of poor quality. The pattern is especially common when someone has internalized them so deeply that they stop asking whether they are actually necessary in that specific situation.

A clear example is a database migration. In a startup, it may make sense to accept a planned production pause if that massively reduces complexity and allows the migration to happen now. Yet some people do not even put that option on the table. They jump straight to a much more complex, slower, and more expensive path simply because the "right way" would be to avoid downtime at all costs.

The consequences

When teams work like that, they make technical decisions without properly weighing their real cost. Timelines get longer, operational complexity increases, unnecessary risk is introduced, and the team can spend weeks or months protecting against a scenario the business may have been willing to absorb in a controlled way.

The problem is not choosing the more robust path when it is truly needed. The problem is failing to consider the alternatives at all because a rule has become untouchable.

How I think it should work

I think the main principle should be pragmatism. Best practices are guidance, not religion. You need to understand why they exist, which risk they reduce, and when that risk actually justifies the cost they introduce.

Obviously, this depends heavily on context. In a large company or a critical system, pausing production may be unworkable in many cases. But even there, that variable should still be allowed onto the table if the alternative means several more weeks of work and the need is urgent.

If you break a rule, the trade-off should be explicit: which risk is being accepted, who is accepting it, how it will be communicated, and how you would back out if things go wrong.

As long as there is a clear justification, a decision that breaks the rule can still be the right one. Breaking a rule is not always irresponsible. Sometimes the more irresponsible move is refusing to revisit the rule when the context clearly called for it.

15. Human skills matter as much as technical ability #

If AI makes pure technical execution easier, then what differentiates one person from another shifts more toward the human side. Being able to explain an idea, communicate clearly, be assertive, handle pressure, adapt to changing context, keep learning, and teach others is now a central part of the value an engineer can bring.

That does not make technical ability irrelevant. What changes is that technical ability alone distinguishes people less if it is not paired with judgment, collaboration, and maturity.

Mistakes I have seen

I have met highly technical people who still did a lot of damage on the human side. Some cases are obvious: they insult, threaten, look for someone to blame, or point at people instead of problems.

Other times the problem is subtler, and precisely because of that, easier to tolerate for too long. These are technically strong people who break the most basic form of respect: they correct from a position of superiority, make other people feel small, or turn normal mistakes into repeated small humiliations. Each comment on its own may not look dramatic. The pattern is what matters. That constant erosion slowly wears down the team's morale.

The consequences

That is why someone who is very strong technically can still do more damage than someone with less skill. If their interactions diminish everyone around them, the team becomes defensive, people share less, ask less, and dare less. You lose safety, honesty, and ultimately talent.

How I think it should work

The good news is that these skills can be developed. In my experience, a junior person with strong human skills can create value surprisingly quickly in the AI era. They ask better questions, use the tools better, and learn faster because they listen, compare perspectives, and stay open to correction.

Technical ability matters, of course, but it should not be used to excuse disrespect. Someone with technical room to grow but who is humble and collaborative usually learns. Someone brilliant who erodes the team week after week ends up costing more than they contribute. I would value those qualities at least as much as raw technical ability.

16. Respect and professionalism in hiring #

Good hiring starts with empathy. Treat people the way you would want to be treated when you are trying to find where you fit. A good interview is not an interrogation. It is a structured conversation where both sides are trying to understand whether there is a real fit.

Mistakes I have seen

Random questions, improvised interviews, and technical exercises that say little about the real job. Unreasonable response times, no room for the candidate's questions, and no final response. Processes run by people who do not understand the market, the technical context, or the business, and therefore make shallow decisions.

I have also seen people arrive late to interviews without warning, fail to show up because the person responsible did not even realize the interview was happening, or take an interview while driving with the call on speakerphone. Those details do real damage to a company's image because they send a very simple message: your time does not matter.

And the problem does not end when the interview does. The offer is part of the process too. Things like negotiating down by two or three thousand after the whole process leave a terrible impression and say a lot about how the company sees its relationship with people.

The consequences

If people leave your process feeling smaller, confused, or disrespected, then the company has already taught them something important about its culture. Bad hiring processes also lead to bad hires, missed good candidates, and a reputation that makes future hiring harder.

A badly handled offer works the same way. If the end of the process turns into a small move to shave a bit off the number, the candidate immediately understands what to expect later if they join.

How I think it should work

Every stage should have a clear purpose. Respect people's time, explain what you want to assess, keep response times reasonable, leave room for their questions, and always close the loop. And, of course, show up prepared and give the conversation your full attention.

Good hiring also means designing against bias. Use structured interviews, shared criteria, and written evaluations. Do not confuse similarity with quality, first impressions with evidence, or confidence with competence.

The offer should also match the tone of the process. If you make an offer, it should be serious, reasonable, and explainable. Negotiation can make sense, but not as a small opportunistic move to cut two or three thousand at the end.

The people who design and run the process need training too. Recruiters and interviewers should keep learning like any other important function inside the company.

17. Prioritize internal promotion #

Before hiring someone above the existing team, I think companies should first look at internal promotion. In many cases, that is the healthier starting point.

Mistakes I have seen

Always looking outside first when a new need appears. Hiring someone above the current team without explaining why. Adding several new people to the same team at once without a clear integration plan.

The consequences

If you always look outside first, people inside the company learn a very simple lesson: their growth is not the priority. Hiring above the existing team can create frustration, especially if the team does not understand why that person is coming in above them. Adding too many new people at once can break the team's rhythm, slow delivery, and hurt motivation.

How I think it should work

If the team already understands that a new role is needed, for example an architect, the situation becomes much easier to handle. If people understand the need, the scope, and the reason the role is not being filled internally, the environment stays much healthier. Another good step is to open the role internally first and see whether someone wants to try.

The important thing is not to act as if the current team stops existing whenever a new need appears. Consider them first. Give them context. Give them room to grow when possible. Even when the final decision is to hire externally, the process should make it clear that the team was respected.