One reality of working in technology is that problems rarely arrive at a convenient time. Systems fail late in the evening. Security incidents begin over weekends. A critical service can go down long after everyone has gone home, and the problem will not wait politely until the next working day.

Over the years, I have often had to call someone from the team outside normal working hours. It is never a call I make lightly, people have families and responsibilities beyond work. Yet there are moments when the organisation needs the team, and in those moments you learn something no meeting can teach you: who stays, who leans in, and who remains beside the problem long after their own part is done.

That is not something a job description can produce. It is built slowly, long before the difficult night arrives.

I have come to believe that this kind of loyalty is shaped in ordinary times, not in the difficult ones. Part of it grows through curiosity. Many people who choose a career in technology are curious by nature, they want to explore a new system or solve a problem they have not faced before. When that curiosity is encouraged, work begins to feel different. A new project becomes a chance to grow. A hard problem becomes worth solving for what it teaches. Salary will always matter, but when people feel they are learning and progressing, work begins to mean more than compensation alone. it stops being the only thing connecting them to the organisation.

Part of it grows through trust. There is a real difference between giving someone a task and giving them ownership. A task tells a person what to do, ownership lets them think, decide and carry the outcome. I have not always found this easy. When you have spent years building systems yourself, there is a natural temptation to stay involved in every technical decision, to review every design, to keep a hand on every architecture choice and sometimes that comes from care rather than control. But a team cannot grow if the leader never lets it carry real weight. Mistakes will occasionally happen. What matters is whether a mistake becomes a reason to withdraw trust, or an opportunity to build better judgement.

And part of it grows through simply knowing people. Over the years, I have come to know many team members beyond the work they do, their families, their ambitions, the things they are quietly working through. Gatherings away from incidents and deadlines let people know one another differently, and those relationships often matter most when the pressure rises. This is why I believe technology leaders must stay close to their teams. Senior roles fill easily with meetings, reports and budgets, and distance arrives without anyone choosing it. Staying close does not mean involving yourself in every technical detail. It means being reachable, understanding where the team is struggling, and being present when the work becomes hard.

People remember whether their leader stood beside them. They remember who accepted responsibility when something went wrong, and who shared recognition when things went well. Over time, I have come to believe that when a leader faces a genuinely difficult period, there are usually two groups most likely to remain beside them. One is family. The other is a team that chooses to remain beside them. They do not stay because a process requires it, they stay because the relationship has become mutual.

The leader stood beside them first, and they remember.