Easy Agile Podcast Ep.17 Defining a product manager: The idea of a shared brain

"I really enjoyed my conversation with Andrew Malak. We talk integrating agile techniques and tips on how to achieve a culture of accountability"

Andrew is a firm believer that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes.

Enjoy the episode!

‍

‍

‍

‍

Transcript

Teagan Harbridge:

Welcome to another episode of the Easy Agile Podcast. I'm Teagan, head of product here at Easy Agile. And we've got a really exciting guest on the show today, Andrew Malak from Spaceship. He's the chief product officer. Andrew is a true believer in creating products and experiences that solve customer problems. He believes that the customer trusts your business by joining, and you have an obligation to repay that trust by helping them achieve their outcomes. In his current role, Andrew aims to help people take control of their wealth from a young age, educating good money habits and helping people invest where the world is going. Andrew is a family man who loves his time with his wife and children. And believe it or not, he uses agile techniques in his personal and professional life. Andrew is an economics geek. He plays and coaches soccer, football. He's a big Liverpool supporter, loves to travel, loves amazing architecture, and loves working with children.

Teagan Harbridge:

There were so many takeaways from my chat with Andrew that I really struggled to pair it down to three. But if you say tuned, here are some of the things that you're going to learn from our chat with Andrew. Why we should stop using the term agile transformation and start calling it an agile evolution. Why it's important to be open-minded to our own limitations so to break the old mindset of protecting original scope. And tips on how to achieve a culture of accountability. So I hope you enjoy. Andrew, can you tell me a little bit about Spaceship?

Andrew Malak:

Oh, fantastic. Well, thank you very much for, first of all, having me, Teagan. Spaceship is a business that's on a journey to make good money habits and investing accessible to all people. So what we look for is trends to do with industries or companies who are building the future of both industry or economies. We invest in them for the longterm, we break down barriers of entry for people, we give them a fee-free product under $5,000, no minimum investments. It's really easy to sign up. You simply download an app and you sign up and make one product selection decision, and you're done. You can start investing on autopilot. We allow you to also invest your superannuation in a not too dissimilar way.

Teagan Harbridge:

So tell me a little bit about who your target customer is, then. Because it seems like you're trying to make something quite complicated accessible for maybe first time investors.

Andrew Malak:

Well, you're absolutely right. There's a niche segment of people out there at the moment, millennials or even gen Zs, that we just don't think have been well serviced by the incumbents. And what we're trying to do is resonate with these young people as much as possible. We're trying to reduce industry jargon and really make things simple to them, because investing doesn't have to be complex. It's really about a lot of discipline around, if I can manage my personal P&L, or money in, money out, then I can create a cash buffer that can go into my assets column on my balance sheet. That's really what we're trying to do. And that kind of language, if we can get it right, can really simplify things that have typically been in the hands of financial advisors and accountants and give it back to everyday Australians who are starting out in their investment journey.

Teagan Harbridge:

Yeah, awesome. And you've been on quite a journey before landing in the FinTech space as the Spaceship CPO. So can you tell me and our audience a little bit about what that journey has looked like?

Andrew Malak:

Oh, where do I start? If you asked a graduate Andrew Malak what he'd be doing now, I don't think I would've been speaking about this because at that point in time in my career I didn't know this space would actually be around, if that makes sense. So I'll go back to my younger years, and I always thought I was going to be an architect. I had this fascination with bridges and I wanted to design things and see them come to life. And let's just say that I do that in different ways right now, but I started out working in CommSec on the trading floor. I moved on to work as a business analyst, and that's where I started my critical thinking into how businesses work and how things can be made more efficient.

Andrew Malak:

I dabbled in teaching for a little bit, I taught high school economics and religion for a little bit. And then I eventually landed in a product role at St. George Bank prior to the merger with Westpac. At that point in time, the light bulb really came on. I realized, "Hey, I like creating things. I like to change things. I don't like to just do things," if that makes sense. And that wondering mind that doesn't like the conform was finally let loose, if that makes sense. And I haven't stopped enjoying it. I loved my time at Westpac, made lots of friends, worked on really cool, successful projects, and implemented lots of things that had great results. Worked on lots of things that have failed miserably and learnt a lot out of that. And when the opportunity at Spaceship started to surface late last year, it was just too good an opportunity to not really come in and have a go. So yeah, it's been quite the journey.

Teagan Harbridge:

Yeah, wow. And I love a good failure story. And you said you've had lots. Can you think, just off the top of your head, what one of those big failures has been?

Andrew Malak:

Where do I start? I think our first attempt at taking a digital experience to allow customers to acquire a product online was quite a failure that taught us a lot. We basically took the systems that our back office staff used and just made it available to customers. And the real good learning out of that is there was a lot of traffic and a lot of demand, but not enough completion ever. And the best learning that came out of that... This is back in 2006, so internet speeds were just starting to pick up. Broadband was starting to go mainstream and customers' trust around doing more transactions that used personally identifiable data was starting to normalize at that point in time. Up until then, people quite reserved thinking, "I'm going to lose my personal data," et cetera. So when we decided to do that, we saw that there was a lot of demand but we quickly came to the realization that we used to train staff for four to six weeks on how to use the systems before they knew how to service customers using them.

Andrew Malak:

But then we've deployed it into production for customers to self-service and realized quite quickly that the experience for customers had to be much more guided than the experience for a staff member. This is where the evolution of usability or design thinking started to come in. We started thinking of, "Well, how do we make these things so easy that a first-time user can go end to end and not encounter friction?" And this is where our understanding of design principles, customer testing using verbatim and anguage that can resonate with a first-time user becomes critical to the execution. It's not just good systems but it's good user experience sitting on top of systems.

Andrew Malak:

That's probably the one that resonates with me the most because I've held that to a very high regard throughout my whole career. Now everything I do I think of, "Where's the friction? How do we make sure there's no friction? What's the customer going to feel throughout this experience? How are we creating unnecessary anxiety in that experience for the customer, and how do we move that away? How do we become more transparent but still be simple?" And yeah, that's probably the one that resonates the most.

Teagan Harbridge:

Seems like a tremendous learning opportunity early enough in that project and something that's stuck with you since, so great learning opportunity.

Andrew Malak:

Absolutely.

Teagan Harbridge:

We've got a ton of customers who are at all stages of their agile transformations, and I know that this is something that you've had experience with if we go back to your St. George, Westpac days. Can you give our audience any tips or stories that you encountered when you were going through those agile transformations? What lessons can you share with our audience?

Andrew Malak:

Oh, I have lots of lessons to share, actually.

Teagan Harbridge:

This is what I love.

Andrew Malak:

Look, I like to position it more as agile evolution more than agile transformation because no matter what you try to do, you're not just going to drop waterfall and become agile next morning. Honestly, I've seen so many attempts and every single time I see that the graduality of the change is a better predictability of the final outcome that you're going to land. So ultimately the Holy Grail that everyone's aspiring to is that, as a leader, you can rock up to a team stand up unexpected and then, without being told who is in what role, who the product owner is, who the engineer is, who the QC is, who the designer is, it becomes hard for you as the leader to work out who's who because at that point in time the team is so well converged on customer outcomes that they will self-organize themselves around what each person needs to do.

Andrew Malak:

And most of the language being used is really around, what are we trying to define the customer? What's the best thing to do within the capacity that we have to deliver this feature to market as quickly as possible, capture value for the customer and the business as much as possible? This takes a long time to get to, where you can start normalizing to a standardized, common set of goals, common cadence, and common ways of working. And I think it's ultimately about how much empowerment you can give people and how much as a leader you can relegate yourself in the background to allow them to work it out themselves as long as you're coming in and nudging things along the way and helping people course correct along the way. So the good news is that I actually think at Spaceship, we're pretty close to getting there.

Andrew Malak:

We have been running scrum and we have been running sprints for a long time, but it has been largely ceremonials. But over the last quarter, we've done a really good job at embedding more cross-functional people into these teams. But the goal for us is that now we feel like our throughput has actually increased and that the constant flow of information between the teams is becoming more natural and there is actually less ambiguity between the teams around, "All right, we built it this way. The API is no longer consumable. It doesn't fit what we're trying to do from our front-end and there's less back and forth." So we can really see that the amount of friction between persons in the team is really starting to reduce dramatically and we're starting to see that throughput really increase. Having said that, the best way to go about an agile transformation is just get started.

Andrew Malak:

You can sit and plan out things and plan towards utopia as much as you want or you can actually just get going. So when I say by get going, I say you have to start by getting buy-in from all the leaders of the different cross-functional teams, because if you don't have that buy-in at the leadership level, it's just not going to work because there's going to be blockers, there's going to be escalations. And if all these things result in conversations around, "Should we keep doing this?" Or, "Hey, maybe this is not the right thing to do." That needs to be off the table really early on and it needs to be a total commitment at the leadership level that we're going to make this work and whatever we encounter we're just going to fix forward. Once you have that commitment at the leadership level, you need to very clearly define the values that the team is going to be handed to work with, because agile itself, it's not a process, it's a set of values that the team needs to just take and start working with.

Andrew Malak:

So we could go and rattle individuals and interactions over processes and tools or working software over comprehensive documentation. Well, give these to the team and they're going to say to you at day one, "We can't go to all of that straight away." So they might actually say that day one, "We're still going to need some documentation because we're not comfortable yet. We don't understand the language of the other people in the scrum team well enough to be able to go and actually code off the back of a conversation." But by the 10th sprint, the 20th sprint, that misunderstanding of what the product owner wants or what the designer is trying to achieve in an experience starts to become embedded in the mind of the engineer.

Andrew Malak:

The engineer understands the customer a lot more, and then you can make do with less process and less documentation and less negotiated outcomes and more commonality across the team. The other thing that then starts to kick in at that stage is that ability of the team to pivot in response to a change and not see that as a threat to what they're trying to achieve. The old ways of working was, define that scope, protect that scope, and not let things disturb that scope, whereas if you're halfway through a project and you get some really good information that tells you that maybe you are not on track to achieve a good outcome, you should be welcoming that. And the team itself in the beginning is going to find that an irritation, but over time they'll become more comfortable with pivoting off the back of new information.

Teagan Harbridge:

Yeah. It's a big mindset shift. I was just having a discussion today about, where does being agile and being reactive, where's that line in the middle. And when does taking information and pivoting because you think something will be better, when can we break that mindset of, "Oh, we're just being reactive?" No, we're being responsive.

Andrew Malak:

Yeah, yeah. And look, I think the word reactive itself naturally has a negative connotation to it, but agility in mindset allows you to flip that on its head and say that no one can work things out in totality to 100% of what's possible, so being open-minded to our own limitations first and foremost allows us to acknowledge that when new information comes in, it is because we didn't think through the solution 100%, but let's also be okay with that because no one can. So I think it's flipping on its head and acknowledging it upfront and saying that this is going to happen, but when it comes we will assess the information we have with the capacity we have with how far progressive we are and make a decision that's right for us, for the customer, and for what's possible.

Andrew Malak:

So I take it as the more information you get along the way, the more reinforcement of, are you doing what's right or should you pivot and change at that point in time? The other thing that happens really early on is that if you as a leader can create a really clear vision around customer outcomes and establish your first cross-functional team and hand over that vision to the team, it becomes theirs. Don't hand over the backlog to the team. Don't give them a ready backlog, just give them the vision and then tell them, "You guys work out what your backlog looks like." When they come up with their own backlog, as long as you as a leader don't see that it's just a list of Hail Marys in it and there is a fair bit in there that is well spread out between hygiene things, strategic things, and a few moonshots and the balance is right, if the team has come up with their own backlog, the motivation they have to build their own ideas just goes through the roof.

Andrew Malak:

And that's what you want to achieve. You want to achieve clarity that the work fits with the vision and the motivation that you get out of the backlog being created by the team itself gets you that throughput enhancement. The other thing that you're going to struggle with really early on is chunking things down to fitting within the sprint cadence. I think that's one that's often been my biggest challenge when moving towards agile practices early on. Typically in the first few sprints, you always have overruns and things don't complete in the sprint because we end up thinking we can do more than we can and it takes us a while to work out, in wrapping up something that becomes shippable in a sprint, you probably take a little bit less in that sprint because you've got to test it or you've got to do a release in that sprint, or you're going to do a PIR in that sprint, or you're going to do a lot of retros in that sprint. Start to sort of formulate what you're going to take through the next planning cycle.

Andrew Malak:

So you've got to budget to that capacity, and I'll find that teams underestimate the magnitude of that work. So be okay with that. Overruns in the first few sprints don't mean you've failed, it means you're learning how to plan better. And then make sure your retros and your pivot off the back of that into your next planning sessions is taking information that is now new to you, and making sure you're working with it. I think as the leader, though, you have to set the expectations that teams can make mistakes and that it's a safe environment.

Andrew Malak:

And I've seen many agile... I was about to use the word transformation, even though I've just said I don't believe in transformation. Any teams that are adopting agile principles expecting that in their first few sprints they don't have any hiccups, and that if throughput falls in the first few sprints, then there's a bit of a, "Oh, well you told me this thing was going to increase our throughput." Yeah, but not straight away. So I think just being realistic with yourself and what's possible, and that shift in itself, until it normalizes, takes a bit of getting used to. The teams need to know it's a safe environment, that if their productivity suffers, if they make mistakes or if they break things, it's going to be okay. We'll fix forward.

Andrew Malak:

But then also there comes a point in time where we have to be very clear about the culture of accountability around using that capacity really well. So what I've found, that the best use of that is the showcase. And what we've done at Spaceship, because we're trying to reduce the amount of ceremonies, we've combined both the planning playback in a sprint as well as the showcase into the same ceremony. So what we do is we play back what we built last session using a demonstration of working software and comparing the amount of work we've executed versus what was planned in the previous sprint. We're saying we've got 80%, 90% through the work and this is what it looks and feels like, and this is what we're deploying to the customer. Then we actually showcase what we plan to do in the next sprint.

Andrew Malak:

And that's part of the showcase, is our hand on heart commitment to, "This is what we as a team are committed to doing in the next sprint." And then that accountability to the organization becomes something that keeps us on track throughout the sprint. As distractors or things that are not committed in the sprint come our way, we quickly think about, all right, can we accommodate these things? Do they need to be done? Are they going to take us off track with what is planned? Are they important enough? Is it a major defect of production, and can customers no longer access our app? Well, drop what you're doing and attend to that. Otherwise, if it's not material, keep focused on the work that you've committed to in front of the organization.

Andrew Malak:

After this you're going to start to experience some growing pain, and the growing pain is good because it means that agile is working and more teams or more feature opportunities become possible for the business. There's going to be a lot more hype around moving to agile. Other teams are going to come across and say, "Oh, how do we piggyback off what you're doing?" Et cetera. This is good. This is good, but what it means now is that some new risks are going to actually start to be introduced. Working with common code, common dependencies, or even common people being needed to be doing multiple things just means that you now need more coordination. I'd say to anyone who reaches this point in time, this is where people feel compelled to start introducing some new roles, coordination roles. And I'd just say, be careful because that can start add to your overhead really quickly.

Andrew Malak:

I find the best way to ensure that teams continue to be in sync is with the right dialogue at the right level with the right rhythm. And this is where I think keeping it simple to just the scrum of scrums works really well. I like the scrum of scrums to be balanced between both product owner and tech lead from each team being present, and a cadence of one to two times per week works really well. And as long as the product owners across the teams and the tech leads across the teams know what the other teams are working on, know what could impact their own work from a release perspective or scheduling perspective or an environment perspective, I think that tends to work really well as well.

Teagan Harbridge:

Yeah, wow. Lots of nuggets in there and certainly things that resonate with our experience here at Easy Agile, being a small company that's grown really quickly. So I can definitely relate. We've had conversations about, do we introduce new roles into this company? We've introduced a new cadence of meeting rhythms only the last couple of months, so we're going through these things too.

Andrew Malak:

Absolutely. Absolutely. What have been your biggest learnings so far?

Teagan Harbridge:

I think that you cannot underestimate communication, and it really does come back to that cadence and that rhythm with the team. And we're experimenting at the moment with a daily huddle where we're talking about, how do we embed showcases more regularly in our cycles? We've got a big demo at the end of the cycle. How can we make that a more ingrained part of our culture? And it really does come back to that culture of accountability as well. So yep, it's all resonating.

Andrew Malak:

Yeah, absolutely. Look, you can go to whatever industry you want but the problems are usually similar. And the great thing is that having these conversations is very important to fast-tracking your way forward, because your problem is not unique to you. Someone else has seen it in someone else has figured out a way. And I think what I like about the FinTech industry is that we compete on products and services, but there's a lot to learn from each other. And even if you just go outside of FinTech, there's a lot to learn from other industries who have adopted agile practices.

Teagan Harbridge:

If we take a bit of a flip, we've gone from your professional career and your experience into a more personal level. You mentioned that you use agile techniques outside of work. So I'm not sure if many others are in the same boat, but can you elaborate on this? What does that mean? What does that look like?

Andrew Malak:

Okay, I hope you don't think I'm extremely weird. We actually have a family campaign. So I guess if I go back to how we've come to actually doing this. Becoming parents, we would look at our children and see so many things that we want them to be better at. And in trying to give them constant feedback, which felt like the feedback was so much that it's all being drowned out because there's so much of it. In fact, my oldest son actually gave me that feedback. He goes, "Dad, why don't we focus on one thing at a time?"

Andrew Malak:

And I was like, "Wow, okay." For a ten-year-old to tell me that, that was amazing. So we came to realize that we needed to narrow and focus on one improvement area at a time, and we don't move on to the next one until we've actually closed out the first one. For example, my oldest son, very clever boy. We're trying to focus with him on the discipline of process over just getting the answer right, because he is clever and nine times out of 10, ask him a question, he's got the answer and he just wants to say it.

Andrew Malak:

But we've started to try to break down the question and work more on the process with him so that in following the process, coupled with his natural ability, we will get more answers right more often. And that's what we're working through at the moment. So our family's scrum wall at the moment has a mix of things on it. Everyone has their own swim lane, and in each swim lane there are a few tasks, some related work or study, some relating to household chores, some related to health or exercise, and some related to acts of kindness. And what we aim to do is make sure that we're moving things across in all four categories every single day. So yeah, you can use agility wherever you'd like but I think that mindset in general, that if I wake up every day and do things that make me better than I was yesterday, then I'll get to keep moving forward in my personal life as well as my professional life.

Teagan Harbridge:

And do you have WIP limits?

Andrew Malak:

We don't at the moment, and we're not doing showcases at the moment. We'll see how we can introduce them in the future.

Teagan Harbridge:

And how was the introduction of a Kanban board at home? How was that received by the family? Have they enjoyed it, has there been any feedback?

Andrew Malak:

Well, it wasn't actually planned. It started by just sticking some Post-its up on the fridge to remind us of stuff. And then one day I said to my wife, "You know what? This reminds me of what we do at work. Why don't we formalize it?" She had a bit of a chuckle but then one day she came back and then she found it there. So yeah, it wasn't really planned.

Teagan Harbridge:

Awesome. And you've already been super generous with your time so I'll close it out with one final question. What advice do you wish someone would have given you when you took the leap from product management into product leadership?

Andrew Malak:

Yeah, that's a really good question. I think first and foremost, that you've got to make sure that you drop your need for perfectionism, because first and foremost, you might have been the best product manager yourself. You might have been amazing. And I'm not saying I was, but if you were and you step up in leadership role, you're going to have people of different abilities working for you. And what you need to understand is that they're going to need some time learning their role and learning their trade. And just don't get in the way of them learn. So for example, you might see someone doing something that may not be the best or most optimal use of that capacity in that sprint. You might feel the urge to jump in and course correct. But if you let them go and just hear their feedback post the retro, they might've had that learning themselves, and a learning that they get for themselves rather than being told by their leader is going to be much more useful for them.

Andrew Malak:

You have to drop your need to make decisions and be in control because, again, the more you can relegate yourself to a servant leadership role and let the team make decisions, when they make decisions and now have to go back up that decision with execution, they're more likely to put their heart and soul into it. The more they feel like you are going to make the decisions, the less inclined they are to think through problems themselves, and then they'll keep bringing the problems back to you. So every time someone asks you a question that has a black and white answer, throw it back to them and ask them what they think, because that way you're coaching them to work it out themselves. And then the last thing that's really important is, I feel like it's really important to think through how your organization allows you to be different and take advantage of that differentiation.

Andrew Malak:

So for example, at Spaceship here, because we're small, we're not a large corporate, our customers are a little bit more forgiving. So you have a limited capacity to build experiences and you can't do all things at the same time. Understand that and take advantage of it, and get your team to also learn that. Because if you're trying to how the all edge cases, it will take a lot longer to get something to market and you might use a lot of the team's capacity to build edge cases. And you can't really afford that when you're in a start-up.

Andrew Malak:

So for example, we launched a new investment portfolio yesterday. We launched the Spaceship Earth portfolio, our first sustainable investment portfolio and it's a sign of more things to come hopefully in the sustainability space. But in launching that, we knew that we have a limitation in our experience or our product set today where each customer can only have one portfolio. We knew that existing customers would want to invest in sustainable investing, but our commitment to them is that it's in our backlog and it's actually the next feature that we're actually going to take to market.

Andrew Malak:

And in explaining that to our customers, they've been very understanding, that they know our throughput is limited but they also know that their voice is being heard and we are building the things that they're telling us about. So I would say that the best piece of advice to tell my young self is to make sure that you get the balance right between the voice of the customer. That's going to tell you all the hygiene things that your product lacks in terms of experience or gaps. And then get the balance between new strategic things that you can go after and new things that you can take to market, as well as a few Hail Marys every now and again. We call them moonshots. They may or may not work, but it's exciting, and if it works, can 10X your volume. And they are the things that are likely to go viral. So getting the balance right is very important.

Teagan Harbridge:

It's been wonderful, Andrew. I've definitely taken a lot away from our chat today, and I'm sure our audience will too. So thank you again so much for your time, and good luck.

Andrew Malak:

No Teagan, look, thank you very much. And it's been a pleasure speaking to yourself and Easy Agile, and I wish you guys all the best too.

Teagan Harbridge:

Awesome. Thanks Andrew.

Andrew Malak:

Have a good afternoon.

"I really enjoyed speaking with Melissa Reeve, VP of Marketing at Scaled Agile about how non-software teams are adopting a new way of working."

It's more important than ever to be customer-focused.

We talk about the danger of 'walk-up-work' and how to avoid this through proper sprint planning.

Melissa also gives an update on how agile is spreading to non-technical teams.

‍

‍

‍

Transcript

Sean Blake:

Hello everyone. And welcome to the Easy Agile Podcast. We have a really interesting guest with us today. It's Melissa Reeve, the Vice President of Marketing at Scaled Agile. We're really excited to have her on today. Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework. In other words, SAFe and its mission. She also serves as the practice lead for integrating SAFe practices into marketing environments. Melissa received her Bachelor of Arts degree from Washington University in St. Louis, and she currently resides in Boulder, Colorado with her husband, chickens, and dogs. Melissa, thanks so much for joining us on the podcast today.

Melissa Reeve:

It's such a pleasure to be here. I really appreciate it.

Sean Blake:

Great. That's great. I really like your enthusiasm straight off the bat. So what I'm really interested in hearing about, Melissa is a little bit about how you got to where you are today. What have been the highlights of your career so far and how as a marketer, did you find yourself in the Agile space?

Melissa Reeve:

Well, thanks for asking. And I have to tell you, but just before the podcast my husband knocked on the door and he was all proud because we just got a new set of chickens and one of the chickens had laid its first egg. So that's been the highlight of my day so far, not necessarily the highlight of my career.

Sean Blake:

So you'll be having scrambled eggs and eggs on toast probably for the next few weeks now.

Melissa Reeve:

I think so. So back to the career, I really fell into marketing. My background was in Japanese literature and language. And I had anticipated this great career and international business in Asia. And then I moved out to the Navajo Indian Reservation and just pivoted. Found my way into marketing and found my way into Agile right around 2013 when I discovered that there was an Agile marketing manifesto. And that really was a changing point in terms of how I thought about marketing. Because up until that point, it really considered marketing in what's termed waterfall. Of course, marketers generally don't use the term waterfall.

Melissa Reeve:

But then I started to think about marketing in a different way. And when I came across Scaled Agile, it brought together so many elements of my career. The lean thinking that I'd studied when I studied in Japan and the lean manufacturing, it was Agile marketing that I'd discovered in 2013 and just education and technology have always been part of my career. So I really consider myself fortunate to have found Scaled Agile and found myself in the midst of scaling Agile into both enterprises, as well as marketing parts of the enterprise.

Sean Blake:

Oh wow, okay. And I noticed from your LinkedIn profile, you worked at some universities and colleges in the past. And I assume some of the teams, the marketing teams you've worked in, in the past have been quite large. What were some of those structures that you used to work in, in those marketing teams? And what were some of the challenges you faced?

Melissa Reeve:

Yes, well, the largest company was Motorola. And that was pretty early on in my career. So I don't think I can recall exactly what that team structure is. But I think in terms of the impediments with marketing, approvals has always been an issue. No matter if you're talking about a smaller organization or a larger organization, it seems like things have to go up the chain, get signed off, and then they come back down for execution. And inherent in that are delays and wait states and basically waste in the system.

Sean Blake:

Right. So, what is Agile marketing then and how does it seek to try and solve some of those problems?

Melissa Reeve:

Well, I'm glad you asked because there's a lot of confusion in the market around Agile marketing. And I can't tell you how many news articles I've read that say marketing should be Agile. And they're really talking about lowercase Agile, meaning marketing should be more nimble or be more responsive. But they're not really talking about capital-A Agile marketing, which is a way of working that has principles and practices behind it. And so that's one aspect where there's confusion around Agile marketing.

Melissa Reeve:

And then another aspect is really how big of a circle you're talking about. In the software side when someone mentions Agile, they're really talking about a smaller team and depending on who you talk to, it could be anywhere from five to 11 people in that Agile team. And you're talking about a series of teams of that size. So when you're talking about Agile marketing, you could be talking about an individual team.

Melissa Reeve:

But some people, when they're talking about Agile marketing, they're talking about a transformation and transforming that entire marketing organization into an Agile way of working. And of course, in the SAFe world, we're really talking about those marketing teams that might be adjacent to a SAFe implementation. So, I think it's a good question to ask and a good question to ask up front when you're having a conversation about Agile marketing.

Sean Blake:

Okay. Okay. And for those people that don't know much about SAFe, can you just explain, what's the difference between just having a marketing team now working in a capital-A Agile way, and what's the difference between an organization that is starting to adopt Scaled Agile? What's the difference-

Melissa Reeve:

Sure.

Sean Blake:

...between those?

Melissa Reeve:

Yeah. So what software organizations found is that Agile teams, so those groups of five to 11 people, that way of working works really well when you have a limited number of software developers when you started to get into the world's largest organizations. So I think of anybody on the Global 2000, they might have tens of thousands of software developers in their organization. And in order to leverage the benefits of Agile, you needed to have cadence and synchronization, not only within a team, but across multiple teams up into the program level and even the portfolio level.

Melissa Reeve:

And the same holds true with large marketing organizations. Imagine you're a CMO and you have 6,000 marketers underneath you. How are you supposed to get alignment to your vision, to your strategies that you're setting if you don't have a way of connecting strategy to execution. And so the Scaled Agile Framework is a way of taking those Agile practices across multiple teams and up into the highest levels of the organization so that we're all moving in a similar direction.

Sean Blake:

Okay. Okay, I think that makes sense. And from a software team's point of view, one of the benefits of Agile is that it helps teams become more customer focused. And many would argue, well, marketing has always been customer focused. But have you found in your experience that maybe that's not so true? And when marketing teams start to adopt Agile, they realize what it really means to become customer focused.

Melissa Reeve:

Yeah. I mean, you raised another great point because I think most marketers think that they're customer focused. Like many things in the world, the world is a relative place. So you can, in your mind, in theory, be thinking about the customer or you can be actually talking to the customer. So I just finished what I call the listening session. And it was during our hackathon, which is our version of an innovation, couple of days worth of innovation. So it was eight hours on a Zoom call with somebody South Africa. Just listening to her experience and listening to her go through one of our courses, slide by slide, by slide, explaining what her experience was at each step of the way.

Melissa Reeve:

So if you think about somebody who is sitting in a large enterprise, maybe has never met the customer, only knows the customer in theory, on one end of the spectrum. And you think about this listening session on the other end of the spectrum, you start to get an understanding of what we're talking about. Now, your question really pointed to the fact that in Agile practices, you're thinking about the customer every time. In theory, every time you write a story. So when you write a story, you write the story from the perspective of the customer. And I would just encourage all the marketers out there to know the customer personally. And I know that's not easy in these large organizations. It's sometimes hard to get face time with the customer, but if you aren't speaking directly to a customer, chances are you don't actually know the customer.

Melissa Reeve:

So find a way, talk to the sales folks, get on the phone with some of your customer service representatives. Go to a trade show, find a way to talk directly to the customer because you're going to uncover some nuances that'll pay dividends in your ability to satisfy the customer. And when you go to write that story again, it will be even more rich.

Sean Blake:

Oh, that's really good advice, Melissa. I remember from personal experience, some of these large companies that I've worked in, we would say, "Oh, this is what the customer wants." But we actually didn't know any customers by name. Some of us personally were customers, but it's not really the same thing as going out and listening to people and what did they find challenging about using that app or what do they actually want out of this product? So there's a huge difference, isn't there, between guessing what a customer might want or should want? And then what their day to day actually looks like, and what are the things that they struggle with? That's hugely important.

Sean Blake:

For someone who's in one of these big companies, they're in a marketing team, perhaps they don't have the power or the influence to say, "Okay, now we're going to do Agile marketing." What would your advice be for someone like that, who can see the upside of moving their teams in that direction, but they don't necessarily know where to start?

Melissa Reeve:

Well, there's a philosophy out there that says take what you can get. So if you are just one person who is advocating for Agile marketing, maybe that's what you can do is you can advocate. Maybe you can start building alliances within the organization, chatting casually to your coworkers, finding out if you have allies in other parts of the organization and start to build a groundswell type movement.

Melissa Reeve:

Maybe you can build your own personal Kanban board and start tracking your work through your own Kanban board. And through visualizing your work in that way, it's a little bit harder now that we're all remote, but should we get back into offices somebody could in theory, walk by your cubicle, see your Kanban board and ask about it. And now you might have two people using a Kanban board, three people. And really start to set the example through your mindset, through your behaviors, through your conversations in order to start getting some support.

Sean Blake:

Oh, that's really good. So be the change that you want to see in the organization.

Melissa Reeve:

Exactly.

Sean Blake:

Okay. Okay, that's really good. And when these companies are moving towards this way of working, and then they're looking to take the next level, let's say it starts in the software development teams and then say marketing is the next team to come on board. How does it then spread throughout the whole organization? Because I know from personal experience, if there's still that part of the organization that's working anti-Agile it actually still makes it really difficult for the Agile teams to get anything done. Because there's still the blockers and the processes and the approvals that you need to go through with those other teams. And I guess SAFe is the answer, right? But how do you start to scale up Agile throughout the whole organization?

Melissa Reeve:

Sure. And what you're talking about is really business agility, is taking the whole business and making the business Agile. And you pointed out something that's key to that, which is once you solve the bottleneck and the impediments in one area of the business, then it'll shift to another area of the business. So the advantage of business agility is that you're trying to keep those bottlenecks from forming or shifting. But what a bottleneck essentially does is it creates what we call a burning platform. So it creates a need for change. And that's actually what we're seeing in the marketing side is we've got these IT organizations, they're operating much more efficiently with the use of Agile and with the use of SAFe. And what's happening is the software teams are able to release things more quickly than the teams that are surrounding them, one of which could be marketing.

Melissa Reeve:

And so now marketing is incentivized to look at ways of changing. They're incentivized to take a look and say, "Well, maybe Agile is the answer for us." So let's just say that marketing jumps on board and all of a sudden they're cranking along, and except for that everything's getting stuck in legal. And so now legal has a case for change and the pressures on legal to adopt it. So there is a way to let it spread organically. Most transformation coaches will understand this phenomenon and probably encourage the organization to just go Agile all in, obviously not in a big bang kind of way, but gradually move in that direction so that we're not just constantly shifting bottlenecks.

Sean Blake:

Okay. Okay, that makes sense. And when these companies are trying to build business agility across the different functions, are there some mistakes that you see say pop up over and over again? And how can we avoid those when we are on this journey of business agility?

Melissa Reeve:

Yeah. So I feel like the most common mistake, at least the one that I see the most often in marketing, although I've seen it in software as well, is people thinking that the transformation is about processes or tools. So for example, in marketing, they might adopt a tool to "become more Agile." Maybe it's a Kanban visualization tool, or maybe they're being suggested to adopt another common ALM type tool. And so they adopt this tool and they learn how to use it, and they wonder why they're not seeing big improvements.

Melissa Reeve:

And it's because Agile at its heart is a human transformation. So we're really taking a look at in trying to change the way people think. One of the topics I speak on is the history of management theory. And while it sounds pretty dry, in reality, it's eye opening. Because you realize that a lot of the habits that we have today are rooted back in the 20th and 19th centuries. So they're rooted in assembly lines. They're rooted in French management theory, which advocated command and control.

Melissa Reeve:

They're rooted in classism. There was a management class and a laboring, and the management class knew the one best way of doing things. So more than a process, more than a tool, we're talking about transforming this legacy of management thinking into a way that's appropriate for today's workers. And I feel like that's the number one mistake that I see organizations making as they're moving into transforming to Agile, an Agile way of working.

Sean Blake:

Mm-hmm (affirmative). Okay. Yeah, that's really interesting. And it really is eye opening, is it? When you look at how the nine to five workday came about, because that's the time when the factories were open and all the history around how organizations are structured. And it's really important, I think, to challenge some of those things that we've done in the past that worked back in the industrial age. But now we're moving into the information age and into these times of digital transformation. It probably doesn't work for us anymore, does it, some of those things? Or do you think some of those things are still valuable now that we have distributed teams, a lot of people are working remotely? Are there any things that come to mind that you think actually we shouldn't get rid of that just yet?

Melissa Reeve:

Oh, I'm sure there are. John Kotter has presented in his book, Accelerate, this notion of a dual operating system. So that you have the network part of the organization, which moves fast and nimble like a startup and then you have the hierarchical part of the organization. And the hierarchy is very, very good at scaling things. It's a well oiled machine. You do need somebody to approve your expense report. You do need some policies and some guidelines, some guard rails. And so we're not actually saying abolish the hierarchy. And I do feel like that's part of this legacy system. But what we are saying is abolish some of the command and control, this notion that the management knows the one best way, because the knowledge worker oftentimes knows more than his or her manager.

Melissa Reeve:

It's just too hard for a manager to keep up with everything that is in the heads of the people who report to him or her. So that's a really big change and it was a change for me. And I think why I got so fascinated in this history of management theory is because I came across some notes from my college days. And I realized that I had been taught these historic management theories. I'd been taught Taylorism, which stems from 1911. And I realized, wow, there's a lot of undoing that I've had to do in order to adopt this Agile way of working.

Sean Blake:

Well, that's great. Yeah, that's really important, isn't it? I've heard you speak before about this concept of walk-up work, especially in the realm of marketing. But I suppose, well, firstly, I'd like to know what is walk-up work. Why is it so dangerous, not just for marketers, but for all teams? And how do we start to fight back against walk-up work?

Melissa Reeve:

Yeah. So, marketers in particular get bombarded with what I like to call walk-up work. And that's when an executive or even a peer literally walks up, so think again about the cubicle farm, and makes a request. So how that looks in the virtual world is the slack or the instant message, "Hey, would you mind?" One is that it results in a lot of context switching and there's time lost in that context switching. And then the other part is rarely do these requests come in well-defined or even with any sort of deadline detach. In marketing, it might look like, "Hey, can you create this graphic for this email I'm sending out?" So now you've left your poor graphic designer with this knowledge that here she has to make a graphic, but they don't really have any of the specs.

Melissa Reeve:

So it's very, very helpful to put these things into stories, to follow the Agile process, where you're taking that walk-up work to the product owner, where the product owner can work with you to define that story, keep the person who's doing the work on task, not making them context switch or do that. Get that story in that acceptance criteria very well defined and prioritized before that work then comes into the queue for the graphic designer. And this is an anti-pattern, whether you're talking about an organization of 50 or 5,000.

Melissa Reeve:

And what I've found is the hardest behavior to change is that of the executives. Because not only do they have walk-up work, but they have positional authority too. And it's implied that, that person will stop working on whatever they're working on and immediately jump to the walk-up work being defined by the executive. So I feel like it's really dangerous to the whole Agile ecosystem because it's context switching, it interrupts flow and introduces waste into the system. And your highest priority items might not being worked on.

Sean Blake:

Okay. So how many people do you have on your marketing team at Scaled Agile?

Melissa Reeve:

We're pretty small, still. We've got about somewhere in the 20s, 23, 25, give or take or few.

Sean Blake:

So how do you-

Melissa Reeve:

I think right now we're three Agile teams.

Sean Blake:

Three. Okay. So those 20 something is split into three Agile teams. And do they each have a product owner or how does the prioritization of marketing work in your teams?

Melissa Reeve:

Yeah, it's a good question. So we do have individual product owners for those three product teams. And what's fascinating is the product owners then also have to meet very regularly to make sure that the priorities stay aligned. Because like many marketing teams, we don't have specialized skill sets on each of those teams. So for the group of 23, we only have one copywriter. For the group of 23, we have two graphic designers. So it's not like each team has its own graphic designer or its own copywriter.

Sean Blake:

Yes.

Melissa Reeve:

So that means the three POs have to get together and decide the priorities, the joint priorities for the copywriter, the joint priorities for those graphic designers. And I think it's working. I mean, it's not without its hiccups, but I think it's the role of the PO and it's an important role.

Sean Blake:

So how do you avoid the temptation to come to these teams and say, "Drop what you're doing, there's something new that we all need to work on?" Do you find that challenging as an executive yourself to really let the teams be autonomous and self-organizing?

Melissa Reeve:

Yeah, I think the biggest favor we've done to the teams is really, I don't want to say banned walk-up work, but the first thing we did is we defined it. And we said, "Walk-up work is anything that's going to take you more than two hours and that was not part of iteration planning." And iteration is only two weeks. And so, in theory, you've done it within the past 10 days. So if it wasn't part of that and you can't push it off to the next iteration planning, and there's a sense of urgency, then it's walk-up work.

Melissa Reeve:

And we've got the teams to a point where they are in the habit of then calling in the PO and saying, "Hey, would you mind going talking to so and so, and getting this defined and helping me understand where this fits in the priority order." And really that was the biggest hurdle because as marketers, I think a lot of us want to say yes if somebody approaches us with work. But what's happened is people have, myself included, stopped approaching the copywriters, stopped approaching the graphic designer with work. I just know, go to the PO.

Sean Blake:

That's good. So it's an extra line of defense for the team so they can continue to focus on their priorities and what they were already working on without being distracted by these new ideas and new priorities.

Melissa Reeve:

Yes. And in fact, I think we, in this last PI reduced walk-up work from 23% down to 11%. So we're not a 100%. And I don't know if we'll ever get to be a 100%, but we're certainly seeing progress in that direction.

Sean Blake:

Oh, that's really good. Really good. And so your marketing teams are working in an Agile way. Do you feel that across the board, not only within your organization, but also just more generally, are you seeing that Agile is being adopted by non-technical teams, so marketing, legal, finance? Are these sort of non-technical teams adopting Agile at a faster rate, or do you feel like it's still going to take some years to get the message out there?

Melissa Reeve:

Yeah. And I guess my question to you would be, a faster rate than what?

Sean Blake:

Good question. I suppose what I'm asking is, do you feel like this is a trend that non-technical teams are adopting Agile or is it something that really is in its infancy and hasn't really caught on yet, especially amongst Scaled Agile customers or people that you're connected to in the Agile industry?

Melissa Reeve:

I would say yes. Yes, it's a trend. And yes, people are doing it. And yes, it's in its infancy.

Sean Blake:

So, yes?

Melissa Reeve:

Yeah. So all of those combined, and I'm not going to kid you, I mean, this is new stuff. In fact, as part of that listening session I mentioned and we were talking about all these different parts of the business. And there was mentioned that the Scaled Agile Framework is the guidance to these teams, to HR, to legal, to marketing could be more robust. And the answer is absolutely. And the reason is because we're still learning ourselves. This is brand new territory that we're cutting our teeth on. My guess is that it'll take us several years, I don't know how many several is, to start learning, figuring out how this looks and really implementing it.

Melissa Reeve:

Now, my hope is that we'll get to a point where Agile is across the organization, that it's been adapted to the different environments. When I've seen it and when I've thought through things like Agile HR, Agile Legal, Agile procurement, the underpinnings seem to be solid. We can even things like the continuous delivery pipeline of DevOps. When I think about marketing and I think about automation. And I think about artificial intelligence, yeah, I can see that in marketing and I can see the need for this to unfold, but will it take us a while to figure out that nuance? Absolutely.

Sean Blake:

Okay. And can you see any other trends more broadly happening in the Agile space? You know, if we're to look forward, say 10 years, a decade into the future, what does the way of working look like? Are we all still remote or how are team's going to approach digital transformations in 10 years time? What's your perspective on the future?

Melissa Reeve:

Yeah, I mean, sometimes to look to the future I like to look to the past. And in this case I might look 10 or 12 years to the past. And 12 years ago, I was getting my very first iPhone. I remember that it was 2007, 2008. And you think about what a seismic shift that was in terms of our behavior and social media and connecting and having this computer in our hand. So I ask myself, what seismic shift lies ahead? And certainly COVID has been an accelerant to some of these shifts. I ask myself, will I be on airplanes as frequently as I was in the past? Or have we all become so accustomed to Zoom meetings that we realized there's power there. And we don't necessarily need to get on an airplane to get the value.

Melissa Reeve:

Now, as it pertains to Agile, I feel like in 10 years we won't be calling it Agile. I feel like it will look something more like a continuous learning organization or responsive organization. Agile refers to a very specific set of practices. And as that new mindset, well, the practices and the principles and the mindset, and as that new mindset takes hold and becomes the norm, then will we be calling it Agile? Or will it just be the way that people are working? My guess is it'll start to be moving toward the latter.

Sean Blake:

Well, let's hope that it becomes the normal, right? I mean that it would be great to have more transparency, more cross functional work, less walk-up work and more business agility across the board, wouldn't it? I think it would be great if that becomes the new normal.

Melissa Reeve:

Yeah, me too. Yeah. And I think, we don't call the way we manage people. We don't say, "Oh, that's Taylorism. Are you going to be practicing Taylorism? It's just the way we've either learned through school or learned from our bosses how to manage people. And that's my hope for Agile, is that we won't be calling it this thing. It's just the way we do things around here.

Sean Blake:

Great. Well, Melissa, I think we'll leave it there. I really enjoyed our conversation, especially as a marketer myself. It's great to hear your insight into the industry. And everything we've discussed today has been really, really eyeopening for me. So thank you so much for sharing that with me and with our audience. And we hope to have you on the podcast again, in the future.

Melissa Reeve:

Sean, it's been such a pleasure and I'd be happy to come back anytime.

Sean Blake:

Great. Thanks so much.

Melissa Reeve:

Thank you.

On this episode of The Easy Agile Podcast, tune in to hear developers Angad, Jared, Jess and Jordan, as they share their thoughts on observability.  

Wollongong has a thriving and supportive tech community and in this episode we have brought together some of our locally based Developers from Siligong Valley for a round table chat on all things observability.

💥 What is observability?
💥 How can you improve observability?
💥 What's the end goal?

‍

‍

‍

"This was a great episode to be a part of! Jess and Jordan shared some really interesting points on the newest tech buzzword - observability""

Be sure to subscribe, enjoy the episode 🎧

‍

‍

‍

Transcript

Jared Kells:

Welcome everybody to the Easy Agile podcast. My name's Jared Kells, and I'm a developer here at Easy Agile. Before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the Wodiwodi people of the Dharawal nation, and pay our respects to elders past, present and emerging, and extend that same respect to any aboriginal people listening with us today.

Jared Kells:

So today's podcast is a bit of a technical one. It says on my run sheet here that we're here to talk about some hot topics for engineers in the IT sector. How exciting that we've got a couple of primarily front end engineers and Angad and I are going to share some front end technical stuff and Jess and Jordan are going to be talking a bit about observability. So we'll start by introductions. So I'll pass it over to Jess.

Jess Belliveau:

Cool. Thanks Jared. Thanks for having me one as well. So yeah, my name's Jess Belliveau. I work for Apptio as an infrastructure engineer. Yeah, Jordan?

Jordan Simonovski:

I'm Jordan Simonovski. I work as a systems engineer in the observability team at Atlassian. I'm a bit of a jack of all trades, tech wise. But yeah, working on building out some pretty beefy systems to handle all of our data at Atlassian at the moment. So, that's fun.

Angad Sethi:

Hello everyone. I'm Angad. I'm working for Easy Agile as a software dev. Nothing fancy like you guys.

Jared Kells:

Nothing fancy!

Jess Belliveau:

Don't sell yourself short.

Jared Kells:

Yeah, I'll say. Yeah, so my name's Jared, and yeah, senior developer at Easy Agile, working on our apps. So mainly, I work on programs and road maps. And yeah, they're front end JavaScript heavy apps. So that's where our experience is. I've heard about this thing called observability, which I think is just logs and stuff, right?

Jess Belliveau:

Yeah, yeah. That's it, we'll wrap up!

Jared Kells:

Podcast over! Tell us about observability.

Jess Belliveau:

Yeah okay, I'll, yeah. Well, I thought first I'd do a little thing of why observability, why we talk about this and sort of for people listening, how we got here. We had a little chat before we started recording to try and feel out something that might interest a broader audience that maybe people don't know a lot about. And there's a lot of movements in the broad IT scope, I guess, that you could talk about. There's so many different things now that are just blowing up. Observability is something that's been a hot topic for a couple of years now. And it's something that's a core part of my job and Jordan's job as well. So it's something easy for us to talk about and it's something that you can give an introduction to without getting too technical. So we don't want to get down. This is something that you can go really deep into the weeds, so we picked it as something that hopefully we can explain to you both at a level that might interest the people at home listening as well.

Jess Belliveau:

Jordan and I figured out these four bullet points that we wanted to cover, and maybe I can do the little overview of that, and then I can make Jordan cover the first bullet point, just throw him straight under the bus.

Jordan Simonovski:

Okay!

Jess Belliveau:

So we thought we'd try and describe to you, first of all, what is observability. Because that's a pretty, the term doesn't give you much of what it is. It gives you a little hint, but it'll be good to base line set what are we talking about when we say what is observability. And then why would a development team want observability? Why would a company want observability? Sort of high level, what sort of benefits you get out of it and who may need it, which is a big thing. You can get caught up in these industry hot buzz words and commit to stuff that you might not need, or that sort of stuff.

Jared Kells:

Yep.

Jordan Simonovski:

Yep.

Jess Belliveau:

We thought we'd talk about some easy wins that you get with observability. So some of the real basic stuff you can try and get, and what advantages you get from it. And then we just thought because we're no going to try and get too deep, we could just give a few pointers to some websites and some YouTube talks for further reading that people want to do, and go from there. So yeah, Jordan you want to-

Jared Kells:

Sounds good.

Jess Belliveau:

Yeah. I hopefully, hopefully. We'll see how this goes! And I guess if you guys have questions as well, that's something we should, if there's stuff that you think we don't cover or that you want to know more, ask away.

Jordan Simonovski:

I guess to start with observability, it's a topic I get really excited about, because as someone that's been involved in the dev ops and SRE space for so long, observability's come along and promises to close the loop or close a feedback loop on software delivery. And it feels like it's something we don't really have at the moment. And I get that observability maybe sounds new and shiny, but I think the term itself exists to maybe differentiate itself from what's currently out there. A lot of us working in tech know about monitoring and the loading and things like that. And I think they serve their own purpose and they're not in any way obsolete either. Things like traditional monitoring tools. But observability's come along as a way to understand, I think, the overwhelmingly complex systems that we're building at the moment. A lot of companies are probably moving towards some kind of complicated distributed systems architecture, microservices, other buzz words.

Jordan Simonovski:

But even for things like a traditional kind of monolith. Observability really serves to help us ask new questions from our systems. So the way it tends to get explained is monitoring exits for our known unknowns. With seniority comes the ability to predict, almost, in what way your systems will fail. So you'll know. The longer you're in the industry, you know this, like a Java server fails in x, y, z amount of ways, so we should probably monitor our JVM heap, or whatever it is.

Jared Kells:

I was going to say that!

Jordan Simonovski:

I'll try not to get too much into-

Jared Kells:

Runs out of memory!

Jordan Simonovski:

Yeah. So that's something that you're expecting to fail at some point. And that's something that you can consider a known unknown. But then, the promise of observability is that we should be shipping enough data to be able to ask new questions. So the way it tends to get talked about, you see, it's an unknown unknown of our system, that we want to find out about and ask new questions from. And that's where I think observability gets introduced, to answer these questions. Is that a good enough answer? You want me to go any further into detail about this stuff? I can talk all day about this.

Jared Kells:

Is it like a [crosstalk 00:08:05]. So just to repeat it back to you, see if I've understood. Is it kind of like if I've got a, traditionally with a Java app, I might log memories. It's because I know JVM's run out of memory and that's a thing that I monitor, but observability is more broad, like going almost over the top with what you monitor and log so that you can-

Jordan Simonovski:

Yeah. And I wouldn't necessarily say it's going over the top. I think it's maybe adding a bit more context to your data. So if any of you have worked with traces before, observability is very similar to the way traces work and just builds on top of the premise of traces, I guess. So you're creating these events, and these events are different transactions that could be happening in your applications, usually submitting some kind of request. And with that request, you can add a whole bunch of context to it. You can add which server this might be running on, which time zone. All of these additional and all the exciters. You can throw in user agency into there if you want to. The idea of observability is that you're not necessarily constrained by high cardinality data. High cardinality data being data sets that can change quite largely, in terms of the kinds of data they represent, or the combinations of data sets that you could have.

Jordan Simonovski:

So if you want shipping metrics on something, on a per user basis and you want to look at how different users are affected by things, that would be considered a high cardinality metric. And a lot of the time it's not something that traditional monitoring companies or metric providers can really give you as a service. That's where you'll start paying insanely huge bills on things like Datadog or whatever it is, because they're now being considered new metrics. Whereas observability, we try and store our data and query it in a way that we can store pretty vast data sets and say, "Cool. We have errors coming from these kinds of users." And you can start to build up correlations on certain things there. You can find out that users from a particular time zone or a particular device would only be experiencing that error. And from there, you can start building up, I think, better ways of understanding how a particular change might have broken things. Or some particular edge cases that you otherwise couldn't pick up on with something like CPU or memory monitoring.

Angad Sethi:

Would it be fair to say-

Jared Kells:

Yeah. It's [crosstalk 00:11:02].

Angad Sethi:

Oh, sorry Jared.

Jared Kells:

No you can-

Angad Sethi:

Would it be fair to say that, so, observability is basically a set of principles or a way to find the unknown unknowns?

Jordan Simonovski:

Yeah.

Angad Sethi:

Oh.

Jess Belliveau:

And better equip you to find, one of the things I find is a lot of people think, you get caught up in thinking observability is a thing that you can deploy and have and tick a box, but I like your choice of word of it being a set of principles or best practices. It's sort of giving you some guidance around these, having good logging coming out of your application. So structured logs. So you're always getting the same log format that you can look at. Tracing, which Jordan talked a little bit about. So giving you that ability to follow how a user is interacting with all the different microservices and possibly seeing where things are going wrong, and metrics as well. So the good thing with metrics is we're turning things a bit around and trying to make an application, instead of doing, and I don't want to get too technical, black box monitoring, where we're on the outside, trying to peer in with probes and checks like that. But the idea with metrics is the application is actually emitting these metrics to inform us what state it is in, thereby making it more observable.

Jess Belliveau:

Yeah, I like your choice of words there, Angad, that it's like these practices, this sort of guide of where to go, which probably leads into this next point of why would a team want to implement it. If you want to start again, Jordan?

Jordan Simonovski:

Yeah, I can start. And I'll give you a bit more time to speak as well, Jess in this one. I won't rant as much.

Jess Belliveau:

Oh, I didn't sign up for that!

Jordan Simonovski:

I think why teams would want it is because, it really depends on your organization and, I guess, the size of the teams you're working in. Most of the time, I would probably say you don't want to build observability yourself in house. It is something that you can, observability capabilities themselves, you won't achieve it just by buying a thing, like you can't buy dev ops, you can't buy Agile, you can't buy observability either.

Jared Kells:

Hang on, hang on. It says on my run sheet to promote Easy Agile, so that sounds like a good segue-

Jess Belliveau:

Unless you want to buy it. If you do want to buy Agile, the [crosstalk 00:13:55] in the marketplace.

Jared Kells:

Yeah, sorry, sorry, yeah! Go on.

Jordan Simonovski:

You can buy tools that make your life a lot easier, and there are a lot of things out there already which do stuff for people and do surface really interesting data that people might want to look at. I think there are a couple of start ups like LightStep and Honeycomb, which give you a really intuitive way of understanding your data in production. But why you would need this kind of stuff is that you want to know the state of your systems at any given point in time, and to build, I guess, good operational hygiene and good production excellence, I guess as Liz Fong-Jones would put it, is you need to be able to close that feedback loop. We have a whole bunch of tools already. So we have CICD systems in place. We have feature flags now, which help us, I guess, decouple deployments from releases. You can deploy code without actually releasing code, and you can actually give that power to your PM's now if you want to, with feature flags, which is great.

Jordan Simonovski:

But what you can also do now is completely close this loop, and as you're deploying an application, you can say, "I want to canary this deployment. I want to deploy this to 10% of my users, maybe users who are opted in for Beta releases or something of our application, and you can actually look at how that's performing before you release it to a wider audience. So it does make deployments a lot safer. It does give you a better understanding of how you're affecting users as well. And there are a whole bunch of tools that you can use to determine this stuff as well. So if you're looking at how a lot of companies are doing SRE at the moment, or understanding what reliable looks like for their applications, you have things like SLO's in place as well. And SLO's-

Jared Kells:

What's an SLO?

Jordan Simonovski:

They're all tied to user experiences. So you're saying, "Can my user perform this particular interaction?" And if you can effectively measure that and know how users are being affected by the changes you're making, you can easily make decisions around whether or not you continue shipping features or if you drop everything and work on reliability to make sure your users aren't affected. So it's this very user centric approach to doing things. I think in terms of closing the loop, observability gives us that data to say, "Yes, this is how users are being affected. This is how, I guess the 99th percentile of our users are fine, but we have 1% who are having adverse issues with our application." And you can really pinpoint stuff from there and say, "Cool. Users with this particular browser or this particular, or where we've deployed this app to," let's say if you have a global deployment of some kind, you've deployed to an island first, because you don't really care what happens to them. You can say, "Oh, we've actually broken stuff for them." And you can roll it back before you impact 100% of your users.

Jared Kells:

Yeah. I liked what you said about the test. I forgot the acronym, but actually testing the end user behavior. That's kind of exciting to me, because we have all these metrics that are a bit useless. They're cool, "Oh, it's using 1% CPU like it always is, now I don't really care," but can a user open up the app and drag an issue around? It's like-

Jess Belliveau:

Yeah, that's a really great example, right?

Jared Kells:

That's what I really care about.

Jess Belliveau:

The 1% CPU thing, you could look at a CPU usage graph and see a deployment, and the CPU usage doesn't change. Is everything healthy or not? You don't know, whereas if you're getting that deeper level info of the user interactions, you could be using 1% CPU to serve HTTP500 errors to the 80% of the customer base, sort of thing.

Angad Sethi:

How do you do that? The SLO's bit, how do you know a user can log in and drag an issue?

Jordan Simonovski:

Yeah. I think that would come with good instrumenting-

Angad Sethi:

Good question?

Jordan Simonovski:

Yeah, it comes down to actually keeping observability in mind when you are developing new features, the same way you would think about logging a particular thing in your code as you're writing, or writing test for your code, as you're writing code as well. You want to think about how you can instrument something and how you can understand how this particular feature is working in production. Because I think as a lot of Agile and dev ops principles are telling us now is that we do want our applications in production. And as developers, our responsibilities don't end when we deploy something. Our responsibility as a developer ends when we've provided value to the business. And you need a way of understanding that you're actually doing that. And that's where, I guess, you do nee do think about observability with a lot of this stuff, and actually measuring your success metrics. So if you do know that your application is successful if your user can log in and drag stuff around, then that's exactly what you want to measure.

Jared Kells:

I think that we have to build-

Jordan Simonovski:

Yeah?

Jared Kells:

Oh, sorry Jordan.

Jordan Simonovski:

No, you go.

Jared Kells:

I was just going to say we have to build our apps with integration testing in mind already. So doing browser based tests around new features. So it would be about building features with that and the same thing in mind but for testing and production.

Jess Belliveau:

Yeah and the actual how, the actual writing code part, there's this really great project, the open telemetry project, which provides all these sort of API's and SDK's that developers can consume, and it's vendor agnostic. So when you talk about the how, like, "How do I do this? How do I instrument things?" Or, "How do I emit metrics?" They provide all these helpful libraries and includes that you can have, because the last thing you want to do is have to roll this custom solution, because you're then just adding to your technical debt. You're trying to make things easier, but you're then relying on, "Well I need to keep Jared Kells employed, because he wrote our log in engine and no one else knows how it works.

Jess Belliveau:

And then the other thing that comes to mind with something like open telemetry as well, and we talked a bit about Datadog. So Datadog is a SaaS vendor that specializes in observability. And you would push your metrics and your logs and your traces to them and they give you a UI to display. If you choose something that's vendor agnostic, let's just use the example of Easy Agile. Let's say they start Datadog and then in six months time, we don't want to use Datadog anymore, we want to use SignalFx or whatever the Splunk one is now.

Jordan Simonovski:

I think NorthX.

Jess Belliveau:

Yeah. You can change your end point, push your same metrics and all that sort of stuff, maybe with a few little tweaks, but the idea is you don't want to tie in to a single thing.

Jordan Simonovski:

Your data structures remain the same.

Jess Belliveau:

Yeah. So that you could almost do it seamlessly without the developers knowing. There's even companies in the past that I think have pushed to multiple vendors. So you could be consuming vendor A and then you want to do a proof of concept with vendor B to see what the experience is like and you just push your data there as well.

Jared Kells:

Yeah. I think our coupling to Datadog will be I all the dashboards and stuff that we've made. It's not so much the data.

Jess Belliveau:

Yeah. That's sort of the big up sell, right. It's how you interact. That's where they want to get their hooks in, is making it easier for you to interpret that data and manipulate it to meet your needs and that sort of stuff.

Jordan Simonovski:

Observability suggests dashboards, right?

Jess Belliveau:

Yeah, perhaps. You used this term as well, Jordan, "production excellence." And when we talk about who needs observability, I was thinking a bit about that while you were talking. And for me, production excellence, or in Apptio we call it production readiness, operational readiness and that sort of stuff is like we want to deploy something to production like what sort of best practices do we want to have in place before we do that? And I think observability is a real great idea, because it's helping you in the future. You don't know what problems you're going to have down the line, but you're equipping your teams to be able to respond to those problems easily. Whereas, we've all probably been there, we've deployed code of production and we have no observability, we have a huge outage. What went wrong? Well, no one knows, but we know this is the fix, and it's hard to learn from that, or you have to learn from that I guess, and protect the user against future stuff, yeah.

Jess Belliveau:

When I think easy wins for observability, the first thing that really comes to mind is this whole idea of structured logging, which is really this idea that your application is you're logging, first of all. Quite important as a baseline starting point, but then you have a structured log format which lets you programmatically pass the logs as well. If you go back in time, maybe logging just looked like plain text with a line, with a timestamp, an error message. Whatever the developer decided to write to the standard out, or to the error file or something like that. Now I think there's a general move to having JSON, an actual formatted blob with that known structure so you can look into it. Tracing's probably not an easy win. That's a little bit harder. You can implement it with open telemetry and libraries and stuff. Requires a bit more understanding of your code base, I guess, and where you want tracing to fire, and that sort of stuff, parsing context through, things like that.

Jordan Simonovski:

I think Atlassian, when you probably just want to know that everything is okay. At a fairly superficial level. Maybe you just want to do some kind of up time on a trend. And then as, I guess, your code might get more complex or your product gets a bit more complex, you can start adding things in there. But I think actually knowing or surfacing the things you know might break. Those would probably be your quickest wins.

Jess Belliveau:

Well, let's mention some things for further reading. If you want to go get the whole picture of the whole, real observability started to get a lot of movement out of the Google SRE book from a few years ago. The Google SRE stuff covers the whole gamut of their soak reliability engineering practice, and observability is a portion of that, there's some great chapters on that. O'Reilly has an observability book, I think, just dedicated to observability now.

Jordan Simonovski:

I think that's still in early release, if people want to google chapters.

Jess Belliveau:

The open telemetry stuff, we'll drop a link to that I think that's really handy to know.

Angad Sethi:

From [inaudible 00:26:12], which is my perspective, as a developer, say I wanted to introduce cornflake use Datadog at Easy Agile. Not very familiar, I'm not very comfortable with it. I know how to navigate, but what's a quick way for me to get started on introducing observability? Sorry to lock my direct job or at my workplace.

Jordan Simonovski:

I would lean, I could be biased here. Jess correct me or give your opinion on this, I would lean heavily towards SLO's for this. And you can have a quick read in the SRE-

Jess Belliveau:

What does SLO stand for, Jordan?

Jordan Simonovski:

Okay, sorry. Buzz words! SLO is a service level objective, not to be confused with service level agreement. An agreement itself is contractual and you can pay people money if you do breach those. An SLO is something you set in your team and you have a target of reliability, because we are getting to the point where we understand that all systems at any point in time are in some kind of degraded state. And yeah, reliability isn't necessarily binary, it's not unreliable or reliable. Most of the time, it's mostly reliable and this gives us a better shared language, I guess. And you can have a read in the SRE handbook by Google, which is free online, which gives you a pretty good understanding of Datadog.

Jordan Simonovski:

I think the last time I used it had a SLO offering. But I think like I was mentioning earlier, you set an SLO on particular functionalities or features of your application. You're saying, "My user can do this 99% of the time," or whatever other reliability target you might want to set. I wouldn't recommend five nines of reliability. You'll probably burn yourself out trying to get there. And you have this target set for yourself. And you know exactly what you're measuring, you're measuring particular types of functionality. And you know when you do breach these, users are being affected. And that's where you can actually start thinking about observability. You can think about, "What other features are we implementing that we can start to measure?" Or, "What user facing things are we implementing that we can start to measure?"

Jordan Simonovski:

Other things you could probably look at are, I think they're all covered in the book anyway, data freshness in a way. You want to make sure the data users are being displayed is relatively fresh. You don't want them looking at stale data, so you can look at measuring things like that as well. But you can pretty much break it down into most functionalities of a website. It's no longer like a ping check, that you're just saying, "Yes, HTTP, okay. My application is fine." You're saying, "My users are actually being affected by things not working." And you can start measuring things from there. And that should give you a better understanding, or a better idea, at least, of where to start with what you want to measure and ow you want to measure it. That would be my opinion on where to get started with this if you do want to introduce it.

Jared Kells:

We're going to talk a little bit about state and how with some of these, like our very front end heavy applications that we're building, so the applications we build just basically run inside the browser and the traditional state as you would think about it, is just pulling a very simple API that writes some things into the database with some authentication, and that sort of stuff. So in terms of reliability of the services, it's really reliable. Those tiny API's just never have problems, because it's just so simple. And well, they've got plenty of monitoring around it. But all our state is actually, when you say, "Observe the state of the system," for the most part, that's state in a browser. And how do we get observability into that?

Jess Belliveau:

A big thing is really, there's not one thing fits all as well. When we talk about the SLO stuff as well, it's understanding what is important to not so much maybe your company but your team as well. If you're delivering this product, what's important to you specifically? So one SLO that might work for me at Apptio probably isn't going to work for Easy Agile. This is really pushing my knowledge, as well, of front end stuff, but when we say we want to observe the state as well, we don't necessarily mean specifically just the state. You could want to understand with each one of those API's when it's firing, what the request response time is for that API firing. So that might be an important metric. So you can start to see if one of those APIs is introducing latency, and so your user experience is degraded. Like, "Hey when we were on release three, when users were interacting with our service here, it would respond in this percentile latency. We've done a release and since then, now we're seeing it's now in this percentile. Have we degraded performance performance?" Users might not be complaining, but that could be something that the team then can look into, add to a sprint. Hey, I'm using Agile terms now. Watch out!

Jared Kells:

That's a really good example, Jess. Performance issues for us are typically not an API that's performing poorly. It's something in this very complicated front end application is not running in the same order as it used to, or there's some complex interaction we didn't think of, so it's requesting more data than expected. The APIs are returning. They're never slow, for the most part, but we have performance regressions that we may not know about without seeing them or investigating them. The observability is really at the individual user's browser level. That makes sense? I want to know how long did it take for this particular interaction to happen.

Jess Belliveau:

Yeah. I've never done that sort of side of things. As well, the other thing I guess, you could potentially be impacted in as well as then, you're dealing with end user manifestations as well. You could perceive-

Jared Kells:

Yeah sure.

Jess Belliveau:

... Greater performance on their laptop or something, or their ISP or that sort of stuff. It'd be really hard to make sure you're not getting noise from that sort of thing as well.

Jordan Simonovski:

Yeah. There are tools like Sentry, I guess, which do exist to give you a bit more of an understanding what's happening on your front end. The way Sentry tends to work with JavaScript, is you'll upload a minified map of your JS to Sentry, deploy your code and then if something does break or work in a fairly unexpected way, that tends to get surfaced with Sentry will tell you exactly which line this kind of stuff is happening on, and it's a really cool tool for that company stuff. I don't know if it'd give you the right type of insights, I think, in terms of performance or-

Jared Kells:

Yeah, we use a similar tool and it does work for crashes and that sort of thing. And on the observability front, we log actions like state mutations in side the front end, not the actual state change, but just labels that represent that you updated an issue summary or you clicked this button, that sort of thing, and we send those with our crash reports. And it's super helpful having that sort of observability. So I think I know what you guys are talking about. But I'm just [crosstalk 00:35:25], yeah.

Jess Belliveau:

Yeah, that's almost like, I guess, a form of tracing. For me and Jordan, when we talk about tracing, we might be thinking about 12 different microservices sitting in AWS that are all interacting, whereas you're more shifting that. That's sort of all stuff in the browser interacting and just having that history of this is what the user did and how they've ended up-

Jared Kells:

In that state.

Jess Belliveau:

In that state, yeah.

Jordan Simonovski:

I guess even if you don't have a lot of microservices, if you're talking about particular, like you're saying for the most part your API requests are fine but sometimes you have particularly large payloads-

Jared Kells:

We actually have to monitor, I don't know, maybe you can help with this, we actually should be monitoring maybe who we're integrating with. It's actually much more likely that we'll have a performance issue on a Xero API rather than... We don't see it, the browser sees it as well, which is-

Jordan Simonovski:

Yeah, and tracing does solve all of those regressions for you. Most tracing libraries, like if you're running Node apps or whatever on your backend. I can just tell you about Node, because I probably have the most experience writing Node stuff. You pretty much just drop in Didi trace, which is a Datadog library for tracing into your backend and your hook itself into all of, I think, the common libraries that you'll tend to work with, I think. Like if you're working for express or for a lot of just HADP libraries, as well as a few AWS services, it will kind of hook itself into that. And you can actually pinpoint. It will kind of show you on this pretty cool service map exactly which services you're interacting with and where you might be experiencing a regression. And I think traces do serve to surface that information, which is cool. So that could be something worth investigating.

Jess Belliveau:

It's funny. This is a little bit unrelated to observability, but you've just made me think a bit more about how you're saying you're reliant on third party providers as well. And something I think that's really important that sometimes gets missed is so many of us today are relying on third party providers, like AWS is a huge thing. A lot of people writing apps that require AWS services. And I think a lot of the time, people just assume AWS or Jira or whatever, is 100% up time, always available. And they don't write their code in such a way that deals with failures. And I think it's super important. So many times now I've seen people using the AWS API and they don't implement exponential back off. And so they're basically trying to hit the AWS API, it fails or they might get throttled, for example, and then they just go into a fail state and throw an error to the user. But you could potentially improve that user experience, have a retry mechanism automatically built in and that sort of stuff. It doesn't really tie into the observability thing, but it's something.

Jared Kells:

And the users don't care, right? No one cares if it's an AWS problem. It's your problem, right, your app is too slow.

Jess Belliveau:

Well, they're using your app. Exactly right. It reflects on you sort of thing, so it's in your interest to guard against an upstream failure, or at least inform the user when it's that case. Yeah.

Jared Kells:

Well, I think we're going to have to call it, this podcast, because it was an hour ago. We had instructed max 45 minutes.

Jess Belliveau:

We could just keep going. We might need a part two! Maybe we can request [cross talk 00:39:21].

Jared Kells:

Maybe! Yeah.

Jess Belliveau:

Or we'll just start our own podcast! Yeah.

Angad Sethi:

So what were your biggest learnings today, given it's been Angad and I are just learning about observability, Angad what was your biggest learning today about observability? My biggest learning was that observability does not equal Datadog. No, sorry! It was just very fascinating to learn about quantifying the known unknowns. I don't know if that's a good takeaway, but...

Jess Belliveau:

Any takeaway is a good takeaway! What about you, Jared?

Jared Kells:

I think, because I we were going to talk about state management, and part of it was how we have this ability, at the moment to, the way our front ends are architected, we can capture the state of the app and get a customer to send us their state, basically. And we can load it into our app and just see exactly how it was, just the way our state's designed. But what might be even cooler is to build maybe some observability into that front end for support. I'm thinking instead of just having, we have this button to send us out your support information that sends us a bunch of the state, but instead of console logging to the browser log, we could be console logging, logging in our front end somewhere that when they click, "send support information," our customers should be sending us the actions that they performed.

Jared Kells:

Like, "Hey there's a bug, send us your support information." It doesn't have to be a third party service collecting this observability stuff. We could just build into our... So that's what I'm thinking about.

Jess Belliveau:

Yeah, for sure. It'll probably be a lot less intrusive, as well, as some of the third party stuff that I've seen around.

Jared Kells:

Yeah. It's pretty hard with some of these integrations, especially if you're developing apps that get run behind a firewall.

Jess Belliveau:

Yeah

Jared Kells:

You can't just talk to some of these third parties. So yeah, it's cool though. It's really interesting.

Jess Belliveau:

Well, I hope someone out there listening has learned something, and Jordan and I will send some links through, and we can add them, hopefully, to the show notes or something so people can do some more reading and...

Jared Kells:

All thanks!

Jess Belliveau:

Thanks for having us, yeah.

Jared Kells:

Thanks all for your time, and thanks everybody for listening.

Jordan Simonovski:

Thanks everyone.

Angad Sethi:

That was [inaudible 00:41:55].

Jess Belliveau:

Tune in next week!