Putting Learnings into Practice — DesignOps Summit 2019
Hi, I’m Jenna 👋, Design Program Manager at AppDynamics! At the end of October, I traveled ✈️ to Brooklyn, NY to attend Rosenfeld’s 4th annual DesignOps Summit. Having been the sole DPM on my team for over a year, I enjoyed the freedom of being able to define DesignOps for our team and focus on the projects I thought were bringing the most impact. But, I still felt like I was missing some key pieces that would really help move the needle on how to make Design at AppD the best it could be 🤔. I purchased my ticket for the DesignOps Summit the second they were released, hoping that by immersing myself for three days around other like-minded DesignOps folks, I’d be able to figure out how to take DesignOps at AppD to the next level.
The website promised two full days of engaging speakers providing case studies, tools, and techniques that we’d be able to implement and use as soon as we got back to work. The talks focused on three main themes: Proving Value, Measuring Outcomes, Partnering Outside Design, and Change Management. Rosenfeld held true to their promise! After returning to San Francisco 🌉, I immediately got to work on putting my learnings into practice!
Learning 1 — Create a baseline and continue to measure against it
One of the first speakers of the day was Diane, a Design Program Manager from Pandora whose team was struggling with ambiguity, instability, and uncertainty after a recent acquisition by SiriusXM 🤷. To address these issues, they decided to create a playbook that covered the team’s roles, responsibilities, workflows, processes, systems, tools, and more. To ensure that the playbook was adding value, they first surveyed the team to create a baseline of how clear things were today. Once the playbook was rolled out, she resent that same survey to see how much clarity the playbook brought📈. The playbook ended up being a huge success and increased clarity on her team by 30%. By creating a baseline and measuring against it, Diane was able to turn feelings into metrics and quantify the success of the playbook.
This was a big “ah ha”❗moment for me and a great reminder to take the time to measure where we’re at before making changes so we can really know if what we’re doing is moving the needle. When I got back from Brooklyn, I had the team complete a skills wheel. This gave the team the opportunity to assess where they felt they were currently with different skills and also where they’d like to be. The team was able to reflect on their skills, while also giving me insight into where the team felt weaker and areas they’d want to improve upon. After collecting the wheels, it was eye-opening to see that the majority of the team wanted to improve their skills in UX analytics, inclusive design, and communication. Being aware of the team’s interests has allowed us to tailor the skills and growth workshops we’ll host over the upcoming months. Additionally, since we now have this baseline — after trainings or workshops, we’ll be able to ask folks to assess themselves again and measure what impact they had on skills growth ✅.
Learning 2 — Aligning on how we got here is just as important.
The second big lesson came when the Head of Design at Atlassian, Alastair, started debunking myths of cross-disciplinary collaboration. The myth starts when teams get together to begin a new project. They align themselves on what they want the solution to be and how they want to get there, but as they start marching into a sprint cadence, they realize that the problem is much tougher than anticipated 😔.
If teams start with a shared understanding of how they got there and why the product or feature is how it is today, they can create a sense of purpose and fully understand the product’s journey in order to move forward.
This really resonated with me 💡. Our product has gone through lots of iterations and changes over the years. The reasons for those changes and decisions have never really been documented or explained. To combat this, our team instituted Design Worksheets 🗒️. These became a common tool the entire team could use. We intentionally made them lightweight and flexible, giving designers enough structure to document who was working on projects, highlight the work that was being done and why certain decisions were being made without overloading the team. This allowed us to describe work from a design perspective🖌️, instead of leaving the documentation up to a TPM, PM, or someone else who might not capture all of the design specific decisions.
When rolling out worksheets, the team was a bit hesitant and concerned that adding in a worksheet would create unnecessary workload. We went through multiple iterations trying to find that sweet spot of including enough information to make them valuable, but not so cumbersome that designers felt they were spending hours upon hours trying to maintain them. We finally landed on a format that gives the team flexibility to keep the worksheet to just the basics (who’s included, why decisions were made, etc.) or go all in and include links to assets, all meeting notes, and more. Both versions give teams insight into why decisions were made, making it easier to figure out where we should go next 😌.
Learning 3 — Change is constant
The last learning was a theme that came up time and time again throughout the three days. It’s one that I’ve always known, but didn’t always appreciate or take to heart when I stepped into this role. Change. Teams go through re-orgs, processes change, new people join, and some folks leave. Change is constant, and part of the role as a Design Program Manager is to help prepare and navigate that change with their team 🗺️.
In a way, this makes my job easier. I don’t have to come up with processes that are going to be set in stone and that the team is going to have to follow super strictly for the next five years. I’m working with the team to figure out what works now, and when things change, how we can iterate and change with it 🔄. It’s something that I say to myself during moments when trying to work through particularly hairy problems and I’m wracking my brain trying to figure out the perfect solution. Perfection is not the end game for DPMs — the focus needs to be on making small, incremental changes that support the team and help them create their best work even when things outside of design are changing.
It’s been a little over four months since the DesignOps Summit, and each day I keep going back to these three learnings when thinking about my role, how the team operates, and what I can do to help take DesignOps at AppD to the next level. By focusing on measuring the impact of my work 📏, understanding why we’re doing the things that we’re doing, and keeping change top of mind when coming up with solutions, I’ve been able to elevate the work that I do and focus on what really matters 🙌.
Interested in joining our team? We’re hiring!
Do you use AppDynamics? Join our user panel!
Design@AppD is leading a transformation of AppDynamics into a user-centered enterprise product company. Interested in following along? Consider following us on Medium!
