Chad Marais, Managing Director and Co-founder at The Gemini Solution, is challenging how tech companies treat client relationships. He believes developing tech systems is an inseparable part of building someone’s business, as opposed to just developing and shipping a product.
In this article, Chad shares how fewer deadlines, a better understanding of a client’s business, and letting developer’s participate fully in client relationships has helped him foster engaged client partnerships, and build better software.
Chad founded The Gemini Solution to be different to his experience of how companies operate in the custom tech solution space: Where-as tech solutions can easily be seen as ‘just a software product’, Chad integrates into a team, and partners with them to build their business into a software venture. He says that many people forget the impact that good rapport and an engaged, collaborative relationship have on the end result. Although it’s possible to build software without those things, he believes that it won’t have real impact on a business in the long-run:
“When you build a system, you are helping someone build a business. No matter how big or small the system you build is, you are always building business logic into it. You’re building business workflows, rules, conditions. You are creating a tangible, software-driven version of that business with a long-term commitment to its success.”.
In order to really impact a client’s business with the potential of software, Chad needs to understand their business inside-and-out, figure out the essence of the problem that needs solving, and be able to help client’s distill what they actually need from what they think they need.
That’s why Chad believes it’s really important to build a strong and engaged partnership with every client he works with:
“My clients become actively involved in the process”, he explains. They check in regularly with Chad and his team, and ask about things they’ve learned and where they’re at. This, he says, creates a completely different, dynamic type of relationship: “There’s a vested interest from their side, and you genuinely feel a connection, rapport, and openness. There’s a congruence there that you simply can’t get when you’ve got this ‘over the wall’, ‘I’ve handed you a spec, give me something in six months time’ kind of setup.”
In practice, this takes some intentionally different approaches to how things are normally done when outsourcing tech systems. These are, namely:
- Understanding the client’s business in granular detail
- Integrating developers into the client relationships
- Replacing hard deadlines with better communication
“Things can be resolved and worked through so much better if you’re dealing with a partner: With traditional ‘vendors’, everyone’s looking to win in their own right; when it’s a partnership, though, the congeniality and you two working together is what you both strive to make successful.”
Understand the client’s business in granular detail
Chad‘s team needs to know as much as they can about their partners’ businesses: Gemini’s mission is to help grow someone’s business, and that requires a deep understanding of what makes that business tick.
Before building any software or launching into ‘solution mode’, Chad’s first step is to thoroughly understand a client’s business:
“At The Gemini Solution, we believe the most effective way to work is to position ourselves as a life partner for our clients — someone who is going to understand them, understand their business model, understand their needs, and understand their budget restrictions.”
To do this, Chad does in-depth business research with his clients. The kinds of things he wants to understand, before scoping the project out in full, are:
- Who is their clientbase?
- What is their business goal?
- What are they trying to do with their current software?
- What kind of market gap are they trying to address?
Once he understands a client’s business and the problem they need solving, only then does he move into the next phase — namely, building a custom tech solution. This, he says, helps them work with a client to distill what kind of system they really need.
PRO-TIP: Communicate your expectations with a client from day one.
As important as it is to understand what clients want from his team, Chad communicates what he expects from his clients as well, right from the get-go. Collaboration is an active process; without this step, it’s harder to get clients invested in the partnership. Putting everything out onto the table like this, Chad says, means everyone knows what’s going to happen, and lets people ask questions and communicate openly:
That relationship just lets you get a far better understanding of what it is that that business needs, and that translates into your code.”
Integrate developers into the client relationships
One of the biggest ways Chad has turned the traditional client relationship on its head, and build ventures as partners, is to keep his developers right at the front of client relationships:
“Once I’ve brought clients into the company, I detach myself,” he explains. “In other words, I hand them over to the ‘unicorn’, right? This is the dev that can manage up and manage down.” Chad says that the ‘unicorn’ for a specific client becomes the primary point of contact, and through them, clients get a direct line to the rest of the development team.
Clients get to actively participate with the developers in building their tech system, which stimulates better client engagement, and also means that Chad’s developers get deeper insight into the client they’re building for. This mean they can think laterally about the problems they’re trying to solve:
“If my developers really have a good ‘feel’ for what that company is, and where that company is going, it helps spark more ‘dialled in’ solutions to those problems. They can spot new ideas, pick up on a conversation they had in passing, and think beyond ‘just a project brief’.”
Over the years, the biggest lesson Chad has learned is to just be a human being. In his experience, transactional relationships breed surface-level products; engaged partnerships, on the other hand, breed innovation, long-term relationships, and better businesses.
Replace hard deadlines with better communication
Too often, Chad has seen deadlines kill software projects. Teams drop backlog features because of an approaching deadline, and build whatever working MVP they can that aligns with the initial brief. Chad, however, doesn’t believe hard deadlines and end-dates are beneficial. In his experience, they risk that potentially ‘big’ improvements get skipped just so that arbitrary deadlines are met:
“I give people estimates, sure, but deadlines completely limit the impact of the work we can do together.”
By removing the complexity and pressure of hard deadlines, Chad and his team have more time to truly partner with a client. This enables building features that augment what they deliver, and features that are in fact often closer to what they really wanted to achieve in their project brief initially.
“As long as you communicate with them upfront,” he adds, “they’re normally happy. They see why that thing is valuable, so they don’t mind that it’s going to take a few more months.” In his experience, it’s only when clients are not engaged from the start that things go wrong: “It’s only when you don’t interact often, and then tell them two weeks before the delivery that it’s going to be an eight or nine-month thing that it breaks down completely.”