5 things happened after measuring our design maturity
I am a design leader for Cisco Secure (the security division at Cisco). A large part of our strategy is focussed on the radical simplification of cybersecurity products and we wanted to make sure we had the right skills, tools and practices to deliver on that strategy.
We were inspired by the InVision design maturity model and decided to use it as a way of measuring delivery teams (sometimes known as a squad) across the organization to understanding where we could up our game, and where we could highlight behaviours worth celebrating.
Here are five really important things that came out of that program.
1. Open conversations about design
Rolling out a program for measuring dozens of delivery teams was a lot of work, but the resulting conversation made it worth while. It was a great way for the product managers, engineers, and designers to review their maturity scores, talk about their strengths and weaknesses, and ultimately discuss how to get more value from their design partners and deliver more value to customers.
2. Back to Basics
Based on the above conversations we recognized that we had to go back to basics. We have a large organization (over 3000 engineers, hundreds of product managers). There is a lot of diversity in the way teams work. Many teams didn’t understand how to get the most value from their designers, and didn’t know exactly how to engage with designin the right way and at the right time. Design terms/language was often misunderstood and there was a lack of awareness for who is responsible for what. We needed to focus on some fundamentals.
3. Establishing a RACI between design, product management and engineering
RACI stands for Responsible, Accountable, Consulted and Informed and its a great model for understanding how teams are meant to collaborate with one another. We are using RACI to evaluate and align on how product managers, engineers and designers work together. As teams move through the software development process we want real clarity on what each role is responsible and accountable for, where do they just need to be consulted, or simply kept informed. Documenting this promotes more conversation, leads to stronger teaming and ultimately improves team velocity.
4. Integrating into the business process
OK, lets be honest… designer friends… do we ever feel like we have enough time to do design research? Not often right? Well we realized that business process might be the answer. Recently we have modified parts of our process where we review roadmap items and commit to starting new work. Design is now an active participant as early as what we call concept and business commit. This is our chance to highlight the things WE care about – like research questions to answer, assumptions to test or risks to mitigate. We can also help to ensure the customer is well represented, and problems are well defined.
By engaging with the business through process, and helping our program management colleagues understand when/how we need to be engaged in a project, we are given the time we need to do our work.
5. Introducing a design producer role
Last but not least, we realized that in order to do all of the above, consistently across many teams, we needed to add a new role to the team. We have recently added our first design producer – read more about that here – and plan to add more. The producer is the glue that holds it all together. They ensure we follow our own RACI and process, and they make sure we have effective communication both inside the design team, and outwards to the broader delivery team.
All of the above came as a result of taking time to be reflective, being honest about where are are, what we need to focus on, and who we need to collaborate with. Sometimes we had to swallow our pride, and other times we got to celebrate our greatness.
I encourage all product teams to spend some time thinking about these things.
Some resources you might find useful: