Nobody likes a backseat driver.
One of the challenges with global Drupal agency partnerships is the assumption that the onshore partner is the subject matter expert, and that they should always be in the driver's seat, so to speak—no questions asked.
The problem is though that partnerships, Drupal or otherwise, can crash when one out of two is silent. When one follows, unquestioning, without lending consultative advice on key elements, this is not a partnership; it’s more aptly described as servitude.
The assumption that offshore Drupal partners are doers, not thinkers, is harmful and wrong. Harmful to the offshore agency of course, but also to their onshore agency counterparts. And most significantly, to end-clients themselves. Wrong? Because there's proof of Drupal consulting success within stories like these.
The voice that is willing to disagree is the voice of a partner. This is the voice that helps drive positive change. Consultative problem-solving with Drupal, questioning assumptions, and pushing back is ultimately to the benefit of the end-client. It helps set realistic expectations, create alignment between partners, and generate greater buy-in and commitment to the long-term vision.
Pushing back and saying no hasn’t been characteristic of offshore agencies. However, as globalized marketplaces become even more connected, with learnings diffusing across cultures, timezones, and companies, this is changing. Meaningful, ROI-focused Drupal consulting is becoming the path forward for agencies looking to grow.
Empathy and curiosity are key to success.
Successful engagements are about more than asking for a scope document and delivering exactly what’s expected. It’s important to look past shipping code into the real business need. This begins with asking the right questions.
We spend a lot of time trying to understand our clients, stepping into their shoes, talking about how their business is doing, their recent activities, where they are headed, and how anything related to digital could potentially help them.Sreenivas, Success Manager
Understanding the competition, how clients differentiate themselves in the marketplace, what new trends or challenges are on the horizon for them—all this helps create a holistic picture for the team working on the end product, allowing them to focus their efforts in the most productive directions.
“Drupal problem-solvers can’t just be doers,” says Prateek Jain, Engineering Manager at Axelerant. To offer impactful services today, engineers need to actively engage in value-driven Drupal consulting—understanding the client’s need, and being able to identify practical, realistic aspects of the task at hand.
“They need to be comfortable playing in the grey areas between what’s idealistic and what’s pragmatic, and knowing what tradeoffs generate the most value for the end-client.”
The "success management" framework has to be the epitome of the Drupal consultative approach by design.
Our success management approach takes into account that change is the only constant, since people, technology and process are evolving everyday, which necessitates continuous learning and evolution for support teams to be able to keep up. And through a consultative approach, we help our partners and end-clients keep up too.
Sreenivas recalls an incident from a few weeks prior to co-architecting a partner success framework, where a partner gave the Axelerant team a relatively low Net Promoter Score (NPS) rating of 6 out of 10.
We conducted open discussions with all our partners to find out more about how they perceived the partner relationship with us, and to learn what could be improved. We took note of any areas of improvement in both process and culture as items for us to proactively work on.
“We mentor our team members on these aspects,” says Sreenivas. In interactions between team members and partner stakeholders, the team is encouraged to be empathetic and proactively consultative at every step. They’re asked to consider whether the solution approach is in the best interests of the partner, and whether the effort estimates have taken into account a 360-degree view of the project, and would reliably prove to be accurate.
By communicating these aspects openly with the whole team, earning the client’s confidence became a shared objective.
Sreenivas utilizes a success framework dashboard in all his meetings with both internal teams and partners to set the agenda, to define, implement and monitor the effectiveness of success plans, risk management, feedback, and change management.
“We wanted to show that we are not just doers. We think from experience and learning before we do, and estimation isn’t just a formality for us. We'll ask questions, we’ll state and validate our assumptions, provide a summary of all discussions, and then offer an estimate,” says Sreenivas. “And then we’ll track our performance against what we have committed to.”
Being consultative builds trust.
Over the next few months, the NPS rating went from 6 to 8—to where it's currently is, at 10/10.
“They trust us more and more now as a reliable partner, which has come through sustained effort, not by accident,” says Sreenivas.
In the digital world, and certainly in Drupal, things change and evolve all the time, and you can’t build trust on stagnation. Partners have to try to understand: what are the client’s preferences? What are their limitations? Why do they need this deliverable? How do they operate, and who are the stakeholders?
Only then can they begin collaborating, designing, and validating initial output.
In one case Prateek recalls, the team realized the client works for federal clients, and had specific preferences per tech (proprietary software). They had to drill down to identify what was needed, and in the end, they were able to offer an alternative—a product that the client is now using, which replaced their proprietary system.
Prateek says: “One benefit of having a partnership built on a foundation of trust is that when there is a mistake—which there will be—they’ll stay. That trust can only come over a period of time through being consultative, and being open and transparent about our approach.”
In spite of significant changes and an aggressive deadline, in this particular engagement, the team went beyond what was expected, wanting to ensure the client’s success, first and foremost.
Most of the time, it’s simply about doing the right thing.
Sreenivas remembers an epic on a particular engagement where the partner Program Manager was building pressure on our team to agree upon a commercial contract with 30 percent lower estimates than estimated by the Product Owner and the partner’s Technical Architect.
Instead of succumbing to the pressure or just refusing, our team took a consultative approach. The bottomline was that committing to doing something in less time than it should take would not have solved the issue at hand, and would have resulted in a loss to the end-client, Axelerant’s partner and Axelerant.
In order to facilitate a win-win situation, the team organized a joint meeting with the partner and end-client Product Owner, and encouraged deeper scope discussions from both the business and technical perspectives. Upon asking proactively, the team was allowed to provide an alternative solutioning approach that could reduce estimates and meet the Product Owner’s budget requirements.
“We were able to give them a different perspective altogether which they hadn’t considered,” says Sreenivas. They’d considered only a front-end approach to achieve a certain standardized look and feel on the homepage. A pure front-end approach would have needed far more effort via trial and error to achieve the desired results, and would also have added long-term maintenance needs.
The Axelerant team highlighted that by using a combination of front-end and back-end development together, the desired results could be achieved with less effort and a lower cost, while almost eliminating maintenance needs.
“Our main objective was to provide the best solution that could render the desired results, and do so at a reduced cost,” says Sreenivas. “We simply considered whether we were opting for the right solution, getting to the root cause of the issue.”
Oftentimes, the end-client is a huge organization, with a huge vendor ecosystem. “If we don’t consciously choose to do the right thing for the end-client in these situations—it’s not just the end-client who loses, it’s a loss for everyone, including our partners and ourselves,” says Sreenivas. “The fact that we take success for everyone seriously is why our partners have really trusted us.”
Pushing back can be hard—but conflict is generative.
When there are many stakeholders—with different capabilities, different skill sets, and different maturity levels—coming together to work on a project, conflict is a natural outcome. Everybody’s trying to bring their perspective forward and make what they believe to be the right decisions.
In the middle of this, being able to respectfully disagree and steer the conversation in a productive and mutually beneficial direction is hard, but essential for real partnerships to be as successful as possible.
Not being able to do that would pose a significant disadvantage to the engagement as a whole—when communication breaks down, projects fail—and would have a negative impact on offshore partners’ growth as well.
It’s relatively easier to push back if you have already earned your partner’s trust. That takes time and moments that test the relationship. It can be extremely difficult to stand your ground when partners don’t already know your work.
A better approach might be one where we say why we disagree. Such suggestions must come from the team, but the decision must ultimately lie with the PO.
Rather than agreeing to go along with what appears to be a bad call, he believes partners should be open with each other and explain why they think something could be done better. Vendors may have to concede to going ahead even if they don’t agree, but airing different perspectives early will be to the benefit of the engagement.
He believes it’s best when all stakeholders can be honest about any potential challenges, have hard conversations together, and make the decision consultatively, rather than any one party taking that call in isolation.
But is this approach right for every project?
“This depends on the project and the client. Sometimes it’s important to just get the job done,” says Prateek.
Drupal consulting partners need to wear multiple hats. “There is a certain time when you need to be consultative, and there are other times when you need to just focus and go. It’s important to understand when to do what,” says Prateek.
He recalls a time on an engagement when one of our partners needed a particular feature built in a couple of days for a demo. The Axelerant team reviewed the requirements, and felt it would need at least a week to build, and doing it the way the partner had suggested might not be the best architecture.
But since the demo was important, the team went ahead and implemented it the way it was needed for the demo, knowing that this wasn’t the best architecture. Later, they fixed the architecture and everything went well.
Sometimes, timeline pressures, budget constraints, or certain custom feature requirements can make it necessary to just go ahead and implement certain aspects.
In another instance, a partner needed a particular feature needed to be built, and the requirements were clear, but the team didn’t really understand the value of it. They went back to ask the end-client why they really needed that feature. It turned out that the client was in fact looking for something quite simple, and that this could be achieved in a much easier way.
In place of the original solution, which would have required a lot of effort, the team proposed an out-of-the-box solution using Drupal that would solve 90 percent of the problem at one-tenth of the cost.
Suggestions like these allow clients and agencies to then refocus their investment towards more valuable activities. “If you care about customer success, these things come naturally,” he says.
Offshore partners as the Drupal agency’s agency.
Offshore partners may hesitate to push their opinions forward out of an unwillingness to undermine their agency partners’ attempts to own the technical strategy.
“I find it helpful to think of us as the technical consultant to the agency. It’s the same job, with a more limited scope,” says Prateek.
In the same way that onshore agencies function as the end-client’s consultative subject matter expert, offshore Drupal partner agencies function as theirs.
Rather than being involved in considering product trade-offs directly, offshore partners work more as technical consultants, helping agencies make architecture decisions, and identify what needs to be done. They still have to understand the requirements to the same level of depth, get the same clarity, understand the business, and its future.
“Asking these questions is what will enable us to build the right architecture into the system. We must do that. Otherwise how do we make sure that we’re building something that will endure?” says Prateek.
The customer is always right. Or are they?
In situations of conflict, if things go wrong, the ability to arrive at a win-win solution often comes down to a question of maturity.
When outsourced vendors are immature in terms of process or culture, it’s easy to blame the partner or end-client. It’s easy to conclude that it was simply a bad decision to work with them.
What’s harder is to consider the partner or client’s perspective from a place of empathy, to keep in mind their needs, their background, any cultural sensitivities that may be at play. And to see that in the end, every client is simply trying to contribute to their own project.
The choice then lies with the vendor: to push back, or to simply do as they’re told?
If you choose to take the easy way out, every time—in the end, people will know. Not being honest and transparent will hurt agencies in the long term. This should be obvious.
Pushing back is hard. It demands honesty and courage. But if you dare to ask: “How can we serve the client’s need best?"—if you dare to do the research, to ask the right questions, and make valuable suggestions, that’s where meaningful change begins.
That’s how better partnerships are forged.
Partnerships can only drive on two-way streets.
Partnerships have the greatest impact when communication flows both ways. This is what allows truly mutually beneficial relationships to take shape.
Which means that, as the vendor, as much as it’s important for our success managers to collect feedback from our partners, it’s just as important for us to be open with our partners about any challenges we’re facing in working with them.
If outsourced agencies genuinely care about their partners’ success, it’s plain to see that being open about any challenges is in everyone’s best interest, as it enables teams to solve problems and deliver their best. This will not only strengthen the partner relationship, but also enhance the end-client’s experience.
We proactively seek partner feedback from the team during internal project retrospectives. And while we do currently share our feedback informally with our partners, we have no official, structured process for this.
These streets are still being paved and repaved.
Realizing that we need a better way to give constructive feedback to our partners, we’re now trying to create a system for this. Having an internal system established would help us generate more value through our partnerships—for end-clients and for ourselves. While we have retrospective points that we share, creating more in-depth reports for them would be advantageous for all parties involved.
Drupal consulting services are diverse.
You have choices. And we are one. All things considered, this is what we believe it means to be consultative doers, not just thinkers—and certainly not just doers. It's a different approach, a global one, and it hasn't gone unnoticed.
Axelerant Editorial Team
The Axelerant Editorial Team collaborates to uncover valuable insights from within (and outside) the organization and bring them to our readers.