Easy Agile Podcast Ep.10 Kate Brodie, Director of Digital AI and CCAI Program at Optus

In this episode, we dive deep into the challenges of aligning teams with strategic goals across organisations of all sizes. From fast-growing startups to large enterprises, teams everywhere struggle with the same fundamental issue: translating high-level objectives into actionable work that drives real value.

Our guest Andreas Wengenmayer, Practice Lead for Enterprise Strategy and Planning at catworkx (the #2 Atlassian partner worldwide and #1 in EMEA), shares his 11 years of experience helping organisations bridge the gap between strategic vision and team execution.

Want to see these concepts in action? Andreas and Hayley hosted an interactive webinar where they demonstrated practical techniques for strategic goal alignment using Easy Agile Programs. Watch the recording here→

About Our Guest

Andreas Wengenmayer is the Practice Lead for Enterprise Strategy and Planning at catworkx, one of the leading Atlassian Platinum Solution Partners globally and the #1 in EMEA. With over a decade of hands-on experience helping enterprise teams scale agile effectively, Andreas specialises in bridging the gap between strategy and execution. His work focuses on guiding organisations through complex transformation programs, optimising portfolio planning practices, and helping teams adopt frameworks like SAFe with clarity and purpose. Known for blending pragmatic insight with systems thinking, Andreas brings stories from the field - ranging from fast-moving startups to complex, multinational enterprises.

Transcript

Note: This transcript has been lightly edited for clarity, readability, and flow while preserving the authentic conversation and insights shared.

Recognising the signs - when teams aren't aligned

Hayley Rodd: Awesome to have you here. So I'm going to start with a bit of a reality check. We've worked in organisations across the spectrum from really fast-growing startups to really big enterprises. From your experience, when you walk into a PI planning or quarterly planning session, and I'm sure they're pretty hectic, what are the telltale signs that teams aren't truly aligned on what success looks like?

Andreas Wengenmayer: That's a great question - one I hear frequently. You can imagine, especially post-COVID when teams returned to in-person planning sessions. Back in 2017, we'd have huge arenas with hundreds of people in one place. People are happy to see each other, excited to chat with colleagues from different locations. This became even more pronounced after COVID, when everyone was working from home more frequently. That's a good sign - the mood is positive.

But you also notice some teams under pressure. They'd rather be working on actual deliverables. They know they have to be there, and it takes two full days to complete all the planning. Meanwhile, they're carrying a mental backlog - technical debt, unfinished work from the previous PI, catching up on delayed items.

This is what I often observe: teams get bogged down discussing minor details. People debate specifics, and you can see they're frustrated about something deeper - but they're not addressing the root cause. This creates its own negative momentum and can derail otherwise solid planning sessions.

Teams get bogged down discussing minor details. People debate specifics, and you can see they're frustrated about something deeper - but they're not addressing the root cause. This creates its own negative momentum and can derail otherwise solid planning sessions.

Sometimes you have to step in and ask what's really underneath. What's the actual cause? People say, "Yeah, I have to be here because that's the format, but I'm not engaged." Maybe it didn't work well in the past and there's lingering skepticism.

The prevailing attitude then becomes: "This isn't really collaborative. Leadership plans from the top anyway. The outcomes are predetermined - here's the plan, just make it work and update your boards." When people feel they can't meaningfully contribute or influence direction, they simply go through the motions.

My favourite example happens at the end when teams must formulate their objectives. It becomes a box-checking exercise - create something that satisfies the coach or Release Train Engineer so everyone can "get back to real work."

What good alignment actually looks like

Hayley Rodd: You've touched on so many things there. I can imagine walking into that room and feeling the pressure. People getting caught up in minor details rather than talking about root causes, or not asking the five whys to get to that root cause. You also touched on getting buy-in across the organisation. When people are really nailing it, when alignment is really there, what does that room feel like?

Andreas Wengenmayer: Yes, I've fortunately experienced those environments, and they're actually more common than you might think. When companies genuinely commit to grassroots planning, truly investing the time it requires, and ensure teams aren't overwhelmed from the start with everything marked "priority zero," you create the foundation for successful planning.

When companies genuinely commit to grassroots planning, truly investing the time it requires, and ensure teams aren't overwhelmed from the start with everything marked "priority zero," you create the foundation for successful planning.

You can see it immediately in people's body language and interactions. The energy in the room is palpable. If people appear resigned or intimidated, afraid to speak up, that's typically a red flag. The opposite creates magic.

Think about high-performing teams, like being a Scrum Master with an exceptional group. The best teams aren't just collections of highly skilled individuals in specific roles.

The best teams are those who communicate openly, genuinely enjoy each other's company, maintain positive energy, and actively support one another. This dynamic enables remarkable achievements. Maybe someone knows a contact in another tribe, release train, or department who can provide crucial answers and facilitate communication. Communication is absolutely fundamental.

That collaborative spirit is the hallmark of truly effective teams.

Hayley Rodd: Absolutely. We would know it in our day-to-day work, right? If your teams aren't communicating, if they're too overburdened as you said, it's not a good place to start. But if you can get that starting point right, if you can get that communication right, so many things will flow after that.

Andreas Wengenmayer: Absolutely. Looking back at any planning cycle, the real test is: did you plan the right things? You only know at the quarter's end whether you estimated capacity accurately.

Here's the crucial question: How does your organisation respond when goals aren't met? Do stakeholders focus on finding solutions? Do team members feel safe asking probing questions and seeking answers? Or does the blame game begin, searching for scapegoats?

How does your organisation respond when goals aren't met? Do stakeholders focus on finding solutions? Do team members feel safe asking probing questions and seeking answers? Or does the blame game begin, searching for scapegoats?

When you're permitted, encouraged, even, to be genuinely open and honest, you become much better at assessing realistic capacity. What makes stakeholders universally happy is predictability. You want confidence that your plans will actually materialise, that your commitments will be fulfilled.

Success breeds success, creating a positive foundation for the next PI. It's a continuous cycle that can spiral upward toward excellence or downward toward dysfunction.

The startup vs. enterprise spectrum

Hayley Rodd: Let's talk about the two ends of the spectrum. You've got a lot of experience, so I love hearing about this. Small companies will often say, "We're agile, we can pivot quickly, we don't need formal goal setting." Then enterprises are going all out on OKRs, cascading objectives, saying they're aligned because they've got those things in place. Yet both struggle with the same core problem. What's really going on?

Andreas Wengenmayer: You're absolutely right. I've been in agile projects since 2014, 11 years now, and I've seen a lot of companies pre-COVID, post-COVID, different sizes.

Starting with the really small ones, startup companies - what's really astonishing is that some very small startup companies tend to become overly complex, which is amazing. Some want solutions that are way too overblown. Basically, they need a sailing boat, but they're thinking about ordering an aircraft carrier.

Some startups want solutions that are way too overblown. Basically, they need a sailing boat, but they're thinking about ordering an aircraft carrier.

Maybe that's part of startup CEO culture - where everyone's a CEO on LinkedIn, and they think, "We're corporate, we have to be like that." They mostly get to their senses in the end, but small companies tend to be overly complex and overblown when it comes to technology, tooling, and organisation.

On the other end, large corporations sometimes seem to try their best to become truly agile - living the values everywhere. Still, it's a challenge. In most cases, there's some kind of hybrid planning going on. There's still a roadmap, which is good, but at some level, some people still stick to classical approaches, have some waterfall going on in the back.

I personally have never seen, for example, a full SAFe organisation where it's done truly at every level. There's a good balance and it should be healthy, but it all comes down to execution.

I feel like mid-sized companies are often the healthiest when it comes to that.

There's a balance of method and tooling, but you still need a solid understanding of goal setting and tracking. This includes pivoting when goals aren't right and learning from how you did things in the past. The gap between management and teams isn't that huge, and it's easier to bridge.

Avoiding death by KPI

Hayley Rodd: You've touched on so many fundamental things around getting the method and tooling right, but also that cultural aspect. I love the insight around mid-size organisations often striking that balance well. When we're thinking about the enterprise risk - which could be "death by KPI" or OKR, do you agree? Can you paint a picture of what that looks like and how it actually makes teams less focused?

Andreas Wengenmayer: Absolutely. There is such a thing as "death by KPI." KPIs are important to get a clear picture - you do need metrics, and there's merit to it. But as always, it's about choosing the right KPIs, the right metrics.

My favourite example is comparing story points across teams or ARTs. You measure velocity, and I have to repeat again and again: it's only individual to one team. You shouldn't compare it to another team or across tribes or ARTs - that doesn't work because you're creating the wrong incentives.

You see what will happen: "Well, okay, my stakeholders want higher amounts of story points. Let's estimate the stories bigger." Of course, that's a continuous loop, but it doesn't give you anything. Story points as a metric are just guidance for a team to get a better feeling for estimations.

You see what will happen: "Well, okay, my stakeholders want higher amounts of story points. Let's estimate the stories bigger." Of course, that's a continuous loop, but it doesn't give you anything. Story points as a metric are just guidance for a team to get a better feeling for estimations.

You want predictability - you want to meet a certain range. So it's not a great KPI when it comes to monitoring progress across teams. They have better KPIs in place.

Other metrics tend to create what I call bureaucracy. If you spend too much time creating reports, you have less time to create anything of value.

Hayley Rodd: I think there's so much in what you're saying about people being realistic and honest, open to pivoting or changing a goal if it's not the right one. Admitting to that is really difficult because no one wants to admit that what they set out to do is failing. But understanding that failure can sometimes be a benefit - you can learn from that. There's so much in that cultural aspect, right?

Andreas Wengenmayer: Absolutely. Coming back to goals rather than KPIs - KPIs are like being on a boat in your control room. You see what the engine is doing, the temperature - those are KPIs. Goals, on the other hand, are the course that you set.

KPIs are like being on a boat in your control room. You see what the engine is doing, the temperature - those are KPIs. Goals, on the other hand, are the course that you set.

You could be a small company like a startup - you're in a canoe, you're rowing. Or you're a large company - you're like a big freighter. Still, if you don't set the right course, the right goal, you will never reach your destination. Your team can be as proficient and perfectly working as they could be. If the course isn't right, hopefully you have enough provisions on board to survive a long journey.

Where organisations get stuck in goal setting

Hayley Rodd: Where do organisations typically get stuck? Is it defining the goals, communicating the goals, or translating them into action - that execution point you made before?

Andreas Wengenmayer: It could be basically any one of those. If you have a smaller or mid-size company, it's easier to communicate - you don't have to bridge as huge a gap. But still, you have high-level goals that have to be translated into real work. Real value is created in the teams.

If you have a high-level goal that's highly abstract and sounds good on paper - "increase customer satisfaction," "create better products," "make the world a better place" - people still have to understand: What does that mean to my daily work? If I'm a developer, what's my stake in that? How can I contribute?

If you have a high-level goal that's highly abstract and sounds good on paper - "increase customer satisfaction," "create better products," "make the world a better place" - people still have to understand: What does that mean to my daily work? If I'm a developer, what's my stake in that? How can I contribute?

That's when communication and breaking down goals becomes really important. Breaking them down the right way, having them visible and transparent, and creating that feeling of contribution. You make it visible that you're not just working for yourself or your team, but you're really contributing. You understand what you're working on and why you're doing it. Purpose is critical.

Bridging the strategy-to-sprint gap

Hayley Rodd: That's a really good segue into the next question about translating strategic vision into team-level objectives that people can grab onto and execute. Leadership will often say something like "increase customer satisfaction," and teams are left going, "What does that mean for me in my sprint this week?" How does an organisation bridge that gap between the high-level leadership view and what we can do in our sprints as a team?

Andreas Wengenmayer: First of all, you as company management need to take the time. There have been, and still are, a lot of approaches with company values, putting posters on walls, creating marketing. Those are all values - that's what a company is like. Then you link it with your products, services - great services, customer satisfaction. Okay. Then comes the real challenge: we want to succeed and create the next service, software solution, or product.

The goal is clear on a high level, but how do we break it down? That's when the real work comes into play - breaking down the goals into smaller pieces.

It's like building a LEGO space station when I was a kid. You have the picture on the box in the beginning - 'Oh, that's what we're going to build.' Then you have to start putting together all the small pieces. You need a plan, you need the little pictures of the steps. You start with the big picture, then you're breaking it down one piece at a time. You create different parts, and they come together at the end. Same goes for goals.

It's like building a LEGO space station. You have the picture on the box in the beginning - 'Oh, that's what we're going to build.' Then you have to start putting together all the small pieces. You need a plan, you need the little pictures of the steps. You start with the big picture, then you're breaking it down one piece at a time. You create different parts, and they come together at the end. Same goes for goals.

Hayley Rodd: Nice. A colleague of mine often says you eat an elephant one bite at a time - similar thing, right? When you see that big goal, it's really overwhelming. But if you can break it down into those chunks and smaller pieces, it becomes so much more manageable and achievable. People can get behind that vision.

Managing moving targets

Hayley Rodd: In fast-moving environments, goals often shift. We're agile, we're always moving. How do you help teams stay connected to a moving target without either ignoring changes or constantly thrashing around?

Andreas Wengenmayer: Back in the nineties and early 2000s, there was a computer game that wasted a lot of time in offices where you were shooting at geese in Scottish Highlands. It was a big phenomenon because people were trying to get the next high score.

If you think of moving targets, it's a bit like that. Imagine you're doing your work - whether you're a hunter or developer doesn't matter - but you approach, you take aim, and the geese keep flying up. You miss the target. Same thing if you have moving goals.

It's harder to aim and approach them right. What you should avoid as a company or someone in charge is constant interference. Stick to your goals or objectives that were agreed upon during PI planning. Don't change them midterm during a PI.

What you should avoid as a company or someone in charge is constant interference. Stick to your goals or objectives that were agreed upon during PI planning. Don't change them midterm during a PI.

That doesn't mean you can't learn from mistakes or wrong goals. You can adjust them, but you have to adjust them in the right place and time, which is during planning. Of course, if something security-related comes up, you have to act, but it has to be agreed upon, and you still have to communicate it and create understanding.

Keeping goals visible and actionable

Hayley Rodd: Even when goals are well-defined, keeping them visible and actionable throughout a PI is tough. What practices or tools have you found most effective for maintaining connection between daily work and high-level strategic objectives?

Andreas Wengenmayer: Good question. Having the goals present at all times helps a lot. If you just meet for planning, have your goals set, and never look back during the PI, it doesn't do you any good.

That could be a piece of paper on the wall like we had back in the day - and still could be if you're working in the office. Also, choose the right tools to track the goals and create acceptance for tools. Really use them. Look into them - whether it's an OKR tool or some other solution, even PI objectives. Are we still on track?

What really helps is if it's not static but shows progress, and especially shows the link of what you're contributing - like what you achieved in your last sprint and how it plays into the objectives or goals, progress moving ahead. There's always a good feeling - everybody loves a green bar moving ahead or a checklist.

What really helps is if your tool is not static but shows progress, and especially shows the link of what you're contributing - like what you achieved in your last sprint and how it plays into the objectives or goals, progress moving ahead. There's always a good feeling - everybody loves a green bar moving ahead or a checklist.

It helps keep the vision and goals present.

Hayley Rodd: When I was a teenager in my final year of high school here in Australia, I wanted a specific score on my final exams. I had a big poster in front of my desk that I sat at for hours every day studying. Looking back, I didn't know what I was doing - I just wanted to visualise my goal, and I didn't know the psychology behind it. But I'm happy to report I got that mark and above.

I think it was as you were saying - that constant reminder, that piece of paper worked for me. In organisations, we're looking for something a bit more complex sometimes, but I like your "keep it simple" advice. It doesn't always have to be super complex. It can just be a checklist, progress bar, or piece of paper - something that helps you feel connected to the goal and reminds you of it often.

When good work doesn't align with goals

Hayley Rodd: Have you seen situations where teams were delivering lots of work - good work, but it wasn't clearly contributing to company goals? What tends to cause that disconnect?

Andreas Wengenmayer: Yeah, that happens quite a bit. I can think of one example with very technical teams, like in semiconductors. Very smart people - everyone has a PhD in physics, material science. Awesome, smart people who tend to love their job. They're awesome, but they're also perfectionists who can still improve things and want to make them even better.

If you're in the business of producing machines used to produce semiconductors, for example, it's a complex task with a complex supply chain or value chain. You're creating lithography machines to create wafers used by other companies, and in the end, you have a customer planning the release of a new phone.

Your customer waits, the end customer waits, and you have to deliver on time. Sometimes this creates a challenge because teams still want to improve and make it even better. That's when economics come into play - the view of the big picture. You still have to communicate it. You shouldn't discourage such a great team, but you need to get the bigger perspective back to the teams and create acceptance instead of saying, "Hey, stop what you're doing, it's good enough." You don't want that. It all comes back to transparency and communication.

On the other spectrum, what you sometimes have is just too much workload on teams. Time for planning gets cut short, and if you don't take enough time to plan well, no wonder the results don't work out. It's just a lot of busy work - a lot of things getting done, but not necessarily the right things at the right time.

On the other spectrum, what you sometimes have is just too much workload on teams. Time for planning gets cut short, and if you don't take enough time to plan well, no wonder the results don't work out. It's just a lot of busy work - a lot of things getting done, but not necessarily the right things at the right time.

Hayley Rodd: If you don't do that planning at the start, you're setting yourself up for misalignments. If you're not communicating that plan regularly, you're setting yourself up for that busy work and people getting distracted. It's just so common. That planning part is so fundamental to getting it right.

One piece of advice for frustrated leaders

Hayley Rodd: We're on the home stretch now. If you could give one piece of advice to an engineering or product leader who's been frustrated because their teams seem to be going through the motions of PI planning or quarterly planning without real buy-in, what would it be?

Andreas Wengenmayer: I can resonate with that so well, and many can. I'd say: take the time to find out what's really going on. Investigate the root cause. It's like if you have a house and you're trying to fix a crack in the wall - you can look at the crack and do some superficial fixing or use a thick layer of paint, but you still have to find out what's causing that issue. Maybe something deeper.

You mentioned the five whys - that can be one way, but you have to have some understanding of the right way to approach people. You don't want to put anyone on the spot. Looking for a scapegoat doesn't help anybody.

We need to look at what's behind it, what's causing it. It all comes back to investing enough time for planning, but doing it with purpose. Not doing the whole planning like theatre, where everybody acts their part - that doesn't do you any good.

It all comes back to investing enough time for planning, but doing it with purpose. Not doing the whole planning like theatre, where everybody acts their part - that doesn't do you any good.

People have to understand why they're doing it. There has to be purpose and understanding - enough time, no distractions, and a positive atmosphere where everybody can contribute and be open.

You don't want people saying nothing because they don't dare to criticise or say no.

The connection between goal clarity and team motivation

Hayley Rodd: What's one thing you wish more organisations understood about the connection between goal clarity and team motivation?

Andreas Wengenmayer: We could get back to the boats we mentioned before. You want to arrive at your destination. If you're not clear about the destination, or maybe some people in your rowing boat don't want to go there, they might not join the rowing. If your crew is not invested, it will take you longer to reach a destination, or you won't get there as well.

It's the same thing. Motivation is key, and I don't talk about superficial motivation that just annoys everybody. Motivation is a positive environment where people rely on each other. They really like spending time with those people.

"Hey, I really like to go to lunch with you and talk to you" - not "I'd rather be home and not talk to anybody." You're not annoyed if your teammate asks you a question; you're happy to help. You're feeling safe that when you have a problem or question, you will get help.

That creates the right kind of motivation - that positive environment, and that can make a lot of things happen. It comes back to openness and transparency, not as buzzwords, but to get the clear picture. As a stakeholder, you get the correct current state because you get true answers.

I've seen strange situations in major corporations where people really didn't report what they were working on or show the right results. I've seen complete shadow Jira environments - one for internal use and one for external use with customers. There can be huge misalignments because people didn't dare to show real progress. In the long term, it will backfire. If you don't have trust in your environment, in your company, you will have a hard time.

I've seen strange situations in major corporations where people really didn't report what they were working on or show the right results. I've seen complete shadow Jira environments - one for internal use and one for external use with customers. There can be huge misalignments because people didn't dare to show real progress. In the long term, it will backfire. If you don't have trust in your environment, in your company, you will have a hard time.

Wrapping up

Hayley Rodd: There are so many key themes coming up throughout our conversation. You've talked about ongoing communication across teams, really planning with purpose, getting that context and buy-in to help with motivation, and allowing for radical candour - being really open if something's not working and being okay to call it out. So many cultural and communication elements are critical to the success of quarterly planning, PI planning, and organisations generally. Great takeaways.

We're going to end it there, but I want to end with a teaser for our interactive webinar that you and I are doing together on September 4th, which dives deeper and shows how to operationalise the ideas we've chatted about here using Easy Agile Programs and linking back to the fundamental services that catworkx provides organisations.

Andreas, it's been super wonderful to chat with you. I look forward to our webinar coming up on September 4th.

Andreas Wengenmayer: Thank you so much for having me. Looking forward to September 4th and seeing you again, talking more about tooling, boats, duck hunt, and anything in between.

Ready to transform your strategic planning?

The conversation doesn't end here. Andreas and Hayley hosted an interactive webinar where they showed how you can put these strategic alignment concepts into practice.

They spoke about:

• Practical techniques for breaking down strategic goals into actionable team objectives
• How to maintain goal visibility throughout your PI cycles
• Real-world examples of successful alignment transformations

Watch the webinar recording here →

"Rebecca is an absolute gold mine of knowledge when it comes to SAFe, can't wait to continue the conversation at SAFe Summit 2022!"" - Tenille Hoppo

In this episode, Rebecca and Jasmin are talking:

📌 The value of the Scaled Agile Framework, who it’s for & who would benefit

📌 The Importance of having a common language for organizations to scale effectively

📌 When to connect the Scaled Agile Framework with your agile transformation

📌 Is there ever really an end state?

+ more!

📲 Subscribe/Listen on your favourite podcasting app.

Thanks, Jasmin and Rebecca!

Transcript

Jasmin Iordandis:

Hello, and welcome to the Easy Agile podcast, where today we're chatting all things Scaled Agile with Rebecca Davis, SAFe Fellow, SPCT, principle consultant and member of the SAFe framework team. Rebecca is passionate about teamwork, integrity, communication, and dedication to quality. And she's coached organizations on building competitive market-changing products at scale while also bringing joy to the work, for what is work without joy. Today, we've chatted all things Scaled Agile implementations, challenges, opportunities, and also the idea around optimizing flow, which Rebecca is hosting a workshop at the SAFe Summit in Denver in August this year. Hope you enjoy the podcast.

Jasmin Iordandis:

Hello everyone, and welcome to the Easy Agile podcast. I'm your host Jasmin Lordandis, product marketing manager here at Easy Agile. And today, we are delighted to welcome Rebecca Davis from the Scaled Agile framework. Welcome, Rebecca, and thanks for joining us.

Rebecca Davis:

Thanks. I appreciate being here. I'm excited.

Jasmin Iordandis:

Me too, especially because we are counting down the days before we get to meet you face to face, in person, at the SAFe Summit over in Denver, Colorado. And before we kick off our conversation, I just want to acknowledge the traditional custodians of the land from which we broadcast our podcast today. The people of the Djadjawurrung speaking country. We pay our respects to elders past, present and emerging, and extend that same respect to all Aboriginal Torres Strait Islanders and First Nations' people joining us today. So before we kick off, Rebecca, can you tell us a little bit about yourself and your role within Scaled Agile?

Rebecca Davis:

Sure. I'm actually relatively new to working for Scaled Agile. So I've been there a little over 90 days now, and I'm a member of the framework team, which means I help actually create the Scaled Agile framework and future versions of it. Prior to that, I led LACE at a company called CVS Health, and I've worked at a bunch of different kind of healthcare organizations across my years implementing or organizing agile transformation and digital transformation. And I think one of the reasons that Scaled Agile was interested in me joining the team is just a lot of different experiences across business agility as a whole outside of technology, in addition to within technology. So marketing transformations and HR transformations, legal transformations. But I love being at Scaled Agile and being part of the framework team. It's really exciting to help more organizations, and just the one I'm at, really understand how to bring joy to their workplace and bring value out to the world.

Jasmin Iordandis:

Yeah, cool. And you've given a little bit of information there around why Scaled Agile was interested in you. What attracted you to Scaled Agile, and did you use the Scaled Agile framework in these previous roles that you've just described?

Rebecca Davis:

Yeah. Those are great questions. I think I'm going to try to answer both of them together. But the reason I have always been drawn to the Scaled Agile framework is I ran a few different organizations, both as owning my own company and then also working in startups and working with larger organizations, where I knew that agility was important. But I was struggling as a change leader to find a way to really bring connectedness across large amounts of people. And to me, that's what Scaled Agile does for us, is after a certain size, it's a lot easier to create this common language and this common way to move forward and produce value with the framework. I also really enjoy it because there's a lot of thought that's already kind of done for you.

Rebecca Davis:

So if you're in an organization and you're trying to create change or change leadership, I'd much rather be leading the conversations and my context and making sure that I have a pulse on my particular cultural environment and pull from all these pieces, from the framework, where the thought's already been done about what are the right words and what do we do next, and what's the next step. So I've just found it an invaluable toolkit as a change leader.

Rebecca Davis:

I joined the framework team for a few reasons. One, I'd led so much change in so many different areas that, it's not that I wasn't challenged anymore, but I was really looking for something larger and different, and I've always had a belief that I really want to be the change that I want to see in the world. And I think being part of the framework team gives me access to things like this and all over the world to really help connect the humanness of people alongside with all the great techniques that we've learned, and hopefully expand it and just create a better place to be in.

Jasmin Iordandis:

Yeah. Cool. And you kind of touched on that in your response, but if we had to say, who is the Scaled Agile framework for and who would it most benefit, what would you say to that?

Rebecca Davis:

Yeah. I guess my opinion on that is I believe the Scaled Agile framework is for people who believe that their organizations have it in them to be better, both internally inside of themselves, as well as have this gigantic potential to go help the customers they serve and may be struggling right now, to really realize that potential. So I don't really see the framework as it's for a specific role necessarily. I think it's for people who believe in betterness. And those people, I found, live across an organization and across multiple different roles, and the framework just really helps you align that.

Jasmin Iordandis:

Yeah. And I think one thing that's evident from SAFe, once you learn how all the different practices and ceremonies work together, is exactly as you've said around connectiveness. And you also touched on having a common language. How important is that, when we're talking really large organizations with multiple different functions who, let's be honest, it's quite common for different functions to fall into different silos and things to break down. So how important is that connectivity and that common language, so that an organization as a whole can scale together?

Rebecca Davis:

Yeah. I don't even know how to state the amount of importance that is. I guess, specifically the organization I just came from, had over 400,000 people that worked there. And the last thing I want to is to debate what the word feature means, because that doesn't actually end up within a conversation where we have an understanding of why we want to feature or why we want this particular outcome, or how this outcome relates to this other outcome, if we're spending so much time just choosing word choice and having a conversation instead about what does the word even mean.

Rebecca Davis:

So I like it mostly because it gives us all this common framework to debate, and we need to be able to do that in really transparent and open ways across all of our different layers. So I don't even know how to quantify how much value it brings just to have this ability to bring stability, and the same language across the board, same word choice, same meaning behind those word choice, so that we can have all those debates that we need to have about what's the best possible thing we could be doing, since everything that we can do is valuable, but some things we have to decide are more valuable than others.

Jasmin Iordandis:

Yeah. And I think that really talks to what you were saying about helping an organization to reach its potential. It sounds like getting bogged down in what you call things or how you discuss things. And to be able to align on a common meaning in the end, you kind of need that common structure or that common language. And you're only going to get in your own way if you don't have it. So it makes total sense that the framework could really enable organizations on that journey. And in your experience, because it's implied in the name, it's about scaling agile. And I guess when we think of the Scaled Agile framework, we think of all those organizations of such a large size as the one you just mentioned, 400,000 employees. In your experience, what's a good time to introduce the Scaled Agile framework? Does it need to be right from the beginning? Does it need to be those organizations that are 400,000 people strong? Where is the right time to intersect the framework with an agile transformation?

Rebecca Davis:

Yeah. I think that's a really fascinating question, and my answer has changed over the years. I originally started researching Scaled Agile, because it was my first big transformation alongside of a large organization, and I knew there had to be some solutions out there to the problems I was seeing, and I discovered SAFe. But thinking back, I started my own startup company right out of high school actually. And I really wish that I would've had something to pull from, that gave me information about lean business cases, and speaking with my customer and getting tests and getting feedback. So I feel like the principles and the practices and the values are something that could be used at any size.

Rebecca Davis:

I think the part about scaling, the part about deciding like, "Hey, I'm going to do PI planning," I don't personally feel like you need to do PI planning if you have four people at your organization, because the point is to get teams across different groups to talk. You should definitely plan things 100%. So I think part of the idea is like, "When do I implement a train," or, "When do I have a solution train," or, "When do I officially call something LPM," versus just having discussions because my company is so small that we can all have discussions about things. I think those are a different part of implementing the Scaled Agile framework than just living and believing in the principles and the values and the mindset from whatever size or get-go you're at. Does that make sense at all?

Jasmin Iordandis:

That does make sense. And I guess then the question becomes, where do you begin and what would the first step be in implementing SAFe? And taking from your own experience, where do you start with this framework?

Rebecca Davis:

Yeah. I love that you asked that, as I've honestly seen this happen to me as well as some other change agents, where Scaled Agile gives us this thing called the implementation roadmap, and it has all the steps that you can start with. And it's proven, and companies use it and it works. And what I've found in my own change leadership is when I skip a step or I don't follow that because I get pressure to launch a train, instead of starting with getting my leaders at the right tipping point or having that executive buy in, it causes me so much pain downstream.

Rebecca Davis:

So if I were to give advice to somebody, it's, "Look, pull that map down the implementation roadmap from the SAFe site and follow it. And keep following it. And if you find that you..." I think that, back when I look back and do my own retrospective, the moments where I've decided to launch a train without training my people or launch or start doing more product management practices without actually training my people, it causes me a world to hurt later on with coaching and with communication, with feedback. So it's there for that reason. Just follow it. It's proven.

Jasmin Iordandis:

Yeah. And that's really good advice. And I think when people look at the roadmap for SAFe, there's a lot on there. But when we are talking agile transformations, necessarily there is going to be a lot that could get you there. So it kind of makes sense when all the thinking is been done for you and all those steps have been done. Just trust the process, I guess, is the message there, and following through on all of that. And I think it's really interesting, because the first step with SAFe is, as you say, getting your leaders on board. And often, we might be attracted to doing the work better. So let's start with those ceremonies. Let's start with all those things that make the day to day work better. How important it starting with the leaders of an organization?

Rebecca Davis:

Yeah. I've run the grassroots SAFe implementations where you start with the bottom and then you kind of move up. And personally, and this is a personal opinion, I'd much rather take the time and the efforts to get the communication right with the leaders and get the full leadership buy-in than be in that place again, where I'm trying to grassroot to move up and I hit the ceiling. The one thing I used to kind of tell the coaches that reported to me, and something I believe in deeply, is what we're trying to do with transformation is a journey. It's not a destination. So because we want to start that journey healthy and with a full pack of food and all those things, we need to take the time to really go and be bold and have conversations with our leaders, get their buy-in to go to Leading SAFe.

Rebecca Davis:

If they're not bought in to coming to a two-day course, then why would we believe that they're going to come to PI plannings and speak the way that we hope they will and create the change that they need to really lead? So I think that's one of the most important things, if not the most important thing from the very beginning, is be bold as that first change leader in your organization, go make those connections.

Rebecca Davis:

It may take a while. I've been in implementations or transformations where it started with just me discovering issues that senior leaders or executives were having, and going and solving some of those, so that there was trust built that I was a problem solver. So I could ask for the one hour executive workshop, which really should be a four to six-hour executive workshop, to get to the point where I could do the four to six-hour executive workshop, to get to the point where I could do PI Leading SAFe. And if that's what it takes to gain you that street cred to go do it, then, man, go do it, because that's where you get full business agility, I think, is getting that really senior buy-in and getting that excitement.

Jasmin Iordandis:

Yeah. That's really interesting. And I think building that level of understanding and building that foundation, we can't go past that. And I guess on that as well, from your experience, you've kind of hinted at one there, but what have been some of the challenges that you've experienced in implementing SAFe or even just in agile transformations more broadly, and as well as some of those opportunities that the framework has helped to unlock? So let's start with the challenges. What's some of the hard things you've experienced about an agile transformation and even implementing the framework?

Rebecca Davis:

Yeah, I'll give some real examples, and this first thing is going to sound a little wishy washy, but I also believe it, is the biggest challenge to transformation is you. So what I've discovered over the years, is I needed to step up. I needed to change. I think it's really easy to be in an organization and say, "My leaders don't get it," or, "Some won't understand," or, "It's been this way and I can't change it." And I think that the first thing you have to decide is that that's not actually acceptable to you as a person. And so you as a person are going to go fight. Not you're going to go try to convince somebody else to fight, but you are going to go fight. So I think that personal accountability is probably the biggest challenge to wake up every single day and say, "I'm going to get back in there."

Rebecca Davis:

I think from an example point of view, I've definitely seen huge challenges when the executive team shifts. So when we've got a set of leaders that we did the tipping point, we've gone through Leading SAFe, we've launched our trains. And then the organization, because every organization is going through a lot of change right now, and people are finding new roles and retiring and all that, there's a whole new set of executive leaders. And I think one of the things to discover there is there are going to be moments where it sucks, but you have to go and restart that implementation roadmap again, and reach that tipping point again, because there are new leaders. And that's hard. It really is, and it drains you a little bit, but you've just got to do it.

Rebecca Davis:

I think other challenges I've run into is there's a point after you've launched the trains and after you have been running for a while, where if you don't pay attention, people will stop learning, because you're not actively saying like, "Here's the next thing to learn. Here's the next new thing to try." So I do think it's the responsibility of a change leader, no matter if you're a LACE leader or not, to pay attention to maintaining excitement, pay attention to the continuous learning culture and really motivate people to get excited about learning and trialing and trying.

Jasmin Iordandis:

Yeah. That's an interesting point. How have you done that?

Rebecca Davis:

Hmm. So I think a few things. One, I had big lessons learned that there's a point inside of a transformation where, as an SPBC or as a change leader, that transformation is not yours anymore. So I had kind of a painful realization at one point that I had in my head the best next thing for the organization, and I was losing pulse of the people who are actually doing the work. So I think what I've discovered after that is, to me, there's a point where your LACE members and your change leaders and your SPCs need to start coming from a lot more areas. And honestly start to be made up of people who are not, at the moment, excited about the SAFe implementation, so you can hear from the pulse of the people.

Rebecca Davis:

And then I think if you can get those people and invite in and say like, "I'm inviting you to share it with me what's frustrating, what's good, what's bad, what's great, as well as I'm inviting you to tell me all the things that you're discovering out there in webcasts or videos that seem you'd like to try them, but we're not trying yet, and start giving back the ability to try new things and try things that you feel are probably going to be anti-patterns, but they need to try them anyway." So kind of a scrum master would do with a team of like, "Yeah, go try and then we'll retrospect." I think you have to do that at scale and let people get excited about owning their own transformation.

Jasmin Iordandis:

And what's the balance there between implementing the framework and taking all the good stuff that the framework says is good to do, and then letting people experiment and try those things, as you say, that may be anti-patents? Where's that sweet spot to allow that autonomy and that flexibility and that experimentation with still maintaining the integrity of the framework?

Rebecca Davis:

So I think the interesting thing is they are not actually different. So in the framework, we say hypothesis first, test first. So what I found is a layered kind of brain path where there're the steps in the framework and make sure we have teams and balance trains and all the principles and the values, and if you can live those principles and values all the time, while you're testing new things. So you test first like, "Hey, I want to try having my train off cadence from the other trains. I think it would be helpful for us." "Cool. Test that." And what we have to test it against is are we still living our principles? Are we still applying our values? Are we still applying the core fundamentals of agility and lean throughout that test and also as proof points?

Rebecca Davis:

So do we have an outcome where," Hey, I just made my train into a silo," or do we have an outcome where, "Well, now we have two different PI plannings within the overall PI cadence that one of them we merge with all the other trains and the other one is shorter because our market cadence is faster." Well, that's a beautiful win. So I think the key is it's not different, but one of the test points is make sure to check in on those principles and values.

Jasmin Iordandis:

Yeah. Have you ever seen that work well? The example that you just provided with the PI cadence, that makes complete sense, and it doesn't seem like it's going against the grain with anything that SAFe is there to help you achieve.

Rebecca Davis:

Yeah, I think that. This was kind of a little bit of what my summit talk was on last year, is during COVID, there were some trains. We had, I don't know, 30 trains. Two of them were having daily new requirements emerging from all the different states across the United States and emerging from the government and emerging from everything. Those trains were making sure everybody could get vaccinated across the United States. That's really darn important. And they needed to re-plan sometimes daily. It just didn't make sense to say, "Now we're just going to stop and go into PI planning for three days," when there wasn't any way that they could even think about what the next day's requirements could be. Since then, they still have a faster market rhythm. Then there are other trains that are working on, have a set unknown. There are trains that know that these holidays are when we need to release something or end of year is when we need to make sure that we've got something ready.

Rebecca Davis:

COVID is still in a reactive state. So what they've emerged into this year is those trains are still doing PI planning from my knowledge, I'm not there anymore, but from my knowledge. But they do eight a year instead of four a year. And four a year are on the same cadence and the other four are not, and it meets both needs. So I do think that key is test, and don't test just for the sake of it just because something feels dry or you get a new leader, and they haven't gone through Leading SAFe, but test because something actually doesn't feel right about, "We're not meeting our principles or values right now. We think that we could meet them better in this way. We think we could accelerate the flow of value in this way. Let's try it."

Jasmin Iordandis:

Yeah, cool. And on that, what are some of the red flags that you've seen in practice where those values aren't being met to be able to say, "Hang on a sec. This isn't working. We need to switch course"?

Rebecca Davis:

Yeah. Some of the things I've seen are the whole fun around when people are prioritizing their hierarchy or their piece of the organization over the enterprise value. So I've definitely seen people come to me and say, "Hey, I'd like to do his test." And when I ask the reasons why, a lot of the reasons are like a thinly veiled, "Because I would like more control."

Rebecca Davis:

So I think back to the values piece is that, "Okay, what's your why? Let's start with why. Why would you like to try something? What does that trial outcome achieve?" And, A, if it's really hard to articulate, probably there might be a bad thing going on, or if it is articulated and it actually goes against agility or lean practice and or diminishes flow or creates a silo, that's an initial gut. I think throughout testing, it's important to, the same way that we would do with iterations, have check-ins and demos, not just of what's the product being produced, but what is the change producing? So figuring out what those leading indicators would be and treat it the same way as we would treat a feature hypothesis or an epic hypothesis. We have some outcome we believe we could achieve. We're 100% open to being proven wrong. These are the things that we want to see as leading indicators as success and be really open with each other.

Jasmin Iordandis:

Yeah, cool. And it sounds like what's key to that though is having some concept of what that intended outcome is as a result of that experiment. It's not just going in for, as you say, the sake of doing an experiment. You want to have an idea of where you want to end up, so you can see if we're actually getting there or not.

Rebecca Davis:

Yeah.

Jasmin Iordandis:

That's really fascinating. And I think experimentation and iterative improvement, it kind of goes together. It's not just blindly following something because that's what you are supposed to do. It's preserving the values. That's a really interesting concept. And I think in that, would also come enormous opportunity. So in your experience as well, going back to the times where you've brought SAFe to an organization, or you've been going through an agile transformation, what are some of those opportunities that you've seen the framework unlock for enterprises or organizations that you've been leading those transformations within?

Rebecca Davis:

Yeah. I always was drawn to this idea of true value flow and business agility. So for me, what Scaled Agile helped unlock in a few of my organizations is, I always targeted that, like I'm not trying to make my thing better, I'm trying to make everything better. And with that mindset, really pushing for anybody should be able to take a class. Anybody should be able to take any of the classes. And these days, the enterprise subscription helps with that a lot. When I first started, we didn't have that. So it was also like anybody can take a class, and there should be creative ways of getting it paid for it.

Rebecca Davis:

But through that kind of invite model of really anybody, I had a nurse come take one of my SAFer teams classes, just because she was curious and she saw something about it on my blog, which ended up with her being more excited and getting to do agile team coaching for a set of nurses who were highly frustrated because their work on an individual basis was ebbing and flowing so much, and they felt like they weren't giving good patient care to coaching them on Kanban and having them all get really excited because they got to nurse as a team and whoever was available took the next patient case, and the patients were happier, and just being able to invite in and then say yes to coaching all of these roles that are so meaningful and they're so excited and they're something different.

Rebecca Davis:

And that same model ended up going from nothing to having a marketing person randomly take one of my Leading SAFe classes, which then turned into them talking to the VPs of marketing, which then turned into an 800-person marketing implementation. So I think the key is be open and spend time with the curious. And it doesn't matter if they're in your org. It's not like that's what I was paid to do, it's just really fun. So why not? If somebody wants to talk to you about agile, talk to them about agile. It's really cool.

Jasmin Iordandis:

Yeah, cool. And I think what I love about that is often agile may be associated just as software development teams. But as someone who's in marketing myself, I love the benefit and the way of thinking that it can provide to very traditional challenges, but the way that it can unlock those challenges in ways that not have not been approached before. And I think that there's something to be said in that too, around what you were saying earlier around maintaining excitement. And I feel like this question's already been answered, because often it's discussed, "Okay, we are scaling agile, we're going through a transformation." And it implies that there's this end state where it's done. It's transformed or we've scaled agile, but it doesn't sound like that's the case at all.

Rebecca Davis:

No, I don't think at all. I think mostly the opposite of... If you look at even yourself as a human, your whole life, you're transforming in different ways. Everything's impacting you. The environment's impacting you, whatever happens in your life is just this whole backpack that you carry around and you're transforming all the time. And the exact same thing, I think, for an organization and company. Today's age is nuts. There're updates all the time, there's new technology all the time. You and I are doing a talk from completely different countries, and there's change literally everywhere.

Rebecca Davis:

So yeah, I think part of transformation is helping your organization feel comfortable or as comfortable as possible with the rate of change happening and all the people within it, and not see change as a bad word, but as a positive thing where we can make betterness out there. And it's forever. It's a journey. It's not done. I really like Simon Sinek when he talks about that infinite game. I just feel really close to that of, we're not in it to win this moment or this year, we're in it to make a better future for ourselves and our children, and that's going to take forever. The people are in it right now and they've got to be excited about that.

Jasmin Iordandis:

Yeah. And I think that's that balance of delayed gratification, but constant improvement. So you'll feel and experience the improvement along the way. It's not like it'll be way out in the future where you won't feel the benefit of what you're doing, but it's something that's going to be built up and happen over time.

Rebecca Davis:

Yeah. And I think you reminded me just from saying that. I did that marketing transformation, and I just deeply remember a call with one of the marketing VPs who, after four or five iterations, I did a check in with her. And she's like, "My team is so happy. Is this because of agile? Is this what agile is, is happy with [inaudible 00:32:17]?" "Yes."

Jasmin Iordandis:

Yeah, joy at work, right?

Rebecca Davis:

Yeah.

Jasmin Iordandis:

Isn't that what it's all about? That is so cool. And yet the goal initially is never to go out and make people happy. It's just one of those bonus kind of side effects, a happy side effect.

Rebecca Davis:

Yeah.

Jasmin Iordandis:

Awesome. And I think I really want to talk about this idea, because you've mentioned it a couple times, you've even just mentioned then marketing, nursing. But then when you're in these larger organizations, you've got all these different functions. And I think it raises this idea around organizing around value. So I want to make sure we talk a bit about that, because value doesn't just happen from one function, or it's not delivered from just one function or one team. It's something that many people across an organization may have a hand in delivering. But I really want to get your take around this concept of organizing around value. What does that mean and what does that look like?

Rebecca Davis:

Yeah. I think there's a base concept that is also in that implementation roadmap around what happens first. So how do we first organize around value, because organizations tend to be organized around hierarchy. I am a VP of marketing and I have marketing all the way down. And so there's that first step of identifying what the value is that you produce as an organization. So being able to articulate it to begin with, which is not always an easy conversation. Sometimes it takes a bit of time, and then organizing all the different types of roles around what that value is. So I think that's your first thing in what most organizations implementing scaled agile start with, is just identifying it, forming around it, which ends up being what your trains end up being.

Rebecca Davis:

My experience is, because of that same rapid market change, the world changing so far, it's really important to re-evaluate how you've organized around value over time. So in my experience, one of the really healthy things that we used to do is, at the end of each year, give a chance to look at the different train structures and look at how we've organized and say, "Is this still right? And what's our strategy for next year? Where are we trying to head for our consumers and our users? And is there a different way to organize, that helps us with that?" And I say give a chance because in some years, we'd be like, "No. 80% of our portfolio is actually good to go. Things are flowing. We're doing okay." 20% of it has an entirely new strategic shift that's going to hit them, or, "Last year felt not good. We had too many dependencies. We didn't have the right people on the right trains," all those things.

Rebecca Davis:

And so at least take a pause and look at it, and see if our value still mean the same thing as it did a year ago or two years ago. Do we need to reorganize? What does that mean? What does the change leadership around it if we do need to, so that we're always focused on value, and it's not a definition that we gave ourselves five years ago and just stopped realizing that the world has changed.

Jasmin Iordandis:

Yeah. A living definition because it changes depending on what's going on in the world, but also what's going on within the organization and coming back to that idea of experimenting as well, like if you've tried out a new way of working, and that's gotten in the way. But even something that you said there really stood out is, "Okay, it didn't feel good. We might have had too many dependencies." And that brings up the idea of, "Well, how does that flow of value happen?" Oh, that sounds like there's a stifle to the delivery of value. So how do you optimize that flow particularly when there may be multiple people delivering that value?

Rebecca Davis:

Yeah. And I think Scaled Agile gives us some tools for that. So I think one of them is that first session I talked about, value stream and down vacation, so that you can really do a process for talking and discussing with the right blend of people. What is the value and how can we organize around that? I think past that point, there's another tool that I see used far less than I would think it would be, which is value stream mapping. So after we've identified it, now can we actually map what's happening? From concept to cash, which teams are doing pass offs? How long does it take to get an answer on an email? How long is it taking from testing to all the way to release?

Rebecca Davis:

So doing a lot of intentional measurement. Not measurement because we're judging people, but intentional measurement of, we organize this way, this is where all the pieces are connecting, and how long things are taking, as well as how people feel inside of their steps, like does it feel silo? Does it have an outcome? Did we put all of the designers and HR people and engineers on a train, but we made them separate teams, and so it still doesn't feel connected? That's what mapping's for. And those maps and also the program boards that actually visualize like, "Here's the dependencies," versus, "At the end of the PI, this is what those dependencies actually ended up being."

Rebecca Davis:

It's not that dependencies are bad, but they should be adding value, not restricting flow. So I think those connected stories as well as things like employee survey scores and just employee happiness are really good inputs, to, are we delivering flow. And it is a blended view. Some of it's qualitative and some of it's quantitative. But are our own internal things showing us good, bad and different, as well as how are our customers. So do they feel like they're receiving value or that they're receiving bits and pieces and they're unsure about the connected value? I think all of those are indicators.

Jasmin Iordandis:

Yeah. And would you say you'd need to have an idea of what those indicators are beforehand, so you can keep an eye on them as the PI progresses? So for example, you've done your value stream mapping, you've built your art. At that point, do you identify what those measurements of flow ought to be and keep an eye on them, or is it more retrospectively where you see these kind of things getting a little bit stuck?

Rebecca Davis:

I think there's both. So definitely those metrics that we indicate inside of the framework are healthy, good for teams and trains and solution trains and portfolio. So I think there is a set of metrics that you should and can utilize. Retrospectives are key, because retrospectives create action. So while we measure, then what's the conversation we have about them? Because what we don't want is vanity metrics. And my personal way of defining vanity metrics is any metric that you do nothing with.

Rebecca Davis:

So I think a key is use them to hold conversations and create outcomes, and create actions and make sure that you're prioritizing those actions. I think there's another piece of just understanding that this is not just about team and train. So teams and trains definitely do need to improve and measure themselves, but so does the portfolio, so does the enterprise, so do the pieces that connect to each other across different trains. So I do think if you over focus on, "Let's just make our teams go faster," you may be missing the whole point of how do we make our organization flow better, which may or may not equate to moving faster right away.

Jasmin Iordandis:

Yeah. Yeah. And team and train don't exist in a vacuuming within that organization like whole bunch of-

Rebecca Davis:

No, [inaudible 00:40:43].

Jasmin Iordandis:

Yeah. Well, I think we've touched on some really, really interesting concepts, and just I can't wait to hit the SAFe Summit, which is a really good segue to the fact that the next time we meet, Rebecca, it will be in person. And you're hosting a workshop at SAFe. Can you give us any sneak peek of what we can expect to be excited about at the summit?

Rebecca Davis:

Yeah. First of all, when we meet each other in person, I'm very short. So I think I'm maybe five foot. So that'll be exciting. So Harry, on the framework team and I, are running a workshop about flow. So we'll be doing a flow workshop. I can't talk about all of it yet, because some of it we're going to announce inside the summit, but I'm really excited. So I think if you do sign up for our workshop, you're going to get active advice, and be able to work also alongside other organizations and other people, really understanding flow, and how to apply improvements to flow and how to identify blockers to flow and what to do about it. So we're really focusing on why do certain things matter and what can you specifically do about it, whether you're at the team level or the train level or solution level or the portfolio level.

Jasmin Iordandis:

Cool. That sounds exciting.

Rebecca Davis:

And we [inaudible 00:42:08] a lot of other workshops, but definitely come to ours.

Jasmin Iordandis:

Well, we've just spoken about the importance of flow, so it makes sense. Right?

Rebecca Davis:

Yeah.

Jasmin Iordandis:

Awesome. Well, I personally am really looking forward to coming to SAFe and coming to Colorado and to get to chat with you a little bit more. But thank you so much for your time and joining us and sharing your expertise and experience on agile transformations, scaling agile and the SAFe framework itself. Thank you so much for your time, Rebecca.

Rebecca Davis:

Yeah, I appreciate it. And I look forward to maybe one day being able to do this in person with you in your own country. So that'll be really awesome.

Jasmin Iordandis:

Yeah. Cool. That would definitely be awesome. Thanks a lot.

Rebecca Davis:

Yeah. Thanks.

"I loved having the space to talk about common interests - all things technical documentation & information architecture" - Henri Seymour

On this episode of The Easy Agile Podcast, tune in to hear Henri Seymour - Developer at Easy Agile speak with Matt Reiner - Customer Advocate at K15t.

Henri & Matt are talking all things technical documentation (we promise this episode is way more interesting than it sounds! 😉)

✏️ Considering technical documentation as a product
✏️ The value of well written documentation
✏️ Why you should be digitally decluttering often
✏️ Information architecture

So many golden nuggets in this episode!

Be sure to subscribe, enjoy the episode 🎧

Transcript

Henri Seymour:

Hi, everyone. This is the Easy Agile Podcast. We've got an episode today with Matt Reiner. I'm your host for today, Henri Seymour, developer at Easy Agile. And just before we start the podcast, I'd like to acknowledge the traditional Australians of the land on which I'm recording today, the Watiwati people of the Dharawal nation. Pay respect to elders past, present, and emerging, and extend that respect to any Aboriginal or Torres Strait Islander people listening to this episode.

Matt is an experienced content strategist with a history of working in the computer software industry, skilled in agile scrum framework, related tools, communication, technical writing, video production, customer interaction, strategic planning. And he's here today to talk with us about writing and specifically technical writing and documentation. Hi, Matt.

Matt Reiner:

Hi. It's great to be here. Yeah, I'm Matt. I'm into all sorts of content things. And one of those is technical writing, which is, I think more interesting than it sounds. I guess you'll have to decide by the end of the podcast, if you think so.

Henri Seymour:

Technical documentation experts. So when you talk about technical documentation specifically, what do you mean by that?

Matt Reiner:

Well, I feel like that term is actually in the middle of a big change right now. In the past, technical documentation was very strictly like, "Okay, we're a team, we're making a thing, a product." Maybe it's an app, maybe it's, I don't know, a go-kart and we need to have a user manual for that. Technical documentation was someone sitting down and writing down, "Okay, here are all the knobs and switches and here's what they do. Here are all the features. Here's maybe why you would use them."

So putting together that user guide, which traditionally was printed material that you would get with the product. But it's become a lot more over time, partially with the internet, because we can just constantly iterate on content like many of us do with the products that our teams make. And then also we are seeing it in new forms. Maybe it's not a printed piece, in fact, most people do not want printed technical documentation anymore, they want it online. Or even better, they want it right in context in your app when they're using it, they can just get the info they need, and then get on with it.

That's what technical documentation is. It's supposed to be there to help you do the thing that you really care about and then get out of the way so that you can do it.

Henri Seymour:

Do you have a description of why good technical documentation? Not just having it, but having it at a good quality in a way that really helps your users, is so important to product users.

Matt Reiner:

Well, I suppose we all find those points in our day or in our journey that we find ourselves in where we want to accomplish something, but we don't know how to do it. So a lot of us have really gotten very used to jumping on Google and saying, "Okay, here's this thing I want to do, how do I do it?" And good technical documentation is there with the answer you need, the explanation you need. Because really ultimately all of us are smart people who should be empowered to do the thing we're passionate about.

And technical writers and communicators who are really all members of our team. People who sit down to create good technical documentation uses few words as possible to get a person on the way they're going. And that's like, when it happens its just like, "Glorious," not to the user. They don't even know that it happened, they didn't even know that they read your writing. But to the writer, it's like, "Yeah, I did it, I did it. They don't even care what I did, but I did it." And now they're doing the thing that really matters.

Henri Seymour:

That's great understanding one of the major differences of like, I've written something and I don't want my user to be spending time on it. I want as little time spent reading this as possible.

Matt Reiner:

Yeah, yeah, yeah. You can have great pride in your work, but one of those metrics that a lot of people look at for websites is time spent on page. So sometimes you can fool yourself into thinking, "Oh wow, they spent 10 minutes on my page. That means my documentation's really good." But also that might mean that it's not very good and they're having to reread it over and over again. So the true metric is, did they get to the thing they really cared about? And unfortunately, it's hard to measure.

Henri Seymour:

You mentioned now that with the advent of the internet and giving you the opportunity to iterate on those docs in a way that you wouldn't be able to with printed documentation. That iterative thing brings the agile process of iterate on something that you already put out and improve it in the same way that as a developer I do for products. Can you tell us more about that iterative agile sort of process?

Matt Reiner:

Oh yeah. Yeah, it's so true. Documentation used to be back in the waterfall standard, more typical product project management days, documentation was a major part of it. You'd start this project by writing these massive documents of, "Here's what we're going to set out to do. And here's all the considerations, and here's how everything's going to connect up." And that did work really well for a lot of hardware. Which was the thing that we made for a long time. Just everything that humankind made was hardware often, as groups anyway.

And then all of a sudden this whole software thing comes along and we're trying to build that like it's a physical thing. And we get to the end of this two-year software project and people are like, "Yeah, that's not the thing that I wanted." But we're like, "Oh, but we go back to the beginning and look at that documentation, and that's what you said you wanted." But now with the internet and with just agile development, we really need to move away from this place where we start with a pile of documents. And then we develop another pile of documents as our, I don't know, development guidelines.

And then our test plans, and then finally we end up with user documentation. Instead, these days, documentation should really just grow from a very small piece of content throughout that whole agile development cycle into that final user documentation. Because it doesn't matter what we set out to make, it matters what we make. Nobody he wants to read about what we thought we would make, that's straight up fiction. And it's probably not an interesting read. It's really that final user guide that comes out of the agile process, but that's a big change, but it's a good one.

Henri Seymour:

I love that idea of just like, this is gradually growing. There is no specific start block and end block. It's a process. And you mentioned the opportunity to iterate on those documents. Do you have any advice for after you've published digitally your technical documentation from iterating on what you've already got there, improving that over time?

Matt Reiner:

Oh yeah. I know every agile framework is different, but they all have that feedback phase, where... And really that's throughout the whole process, but we do need to dedicate some time. So, there's a lot of different things we can look at. For example, I don't want to say basic, a standard one that we should be looking at is, you should have a help center, where you can implement something like Google Analytics so you can see just, what are people looking at? How long are they looking at it?

Another really good one is, you have to set it up separately in Google Analytics. What are people searching for on your site? You can also use Google... used to be Webmaster Tools. I think it's called Site Tools now, but you can see what were people searching for on Google before they came to your pages. That's all really, really valuable stuff. Then you can get more advanced. You can look at pointer tracking, apps that you can embed on there, which you get some pretty wild stuff.

But then you also, you want to consider having a forum at the bottom of each page like, "Was this helpful? Was it not helpful? Oh, it wasn't helpful? Tell me why. Oh, it was helpful? Tell me why." Just like a YouTube creator, they look for that feedback. That feedback is essential, the thumbs up. In fact, it's very controversial, YouTube just announced that they're going to hide the thumbs down numbers, but a lot of creators are like, "No, no, no don't do that because that communicates the value of this video that is out there."

So there's a lot of those signals. And then there's just really soft signals that, it's hard to know if people are using the content or not. Because you may never hear. Especially, if it is one of those things that they just get in and get out, you're not going to hear anything about that. But the feedback phase, it's really great to... Anytime you're getting feedback on your product that you're making, try to get your documentation out there as well. Because that's the time where people are open to exploring your product and giving feedback.

So why not explore that same documentation, the related documentation to see, "Okay, is this actually helping these people do the thing that they want to do? Or should we improve it just like we do with the product?"

Henri Seymour:

No, that's a really good, comparing the, we've just released a product. Give us feedback with doing the same thing with the documentation. Because that's when it's going to reach its peak use before everyone's got the hang of it. We've just done this feature release, let us know how you go using it, and the documentation is in a sense part of it, especially for more complex products.

Matt Reiner:

Exactly.

Henri Seymour:

Do you have any background in the customer support side of things? We do customer support in-house as well as their documentation. So we're trying to improve the documentation to lower the support load on our team. Do you have any background in that... Can you solve it?

Matt Reiner:

Yeah. Well, yes and no. It's interesting. I work at K15t now, I used to be a customer of K15t's, so that's actually how I met the team. And that was also how I met documentation in the first place. At my last job, they brought me in to administrate this system called Jira. And I was like, "I don't know what that is." I told them, "I thought I could do it." And I figured it out, it was this little thing called Jira On-Demand, which is now Jira Cloud. And I introduced Confluence On-Demand to the company as well. And wow, I broke Jira a lot of times.

Luckily it wasn't like mission critical at the time, we were still really figuring it out. But it was through Atlassian's documentation on Jira that I really learned like, "Wow, there is tremendous value to this content here." And then I discovered, "Okay, how is Atlassian creating their documentation? Oh, they're doing it in Confluence. They're writing it in Confluence. They're using these apps from K15t." And so I started using those apps, and then I talked a lot to K15t customer support, just questions and how do I get this started?

And we also do our support in-house, so it's really great. So maybe as a customer, I overused it, I don't know. I should ask some of my colleagues if they got sick of me. But the benefit was very clear because they would send me, "Oh, here's documentation on this. And here's the answer to this question or here are the considerations you should keep in mind." And actually several of our teams now, we're really looking at, especially, for those features that are very robust, people have questions.

So it's like, how can we enable them to help them help themselves? And putting those resources out there is one thing, making sure that Google can find them, well, is another. But that is a really important thing, especially, since as a product team, when your user base grows, so does your need for support. It's just... I don't want to say it's exponential, but it's in line with each other. And so, one of the ways you can mitigate that is, making sure you have good design so that your product is easy to use. And then another is you need to have good content all around that entire experience so that you don't have to keep hiring more and more support people.

Or your support people can specialize and really focus on those deep entrenched issues, and then the documentation should help with the rest. But the secret sauce there is tricky. It's hard to write the perfect content to deflect the cases. That's everybody's dream.

Henri Seymour:

Even if it is just not all of them, but some of the common use cases start to get deflected away from support because people can self service. It does make a difference. And I really understand the idea of Jira documentation as well. Easy Agile works on Jira and it's... Jira is an incredibly complicated product at this point, and I imagine it probably was also complicated when it was Jira On-Demand. Because it's so complicated and so detailed, there's no way to make that easy to understand for a user without that documentation. There's no getting around that one.

Matt Reiner:

Yeah. I think there should be a club for the people who have broken workflows too many times in Jira. But yeah, I mean the documentation saved me many times and I would have to put out a... Well, it was a HipChat message at the time. May it rest in peace and I'd have to say, "I broke Jira, give me a minute. I got to go read something." Not the way you want to learn Jira, but it's an option.

Henri Seymour:

It is. Sometimes you learn things by breaking things. That's-

Matt Reiner:

That's right.

Henri Seymour:

Really seems like my experience in software so far. You try to break the things that people aren't currently using and that's about all you can do.

Matt Reiner:

Exactly.

Henri Seymour:

So K15t has recently published Rock the Docs. Can you tell us a bit more about this project?

Matt Reiner:

Yeah. Rock the Docs, actually, it came out of a lot of that information that I got from K15t. Customer support, I got from K15t documentation, I got from Atlassian documentation. And then some of the stuff I figured out on my own, or some of my colleagues at K15t did. Essentially like, what are the best practices for creating really good content in Confluence? And it really started with a collection of guides on how to create technical documentation content. It's geared toward like making a public help center, but really it's for any kind of content that you want to be like evergreen, longstanding content to be able to help people.

So we initially talked about all sorts of things like structuring your content, content reuse, managing multiple languages, which can be tricky in Confluence. Collaboration, publishing your content outside of Confluence in one way or another, managing versions of that content. So, that's the start of it. And then we saw a lot of positive response with that and we had more general questions like, "Okay, but what are the best ways to get feedback in Confluence?" Or, "How do I make a template or a good template or how do I make a good diagram in Confluence?"

And so we've grown that content to focus on just all sorts of general Confluence things. Because we found that there's a lot of information out there on how to do something. Atlassian documentation really helpful, but there wasn't as much, I'm like, "Why would you do it? And why would you do it this specific way?" And we've been working with Confluence for over 10 years now. Like I said, I've been with Confluence since the crashy early cloud days. It's grown up so fast, it's beautiful.

But we just know we've done a lot of stuff with Confluence, so it's been a real privilege to share that both in like these written guides. And then actually recently we've started publishing a series to our YouTube channel as well, all about Confluence best practices.

Henri Seymour:

That's great. It's real interesting to hear how that started as a smaller project than it turned out to be, because you could see the value in it and the use in it. We've discussed Confluence a few times now and K15t builds apps that use Confluence as a documentation source. Can you tell us more about what makes Confluence useful for building technical documentation? What sort of tools and approaches that make it useful in this context?

Matt Reiner:

Yeah. Confluence is by nature open, which is not the way technical writing tools are built. In fact, I remember the first time I went to a technical writing conference and someone asked me, "Oh, what tool do you use?" Which is like, what technical communications people talk about, because we're all nerds in that way. And I was like, "Oh, I'm doing it in Confluence." And they didn't really want to talk to me after that because they didn't think I was a serious tech writer. And I was like, "Oh no, no, no, no, this is all happening."

At that point, Rock the Docs didn't exist. So I couldn't be like, "Go over there and see how it works." But the biggest difference is most tech writing tools are just totally locked down. You have two licenses for your two people who are trained professional tech graders, and then everybody else, there's no access. You don't touch it. Maybe your tech writers will send you a PDF and you have to go through the God awful process of marking up a PDF to tell them like what to correct. Or, I've heard of teams printing out the content and people penciling in what needs to be changed.

The review processes are just out of this world insane. And those tools don't fit terribly well with agile processes because it's like, you build the thing over here, and then here's the two tech writers over here in their separate tool. And at some point we'll be like, "Okay, this thing's done. Would you write about it?" So with Confluence, the benefit of using Confluence is, it's accessible to everyone on the team and even people outside the team. And that's incredibly by an official because we've seen with agile, but we're also seeing in this technical communication and in information design field, that teams are less and less looking for those specialized individuals who are trained tech writers.

Which that's an oxymoron because half of us, we don't have degrees in tech writing, we fell into it for one reason or another. But now teams are starting to see, "Hey, I can be a code developer and an information developer. I might not write the final piece of written content that is seen by our customers, but I might write the first draft." Confluence really opens that up for everyone. And especially with like at mentioning and inline comments, review processes are just so fast.

Actually, the reason that I switched to Confluence at my last job, was my product manager threatened me and said, "I will not mark up another PDF. Go and find a good tool that we all want to work in." And that's where we landed on Confluence. It's about bringing the whole team into the writing process instead of having it be this separate thing. Because when it's a separate thing, we lose track of it. And content, we forget how important it is to our product, to the customer life cycle, to... God bless customer support, who really, really need that content to be good and accurate.

And it needs to be seen by the real experts who validate, "Yeah, okay, this is correct. This will actually show people how our product works." And Confluence is like the heart of that.

Henri Seymour:

No, it's great to hear how that all comes together to build the documentation as a team. Can you speak more to the different roles in, specifically in software development and the different roles you're looking to get involved in your documentation process? We are working on building our specific app teams here at Easy Agile as we're growing at the moment.

Matt Reiner:

Yeah. That's such a good question. Well, what-

Henri Seymour:

And how do you incorporate... Sorry, this is more specific to my question. How do you incorporate that technical writing process as part of the work of an agile software development team?

Matt Reiner:

Well, first, it starts by rethinking priorities because most teams are like, "Documentation down here, testing and then everything else above." So generally, those two things should be moved up. And actually, the content around our product is... I don't want to sound over traumatic, but if we don't have information, we don't have a product. I don't care how much code you write. If we're not explaining it to people, if we don't have good UI text, if we don't have good in-app help, it doesn't exist. It's not a useful tool, it's just a set of mathematics that humans can't interact with.

So content is essential, so it's really important that we elevate it to the position where everyone on the team recognizes that the content experience that our users have is the product experience they have. So it needs to be part of the product development process. So then the next step, which I know you're talking about team structure, but the next step is really everyone on the team needs to know they're a writer, and they're a good writer. And that's important because a lot of people have never heard that. They've never heard that they're a good writer, and they probably have never heard that they're a writer.

I remember going through university, my writing classes were the things that I didn't pay attention to. I was doing mathematics, and Java programming, and statistics. Even that seemed more important to me, not the writing classes. And then sure enough, it turns out everyone has to write. We all write. So knowing that that is a role that everyone fills is really important. And then when it comes to actually team structure, you need to have individuals who are willing to cross the streams, so to speak. If you're bringing in someone who's focusing on test engineering, they need to realize that the test plans they're writing are very similar to a lot of user documentation that needs to be written.

They're writing task topics, or task instructions, do this, do this, do this over and over again. That's documentation. They could be contributing in that way. Engineers, as I mentioned, they could be drafting the first copy of a lot of what are called concept topics. So areas of documentation where you explain concepts, because they already know what those concepts are. In fact, if you look at the root of a lot of agile development teams, they're using epics and user stories and acceptance criteria. And all those map perfectly into the documentation you needed to create for that new feature you're working on or feature you're improving.

So really, it's essential to have everybody recognize, we are all already creating documentation, so we can contribute. And then of course, you really do want to have at least one probably native English speaker. Maybe not native, but someone who feels confident in their English or whatever language you're authoring in. English is typically the cheapest one to translate to other languages, so that's what people go for often. But that person's the person who takes everything everybody's written, gets it to the right style and tone. And then gets it out there. That's what we are seeing be successful.

Like our teams right now, we don't have any legit tech writers. We have product managers writing. We have product marketers writing. We have engineers writing. Some of the best documentation I've ever read was from one of our German-speaking engineers. I was like, "Peter, this is an amazing guide. You got to get out of this Java and get into English, man. It's great. It's great." So he's done a few, which I really love. But yeah, it's about jumping out of your typical roles and realizing, we're all documenting this stuff, anyway.

Henri Seymour:

I love the focus, especially with your German-speaking colleague. The focus on, it's not just that you must write the documentation because you know how the product works and we need that written down. It's, you are capable of writing the documentation, you can do this. You have that added barrier of safety with somebody who's got the language proficiency that they're going to massage it and edit it at the end.

So, before it gets anywhere, anything that you do is going to get filtered out if it's not working. But you don't need a specific tech-writing background to write the docs.

Matt Reiner:

No, absolutely not. In fact, there's an entire community of what... They call themselves documentarians called Write the Docs. And that whole community, that whole group is focused on, it doesn't matter what you do, it matters that you care about writing the docs, contributing to the content. And that's been a big shift, I think in the industry, where people thought we're separate. But now it's like, "No, no, no, we are all able to do this." And once we can respect the contributions that each of us can make.

And then also, I have that protection of somebody else is going to have their eyes on this, which even my writing, I'm like, "I don't like to send it out until someone else has seen it." Because I make spelling mistakes and typos all the time. I really want to have another colleague look at it. Even if they're not native English speakers, because they catch my typos pretty often. That feeling of togetherness, it's the same way that we feel when we ship out a project or a product.

Whether you did the testing for it, or you wrote the code for it, or you did the product marketing for it. It's like, "It's our baby. Let's send it out and see what happens." Content's the same way.

Henri Seymour:

Yeah, part of my daily role and [inaudible 00:28:03]... We don't have QA team separate from developers. Our developers also review our code and it's that sense of, "I wrote this thing, but I have one or two other people who've refined it, who've made sure that it's good enough quality. They've got that fresh eye, so they'll see the spelling mistakes, they'll see the minor little errors that I've just been looking at it too long to notice anymore."

I found the documentation writing process has some parallels in there like, "Here's my thing. I'd like some feedback on it before it goes out into the real world."

Matt Reiner:

Yeah.

Henri Seymour:

That's great.

Matt Reiner:

Yeah, absolutely. Yeah.

Henri Seymour:

All right. Can you talk a bit about the difference between the customer-facing documentation that we've mostly discussed so far and internal documentation?

Matt Reiner:

Yeah. There are some differences and there are some major similarities. So this very... It sounds very technical and ugly. The term information architecture, it's really important with any kind of content, internally and externally. And really that's like, if you're a developer you're familiar with XML, you're familiar with structuring things in that way. Our content needs to work the same way. And that goes for internal and external documentation. So, many of the things that they use, writers, when they write a page or an article in the newspaper, they'll use that Pyramid approach, where they put the broad bits of information at the top. And then they slowly focus in on the topic and give more and more information about it.

But you want to make sure that if somebody only reads the first paragraph, they're getting a rough idea of what the information is. And that's really important for successful Confluence pages and spaces. People should be able to start at the top level of the space, understand what the space is about, and then be able to navigate down into the thing that they really want to learn about into the page itself. Which should then be using headings and subheadings and bullet points to get, again, just disseminate that information and break it down. Because everybody skims.

We need our content to be skimmable, our spaces need to be skimmable. And that kind of content also makes Confluence search happy, especially the new Confluence Cloud search, which has been greatly improved. There's a whole new elastic search base to that that's being optimized. But it's happy, it's just like with Google when we structure our content like that. So when you have a page that is just a wall of text, no headings, you're not breaking it up into pages or even spaces, nobody's going to be happy with that.

The bots aren't going to be happy with it, the people reading aren't going to be happy with it. So it takes a bit of work to structure, break up the structure of our content. It's probably all good as long as it's up-to-date, but it's really essential that we think about, how do we structure that in Confluence so that people can find it and people can skim it? And that is what seems to plague a lot of internal Confluence instances, because a lot of... Maybe the team isn't so focused on that.

It's like, "Oh, our external help center that's come coming from this space over here, that's fine. Our team space, hot mess, total tire fire." And nobody cares because they think they know where everything is. But then you start to think about, "Okay, but what about the new team member? How do they find something?" Or, "What about the team member who's been away for Paternity leave for six weeks? Are they going to remember where everything is or know where all the new stuff is?

What about folks with disabilities? Is it going to be much harder for them to navigate to the information they need? Because they're working with a screen reader and they're trying to go through a wall of text. They need headings, a screen reader relies on those headings and titles." So there's just so many considerations that really leadership of companies needs to understand, just because you have a process to do something or the information is somewhere, doesn't mean you don't have a major information problem. And maintaining all of your content in Confluence and then maintaining it well.

That is what enables people to avoid the frustrations of searching for information, losing information, having to relearn or rewrite information. I have worked at too many companies that just information sieves everywhere. I don't even want to call them silos because nobody knows where stuff is anymore either. That's what Confluence brings to things, and that's what matters with internal content pretty much as well as external.

Henri Seymour:

That's a great perspective on it. And I can see the silos, it's a really more... Just a one big pile, you can't find anything. I've been-

Matt Reiner:

Exactly.

Henri Seymour:

... at Easy Agile for more than half of its life now and I've got that sense of like, "Oh, I know I wrote this down somewhere. I know I've seen this written down somewhere." And we are making a habit, especially as we're hiring more and more people. Every time somebody's going through onboarding, they're going to be looking at all of this documentation with no previous background on it. And we want to hear their feedback on it specifically. Because if it works for them, then that's the documentation that we need for them and for everyone after them, and for everyone who's already here.

Especially, I've been at Easy Agile for almost three years now, and I've seen it grow from eight people to now we're up to high 20s, I think. We're going to cross over into the 30s by the end of the year.

Matt Reiner:

Wow.

Henri Seymour:

The growth of information that we have in our internal documentation, and I'm sure it would parallel the growth of the product documentation for a product that's been expanding for three to five years. How do you manage the documentation and the Confluence spaces as the team and the company grow and you just develop more and more pages out of it?

Matt Reiner:

That is the question since the dawn of the universe or at least the dawn of Confluence, which, what's the difference? The biggest thing is team responsibility, so knowing this is our space, this is our content. And not like in a territorial way, but this is our responsibility. Much the way we should think about our planet, we should also think about our content, keeping it groomed and taken care of, and up-to-date and accurate. And then as things change.

For example, we have a product called Scroll Viewport, which is actually what enables you to publish content from Confluence to a public health center, which is really, really cool. So with that, we had a server and data center version. We've had that for quite some time. That's what I was a user of. And then we set off to develop a cloud version, and cloud requires a whole bunch of new infrastructure, which is a lot of fun and very challenging, but it's a totally different beast.

It's not like you can just lift the server code and just drop it into cloud, which is what as a user I asked them to do for years, "why isn't this on cloud?" Now I know why. So we created a new team that started off this Scroll Viewport on cloud effort. And it was just a very scrappy project at first. And I remember the first page we got up there, it's like, "Whoa, look at this page we published." And then it progressed from there. But then at some point, we needed to bring the two teams back together. And what we could have just said, "Oh, this old Viewport space, whatever. We're just going to leave it there and then just go on with the new one."

But instead the team took time and brought the two spaces together and really went through the old content in the Viewport Server and data center space to say, "Is this all still relevant? Do we still need this?" So it's been reordered in such an amazing way. Several of our teams have gotten really good at making these spaces so that I can come in. Because I work with all of our teams, just get in and find what I need, even though I'm not working their day-to-day. I'm just so glad, I'm so proud of the team for not just letting that space languish somewhere or being afraid to delete or archive content, which a lot of people are.

It's like, "No, what if we lose something?" It's like, "No, no, no, we've moved past this. We really do need to delete it." So that's the kind of attitude it takes is, our teams to split and expand and grow, and we need conscious of that content. Because again, think of the new person, think of the person who's learning something new. Think of the person who maybe does have disabilities and is trying to get the content they need. They just don't have the background that you do. Having been with the company for half its life, you know how to dig through the thought pile to pull out just the thing you want, but they don't.

Henri Seymour:

Yeah, and I don't want to be the person that they have to ask every time they need information, "Hey, can you find this for me?" No, no. I want to build a system that means that I don't have to answer the same questions all the time. That's one of the reasons I've been doing internal documentation so much since [inaudible 00:37:36]. I've answered this question once, that will do.

Matt Reiner:

Yes. That's a really good way to motivate any contributors to documentation. "Hey, you know how you wrote that piece of our app that one time and then everybody's asked you about how it works ever since? Just document it once and I promise you can never answer it again." That's good motivation right there.

Henri Seymour:

It is. As well, we've got a team on support models, so I'm working on the store maps and personas, product development team. And that's the same team that gets all of the support requests about story maps and personas. So yeah, the better we make the product, the better we make the documentation, the less of our time every morning we spend doing that. And the more we can get back to our regular jobs.

Matt Reiner:

Exactly.

Henri Seymour:

It's been great for helping us keep in contact with the customers and what they're doing and what information they need when they're using our product. You mentioned that like it's necessary, it's valuable to be deleting an archive-based stuff, pages in Confluence from time to time. When you're looking at a page and wondering whether or not it's time to go, what sort of questions are you asking yourself?

Matt Reiner:

Well, a great one is like, look at the last modified date on that page. That's general a pretty good sign of like, "Are people even looking at it?" In fact, if you're on cloud premium and above, you can look at some great metrics on every page to see like who's looking at this thing? Is this valuable? What are the views like? Just the same way that you would look at your external website to see if your content is valuable or effective. But typically, we have a lot of debris left over from product development or team activities.

Like if you're in marketing and you have a campaign from three years ago, do you really need all of those detailed pages? Maybe keep the overall campaign page, maybe that's useful, but do you really need everything? If you're into testing, do you really need every test plan you ever created? If you're in the legal team, do you really want your legal terms from 10 years ago? Maybe, maybe, I'm not in legal. But often we have this fear of, it's like fear of missing content.

It's like, "Oh no, if I get rid of that, then I won't have it." But information, just like language, just like the way we think, just like the way our teams grow, it changes. And so we need to be aware of that. As we are changing as a team, you should expect our content to change. And part of that is shedding that old stuff. So it's always worth it, like if you're questioning it, ask another subject matter expert and be like, "Hey, I'm pretty sure we don't need this anymore, or we should revise this. What do you think?" But if nobody has any qualms, you should probably delete it.

Henri Seymour:

No, that's great. I am a big fan of decluttering, even digital decluttering. It's, I want people to find stuff and the less pile there is, the easier it's going to be.

Matt Reiner:

Yes. Because somehow bad information is less helpful than no information.

Henri Seymour:

Yes. It's like coming across a question and they're like, "Oh, I tried doing it this way." I'm like, "Oh, that way doesn't work anymore. You're going to have to do... Where did you find that written down? I'll go update out." It's-

Matt Reiner:

Yeah.

Henri Seymour:

... new people doing stuff. The best way to understand where your documentation is falling over. It's the same as you're never going to understand how your product documentation and that your product itself is failing your users until they come to you and tell you, "Why can't I do this thing?"

Matt Reiner:

Yeah. Yeah. In fact that that power of bringing in someone new on your team is so amazing. And it's almost hard to impart like first day of onboarding like, "You have fresh eyes, please use them. This is called an inline comment, please put it everywhere." I remember going through our human resources employee handbook, which we had just created not too long before I joined. And I remember them telling me, "If there's any questions, at mentioned us." And I was really afraid to do that. But we corrected a lot of things.

For example, we mentioned do these things on... What was it called after HipChat? The product that lived and died so quickly.

Henri Seymour:

I think I missed that one.

Matt Reiner:

Oh, the one that Atlassian made and then they sold it to Slack.

Henri Seymour:

Now, where do I even start on that?

Matt Reiner:

How am I... It was a great app, I really liked it. But we mentioned in the employee handbook to use that. And I'm like, "Oh, I think we're using Slack now, we should update this content." That's stuff that HR is never going to go through and catch, but your new employees can do that. New people are the best way to tell you if your processes are bad, if your content is better. Maybe not bad, but they're bringing in something new. That's why we added them to the team. And they should not be afraid from day one to ask questions, or poke holes in our already messed up or failing process.

Henri Seymour:

Yeah. And I can really see the benefit of the tools in Confluence, like that inline comment. Even if you don't know how you need that page updated or what the new version's supposed to be. It's just coming in fresh, you can go, "Oh, this is weird, or incomplete, or it might be wrong." It's just a little comment. You don't have to change it yourself, just say something. Here's a way to speak up without changing it yourself. And somebody who does know is going to be able to change it for you.

I was excited to hear you talk about information architecture. That's something I only got introduced to last year also. Do you have a general explanation of what information architecture is and why it's relevant to documentation?

Matt Reiner:

Oh, information architecture is, there are whole, people, professionals whose entire career is coming in and helping you. So I'm not one of those professionals, I just play one on TV. Really in essence, information architecture is breaking down what would be a wall of text into a pattern of information that anyone's mind can connect to. That's the real and ultimate goal, and that starts by just breaking up logical chunks. In fact, in a lot of pure technical writing, you break the content into tiny, tiny pieces, chunks or some technical communicators talk about atoms of information, really tiny pieces.

And then once you've broken that down and said, "These are separate pieces," then you assemble them together in an order that makes sense. In fact, you can also do really cool stuff with content reuse in Confluence, using include macros and the new Excerpt Include Macro is very cool in cloud, because you can do new stuff with that. But it's really about breaking apart all your content, figuring out what's the order of all of this? What's most important? What's more specific? What is important for everyone? What's important for just a few people?

And then just going down like you would with an XML structure or any other sort of hierarchy and tier that information using your spaces, your pages, your headings. And then finally bullets and paragraphs and that kind of thing.

Henri Seymour:

Thanks for getting that generally explained. Is there anything you want to mention in your work at the moment that you would be interested in getting readers onto?

Matt Reiner:

Yeah, totally. A major new effort for me, because I'm just this content explorer, I guess. I've done like technical content, I've written some marketing content. I started speaking, which I enjoy speaking. I got to speak in front of one live audience before... No, I guess a few, and then, the world's shut down for good reason. Because when you're breathing out on a bunch of people, you want to make sure that you're not potentially putting them at risk. So been doing a lot of virtual speaking.

But recently, I mentioned, we've worked on all these best practices on Rock the Docs. And so we've started this video series about Confluence best practices and it's been very exciting to figure out, "Okay, so I know how to create fairly good in Confluence, how to structure that content. Now, can we make a good video?" And it turns out, no, not at first. Made some pretty poor ones or ones that just took way too much time to make. And finally, as you do with any kind of content, we finally got a good structure, a good rhythm. And we also found what are those things people really want to hear about?

And so we've developed 16 of these now on our YouTube channel that are just out there for administrators to share with your users who are asking these questions. Or maybe these are for users directly who just want to subscribe and get these things. But it's like eight minutes of just as much information as we can pack and still speak fairly legible English. And then show just like how do you do this in Confluence? Why would you do this in Confluence? What are the things you should consider in Confluence? What are the best ways to do things in Confluence?

We've actually just started a series of live streams as well, where we're trying to look at those more in depth and then have people live listening in, asking questions and directing the whole thing. So far those have been really great and we're looking to do more of that. So the more people who pile into those, the more direction y'all get to give that content. But it's been new types of content that it's exciting to see, okay, our good written content in Confluence is coming to the real world in a new format. Which has been cool and challenging and fun and scary all at the same time.

Henri Seymour:

Yeah. That's sounds like a really exciting project. Rock the Docs is going audio-visual. And I can-

Matt Reiner:

That's right.

Henri Seymour:

... figure what... Get users on there to give you that iterative feedback that we talked about at the beginning. And so is this worth the thumbs up? Do you have comments? What else can we do? And especially in that sort of live stream webinar format, you get that direct contact with your users so you can find out what they're needing. That's that's fantastic. Probably see if I can come along with those. Easy Agile started using Scroll Viewport for cloud specifically earlier this year.

Matt Reiner:

Oh, cool. Oh, cool.

Henri Seymour:

So that's been a major improvement for us actually.

Matt Reiner:

Oh, good. Yeah. I'm just loving what the cloud team is putting out. It's so exciting and so polished and it's just like every team has that documentation space, and Viewport, it lets you put it out there and you're like, "Ah, looks so great. We're so proud of it." You can read it on any device. It's just like it's the magic that everybody wants, but no team has time. Our very few teams have time to make it look that good, so it's nice to have Viewport just do the heavy lifting.

Henri Seymour:

We've got the Confluence space, we've got the documentation. We don't have to make a website about it. It's just, "Go ahead, please make this website happen. Here's what we need on it. Here's the structure." And golly, it looks a lot better now, even just aesthetically, it looks a lot nice in the house.

Matt Reiner:

Yes. And it's nice to know that like some designer peered over the spacing between navigation items to decide how spaced out they should be. And as a writer, I can just like, I don't have to care. I don't have to care. I can throw in Confluence macros and stuff, and they just look really great when they're published. And I don't know how or why, but I'm happy. I can just keep writing. Yeah.

Henri Seymour:

Yeah.

Matt Reiner:

It would be great to have someone from Easy Agile join us for one of those live streams. Because what we're really focusing on is just like great way to do things in Confluence. We haven't jumped into Jira yet. I'm not as much of an expert in Jira, but I have thought about it because that content doesn't really exist yet. But it's not necessarily app-focused or K15t app-focused. It's just like one of the best ways you've found to do certain things in Confluence, and we're just sharing those with people alive, and it's a lot of fun.

Henri Seymour:

Yeah, that sounds great. I've got the parallel of get really into Jira and making Jira apps and Confluence is, "Yeah, we've got a Wiki. This is where we write stuff down." And it is great to have stuff like "There's the visuals on our docs page." But I don't do those. I'm busy making visuals in a Jira app. I don't want to think about that spacing. I've got my own spacing to do.

Matt Reiner:

Yeah. Yeah.

Henri Seymour:

And it really is that, I can just do the writing, I can just do product. I can do my job more because this other stuff taken care of because the experts at K15t have made that happen. And I hope that our apps can do a similar thing for their users of, this is the thing we need, we don't have to think about this. Bring in this app and it will solve a problem for us. It'll help us see what we need to and organize our information in Jira. Which is a different type of information again, but.

Matt Reiner:

Yeah, yeah. It's funny. I've talked with some people who have actually described that whole app part of Confluence in Jira as App Hell. That's a term that I've seen and I can't help but love the community because we all come up with this stuff. But app hell is, it really comes out of not understanding what a platform is partially. For example, if you're using the Salesforce platform, yeah, that's going to be app hell if you really want Salesforce to be a marketing platform. Because Salesforce is a sales platform. But then there's apps, and Salesforce happens to a sell big one. And then all of a sudden it's a marketing platform.

So that is a really interesting perspective shift for people who are used to a tool that just does one thing. Everybody thinks Excel does everything. It doesn't, we really should just use it for spreadsheets, everybody. It's not a platform for other things. Confluence is really good at these core things, Jira is really good at these core things. And then these apps, they come in to answer the questions that don't have answers and do the things that can't be done. And that's why. So is it App Hell or is it App Heaven? That's the real question. Or maybe it's maybe it's App Purgatory, I don't know. I guess the listeners gets to decide.

Henri Seymour:

The constant stream of, and yet another app needs to update. Which to be fair, I think is not a problem on cloud at this point. That's an exclusively an on-premise problem, the constant app update cycle. But we are hopefully moving towards the end of the purgatory perhaps.

Matt Reiner:

Yes. Yes. I think we're all ascending together. We're just reaching new heights all at the same time.

Henri Seymour:

Is there anything else you'd like to bring up while we talking tech docs?

Matt Reiner:

I guess, I typically go back to when I was in university, I had a manager there who told us in this on campus job that I had, "Our job is to connect people with the resources that are already around them. You're not a teacher, you're just here to connect people." And that has really stuck with me. And that is essentially what we all do. Whether we're building a product that connects people with resources or that is the resource or we're contributing to documentation or some kind of content.

We're really trying to enable people to do that greater thing, that higher level thing that is above our content, it's above our product. It's that thing that they truly care about and any part we get to play and that greater thing, that better thing. That's what it's all about.

Henri Seymour:

Yeah, that's really great perspective. That's probably also a really great thing to round off the end of the podcast with.

Matt Reiner:

I guess so.

Henri Seymour:

Yeah. Thank you very much for joining us, Matt, and for talking all things technical documentation with us on the Easy Agile Podcast.

‍

‍