My colleague and I just can’t seem to see eye to eye and I’m not sure how to improve our relationship. Can you help?
Dear Maria,
I’m an engineering manager in a tech company and my relationship with my product counterpart is strained. They like things planned out, whereas I like to do things quickly. There is so much back and forth when we tackle something in the team. I hate to say it, but at this point, their questions and “what if”s are just getting in the way. I want them to fill any knowledge gaps independently and just understand what needs to get done.
Here’s an example: we’ve been working on a continuous delivery project that I consider purely engineering work, but that they also perceive as product-relevant. This is slowing down the project. They should take the time to research the concept and beyond that, just get on board with the engineers.
––Stevie
Start by reflecting: Why is this a big deal?
Dear Stevie,
That was a lot of “just’s”! It can be frustrating not seeing eye to eye with a colleague; even more so in a leadership position, with the added weight of being ultimately accountable for the results of the entire team.
Moments like this are often a blessing in disguise both for the project’s success and our personal growth.
Before we go any further, I want you to take 30 minutes and a piece of paper and ask yourself: what is this situation bringing up for me? Which of my deeply-held values do I feel is at risk and do I want to protect? You might well find that certain things on your list will be linked by a common thread to each other. To use a made-up example: it’s understandable that “I value success and achievement” would connect to “I worry this project is moving too slowly”; it can feel that the slower speed is a sign of the project failing. Either way, nothing’s “good/bad” or “right/wrong”; it’s just information.
Once you’ve arrived at a conclusion, use up some of that 30 minutes to empathize with your product counterpart and try to understand what they might be hoping to achieve. Assume positive intent and write your theories down.
This is important; it will give you a clearer view of the situation, the perspective that you’re coming from, and, deep inside, what you’re trying to accomplish.
An additional perspective to try
I want to add something to your point of view: often, things we frame as “or’s”, are actually “and’s”. That is, there doesn’t have to be a power struggle between one thing or another. Instead, both things can coexist.
In your case, the structure and planning that your colleague is seeking isn’t an inhibitor of speed; if done right, they complement, not cancel each other. Product and engineering are rarely isolated from each other. In tech, this is especially true. Implementation decisions often translate into user value, even if that means the team can work more efficiently and ship that value sooner. And vice-versa; the product vision informs engineering decisions, be it architecture decisions or the team’s process of how tests run and features get delivered.
I’m not saying this to invalidate your experience. But I bet there’s more overlap in the things you both care about than you might think.
The next step: Have a retrospective
Much like a team can benefit from frequently reflecting on how they work together, what they prioritize, and how they execute on it, so can you two. And just like in a team retrospective, the key is to work jointly on the problem, not to place blame.
Put in a 1:1 with your colleague on the calendar. Say, “Hey, I want to share some observations on how we’re working together, and hear your views too. Would this be a good time for you?”
Here are some things you could do in the 1:1 meeting to bring about progress:
- Be open about what’s important for you and what it is about your working dynamic right now that’s making you uneasy.
- Then, listen and ask questions. What is their perspective on the situation? In their view, what is working well and what do they wish they could change?
- Find a way forward, together. With the cards on the table and an honest discussion behind you, come up with a plan of how you’ll team up to make sure the project is successful. Some prompts: list out what jobs need doing, what skills are best fitted for each, what other bases need covering to allow the team to focus, what each of you can own, and how you’ll keep in sync.
- Lastly, but maybe most importantly, come up with a plan of how you’ll bring up concerns to each other when (not if) they come up. How will you both check in on this going forward? It’s possible that it will take more than this one conversation to feel fully in sync with your colleague; having a feedback loop in place is key to the change sticking.
The best thing about working with people from other disciplines is the variety in perspectives, which in the end makes for both better teams and better products. This can be hard to navigate if it feels like you’re pulling in opposite directions. By focusing on what’s common, communicating well, and iterating just like you’d do on a codebase, you can turn this into an awesome working relationship.
–– Maria
