Diego's Manifesto
Why this manifesto
These are the principles I believe keep teams healthy over time. I mainly have engineering teams in mind, because those are the ones I know best, but most of it applies to any team where several people have to coordinate. Many of them come from things I have seen go wrong.
It 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.
1. Respect #
Probably the most important point, and the easiest to break. You do not need to insult someone to disrespect them: respect usually breaks down through small, frequent gestures, especially under tension.
Mistakes I have seen
Giving harsh criticism in public instead of speaking in private. Dismissing someone's work with a label instead of useful critique. Complaining about a decision without real arguments, walking away from a conversation once someone pushes back, or ignoring someone who says something you did bothered them. Each seems small on its own; together, they erode trust. People become defensive, share less, and conflict stops being resolved and starts being avoided.
How I think it should work
Disagree with real arguments and stay in the conversation until it is closed: reply, reconsider, or refine your position. If someone tells you something you did bothered them, acknowledge it and apologize, even if you do not share their full interpretation. And when tension is high, pause before you answer. Respect is easiest to break right when it matters most.
2. Freedom to speak up #
Anyone on a team should be able to share an opinion, question a decision, or suggest a different way forward without their title turning them into a spectator.
Mistakes I have seen
Shutting down people who tried to improve something: "that is not your business", "we do it this way because I said so". No context, no dialogue, just authority used as an argument. When speaking up only gets you put back in your place, people stop doing it. Decisions get worse because nobody challenges them, and the people with the most to contribute disengage or leave.
How I think it should work
If the idea does not work, explain why. If context is missing, share it. And if the person still believes their approach is better, ask for 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 #
Hard conversations (salary, friction with a colleague, disagreement with a decision) do not come up on their own in a group meeting or a Slack channel. If there is no clear place for them, they 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. And the opposite problem: spaces that exist on the calendar but not in reality, like rushed 1:1s where you cannot finish explaining yourself, or where the leader takes the call while driving on speakerphone. Either way, problems grow in silence, and by the time someone finally speaks, someone else has already burned out or left.
How I think it should work
There are three minimum spaces: regular 1:1s to talk calmly about growth, compensation, or friction; retrospectives to review what worked and what did not; and anonymous channels to talk about decisions or leadership without fear. Not everything has to be anonymous, but it does need to be safe. If speaking up could cost you something, or if nobody is really listening, the channel does not work.
4. Shared responsibility for alignment #
It is impossible for everyone to agree on everything, and that is normal. The problem is when disagreement becomes the team's default state.
Mistakes I have seen
Teams where more than half the engineers were not aligned with the person making the decisions. Leaders who say "I have more context" without sharing it, who decide in isolation, or who roll out changes that affect people's day-to-day work and, at best, explain them afterwards. People stop pushing back, not because they agree, but because they assume it is pointless, and the team goes from thinking to complying.
How I think it should work
Alignment does not mean everyone gets what they wanted. It means understanding the decision well enough to support it honestly. The person deciding is responsible for building that alignment, and the team is responsible for seeking it. If a decision affects a team's work, listen to them first: not to hand over the decision, but to catch risks that are invisible from above. I have changed my mind completely more than once after listening, and I see that as a strength.
5. Honesty in leadership #
A leader does not need to have every answer, but they do need to avoid lying.
Mistakes I have seen
Presenting equity, compensation, or future changes as if they were already secured when they were not, or promising promotions that did not depend on the person promising them. Sometimes it is subtler: selling certainty where there is none, or letting someone believe something you know is unlikely to happen. When someone discovers they have been lied to, it is not only that conversation that breaks, but the leader's credibility. From then on, every promise is heard with suspicion.
How I think it should work
If you do not know, say you do not know. If you cannot share something yet, say so. If it depends on someone else, explain that. Only commit to what you can genuinely stand behind, and if you get something wrong, correct it quickly. People tolerate an honest limitation much better than false certainty.
6. Clear priorities and planning ahead #
Much of a team's exhaustion does not come from workload, but from working without direction. Not knowing what matters now or what comes next creates a constant feeling of being late.
Mistakes I have seen
Teams living in reactive mode, responding to whatever feels urgent just to survive the week, with no idea what they will be building in the coming months. Obvious problems, like technical debt, fragile dependencies, or parts that will scale badly, left for later because they are not exploding today. Every patch calls for another, and what could have been solved with some breathing room ends up costing far more, in a rush.
How I think it should work
People should know the current priorities, the direction for the next few months, and the reasons behind both. That clarity creates focus and also calm. Planning ahead is part of the work too: keep some capacity for prevention and cleanup, not just for firefighting.
7. Look for causes, not culprits #
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: a weak process, missing safeguards, weak review, or a system that made the failure too easy to reach. The underlying problem remains, and the same failure happens again to someone else. The person who was blamed starts working from fear, and that fear spreads: people ask fewer questions, hide uncertainty, and the team becomes slower and more fragile.
How I think it should work
Focus on process and learning. Postmortems matter. Looking at systemic causes does not remove individual responsibility, but it means examining it with context. The useful first question is not "who failed?" but "what made this failure likely, and what are we going to change?"
8. Early detection of team strain #
Safe channels are not enough. Leadership and HR also need signals that help them detect strain before someone reaches their limit. I do not mean spying on people. I mean getting there early enough to help.
Mistakes I have seen
Startups with no 1:1s, no useful reviews, and no surveys, where some leaders were doing a poor job and some teammates were burned out without the company noticing. Or saving important feedback for formal reviews: if someone hears an important criticism or piece of recognition for the first time there, the system has already failed. When a company only reacts once someone is already thinking about leaving, it is too late.
How I think it should work
Combine voluntary channels with structured signals: 1:1s, reviews that actually help, surveys, anonymous feedback, and leaders who notice changes in energy or tone. Above all, read those signals and act. If several people describe the same problem, move quickly.
9. Timely recognition and compensation #
Saying "good job" is the first step, not the last.
Mistakes I have seen
Waiting for someone to ask for a raise, when they have probably been thinking about it for months and may already be looking elsewhere. Deciding how to compensate overtime once the hours are done and people start complaining. Keeping pay just low enough that the person hesitates before leaving, or even renegotiating a raise downward to make the budget work. That destroys trust faster than almost anything else, and the best people leave first because they have the most options.
How I think it should work
The key is anticipation. A leader who is paying attention can say: "I can see the effort you are putting in. I believe you have earned a raise, and I am going to make that case." Hearing that before having to ask changes everything. If extra hours will be needed, say so beforehand: how many, for how long, and how they will be compensated. And when someone takes on more than their share, recognize it early and visibly.
10. Salary transparency #
Salary is one of the easiest places to hide arbitrary decisions, and also one of the clearest ways to show whether you value someone.
Mistakes I have seen
Companies that do not want people talking about pay, often to avoid explaining why one person earns more than another, or why a new hire joins on a much higher salary. But people talk anyway, just in private and without context. That gap fills up with assumptions, and once the team reads the numbers as arbitrary or driven by favoritism, rebuilding credibility is very hard.
How I think it should work
Every person's exact salary does not need to be public, but the bands for each role and the criteria for moving within them should be. If the company is financially healthy, it should pay in a clearly competitive way, and above market when it can genuinely sustain it: people already inside know the codebase, the product, and the team, and that is worth something too. Talk about pay openly, with market data and an explanation for every number. When people have to guess the rules, that is where distrust starts.
11. Freedom with responsibility, not control #
People should have real room to organize their work in the way that lets them perform best. But freedom is not disorder: in engineering, your work almost always affects other people's work.
Mistakes I have seen
Controlling schedules and presence as if that guaranteed productivity, expecting everyone to perform well under the same pattern. And the opposite error: using freedom as an excuse not to think about other people, like handing someone a task at the end of the day when you could have given it to them first thing in the morning. The first wears people down and kills motivation; the second blocks teammates and creates friction that has nothing to do with the work itself.
How I think it should work
Real autonomy, with responsibility, visibility, and coordination. If someone is tired, it is often better for them to rest, even sleep for a while, and come back with more clarity than to stay visibly present when they are not in good shape. The condition is thinking about the impact on others: if your work unblocks someone, deliver it as early as you can, and if someone depends on you, give them context and room to plan. That is also a form of respect.
12. Learning is part of the job #
In engineering, curiosity is not a nice-to-have: it is part of doing the job well. And with AI accelerating the pace of change, making time to learn is a necessity, not a luxury.
Mistakes I have seen
Companies where the only thing that mattered was output: no time to learn, no budget, and no room to experiment, because everything was urgent all the time. People lower their standards and focus on surviving the week. That may produce output for a while, but it does not build strong engineers or strong teams.
How I think it should work
Budget for training and certifications, time to investigate and try new tools, and real knowledge sharing inside the team. It shows in daily habits too: tests are part of the work, technical debt is made visible, and code review is a conversation. Learning should not depend only on what people do at night or on weekends.
13. What works can still be improved #
If something works, that is a good starting point, not the end of the conversation.
Mistakes I have seen
Many people react to any proposed change with "but it already works, why touch it?" And often it did work, but in a clumsy, slow, or fragile way. Friction gets normalized, inefficiencies settle in, and changes only happen once something is already failing: late and under pressure.
How I think it should work
Review processes, tools, and technical decisions with some regularity. The goal is not to touch things for the sake of it: if something works well, keep it. But if it can become meaningfully simpler, faster, or more resilient, it is worth discussing. Teams that examine their habits without ego arrive better prepared when pressure appears.
14. Pragmatism over dogma #
Best practices usually exist for a good reason. The problem starts when they are applied every time, regardless of context: at that point they stop being a tool and become dogma.
Mistakes I have seen
A clear example is a database migration. In a startup, a planned production pause may make sense if it massively reduces complexity. Yet some people do not even put that option on the table and go straight for a much slower, more expensive path because the "right way" is to never stop production. The team can spend weeks protecting against a risk the business could have absorbed in a controlled way.
How I think it should work
Best practices are guidance, not religion. Understand which risk they reduce and whether, in that context, it justifies the cost they introduce. If you break a rule, make the trade-off explicit: which risk is being accepted, who is accepting it, how it will be communicated, and how you would back out. Sometimes the irresponsible move is not breaking the rule, but refusing to revisit it.
15. Human skills matter as much as technical ability #
If AI makes technical execution easier, what differentiates people shifts toward the human side: explaining an idea, communicating clearly, handling pressure, adapting, and teaching others. Technical ability still matters, but on its own it distinguishes people less and less.
Mistakes I have seen
Highly technical people who did a lot of damage to the team. Sometimes obviously, with insults or by looking for someone to blame. Other times more subtly, and precisely because of that, easier to tolerate: correcting from a position of superiority, making others feel small, or turning normal mistakes into small, repeated humiliations. Each comment on its own seems minor, but the pattern wears down morale. People ask less, dare less, and eventually leave.
How I think it should work
These skills can be developed. In my experience, a junior person with strong human skills creates value surprisingly quickly in the AI era, because they ask better questions, listen, and stay open to correction. Technical ability should never excuse disrespect: someone brilliant who erodes the team week after week ends up costing more than they contribute.
16. Respect and professionalism in hiring #
Good hiring starts with empathy. An 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
Improvised interviews, technical exercises that say little about the real job, weeks without a reply, or no final response at all. Interviewers who arrive late without warning, fail to show up, or take the interview while driving on speakerphone. And, to finish, negotiating the offer down by two or three thousand after the whole process. All of it sends a very simple message: your time does not matter. The candidate immediately understands what to expect 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, leave room for the candidate's questions, and always close the loop. Design the process against bias, with structured interviews and shared criteria, and do not confuse confidence with competence. The offer should be serious and explainable, and the people who interview need training too.
17. Prioritize internal promotion #
Before hiring someone above the existing team, companies should look inside first.
Mistakes I have seen
Always looking outside first when a new need appears, hiring someone above the current team without explaining why, or adding several new people at once without an integration plan. People quickly learn that their growth is not the priority, and the team loses rhythm and motivation.
How I think it should work
Open the role internally first and see whether someone wants to try. If you need a profile that does not exist inside, an architect for example, explain the need, the scope, and why it is not being filled internally. Even when the company ends up hiring externally, the process should make it clear that the team was respected.