Based on a LinkedIn post originally published on 6 April 2026
My first professional role in New Zealand was as a Delphi programmer.
The company developed an education platform sold across several Pacific islands. It was an interesting product and an important opportunity for me in a new country.
It was also a technical challenge.
By that point, my most active programming years were largely behind me. My development background was primarily in C, C++, Clipper and BASIC. Delphi was not my natural comfort zone.
Nevertheless, after several interviews, technical discussions and tests, I received an offer.
I was genuinely happy. A new country, a new position and a welcome sense of stability appeared to be coming together.
On my first day, that optimism encountered a reality I had not expected.
The empty office
I arrived at the office and found it almost completely empty.
There were no developers, no visible activity and none of the normal signs of a functioning engineering team. There was only silence.
At first, I assumed I had arrived early. Perhaps the development team worked different hours or was operating remotely.
As the hours passed, those explanations became less convincing.
What I expected on the first day: - Development team - Product introduction - Technical environment - Colleagues and responsibilities - Normal onboarding What I encountered: - Empty office - No developers - No clear explanation - No visible operating context
Something was clearly wrong, but the information necessary to understand it was not being offered.
The vacancy had been presented as an ordinary hiring need. The first day revealed that it was actually the consequence of an organisational crisis.
The explanation that took days to emerge
I continued asking my manager what had happened.
She avoided giving a clear answer for several days. Eventually, she explained the history as it had been presented to her.
Over the preceding months, the company had invested heavily in training the complete development team in C++.
The technical direction had been explicit: the existing education platform would be rewritten, and C++ would become the foundation of the new system.
The team had invested in that direction:
- they had attended training;
- developed new technical skills;
- prepared mentally and professionally for the migration;
- and accepted that the future of the product would require substantial change.
The company then reversed the decision.
The planned C++ rewrite was cancelled, and the organisation decided to continue with Delphi.
I was told that the development team responded by resigning collectively in protest.
Strategic decision:
Rewrite the platform in C++
|
v
Company-funded training
|
v
Team invests effort and belief
|
v
Migration is cancelled
|
v
Platform remains on Delphi
|
v
Development team resigns
|
v
Vacancy is createdThat was the context in which I had been recruited.
The vacancy was technically accurate but contextually incomplete
The company did need a Delphi programmer.
From a narrow recruitment perspective, the role description may therefore have been accurate.
But the vacancy could not be understood properly without knowing why the previous team had disappeared.
I was not joining a stable development organisation with an ordinary capacity gap. I was entering an environment in which:
- the development team had left;
- institutional product knowledge had been lost;
- a strategic technology decision had been reversed;
- trust between leadership and engineering had broken down;
- and the remaining organisation still needed to support customers.
A role title describes the work. Context explains the risk, expectations and operating environment surrounding it.
Technical direction can change
Cancelling a rewrite is not inherently evidence of poor leadership.
Large migrations frequently become less attractive as more information emerges. Costs increase, delivery estimates prove unrealistic or the business discovers that the existing platform still satisfies its commercial needs.
A responsible leadership team must be able to reverse a technical decision.
Continuing a migration merely because people have already invested time in it can create a much larger failure.
The central issue is not whether a strategic decision may change. It is how that change is evaluated, communicated and implemented.
A strategy may change because: - New evidence appears - Cost exceeds expected value - Risk becomes unacceptable - Business priorities change - Technical assumptions prove wrong Changing direction can be responsible. Ignoring the human commitment surrounding the direction is not.
Training communicates more than knowledge
When a company invests in substantial training for an entire team, it sends a powerful signal.
The formal message is that employees should acquire a new capability. The implicit message is that the capability belongs to the organisation’s future.
People respond accordingly. They invest not only working hours but also identity, confidence and career planning.
The team may begin to imagine itself as the group that will build the new platform.
Formal investment: C++ training Implicit organisational promise: This skill will matter here. This migration is real. Your effort supports the future. You will participate in building it.
If the strategy later changes, leadership must address both layers.
Explaining only the commercial decision leaves the implicit promise unexamined.
The invisible contract
Employment contracts define salary, responsibilities, working hours and other formal obligations.
Teams also operate through an informal psychological contract.
That contract contains expectations such as:
- leadership will communicate consequential decisions honestly;
- effort invested in an agreed direction will be respected;
- people will not be asked to reorganise their professional future casually;
- and changes in strategy will include a credible explanation of what happens next.
The company may have retained every formal right to cancel the migration. The team could still experience the reversal as a breach of the relationship on which their commitment depended.
People rarely resign collectively because one programming language was selected over another. They resign because the decision changes what they believe about leadership, their future and whether their commitment is reciprocated.
Reversing direction without destroying trust
A difficult strategic reversal can be managed more responsibly.
Leadership should explain:
- What changed. Which evidence or constraint made the original direction no longer viable?
- Why the earlier decision was reasonable. Was it based on information available at the time?
- What remains valuable. How can the skills and knowledge acquired through the training still be used?
- What the new direction means for each person. How will responsibilities and career opportunities change?
- Who owns the transition. How will the organisation support both the product and the team?
Communication cannot guarantee agreement. It can demonstrate that the people affected are considered participants in the transition rather than resources that will automatically follow another instruction.
The operational cost of losing a team
When a complete development team leaves, the organisation loses more than coding capacity.
It loses accumulated knowledge about:
- the architecture;
- undocumented product behaviour;
- customer-specific adaptations;
- deployment and recovery procedures;
- historical design decisions;
- known defects and workarounds;
- and the relationships required to deliver changes safely.
Team departure
|
+---- Development capacity lost
+---- Product knowledge lost
+---- Support continuity weakened
+---- Onboarding burden created
+---- Delivery risk increased
+---- Trust signal sent to future hiresThe cost of the reversal therefore extended far beyond the training investment.
What candidates should be allowed to understand
Recruitment does not require an organisation to disclose every internal disagreement.
But when a vacancy exists because an entire team resigned, that context materially changes the opportunity.
A candidate should be able to ask:
- Why is the position open?
- Who previously performed this work?
- What knowledge remains available?
- What strategic decisions recently changed?
- What does success look like during the first months?
- Is the organisation rebuilding a team or replacing one person?
Honest answers allow candidates to evaluate the real challenge and decide whether they have the appetite and capability to take it on.
Staying, learning and delivering
For me, the situation also became a lesson in adaptability.
I stayed. I learned Delphi, understood the product and delivered the work required.
Adaptability did not mean pretending that the surrounding situation was normal. It meant accepting the reality of the environment and determining how I could operate effectively within it.
The experience required:
- learning an unfamiliar language and product;
- reconstructing knowledge that had left with the team;
- understanding the business context;
- and separating the work I could control from the history I could not change.
But I never forgot the first day or the explanation that followed it.
Engineering is held together by invisible structures
Technology organisations are built from code, infrastructure, architecture and process.
They are also held together by less visible structures:
Trust Shared belief in the direction Confidence that effort has meaning Respect for professional commitment Credible communication A future people can imagine together
Those structures do not appear in architecture diagrams. When they fail, however, the operational consequences become immediately visible.
Technical direction can change. Roadmaps can be cancelled. Technologies can be replaced. But when leadership reverses a strategy without respecting the people who invested in it, the organisation may lose something far harder to rebuild than software: trust.
This article is based on my original ideas, experience, analysis and conclusions. Artificial intelligence tools were subsequently used as editorial and research assistants to review grammar and wording, improve structure and presentation, organise some arguments into clearer logical sections, and help review references to legal, regulatory and technical concepts.
Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.
Comments
Post a Comment