Day 1 Session Notes–Leading Change with Confidence Strategies for Optimizing Your Process

— Hello everyone and I’m excited to present my talk as part of this summit

• I’ll talk about resilience in context of leading changes
  • Lead big or small changes everyday, and how to bounce back when things don’t go as planned
• I want you to feel confidence about changes you are leading

— Background info about myself

• I was supporting the Adobe Deign System called Spectrum, which is supporting 100+ Adobe products

— Switched careers from recruiting to program management and career searches and switching requires its own type of resilience

— Session will tell particular story of where change I led didn’t go as planned and valuable lessons learned

— We had a team of eight designers and our processes were going well, and people used to how things run, and team happy

— Suddenly team doubles in size to 16 and so many things changed at once

 

— Previously had high-maturity team, but it now changed to one that was low-maturity and we were trying to figure things out

• Processes and tools needed to scale to the new team

— As people get onboarded, feedback comes flooding in, and one part causing more confusion than others

• Questions dealt with tracking tasks and approvals
  • Some people can’t get access to tracking software, and not sure what was assigned
• People feel lost and don’t know who is reviewing and approving the work

— Taking in feedback and no way to fix with solution you have

— So you do research and explore options available

• Find something that seems to meet team needs

 

— So migrate team from Tool A to Tool B, and you know there is a lot of planning and energy of moving from one space to another

• Effort for comprehensive support like documentation, training sessions, etc.

 

 

— So is the problem solved?

 

— Actually, no, more road-blocks appeared that were worse than ones from before

• Some teams didn’t migrate with you to new tool, so you need duplicative tracking

— More manual work to manage statuses and tasks

• Also limitations to features for team collaboration

— So, now what?

• No other options for software, as IT department has only a few tools for use
• So what to do?

 

— After some thought, we moved people back to original solution

• Even though solution wasn’t perfect, there were small changes to original process to address team concerns

 

 

— We ended up having a nightmare of two system migrations in same year

— How to avoid this?

• Talk through three lessons to keep in mind

 

 

— Say you want to go shopping, but don’t know where to go?

• You can read reviews, and find the right place to shop

— Leading change is similar

 

— Assess feedback before decisions

• Implementing feedback before assessing it can lead to the wrong solution
• In my story, I got feedback, but didn’t fully vet it, and would have found way to address it without a big change
  • Vet suggestions thoroughly and focus on problems statement for right solutions

 

 

— For any feedback ask:

• How urgent is it?— Think of stakeholders involved, and if feedback should be addressed right away, and if blocking critical work for team or org, and risks related to the feedback
  • Help decide timeline for addressing feedback and making a decision. It can wait until you get more data or info
• Is feedback reflective of broad majority or vocal minority?— If small group, is it worth it to explore and accommodate request, without impacting majority
• When was last change?— Optimal frequency of change will depend on team and situation
  • Often lock-up changes for 1-2 months, unless serious circumstances appear
  • Choose what is more sustainable for you

 

 

— Back to shopping analogy

• Now looking for new shirt for event you will attend. You can try the shirt at the store, or buy it and return it later
  • Take extra time to try on first time around

 

— Recommend you pilot and test your ideas before committing to them, if possible

• Sometimes can’t be done, but if you can, take time to do it

— Take time to pilot new solution before migrating everyone and issue sooner

• Might be wondering if you didn’t test idea for first-time around and assumed you didn’t need to
  • Even if idea foolproof in theory, test it on some scale

 

— First use pilots for stakeholder buy-in

• People might not be interested with process improvement, and smaller group can work more than larger org
  • Pilot data can show why change is needed
• Measurable goals:
  • Data you gather or test should inform your decision, to see if solution would address problem statement you identified—like retrospective meetings, or quick poll on Slack
  • No matter medium used to connect data, make sure connected to problem trying to solve
• Allocate time for testing
  • Not all orgs will value this, so recommend you still do it, but at smaller scale
    • Test for less time, and include less people
    • Set-up workarounds so team can function while you work through optimal solution
• Learn from pilot and then iterate
  • Once you see pilot results, and think how to roll-out change to rest of team
  • Processes aren’t perfect, but energy into thought and testing to limit disruption to team

 

 

— Final lesson, from clothing store analogy

• Found store, shirt to wear, and bought it

— After you bought something, have you often wished that you kept the receipt?

• Keep receipts is valuable for future reference

 

— Collect info and outcomes from lessons learned to prevent repeating a cycle in the future

• Document research pilot programs and findings to explain rationale and revisit your decisions in the future

 

— Some questions for documentation about changes

• Documentation medium is up to your preference and depends on situation and team and details

— Questions to ask

1. What changed and why?
2. Who approved the change?— who was involved?
3. What other options were explored?
4. What was outcome of pilot program, if you hosted one?

 

— Assess feedback you receive , test ideas, and document learnings

• Roadblocks will come up, but it’s about how to persevere and learn from experience

— This process has made me more confident in choices I make and changes I lead

 

— There are also courses on how to do this in more detail

• Change management certification programs
• I’d like to hear other recommendations over Slack— as they can help others

— Will leave with James Baldwin quote above

• Let’s face challenges head-on with confidence
• Even if you can’t change the situation, you can still impact people around you

 

 

— Thank you for engagements and Rosenfeld Media for having me and the included URL and QR code

Questions

1. What would be strategy to push back pressure from upper management to push through changes?
   1. Look for workarounds and have small change to make
   2. If not possible, understand why there is need to rush
      1. Seek to understand people’s perspectives, and use info you learn to influence in their direction
2. How to avoid bias in assessing feedback— like your ego as viewing feedback as wrong?
   1. Relying on other people you trust to give their honest thoughts
   2. Keeping feedback anonymous helps and clarifying questions during retrospective and overall question of how to do better, and other questions to click into process
      1. Gather more or check-in with someone you trust
3. As Ops team often need to share feedback when we haven’t landed on a solution. Any advice on letting people sit with feedback and take time?
   1. Found anecdotal feedback from team to directly quote team focus
4. Thoughts on prototype before pilot?
   1. Love it, and worth setting up to get feedback on how it’s doing and provide proof-of-concept
5. Can you provide examples that you created and evaluated measurable goals, for non-numeric goals?
   1. Comes back to problem and if problem that team can’t find info, as you follow-up with data, make sure data connects to original stated problem like finding information
   2. Comes back how to quantify and figure out how to solve the problem and go from there
6. How to approach managing tension between overloading people with change versus managing change well?
   1. Would challenge you there, if managing change well means more frequently, or if people bought into it, and balance between pulse surveys and health of team and experience of team members and understanding what they are going through