Launching product delivery teams is a significant endeavor and the mindset doesn’t just shift overnight. Much like a weight loss journey, there is planning, monitoring, adapting and continuing need to cultivate the desired outcome.
Most teams will appreciate and look forward to the owning an area of the product and you can capitalize on that energy and enthusiasm. However, as humans, we’ll naturally fear what we don’t understand, and even those who don’t shy away from uncertainty will likely have some fear about the skills that will need to be developed to work in this manner.
Note: I’ve seen some folks be resistant to this change because it places a high amount of accountability on all team members as the team succeeds or fails together – gone are the days where Engineers can just blame “bad requirements,” Product can just blame the “customer,” QA can just blame the Engineers, and so on and so on. Alternatively, everyone simply blames the process and status quo. My advice for this is to have compassion and kindness and do whatever can be done to create psychologically safe environments to support folks through this change.
So, we’re at the point where we have the end in mind – a beautiful map of all the product domains/areas, with goals/outcomes and KPIs, and the team members who will be working on them. We just hold a meeting and roll it out. Right? Surprise – No!
Below are some musings on what I’ve learned helped support this transition:
- Product Principles – establishing principles for the teams to consider when working and also establishing non-negotiables – usually, things like “safety/security” and “don’t hurt the brand.” Disney has some great principles as an example.
- Training – not just “agile” training, but product training – story mapping (Jeff Patton’s work is awesome), value stream mapping, discovery training, etc. Create the epiphany that it’s not about following the process but understanding and testing/validating/invalidating assumptions about customers and the value work provides. Agile training is important too once it’s decided how the teams will operate – most companies go with Scrum. Check out Marty Cagan’s Dual-Track Scrum process.
- How the PMO Director can help – because you’re likely in an agnostic position, you can look at the training plan holistically and ensure that all groups have the necessary training, no “oops, we forgot QA!” If your company has an internal training team, also leverage them because they know your organization best; however, bring in the various experts as the SMEs for the actual training content.
- Job Descriptions – whenever the process is selected, and likely adapted (it’s okay all companies do this), there will be roles that folks play on the team, which may or may not match their current HR title. While the role that a person plays on a team can be independent of their HR title, there may also be some changes needed. Because you’ll have insight into what the person should be doing on the team, you can work with the functional manager and HR to ensure that the title is updated appropriately – or at a minimum the responsibilities that come with the role that they’re playing on the team don’t conflict with their current job responsibilities. This will also aid hiring (recruiting will love you!)
- Individual Performance Objectives and Plans – each functional manager will need to review these and ensure that they are not in direct conflict with the team goals. You can also decide if you want to adapt performance objectives to include some that are based on team performance.
- Utilization Understanding – establishing the mindset that if someone’s on a product delivery team, they are 100% utilized. Do not give them anything else to do – even if you go by their desk one day and they’re reading the news. If the team is not hitting their goals or appears to be over-staffed, that’s a different story, but if they’re adequately staffed and hitting their goals, leave them alone. No more resource levelling!
- Infrastructure, Code Architecture and DevOps – I covered this briefly in the previous post. There is likely some work to be done to enable the teams’ delivery with automated testing, CI/CD, etc.
- Process Documentation and Training – documentation of the process and associated ongoing training, maintenance and updates. Write down just enough to explain the principles, how things operate and what’s expected of each role on the team. I usually think, “if I was explaining this to a new person on the team, how would I do it?” Don’t overdo it on the documentation, if it’s a thousand page manual, no one is going to read it. Have it in a centralized place and keep it updated. The PMO Director can specifically help, much like with the Training, to make sure that all groups are appropriately represented and covered.
- Give teams the benefit of the doubt – don’t just throw them into the deep-end of the pool, however, we as humans need a little trial-and-error when learning something new. Think training wheels. Being too protecting and sheltering is just command and control in a seemingly positive light; this especially shows up when there is an over-emphasis on process and methodology vs. mindset.
As a PMO Director, you can help keep track of the execution plans against these (and many others), remove blockers, enlist help from stakeholders, communicate progress, reflect and adapt to change to the plan, etc.
Some companies choose to create a Transition/Product Development Enablement team made up of all the functional leaders and is run like a durable program team to implement, monitor progress, and continue to enable the product delivery teams in a servant leadership model. The PMO Director might not only be the facilitator of the group but also apply some program management tactics.
See any other areas that I’m missing? Please let me know.
Previous: Evolution to Product-Based Teams Next: Functional Managers
Shortcut: All PMO Directors Series Posts