How To Pick your Battles When There Are Little Fires Everywhere?
📝

How To Pick your Battles When There Are Little Fires Everywhere?

Agenda

7:55 - 8:00 am - "arrive" online [link here]

8:00 - 8:15 am - opening + introductions

8:15 - 9:00 am - discussion in break-out rooms (groups of 4-6)

9:00 - 9:30 am - regroup and align on session outputs

Zoom Link

Intro brief:

  • Name + company
  • Why are you interested in the topic / what’s your experience so far?

HOUSEKEEPING

  • Bring a snack/drink! :)
  • Please use this Notion doc freely to write up notes/questions before, during and after the event. This will make it easier and more efficient to share the notes with everyone after the event. It doesn’t have to be perfect or coherent. This can be from recommendations to current challenges, to questions, to quotes from other people that you don’t want to forget. Anything you can think of during this call.
  • If you have a question or something to share, please jump into the conversation! You can also use the chat if you don’t want to interrupt

Questions

🔥

This feels like the story of my life at the moment. I feel if I don't put out the little fires it will hurt my teams in the long run.

Process

  • How do you transition quickly from "storming" to "performing". Are there any articifacts / cultural traits that have been developed to allow for a quick transition?
  • How to learn from little fires and document them for future use
  • How do you juggle fires with the normal BAU and roadmap work?
  • How do you prioritise what to escalate?
  • Any particular processes that people have to handle prioritising cross-functionally (outside OKRs and Goal Setting Processes). Thinking more tactical - moving the needle on a weekly basis.
  • Is there a good framework for prioritisation?
  • How do you keep your focus on your current roadmap when others might come disrupt the peace?

Communication

  • How to communicate if the disruptor of the ops processes is your boss.
  • How to give feedback to those who think every little fire is a burning city.
  • How to communicate the opportunity cost of doing something?
  • Communicating problems to different team leads that may not agree?
  • How to handle different teams thinking different items are priorities?
  • How do you get people to listen? (Especially when you have predicted the potentials fires)
  • How do you communicate that if people don't listen to you, your team will be having more work than necessary fixing it?
  • How do you communicate with people that this problem isn't one for the ops team?

Team

  • How to determine when the Ops team needs to grow in terms of headcount and by how much?
  • How do people politics factor into the battles you choose to fight?
  • How do you train others to put out the fires? (So isn't always you personally)?
  • How do you leave the guilt behind when you're turning your back on something you could help fix?
  • Are all the problems an ops team thing, where does the limit lie?

Notes

Kirsty's Group (Charlie V, Eli R, Gabija D, Fannijozsa)

  • Co-founder/CEO can be the disrupter - is this industry specific/size of the group (convince the leadership team first)
    • Managing expectations
    • But can be missed as a communication point - direct to other teams but miss Ops
    • Helpful skills - asking lots of leading questions (you get to the core of what is needed) / getting to the why
  • Can you step back by a day/week to think something through before jumping into a project
    • Every day at the start of the project saves a week later on
  • Prioritisation
    • https://www.eisenhower.me/eisenhower-matrix/
    • Macro/micro
    • Dairy management making the micro into the macro
    • Do you prioritise versus what we care about the most - do this tie to the business overall goals
    • BAU versus bigger picture business goals
    • Working remotely means 'people can't find you'
    • Delegation
      • How to delegate the fires (can someone else solve):
      • reporting lines can help here/heads of departments
      • management training / problem solving / redirect the route of the problem
      • 'making fires scalable'
      • remember that it won't happen over night
      • What and who to fix
  • Anxiety to grow as fast as possible
    • Mindset change
    • Sharing the importance of set up and process before growth - will this solve the problem - links back to managing disrupter expectations (can waste a lot of time)
    • Knowing when something is not an Ops team project/fire - delegate, say no, link it back to the business goals, closure - parking until a different quarter - it is your call to make this decision (make a proposal of where else it should sit)
    • Not everything is urgent
    • Takeaway points:

    • Training others (delegation)
    • "Every day at the start of the project saves a week later on" (From Eli)
    • Managing the CEO/disrupter expectations (having these discussions early on - in depth conversations)
    • Not everything is urgent
    • Documenting - to prevent future fires (Confluence/Notion), Critical Paths (detailed) , Retros (https://metroretro.io/), mapping the journey

Attendees

Misbhah Akram

Andy Aitken

Živilė Lazauskienė

Simon Rodrigues

Gabija Duoblyte

Hanna Lewis

Cristina Munteanu

Laura Parker

Michaela  Peicheva

Sarah Touzani

Jessica Dennis

Amanda Green

Charlie Vinall

Eli Rezinsky

Kirsty Power

Gemma Happe

Peter Grillet

Mara Livermore

Jessica Dennison

Marta Kutt

Fanni Jozsa

Samantha Holt

Wesley Kirschner

Ellie Burgos

Alexander d'Annunzio

James Fell

Aušrinė Keršanskaitė

Ausrine's group

(Jess Dennis, Jess Dennison, Alex D'Annunzio, Mara Livermore, Marta Kutt, Sarah Touzani)

  • Definition between little fire vs low hanging fruit [Alex]
    • Lots of little fires add up to forest fire
    • Little fire = downside; low hanging fruit - upside. Which one should you pick first?
    • Getting me in trouble vs trouble for the company.
    • Collaboration to put out fires = low hanging fruit in itself.
  • What does the fire mean for everyone? [Marta]
    • Something unexpected. Not a part of work / regular day to day.
  • Helping people to identify fires / people side [Mara]
  • Standing back from fires, only being the steer [Jess Dennis]
    • Danger that if you put out one fire, you're gonna become the firefighter for this spot forever. When do you start pushing back?
  • Find root cause of those little fires
  • Quick growth magnifies fires exponentially
  • Our job is to plan all those unexpected things...so fires end up being a big part of ops role.
  • Sources of fires
  • Appropriate firefighting response from others when you firefight something

Takeaways:

  • Definition of fire: something unexpected, not a part of work.
  • Fire vs low hanging fruit?
  • Collaboration to put out fires = low hanging fruit in itself.
  • Find the root cause of those fires so that they don't continue popping up.
  • Staying away from fires / training others to pick them up before you do. Remembering that this fire is not your responsibility / help grow responsibility of others.
  • People only understand the price/pain of fire after it's happened. It's important to share that pain. Show what it meant for you / what impact it had for you. Overcommunicate.
  • How do you balance it: startups are high growth so we need to take more risks / shouldn't be risk averse. Some fires are okay - make people more comfortable to live with those fires, explain how it's gonna work in the long run.
  • It's only when something breaks you know that ops people exist 🙂 For every 1 fire there are 10 that we put out

Actions:

  • Sit down with people/teams who're causing fires and show what it takes to fix. It makes it more real when you show the work that it takes to fix.
  • Retrospectives for incidents across the company (root cause, what needs to be changed process wise so that it doesn't happen again, how fast did we see that something was wrong, what was the impact, etc.) This creates a level of responsibility across the company, knowledge sharing, increases the risk mindset.
  • Farnham Street: Alex's quote 🙂 — When we promote problem solvers, we incentivize having problems and because most organizations reward problem solvers, it can seem like a better idea to let things go wrong, then fix them after. That’s how you get visibility. You run from one high-level meeting to the next, reacting to one problem after another. It’s great to have people to solve those problems but it is better not to have them in the first place.

Michaela's group

  • Ops hard to communicate to other stakeholders - be visible
  • In Ops rely a lot on instinct, especially when small
  • Tendency to prioritise things for people who are the most annoying.
  • Learnings from Product
  • Fitting Ops into OKRs
    • Ops not always in company objectives.
    • Hard to plan Ops into the long time frames
    • OKR process - some quarterly, 8 weeks, 6 weeks
    • Can align your Ops work to sprint cadence in the company - even do a 'sprint demo' with the CEO/boss
    • Can change your Ops OKRs during the process when things change.
  • Balance Urgent and Important so not just focusing on the easy things.
  • Can also look at what is going to make the most noise for the company when prioritising.
  • Post wins on the Slack channel - need to shout about your work even if it can feel uncomfortable!
  • Buy in from senior stakeholder is helpful. They need to know what Ops is and appreciate the work involved
  • Remote challenges

Astrid's Group

Astrid – Ops Consultant

Albie – Allplants, Ops Manager

Wesley – Commercial Ops Lead, Vice

Samantha, Chief of Staff

Spoting > Problems come to you > Failure – went full circle within the conversation. Need to have a culture to be able to deal with it.

Albie moved to new supplier 4 months ago but have let the business down completely. Decisions to prioritise and not to prioritise has been an everyday event. Holding weekly meetings to help prioritise but after a while it stopped working. Management tends to just say “delegate” which isn’t always the solution. Shared article about prioritise activity and picking your battles. Awards for praising failures.

Wesley, having to deal with people who always believe that there is a problem. Issue with salespeople being very impatient with having to solve their problem. Getting closer to the role as a view to getting closer to the cause of the problem. Have a hard time letting people fail. Slack channel #ididthisdontdothis to share fails – culture divide, EU positive, US negative to its function.

Samantha, lots of firefighting, do not sit within a team. Tends to prioritise fires, define prioritse, and consider whether they are going to get worse. Recent hire, head of product, saw as an opportunity to let fires burn if its worth it. Frameworks to solve fires and zoom out of the contents. Newsletter – staysassy – really recommended - good content for staying on top of problems. Every conversation has a yes or no, company culture to ruthlessly prioritise and empowering them to say no – productivity has gone up. Questioning whether (a) its your fire and (b) whether you should let it go. Learnt that you need to let people fail, rather than rescuing. Most difficult conversations is where trust is built.

James talked about reliance to help people as a useful framework to help prioritise activity. The OKR plans are a good way to prioritise the activity.

Astridspeak in solutions, is there a way that people frame issues to ops people, does this cause constraints. Has found dealing with finger pointing difficult, despite the best efforts to avoid.

Idea of a Slack channel to not make the same mistakes "I did this don't do this" a place where people can share what they did and that you absolutely shouldn't copy.

  • There are always teams that are more persistant to have you solve their problems. If you don't, they may end up solving it their own way.
  • There's reactive and pro-active fire fighting. People coming to you with their problems vs you finding problems that nobody has raised yet.

🔥

Growth only happens in chaos

Framework/questions to ask yourself:

  • How severe is the problem? Low - Medium - High level
  • Is it getting worse?

Resources

Actions

  • Go talk to people directly to find out the actual pain points.
  • Stick with high level analogies to make people understand the problem better. It will take their attention away from details that may not be as important and focus them on the real problem.
  • When you have conversations about changing your priorities take the time to say what you say "yes" to and what you're saying "no" to. E.g. If I solve this problem for you today, then I will not be able to finish this piece of work tomorrow.
  • Look at your OKRs to help with the priorities
  • Keep asking in different ways if it's really a priority. People have different definitions of what priorities are.
  • Give people long deadlines, say you won't be able to do it in before next week. Usually people will do it themselves, or admit it's actually not that much of a priority