Recently Akrem and Erick presented Consulting 101, an annual presentation delivered at a Source Allies University event. We are publishing a three-part blog series that is a distillation of that presentation; Agile Crash Course, Team Dynamics, and Partner Dynamics.
Part 3: Partner Dynamics
When we work with our partners, our goal is to be their ally for delivering high-quality software solutions through our strong work ethic, ownership mentality and expertise.
Naturally, fostering a strong relationship with our partners is a very important part of how we achieve that goal and we will walk through steps you can take to build and maintain such relationships.
Find the Purpose
Just like it’s important to understand the goal of building a software solution before building it, it’s also important to understand why the partner chose Source Allies to help them build it.
It could be that they don’t have the capacity today to do it themselves. Sometimes a partner wants us to demonstrate how an agile team operates so their other teams learn from it. Another common scenario is that they need outside help to accelerate an ongoing effort. Some partners look to leverage our expertise in certain technologies and paradigms that are new to them.
You might be wondering “Why is knowing this is important?” Well, the truth of the matter is that those reasons are additional expectations the partner has from the project. For example, if they chose us because they lacked expertise in certain technologies, then we need to make sure we’re educating them along the way so they have that expertise.
After we understood their reasons, then we we need to ensure that those expectations are documented by either amending our working agreement (from Part 2), capturing them as stories on our backlog (from Part 1), etc. The final step, is that we deliver on those expectations.
It’s crucial to engage with key project stakeholders early on and work with them on articulating their definition of success for the project. Start by identifying those stakeholders like project sponsors, product owners, internal users, leaders, or other engineering teams.
Then we can have conversations with them to nail down what their vision of success look like. There might be certain goals to be achieved in three months or there might be certain milestones we need to hit.
During conversations about the definition of success, identify potential roadblocks and dependencies. It is important to have a dialog about these risks as they will impact your teams’s ability to be successful.
From our experience, building rapport and trust with the partner helps projects run more smoothly and aids in communicating transparently. Initially you need to know the role of different stakeholders on your project and you need to build a relationship with them (specially those you work with frequently).
Whenever you get the chance, ask them individually about their own personal goals, aspects of the project they are passionate about, what speed bumps they anticipate, etc. Also ask questions, show interest and commitment. Knowing and engaging with them will help you identify and leverage partner’s domain knowledge and experience.
Pro Tip: Regularly solicit feedback on the team’s work.
Credibility is something you earn and accrue over time. The quickest way to build that credibility is by doing quality work, investing time in learning the tech stack, and understanding the reasons behind architectural decisions made so far.
After you have understood the problem space and how the partner went about solving it, you will be equipped with the necessary context to advise them on next steps and enhancements. Further, keeping that context behind past decisions in mind will help you build upon the partner’s expertise instead of starting from zero.
Pro Tip: Also remember to deliver value and demo frequently.
Building rapport, opening lines of communication, establishing a history of credibility do not happen overnight. It will take time and commitment.
You will need to be especially patient after setbacks. For example, if your proposal is rejected or your suggestions do not get traction with the partner.
So what do you do when the partner makes a decision you disagree with and you were not able to change their mind? Well, be positive, disagree (tactfully) and commit to that decision. You can say something like “I understand the reasoning behind the decision and I’m fully behind it. I wish we’ve had gone with a different approach. Nonetheless, I’m fully committed to making the decision succeed.”
Pro Tip: Avoid saying “I told you so” when a solution you disagreed with didn’t succeed.
It’s worth pointing out that influence is earned through actions, behaviors, what your team delivers, and how you treat people. They need to experience first-hand how you work, your expertise and your professionalism. After that you will find that your suggestions are getting more serious consideration.
Don’t Walk Alone
As we discussed so far, building rapport and credibility takes time and you might not succeed in your first few recommendations and proposals you make to a partner.
One thing that will help you speed up and get to your goal faster is to leverage your fellow Source Allies teammates whether they work with the same partner or not. Those teammates might have ran into similar difficulties, worked with a similar partner, have expertise in the tech stack you’re using.
So building relationships with your Source Allies teammates is crucial. We have a vibrant and supportive community in-house which you can reach out to and get to know. They will also be more than happy to share their experience and knowledge with you and even be a sounding board for your ideas.
If you’re not sure where to start, reach out to your account manager or onboarding buddy and they will be able to hook you up.