Almost every knowledge resource around program management or product management and even job description around these type of roles want the cross-team collaboration skill as a skill. Here’s what I have encountered in my experience as part of exercising this skill.
How do I know if this skill has worked?
Regardless of industries I worked in, I think these were the common elements with which you can evaluate this skill.
Discovery – Are we building the right thing?
In my very 1st company, I learnt this the hard way. I was a developer, handed over requirements. My team took a couple of months to build it, only to find out that it was not what the users wanted. We had not done a proper discovery with end-users. Needless to say, while time and money was lost, we had to fix our brand as well.
In later companies with better knowledge, I partnered with different functions to determine the product, they need. A product trio (PM, UX, developer) was formed to interview users. We also engaged with other teams (eg: medical affairs, marketing and sales etc.) as well to ensure that we had a good commercial plan for our product.
Regardless of OKRs of the company or initiatives, product teams should have the relevant inputs. Why is this important?
Trust is a fragile thing – hard to build, easy to lose!
M.J. Alridge
- You need to understand how product teams are related so that peers across teams can talk to each other.
- Excluded teams might think that they were excluded on purpose. If the culture is set such that product teams are included when the program/product manager knows about it then trust is built. As a platform product manager and team member in the past, I have experienced this. In a few cases, we easily understood that it was hard to make out that our team had to be included and in other cases we had our doubts.
- When all the necessary teams are included in the planning stage, then they are able to able to prioritize their share of work and prepare their teams for the same.
- If at a later stage, we determine that some team(s) were excluded then something has to change. We either change the scope that we commit to, for that deadline OR we change the timeline. Either option is better than delivering a half-baked product, especially in licensed industries such as healthcare, financial services etc.
Flawless execution
One of the things that one of my client managers said was “We have great ideas but what we fail at is Execution!”.
- If we have done a great job at planning then we can be transparent
with the related teams. We can consider great workshops with related
teams so that we can figure out the dependencies and challenges.
- In some companies, there are concerns that involving all the
necessary people would be too much in one workshop.
- Consider the reality – You need inputs from qualified people to reach your goal. In many situations, the reality was that there were too many new people in respective roles and so you don’t have any good outputs from those conversations!
- What happens when you just consider “titles” is that the initiative starts crashing, people get demoralized and you might just lose your best people.
- In other companies, the workshops are organized very effectively. You just have few related people in one workshop. And then, you can communicate outcomes of different workshops so that related teams can work together.
- In some companies, there are concerns that involving all the
necessary people would be too much in one workshop.
- We need to handle distractions, which you were unaware of when you in the planning phase. For instance, we need to upgrade infrastructure because AWS is retiring a technology.
Our intended users achieve the intended outcome
This goes back to how we have planned and executed our initiative! While our product teams have their share of responsibilities, we cannot work in a siloed manner.
- Different roles in our teams should understand what we are doing for
our end users.
- In other words, our end users should be able to use our product effectively.
- In my experience, many leaders considered deployment of their apps to production as success. But in my view, it is a big stepping stone but NOT the final goal.
- If they do that then they would be able to achieve their intended outcome.
How do I know that this skill has failed?
There are few definite indicators of this one!
No connection between the PM and users.
This leads to a “lost in translation” scenario. I have seen a few flavors of this case.
- In some cases, we had a lead PM talking to end users and communicating the requirements to other PMs. This didn’t give them everything what they needed for building their product. Instead, we realized that sometimes, we had an incomplete product, which we had to fix later.
- The lead PM was getting burnt out. Since most of the time, products were global, we had to talk to users in multiple time zones. So, if only the work of discovery was efficiently organized, we wouldn’t really have had this scenario.
Chaotic environment for the company
This is the case for practically all employees, when they have no clue of what is happening.
- With ineffective communication, employees might be afraid of losing their jobs.
- They might be stepping on each other’s toes, just for job security.
- There is blame game instead of fixing the situation because the team doesn’t trust the leadership.
Uncalled urgency for teams to meet deadlines
Teams are working 12+ hours a day to meet deadlines only because they were engaged late in the game. Happy realization for me – Early in my 1st company (when I was a developer) in 2004, my team practically stayed on company campus and went home only on weekends because our sales executive had promised them software to be built in 6 months when realistically no one had asked us for an estimate. It took 3 teams realistically to work this for a year. Cut to 2024, I have a PM from another company telling me a similar story. He has been put on 6 teams and works for 12+ hours a day. The lead PM isn’t effective in his situation.
“Poor planning on your part does not constitute an emergency on my part”
Bob Carter
Final thoughts
Cross-team collaboration along the journey is important when multiple teams are involved. Let team members share their ideas because you get the best product when you get multiple perspectives!