Diego's Manifesto

Why this manifesto

I wrote this manifesto because I have seen too many engineering teams drift into unhealthy cultures. When hierarchy, fear, and unspoken rules become normal, people stop speaking openly, decisions lose clarity, and the work suffers sooner or later.

This manifesto is my attempt to make explicit the kind of engineering culture I believe in: one where people can do good work, grow, stay motivated, and get help before they burn out. It is not a description of a perfect company, but of the principles that help teams stay healthy over time. Most of these ideas are not new to me. I have carried them with me for years, and with more experience behind me now, I feel even more confident saying that time has only reinforced them.

1. Every opinion deserves a real answer #

Everyone should feel free to speak, question a decision, or suggest a better way to do something, no matter their title or seniority. I have worked in places where people were told not to get involved, that something was not their business, or that "we are not doing that" was the whole conversation. That teaches people to stay quiet.

When someone says, "I think we could do this another way", they deserve more than a simple no. If the idea does not work, explain why. If they are missing context, give them the context. If they still think their idea is better, ask them to write 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.

Sometimes the best thing is to open the discussion to more people. Another engineer may explain the tradeoffs more clearly, or may see value in the first idea. The goal is not to shut people down quickly. The goal is to make better decisions while showing the same respect to everyone, from the most junior engineer to the most senior.

All of this comes down to communication. Good communication in technical teams is not a nice extra. Overcommunicate what matters, assume other people do not have your context, and do not assume bad intent when confusion is a more likely explanation.

2. Leaders must earn alignment #

A team should not be pushed in a direction it does not understand. If most of the team disagrees with a decision, saying "I have more context" is not enough. If people cannot see the reason, then the reason was not shared clearly enough.

A leader's job is not only to make the call. It is to explain the tradeoffs, answer questions, share the missing context, and do the work needed to align people. If a leader wants to move forward while most of the team still cannot understand the decision, that is not a team problem. That is a leadership problem.

I also think leaders should avoid deciding in isolation whenever possible. I have changed my mind 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 manager, someone from a different team, or simply someone who helps you see the blind spots in your own thinking.

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 choose something else. That is very different from a team that stops arguing because it thinks arguing is useless.

Good teams should not work by blindly following orders. People should understand the problem, the goal, and the reason behind the decision. Without that context, teams become dependent and end up asking permission for everything.

3. Blame fixes nothing, improve the process #

In companies, problems are rarely the fault of one person alone. When someone immediately looks for a guilty person, that should raise alarms. Most of the time the real issue is a weak process, missing safeguards, unclear context, poor review, bad communication, or a system that made the failure easy to reach.

Pointing at one person will not solve that. At best, it gives someone a place to dump their frustration. At worst, it creates a chain of damage. First, the underlying problem remains, so the same failure will probably happen again to someone else. Second, the person who was blamed is left working from fear, and that fear spreads fast through the rest of the team.

People who make decisions in fear stop taking healthy risks, stop asking questions, hide uncertainty, and start optimizing for self-protection instead of for the work. That is how teams become slower, less honest, and more fragile.

That is why I believe teams should focus on processes and learning. Postmortems matter. Looking calmly at what happened matters. Failures are natural, and expecting a system with no failures is naive. The real goal is to reduce how often failures happen, stop the same failures from repeating, and reduce the impact when they do happen.

4. No leader should be above feedback #

I have seen companies where engineering became a bunker. Nobody could go outside it. Everything had to go through the CTO. That kind of structure becomes a bottleneck very quickly, and it also makes problems at the top harder to see.

If people believe the person at the top of the hierarchy is not doing their job well, they need safe ways to say it. Without that, the company ends up protecting the role instead of fixing the problem.

Many people become managers without real training for it. Companies should not assume they will figure it out alone. They should support that transition, especially when technical leaders move into people leadership.

Sometimes the answer is not to remove that person, but to have an honest conversation and make it clear that the company has changed and the role has changed with it. This happens a lot with CTOs. The profile that fits an early company is not always the profile that fits the next stage.

That is hard to accept, but pretending it is not true is worse. Healthy companies create room for upward feedback and help leaders let go of responsibilities they are no longer the right person to carry.

5. You need real signals before people burn out #

Saying that employees should be monitored sounds wrong, but that is not what I mean. I do not mean spying on people. I mean having real ways to know how they are doing before they burn out. The goal is not to use that information against them. The goal is to help early, protect motivation, and keep the team healthy.

I have worked in startups where there were no 1:1s, no career plan, no performance reviews, and no real salary growth. Some leaders were doing a poor job. Some teammates were already burned out, which made the environment even worse. The most striking part was that HR did not know what was happening, and because of that the CEO did not know either.

The company survived because the product was good and because some of us decided to act before everything broke. That is not a healthy system. A healthy company should detect these problems earlier, not when people are already at their limit.

If nobody talks to people about their satisfaction, growth, or future until they are already thinking about leaving, the company is already late.

And even if you only look at this from the company's side, there is still a very practical reason to care. When people leave, the company loses knowledge, momentum, and a lot of time and money replacing them. People are not interchangeable parts, and turnover is much more expensive than many leaders want to admit.

Feedback should not be saved for formal reviews. If someone hears an important criticism or recognition for the first time in a performance review, the system has already failed.

That is why I believe in regular 1:1s, clear career paths, performance reviews that actually help, and spaces where people can speak honestly. A performance review is useful only if it reduces uncertainty, aligns expectations, and has real consequences for growth or salary. If it changes nothing, it is just process for the sake of process. Tools like Nailted can help, but the tool is not the point. The point is to make problems visible while there is still time to fix them.

People do not stay because of perks. They stay where they can learn, trust the team, work at a sustainable pace, and see what comes next. Motivation is not built with speeches. It grows from autonomy, learning, purpose, recognition, and real ownership.

People should have safe ways to speak, sometimes anonymously. They should be able to explain why they believe they deserve a raise. They should be able to talk about problems without feeling they are creating risk for themselves. Good leaders do not try to control employees. They try to support them and help them grow.

6. Reward people before they have to ask #

Recognition matters, but a pat on the back only goes so far. Telling someone "good job" is the first step, not the last. A leader who truly pays attention can go further: "I see what you are doing these days, and when this is over I am going to fight for a raise because you deserve it." That kind of sentence, said before the employee has to ask, shows something much more powerful than gratitude. It shows that the leader is paying attention and is willing to act.

Waiting for people to come and ask for a raise is already being late. By that point, they have probably been thinking about it for months, maybe even looking at other options. A good leader does not wait for that moment. They get ahead of it.

The same applies to overtime. If a critical delivery is coming and extra hours will be needed, say it in advance. Tell the team: "We may need some overtime for this, but we have already spoken with HR and this is how we are going to compensate it." Do not wait until the hours have been worked and people start complaining to figure out the compensation. That reactive pattern is one of the most common leadership failures I see. The key to all of this is the same: anticipate.

In most companies there are two kinds of profiles. Some people prefer to do their job well, keep things stable, and have a balanced life. That is completely legitimate. Others are more proactive, more invested, and tend to go beyond what is expected. Both profiles are valid, but the second group often creates more value over time, and they deserve to be recognized for it. Try to detect those profiles early and reward them, not just with money, but with clear signals that their effort is seen and valued.

If the company is in a healthy financial position, your employees' salary should be above market, not below or just at it. They already have something no external candidate has: deep knowledge of the codebase, the product, the team, and how things work inside the company. That knowledge has real value, and salary should reflect it.

When someone earns noticeably more than what they see in the market, they stop looking. They feel proud to work where they are, and they start recommending the company to others. That is the kind of loyalty you cannot buy with perks or speeches.

Some leaders try to save five or ten thousand by keeping salaries just low enough that the employee hesitates to leave. That is a serious mistake. I have even seen leaders renegotiate a raise downward by two or three thousand to stay within budget. That kind of move destroys trust faster than almost anything else.

Instead, ask your employees directly: what salary would make you feel comfortable? Then work on it together. Share market data with them. Ask them for data too: offers they have seen, or even selection processes they have participated in while working at the company. Let them share that without fear. HR often has salary bands already. Share that information with your employees instead of keeping it behind closed doors.

7. Salary transparency is healthier than silence #

Salary is one of the areas where companies are often less honest than they should be. Many companies do not want employees to talk openly about salary. I understand why they think it can create tension, but I often think they are really trying to avoid explaining why one person earns more than another.

I am not saying every employee's exact salary must be public. But people should have a clear idea of the range for each role. That is a reasonable middle ground. Regardless, telling people not to talk about salary does not solve anything. Sooner or later people talk anyway.

When that happens in private, people find differences without the context behind them. Then confusion and frustration grow. Leaders often do not see the damage early enough, and the team fills the gap with assumptions. That can easily turn into distrust, resentment, and burnout.

I have not worked at a company with fully public salaries yet, so maybe there are problems I have not seen. Still, for now I believe more transparency is healthier than forced silence.

The same applies to new hires. If someone joins a team with a much higher salary, there should be a clear reason. Maybe they bring skills, scope, or responsibilities that the current team does not have. If not, the difference will feel unfair.

Existing employees already have valuable knowledge of the codebase, the product, and the company's way of working. That value matters too. Salary decisions should reflect it, and leaders should explain them clearly enough to keep the team aligned.

Clear salary bands and clear promotion criteria make these conversations fairer. Salary, role, and performance should not live in separate systems. When those things are disconnected, people are left guessing, and that is where distrust starts.

8. Flexibility needs trust, not control #

I have been lucky enough not to work in companies with excessive control over schedules. Most companies get this one right because extreme rigidity affects everyone and the pushback is immediate. But there is still room to improve.

It makes sense to have core hours, at least four hours where everyone overlaps and meetings can happen. But respecting core hours also means respecting the hours outside of them. If someone prefers to start early and leave early, or work late at night, that should be fine as long as the work gets done and the team can coordinate.

I am much more productive at night. There are no distractions, no pending calls to make before something closes, no interruptions. Everything outside work is already settled for the day, and I can focus completely. Other people feel the same way about early mornings or mid-afternoon. The specific hours do not matter. What matters is the output and the trust.

Be responsible with your own time, and trust others to be responsible with theirs. Control does not create better work. Trust does.

9. Learning should be part of the job #

I have worked in companies where the only thing that mattered was producing. That may create output for a while, but it does not create strong engineers or strong teams in the long term.

When everything is urgent all the time, people stop improving. They lower their standards, focus only on surviving the week, and lose the space needed to learn, experiment, and do thoughtful work.

Outstanding engineers usually share something beyond raw output. They may have side projects. They like to stay up to date. They enjoy learning and exploring new ideas. That curiosity is part of their value.

Good companies should support that mindset instead of squeezing it out of people. That means budget for certifications, time for spikes, space to try new tools, workshops, and real knowledge sharing inside the team.

A strong engineering culture also appears in daily habits. Tests are part of the work, technical debt is made visible, code review is 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 as part of the job.

10. In the age of AI, soft skills matter more #

Recently, I have met highly technical professionals with attitudes that were clearly toxic. That made something very clear to me: if AI makes raw technical execution easier, then soft skills matter even more than before.

Some toxic profiles are easy to spot. They insult, threaten, point at people instead of problems, or look for someone to blame when something goes wrong. That kind of behavior should not need much interpretation. It damages trust immediately.

Other profiles are more subtle and can be easier to excuse, but they still do damage through repetition. Someone may respond to a mistake with comments like "this has happened many times", give negative feedback in a public channel instead of in private, or make comparisons like "I have never seen anyone do something like this". On the surface, those may look like small remarks. In practice, they create shame, defensiveness, and silence. The pattern matters.

Knowing how to explain an idea, communicate with clarity, be assertive, handle pressure, adapt to context switching, keep learning, and teach others is now one of the most valuable things an engineer can bring to a team. The good news is that these skills can be worked on and improved.

In my experience, a junior with strong soft skills can create value surprisingly fast in the age of AI. That person will use AI to learn faster, ask better questions, and contribute earlier than expected because they are proactive and open to feedback.

If someone has weak technical judgment, they may still make wrong decisions. But if they are humble and healthy to work with, they will often notice, learn, and self-correct. A toxic person does much deeper damage. They can drag down the whole team, push good people away, and make the people with the best soft skills leave first. That kind of damage is much more expensive to repair.

11. The way you hire is part of your culture #

The other day I ran an interview with another engineer from the team. When we finished, he told me he wished more interviewers worked that way because the candidate felt comfortable and everything had been explained with complete transparency. That made me happy, because that is exactly the point.

Hiring should start from empathy. Treat people the way you would want to be treated when you are trying to find your place. A good interview is not an interrogation. It is a structured conversation where both sides try to understand whether the match is real.

Every stage should have a clear purpose. Do not ask random questions, improvise the whole interview, or design technical exercises that say little about the real job. Respect people's time, explain what you want to evaluate, keep response times reasonable, leave room for their questions, and always give feedback.

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 people who design and run the process also need training. A hiring team that does not understand the market, the technical context, or the business will end up making shallow decisions. Recruiters and interviewers should keep learning too.

If people leave your process feeling smaller, confused, or disrespected, then the company has already told them something important about its culture.

12. Look inside the team before hiring outside #

Before hiring someone above the current team, I think companies should first look at internal promotion. In many cases that is the healthier place to start. If you always look outside first, people inside the company learn a simple lesson: their growth is not the priority.

Hiring someone above your current employees can be the right decision, but it is often hard to manage if it is done badly. It can create frustration, especially if the team does not understand why that person is coming in above them. In some cases, it is a very good idea to talk to the team before making the decision.

Growth also needs planning. Adding several people to the same team at once can break its rhythm, slow delivery, and hurt motivation. Teams should scale with care, not as a reaction to urgency or excitement.

If the team is already aligned that a new role is needed, for example an architect, the situation is much easier to handle. If people understand the need, the scope, and the reason why this 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 pretend current employees do not exist when a new need appears. Consider them first. Give them context. Let them grow when possible. Even when the final decision is to hire from outside, the process should show clearly that the team was respected.