About 10 years ago, our CEO, Richard Ney, witnessed something which became a key trigger for what Aldemis is today.
Richard had been brought into a large organisation (£250m+ ARR) as they faced significant business issues that were deeply impacting their bottom line. It was perceived that one of the main reasons was one of their software teams underperforming. The quality of the software was low, releases were going out the door late and running over budget, and the team experienced an extremely high level of turnover.
Those facts were accurate, and the reason for it was apparent. The resolution was straightforward. The result was mind-blowing.
The team — about 50 people across product, development, testing, release and support — was working on an end-of-life product. The software was old and complex; few new features were being worked on, and the work consisted mainly of BAU bug fixes, which were uninteresting. To top it off, although it was not official, everyone knew the product was going to be retired within a few years. The team was simply unmotivated, and the performance was very poor.
After a month into the business, Richard asked the CEO and CPO if they could spare 30 minutes to talk to the team and explain where the product fit within the organisation. What happened was truly extraordinary.
The 50 people were packed into the boardroom, and then the CPO arrived, followed by the CEO. They spoke to the team and explained that the system was indeed a cash-cow product, planned for retirement within three years. They explained that a new product would be introduced as a replacement and that the team would transition to it afterwards.
In the meantime, the business needed the current software to remain stable, as it was generating 80% of the revenue. Eighty per cent.
They explained that most people in the office were being paid thanks to that product, and therefore the work the team was doing to keep it stable was truly appreciated. Every time the system failed and had to be turned off, 80% of the revenue for that period was lost. It was simply the best product the business had until the replacement came in.
The situation changed literally overnight. Turnover stopped, productivity increased, and the team became very proud of their work. They understood their purpose and value.
Of course, such a significant business problem wasn't caused solely by one team, so once the software team's issue was fixed, Richard went on to help identify and resolve many other issues within that part of the business. But that's another story.
This real-life story was a realisation for Richard, and we're now using some of those principles, and others, to boost business productivity within our customers' teams.
Across the years, we've learnt some dos and don'ts when it comes to team motivation, and we're sharing some with you here.
The five dos
1. Foster a sense of purpose and impact
Engineers and developers are, at their core, problem-solvers. While they enjoy tackling complex technical challenges, their motivation skyrockets when they understand why they are solving a particular problem. It's not enough to assign a ticket from a backlog; you must connect their work to the bigger picture. Clearly articulate how the feature they are building will alleviate a customer's pain point, drive business growth, or contribute to the company's mission.
Regularly share customer feedback, business metrics and success stories. Instead of saying “we need to build an API for data export”, try: “our enterprise clients are struggling to integrate their data, which is a major blocker for renewals. By building this API, you'll be directly enabling our top 10 customers to succeed and securing millions in revenue.” This transforms a technical task into a meaningful contribution, giving a clear line of sight from code to real-world impact.
2. Grant autonomy and trust
Once the what and the why are clear, the best thing a leader can do is step back and trust the team with the how. Technology professionals are highly skilled experts who thrive on autonomy. Micromanaging their technical decisions, dictating specific implementation methods, or requiring constant status updates erodes trust and stifles creativity. Empower your team to make decisions about their architecture, tools and processes.
This doesn't mean a complete hands-off approach. It means setting clear goals and constraints and then giving them the space to figure out the best path forward. Encourage debate, let them experiment and sometimes fail, and support their technical choices. When you show that you trust their expertise, they will take greater ownership and pride in their work.
3. Invest in growth and learning
The technology landscape changes at a dizzying pace. What is cutting-edge today is standard tomorrow and legacy the day after. Top tech talent is deeply motivated by opportunities to learn and grow their skills. Stagnation is a career-killer, and a team that isn't learning is a team that is falling behind.
This investment can take many forms: a budget for online courses, books and conferences; hack days or 20% time for experimentation with new technologies; and knowledge-sharing through tech talks or brown-bag sessions. Create clear career paths that allow for growth as an individual contributor as well as a manager. When team members see a future for themselves at the company, they are far more likely to stay engaged.
4. Protect their time and focus
One of the biggest demotivators for a technical team is constant context-switching. Deep technical work requires long, uninterrupted periods of concentration. Every unplanned meeting, shoulder-tap or urgent Slack message can break that flow, costing significant time and mental energy to regain focus. A great leader acts as a shield.
Be ruthless about scheduling. Question the necessity of every meeting and ensure it has a clear agenda and only the essential attendees. Funnel external requests through a single point of contact rather than letting stakeholders approach developers directly. Establish no-meeting blocks and respect the team's need for focus.
5. Recognise and reward both effort and outcome
Recognition is a powerful motivator, but it must be applied thoughtfully. Acknowledge not just the successful launch of a major feature but also the invisible work that makes it possible: the engineer who spent a week refactoring complex legacy code to improve stability, the person who wrote excellent documentation that unblocked the rest of the team, the one who patiently mentored a junior developer.
Make recognition specific, timely and authentic. While financial rewards are important, don't underestimate the power of acknowledging the craft, effort and teamwork that often goes unnoticed.
The five don'ts
1. Don't micromanage the how
This is the direct counterpart to granting autonomy and is perhaps the fastest way to demotivate a skilled professional. Micromanagement sends a clear message: I don't trust your judgment or your skills. It turns engineers from creative problem-solvers into typists executing someone else's commands.
If you have concerns about a technical direction, frame it as a question to foster discussion rather than a directive. Instead of “you must use a NoSQL database for this”, ask “have we considered the scalability trade-offs between a relational and a NoSQL database for this use case?” Your role is to guide and unblock, not to control.
2. Don't ignore technical debt
Every engineering team accumulates technical debt. But consistently forcing the team to build new features on a shaky or poorly architected foundation is profoundly demoralising. It's like asking a chef to cook a gourmet meal in a dirty kitchen with broken appliances.
Ignoring technical debt signals that management prioritises short-term speed over long-term quality and stability. This leads to burnout as engineers fight the same fires over and over. Actively budget time for refactoring, paying down debt and improving infrastructure. This shows the team you respect their craft.
3. Don't tolerate fire drills and constantly shifting priorities
While business needs can change, a constant state of emergency will burn out your team. When priorities shift daily and the project they've poured their energy into is suddenly de-prioritised without clear reason, it creates a sense of futility. This whiplash effect makes it impossible to plan work, maintain focus, or feel a sense of accomplishment.
Work with product and business stakeholders to establish a clear, prioritised roadmap and communicate changes with transparency and a strong rationale. When an urgent issue does arise, clearly define its priority relative to existing work. Predictability allows a team to build momentum and derive satisfaction from completing what they start.
4. Don't treat them as a feature factory
A technology team is not a vending machine where you insert a specification and a feature comes out. If you treat them solely as implementers and exclude them from discovery and planning, you are missing out on their most valuable contributions.
Involve your engineers early. Bring them into brainstorming sessions, have them participate in customer interviews, and ask for their input on feasibility and alternative solutions. They often have a unique perspective that leads to simpler, more elegant and more technically sound solutions. When they are partners in solving the problem, not just builders of the solution, engagement and ownership increase dramatically.
5. Don't foster a culture of blame
When a production issue occurs, a deadline is missed, or a bug reaches a customer, the worst possible reaction is to ask whose fault it is. A culture of blame creates fear, which kills psychological safety. When people are afraid to make mistakes, they stop taking risks, stop innovating, and start hiding problems instead of raising them.
Cultivate a culture of blameless post-mortems. Focus on understanding the systemic causes of the failure, not the individual who made the error. Ask what went wrong and how we can improve our processes, not who did this. When your team knows they can report a problem or admit a mistake without fear of punishment, you create a resilient, transparent, continuously improving organisation.
Wondering what this means, in practice, for your business? Contact us to discuss.
