
Desde que entré en el mundo del desarrollo, nunca tuve un rol de consultor, sino más bien uno de acompañamiento, donde me conectaba con el equipo del colaborador y trabajaba siempre como un miembro más del equipo: sacando funcionalidades, participando en reuniones, dando mi punto de vista, recordando que existen tests y que no se harán solos, etc.

Pero en los últimos años he estado más con colaboradores...


El código no lo es todo

En este artículo reflexiono sobre la importancia de las personas antes que el propio código.


Since I entered the world of development, I never had a consultant role, but rather one of accompaniment, where I connected with the collaborator’s team and always worked as another member of the team: building features, attending meetings, giving my point of view, reminding everyone that tests exist and won’t write themselves, etc.

But in recent years, I’ve been working more with collaborators where I did have a consultant role, which—unlike the accompaniment role—has the main goal of helping people grow rather than writing code or delivering features. Your mindset shifts from "*this might be a good solution*" to "*if I say it this way, maybe my teammate can find the right solution*".

Based on my experience, I’ve drawn some conclusions that might be helpful:
- **Self-confidence**: It might be impostor syndrome or the fear of facing a new challenge that doesn’t seem easy at first. Whatever the reason, the important thing is that you were brought into this project because they know you can handle it and have the knowledge. When you see that the people you work with thank you, start relying on you to solve problems, and apply what you’ve explained, that’s when you realize you have the ability to face it, and that initial difficulty begins to fade away.

- **Hierarchical communication**: This happens when the collaborator is someone or a group of people who aren’t coding with the team but are the ones who called us in because they want to instill our way of working in the company. When this happens, it’s common that the people we work with daily either don’t understand why we’re there or simply don’t agree with the change, which creates difficulty. The solution could be as simple as, at the beginning, asking all teammates what they expect from the collaboration or even from you personally, and then explaining the purpose of our involvement. This way, we align from the start and can avoid potential short-term problems.

- **Those who don’t want to, won’t**: Continuing from the previous point, when one of the teammates doesn’t want to go the same way as we do, don’t take it personally. We’re not here to change the entire company or preach a superior truth; we’re here to contribute our grain of sand and try to make things a little better when we leave than when we arrived. Something that can help a lot is identifying people who are more aligned with us or our ideas and focusing on supporting them more. That doesn’t mean ignoring the rest, but those aligned individuals will more easily absorb what we teach and, as a result, can help others who are less aligned. Thus, we go from a grain of sand to a snowball that expands exponentially.

- **"Listen with your eyes"**: Not everyone can express themselves the way they’d like, so pay attention to small details. This is a bit harder, but when you’re in meetings or explaining things, pay attention to the person who rarely speaks, to the one who talks too much, or to the one who exudes confidence—you can learn a lot indirectly that will help you later. Of course, you can’t pay attention to everyone, but there’s always a solution: try recording the session and later, with more calm, analyze situations and behaviors.  
  For example, if one day you’re with someone who’s usually quiet in group meetings, you could mention something they said before to show you remember their words. Or if you’re with someone who can’t quite grasp what you’re explaining, maybe instead of repeating everything, you could ask questions that lead them to reflect and find the answer themselves.

I could mention more points, but I think these have helped me the most. My first consulting collaboration, for me, was a failure. We were two consultants, and thanks to my colleague, things went quite well. I say that with no remorse, because the challenges I faced are what helped me grow and learn from my mistakes. We’re not perfect; we can’t get everything right the first time—after all, we’re human.  
Rely on your colleagues, express the situations you couldn’t handle, celebrate your successes, ask questions without fear... Thanks to that, in my next collaboration, I achieved great results, avoiding or solving many of the difficulties I had faced before.

Code doesn’t change on its own, but the people who write it do.

> The original version was written in Spanish. This version has been translated using AI, so please keep in mind that coherence may be lost or there may be some unusual phrasing. Thank you very much for your understanding.


In this article, I reflect on the importance of people before code itself.

Code is not everything


開発の世界に入って以来、私はコンサルタントという役割を持ったことはなく、むしろチームに寄り添いながら一緒に働く「伴走者」として活動してきました。チームの一員として機能を実装したり、ミーティングに参加したり、自分の意見を述べたり、「テストは勝手に書かれない」と思い出させたりしてきました。

しかし近年では、実際に「コンサルタント」としての役割を担う機会が増えました。この役割は、単なる伴走者とは異なり、主な目的は「人々の成長を支援すること」であり、コードを書くことや機能を実装することではありません。考え方も「*これは良い解決策かもしれない*」から「*こう言えば、相手が自分で正しい答えを導けるかもしれない*」へと変わります。

これまでの経験から、役立つかもしれないいくつかの結論を挙げます：

- **自己信頼**：それはインポスター症候群かもしれないし、新しい挑戦への恐れかもしれません。理由は何であれ、あなたがこのプロジェクトに参加しているのは、周りがあなたの力を信じているからです。チームの人々が感謝してくれたり、問題解決を頼ってくれたり、説明した内容を実践してくれたりすると、自分には対応できる力があると実感し、最初の困難が徐々に消えていきます。

- **階層的なコミュニケーション**：これは、開発チームと一緒にコードを書かない上層部の人々が、会社に私たちの働き方を根付かせるために私たちを呼ぶようなケースです。このような場合、日々一緒に働く人たちが私たちの存在理由を理解していなかったり、変化に反対していたりすることがよくあります。そのため、最初に全員に「このコラボレーションから何を期待しているか」「あなたに何を望むか」を尋ね、次に私たちの目的を説明するだけで、初期段階から方向性を一致させ、問題を未然に防ぐことができます。

- **「やりたくない人はやらない」**：前の点とも関連しますが、同じ方向に進みたくないメンバーがいても、個人的に受け止めないでください。私たちは会社全体を変えるために来たわけでも、上から目線で教えに来たわけでもありません。小さな改善を積み重ね、出発時より少しでも良い状態で終えることを目指しているのです。自分たちの考え方に近い人を見つけて、その人たちをよりサポートすることが大いに助けになります。そうすることで、彼らが他のメンバーを支援し、やがては雪だるまのように良い影響が広がっていきます。

- **「目で聞く」**：誰もが自分の思うように表現できるわけではありません。小さなサインに注意を払いましょう。これは少し難しいですが、ミーティングや説明の際、あまり話さない人、話しすぎる人、自信にあふれている人などを観察することで、多くのことを間接的に学べます。全員に常に注意を向けるのは難しいですが、セッションを録画し、後で冷静に分析するのも一つの方法です。
  例えば、普段あまり発言しない人に対して、以前の発言を引用して「覚えているよ」と伝えることで信頼を築けます。また、説明がうまく伝わらない相手には、再度説明する代わりに質問をして自分で考えてもらう方が効果的なこともあります。

他にも挙げられますが、これらが最も役立ったポイントです。私にとって最初のコンサルタントとしてのコラボレーションは「失敗」でした。2人のコンサルタントのうちの1人として参加し、同僚のおかげで最終的にはうまくいきました。後悔はありません。なぜなら、その失敗こそが私を成長させ、学ばせてくれたからです。完璧な人間などいません。最初からすべてを完璧にこなすことはできません。結局、私たちも「人間」なのです。
仲間を信頼し、コントロールできなかった状況を共有し、成功を分かち合い、疑問を恐れずに質問しましょう。それが次のコラボレーションで成功するための糧になります。

コードは勝手に変わりません。しかし、それを書く「人」は変わるのです。

> オリジナルのバージョンはスペイン語で書かれています。本バージョンはAIによって翻訳されたものですので、文章の一貫性が損なわれていたり、不自然な箇所があった場合はご了承ください。ご理解いただき、ありがとうございます。


この記事では、コードそのものよりも「人」の重要性について考察します。