To unify or not to unify
Unifying processes or tools is always difficult and can even be a trap.
Truths
Truth 1
Simple tasks are easier to refine into a single best practice.
Truth 2
Software development is not a simple task.
Introduction
Over the years of coaching, consulting, and even as an internal hire there has been a singular common refrain more than any other.
“How can we get all of our different teams to work the same way?”
This team uses scrum. This team uses SAFe. This team uses kanban. Because of truth 2 noted above, I can also correlate that when working in an environment that is complex, there are multiple ways of work that are equally successful. Of course, there are multiple ways of describing success within a complex system and there are even multiple ways to be successful from the multiple points of view within that complex system.
What to do?
“Just because ‘the client’ says they need a bridge, doesn’t mean that you should design a bridge.”
The first activity is always going to be to dig deeper to understand the problem. You need to understand the point of views of many people in the system and not just the point of view of the person who brought up the problem.
This is a design problem…
… so treat it like a design problem. You need to figure out how to frame the problem in a way that works for all stakeholders involved. You need to be inclusive of all stakeholders to be sure that you don’t miss anything. You need to design the research. You need to find a way to analyze it. You need to have a way to turn this analysis into an action plan that aligns to as many of the needs of all the stakeholders.
What you can’t do, if you want to be effective, is to propose a single way of working and expect everyone to just follow it.
In my previous article I discussed a framework for learning and prioritizing, so I won’t repeat myself here.
Choose your path wisely
One of the biggest things that happens when people first get introduced to doing design research is that they confuse the symptom for the disease, and relief for the cure. There is a difference between taking a Claritin to stop sneezing and getting shots to suppress your immune response permanently. The same goes for this type of work, too. Now, this doesn’t mean you only look for cures and ignore relief, but it does mean you need to know the difference. You also need to measure if you have enough fingers to plug all the holes in the damn (mixing the metaphors is fun). This is to say, I definitely need to make sure people are taken care of right away, but while I’m doing that I also need to work on initiatives that fix the issues permanently. To do this you will need a mix of short-term and long-term initiatives.
Prioritization is your best ally
Unless you prioritize you really aren’t creating a viable plan. Prioritization is difficult but it keeps you and your team sane, and on a steady course to success.
Priorities can change. They are not immutable at all. Doing the work itself is a learning exercise. Outside forces swoop in with their own agendas and needs. Sometimes these are arbitrary and sometimes these are rooted deeply in the business. This is to say, do the work of prioritizing, but don’t hold to them absolutely. Rigid things break more easily than flexible things.
Solve their problems
You want to make sure that when you do have ideas that you are addressing THEIR concerns. You can also reframe your concerns in a way that they are motivated by.
Help me help you.
— Jerry Maguire
Some of the things you might hear from your teammates is
“It would be great if I can see the program planning of team X.”
“Dependencies are important for me to know.”
After those moments you can then ask the question, “how do you think we can make that happen?” This way it becomes something you are all motivated to solve together and they begin to understand how your problems are really their problems.
Examples over directives
Even if you can get people motivated for the idea of unifying tools and processes there are still obstacles. As noted above it seldom works out to tell people what to do. They end up feeling micro-managed or that their opinions are not respected. Besides, they are doing the work and they know how they work best.
The best path forward for the reason of adoption and to make sure what is being is proposed will be executed successfully, you want to start small before you go wide and big. First, start with one team. Make a pilot and turn them into a case study of success not just of adoption, but also of meeting the success criteria of the initiatives the changes are being done.
But don’t only turn it into a case study, turn it into a playbook that any team can take up and use but also make their own. In this playbook, include principles and goals, so when people start amending their playbook, they do not prevent original goals from occurring.
Coaching and management
People will be making changes to the original playbook. That is great. They will implicitly be running their own experiments and the different teams will be teaching and learning over time about how to constantly improve.
The role of a Design Program Manager/Design Operator is to keep everyone moving forward and constantly improving metrics that help meet team and business goals. For teams that might be struggling to do so, you might want to step in and help them more directly in a coaching role, or maybe as resources and priorities allow, as a temporary program manager for the team. Regularly facilitate meetings with design team leads to share success stories and challenges where everyone gets to learn and help each other.
Middleware over unification
You may find that your solution is not to unify. That there are too many stakeholders to try to unify and too many blockers. That doesn’t mean that you are out of luck. It means you have to re-think your “bridge”.
Is there something that can be a connector?
Is there a way I can get all of my team’s systems communicating using the same data mapping, so I can use my own system to connect to their data and make use of it to more closely and more easily achieve success criteria?
This may have its own challenges, but it is definitely better than rationalizing exports into excel files each with their own data models. Tools like Airtable, Notion, Coda, and Smartsheet might fit what you need with the smallest short term effort.
Conclusion
In the end, unifying tools can be problematic on social and technical levels. Sometimes you have forcing functions that help you make decisions, like money, or IT governance. Regardless there are reasons for unification that may or may not be required to make business objectives. The questions then are how you make those objectives with the least amount of friction as possible. Being intentional, collaborative, and focused on principles, values, and goals will bring about the greatest success.