End an engagement

It would be unfair to say that Devbridge always wins. There have been several instances in our history where we didn’t follow our process, didn’t stick to our gut, compromised on our values, and the project failed. We can reduce the number of times we stumble, but even when we take ownership, some things are out of our control.

The cornerstone of everything we do is trust. Failure in an ecosystem saturated with trust is tolerable, but failure on an entirely new account and project rarely recovers.

I genuinely believe that a person’s character originates in these moments of failure and hardship. While some give up and are easily defeated, others rise to the challenge. We can’t change the minds of people who harbor ill intent in their hearts, but those who want to accomplish great things are eventually won over by our relentless pursuit of results.

We partnered with a tier-one bank in the US. The client was a whale of an account for us—so naturally, we felt overjoyed by the possibility of working together. We were so focused on maximizing revenue that we lost sight of our process to accommodate deviations that would lead to disaster.

  • We had to physically walk source code over to the client’s Chicago facility.
  • We were forced to use an outdated front-end framework because that was the approved asset in the corporate toolkit.
  • We agreed to cater to multiple stakeholders and business units, without a single clear champion.
  • We ignored poor demo attendance.

As a result, not a single release reached the market, effectively neutering our ability to demonstrate value by releasing working software. The work was eventually taken away from us and handed over to internal teams.

Most of the failures in this scenario are not related to our team or the work we did, so it may seem like it was a cause not worth fighting for. And perhaps there was not much we could have done, but I like to think we learned something from the experience. We need to stick to our process. We’ll act faster and escalate sooner with the next client.

Exiting with grace

The end of a project is not the end of the relationship. A perceived end of a relationship is just a temporary break. To date, we have experienced several large clients changing their partnership strategy owing to economic climate, a planned market event (e.g. going public and saving costs), or a new executive bringing in his or her own preferred vendor. In most cases, we are able to recover and reengage.

It may seem far-fetched and it may take a few years, but there’s strength in persistence and consistency. Proceed with grace and professionalism. Don’t destroy a relationship. Always exit with your best qualities on display.

Here are a few best practices to follow when a graceful exit is needed:

  • Knowledge transfer. The team taking over the project will likely struggle. The general level of competence in our industry is low, and we play at the peak of performance. Be courteous and accommodating, never resist or impede progress of the transfer.
  • Documentation, artifacts. Provide well-maintained assets such as Confluence documentation, technical architecture, Jira data, and any other materials that would demonstrate our maturity. Demonstrate our code review process and how information is stored in pull requests.
  • Recommendations to succeed. Assemble and present a list of impediments and recommended changes to make the client successful. Even if we’re not doing the work, our sponsor is our ally. Enable them to win, and they will pull you back in again when the time is right. We have a template for this type of deck.
  • Post-transition support. Offer critical support even when ongoing delivery has been transitioned to internal teams or other vendors. This gesture in good faith goes a long way.
  • Demonstrate intent to win back the work. Always persist and offer to take back the work. Acknowledge issues of the past, demonstrate how the future will be different. There’s safety for the client in the knowledge that we’re not abandoning the project and will be standing by if something doesn’t work out with the new strategy.
  • Allow competitors to fail. This business is not a charity, and we shouldn’t save mediocre vendors from their own failures. Document and advise the client of poor performance in a courteous manner.

Example handoff assets

Example of a detailed feature and approach summary

Example of documenting features completed with build measure learn model and checklist of what was done.
Example of documenting features completed with build measure learn model and checklist of what was done.

Timeline overview noting kickoff - production – release

092 example of project breakdown over time

Example of slide noting recommendations & outcomes

094 example of reccomendations and outcomes

Provide imagery highlighting the work

093 example of product with advanced filters

Example of final deliverable list

095 example of final deliverables

The Secret Source by Aurimas Adomavicius

About the author

Aurimas Adomavicius is the president and co-founder of Devbridge. When not in the trenches working with clients, Aurimas is an active speaker and writer on product design and engineering best practices.

Get in touch