Easy Agile Podcast Ep.23: How to navigate your cloud migration journey

"It was amazing to talk with Ida and Ulrika from TietoEVRY, they are truly leading the way in sustainability" - Rebecca Griffith

Rebecca and Caitlin are talking with Ida and Ulrika from TietoEVRY, about big picture sustainability and the role of business in supporting sustainability initiatives.

🌍 Implementing sustainability in daily business operations
🌍 The role of technology in advancing sustainability
🌍 Ensuring your sustainability & DEI report doesn't turn into a stagnant document
🌍 Framing challenge in a way of opportunity
🌍 Getting the whole team on board

An important listen for everyone, enjoy!

📲 Subscribe/Listen on your favourite podcasting app.

Transcript

Caitlin Mackie:

Hi, everyone. Welcome to the Easy Agile Podcast. I'm Caitlin, marketing coordinator at Easy Agile.

Rebecca Griffith:

And I'm Beck, team and operations assistant at Easy Agile, and we'll be your host for this episode. Before we begin, we'd like to acknowledge the traditional custodians of the land from which we broadcast today, the worthy, worthy people of the Tharawal nation and pay our respects to elders past, present and emerging. We extend that same respect to all aboriginal and Torres Strait Islanders people joining us today.

Caitlin Mackie:

Today, we're joined by Ida and Ulrika from TietoEVRY. Welcome. Thanks for joining us.

Ida Bohman Steenberg:

Thank you so much for having us.

Ulrika Lagerqvist Von Unge:

Thank you.

Rebecca Griffith:

It would be great if we could start with some introductions. Ida and Ulrika, could you tell our listeners a bit about yourselves and your role at TietoEVRY?

Ida Bohman Steenberg:

Yes, of course. I'm Ida and I'm heading up the sustainability team at TietoEVRY since four years back. And Ulrika?

Ulrika Lagerqvist Von Unge:

Yeah. I work within the sustainability team as a sustainability manager also here at TietoEVRY.

Rebecca Griffith:

Excellent. Thank you. Thanks for the introductions. Let's jump in. For our listeners who might not be familiar with TietoEVRY, can you give us a bit of an overview about what the company does?

Ida Bohman Steenberg:

Yes. Sure. We are a company based in the Nordics, like very, very far away from sunny Australia. We are a tech company. We provide different solutions. For instance, in software, cloud and infra and also business consulting. I think nowadays, we are the biggest tech provider in the Nordic, at least.

Caitlin Mackie:

Sustainability is a huge part of TietoEVRY. You really have a robust sustainability game plan and your strategy for 2023, which highlights your key priorities for ethical conduct, climate actions and creating an exciting place to work for your employees. Can you elaborate on the sustainability game plan for 2023?

Ida Bohman Steenberg:

Yeah, we would love to. The sustainability game plan is our long term plan that we created last year. We were actually two companies merging into one last year. We had different legacies. X Tieto were good at some things and X EVRY were good at some things, but of course, we had lots of challenges too. We had to sit down and really try to find out what should be our focus going forward and not only actually to build upon what we already have, but also look at the major challenges out there to see like, where do we want to be and what role do we want to have? We created a game plan that is two-folded. We have like the responsible operations that is the traditional sustainability work that you would find at any organization that takes sustainability seriously.

We have the ethical conduct where we have business, ethics, and the corruption, cyber security, privacy, human rights, responsible sourcing, for instance. Then, we have exciting place to work, which is more like HR related because we're people companies, we have to be very good at this in order to attract the right talent and also to keep the talent that we have. We have major challenges when it comes to bringing in and keeping women in our sector, for instance, so we have to be very good at diversity and inclusion and also employee experience, of course, to make this a fun place to work at. Then, of course, climate action may be the one thing that people think about most when they think about sustainability due to the emerging climate crisis. We work a lot with that, of course, and also circular economy and our take on that.

That is like the foundation for us that we have to be very good at like our license to operate, and we work throughout the value chain with these topics, but then because we are a tech company, we also wanted to see what can we do to not only improve our own sustainability performance, but foremost our customers? What's due, I think, and what really stands out for TietoEVRY now is that we have this really, really strong business focus going forward for this sustainability game plan. I was thinking maybe Ulrika could take over and explain and elaborate a little bit about the upper half of the circle.

Ulrika Lagerqvist Von Unge:

Yeah, exactly. What we identified when we were developing this strategy or long term plan was that some of our biggest impacts also actually resides among our customers. We have a lot of capabilities and we have a lot of customers, so why not combine those and see where do we have the biggest opportunity in terms of actually helping our customers to become more sustainable? We developed a methodology where we investigated our capabilities, our customer pain points, our customer opportunities and landed in four broad impact opportunities. That's where we have business opportunities in making our customers sustainable. Those are new focus areas within our sustainability long term plan, where we engage with our own business to drive these areas and develop together with our customers to create positive impact on people, planet and societies.

Ida Bohman Steenberg:

I think also if I may add to that, Ulrika, so we set the plan to do that, and we had of course, a lot to build upon. We had lots of good reference cases, but of course, we needed to pin it down to get the buy-in from management. Also, of course, get the resourcing. We started with identifying those areas where we think that other people have, or other customers or stakeholders have impact opportunities, which means a business opportunity for us. We must not forget that, but in order to actually deliver in a good way and at the speed that our customers require, we also had to create a consultancy team that could help in the delivery organization because the customer requirements become... The pressure was so high.

For our little team group sustainability, we couldn't really handle everything, so we created something that we call the sustainability hit team, which is a consulting team consisting of consultants that knows data and sustainability within business consulting. Ulrika, you have been given also... You have the role of leading this group, perhaps you would like to say something more about that group?

Ulrika Lagerqvist Von Unge:

Yeah. Yeah. Sure. Well, this is a group of people that, just as Ida said, they have this kind of expertise, combining sustainability knowledge with IT and technology. We work together to identify both ongoing projects that might be related to sustainability in one way or the other that we perhaps can scale and create synergies, but we also work to identify new opportunities, having our ears towards the ground and listening into what do the customers actually want to have. Then, we take in these opportunities and try to see how we can develop them to actually support our customers. Hopefully, this team will just continue to grow and us with our other efforts, become very integrated in all our business operations. That is at least our aim, so the responsibility lies where the responsibility is sort to say.

Rebecca Griffith:

That's wonderful. Now, I think you've kind of touched on this in a broader sense, but in the TietoEVRY annual report, you talk about implementation of sustainability into daily business operations. What are some other key ways that you're doing this?

Ulrika Lagerqvist Von Unge:

Yeah. If I can start, Ida?

Ida Bohman Steenberg:

Sure.

Ulrika Lagerqvist Von Unge:

I think one of the most important things is to involve everyone from the beginning in what we actually should focus on and what are the most important topics in terms of sustainability, both for all our stakeholders, but also for our business, so that we actually give the ownership of sustainability to the organization. Not so that they feel it comes from the side or from above, but it's actually something that is relevant and that the organization owns. That means that each and everyone has the responsibility to also contribute to our joint targets that we also have involved the different business leaders and parts of the organization in setting. I think that ownership is a keyword here to actually enable integration of sustainability in the operations. Ida, do you agree?

Ida Bohman Steenberg:

Yeah. No, but the group sustainability, our group, we are a small team consisting of specialists with long experience, but we are only so many, so we have to have a very integrated way of working in order to make this fly. What we've been focusing on a lot since many years back is to get it integrated. For instance, if we look at responsible sourcing, which is crucial how we handle our supply chain. We work closely together with a chief procurement officer. The sustainability goals that we have that are public and that we disclose every year in our annual report is just as much his goals as it is our goals, so we really get some power behind driving it and we get the results that we need in order to move forward. That is one thing. Then, as Ulrika explained earlier in the last question about the sustainability hit team, how we also now have taken this step further to really approach the business in a more structured way that we have done before. As I said, we had very good reference cases and we have a portfolio of sustainability related services, but now we're doing this in a much more structured manner because of the market, the demands that has increased so much.

Caitlin Mackie:

Yeah. That's great. I think what you mentioned, having that structure helps with that company buy in and getting everybody on board and realizing that it's everybody's commitment and it's like a journey you're all on together. Yeah. I think that's great. Something that's often talked about is the overlap between business and sustainability and the role of the business in addressing some of the major challenges we face as a society. I think so many look to clearly distinguish their responsibility and draw a line somewhere, but I'm not so sure that's the right approach. TietoEVRY certainly recognizes they have an important role to play and really pave the way towards carbon neutrality. What's your approach to this?

Ida Bohman Steenberg:

Okay. First of all, I think there must be an overlap or there must be like, if you are a company like we are, we cannot do things that we don't think also is good for us, like financially long term. That is the beauty of sustainability. If you have good and long term targets, it's also support the growth of the company in financial terms, so we always have both those perspectives in mind, creating strategies going forward. For us, we work both for our own operations when it comes to climate change to decrease our carbon footprint, obviously, so we are changing. We have renewable energy in all our data centers and offices. We are now currently at 80% and approaching 100. It's going to be difficult. The last percent is always the most difficult ones, but we have a good development as for now.Then, of course, we work super hard because this is the, I think number one question that our customers is asking for, ways to manage their own carbon footprints. Here we are strong in data, of course. Do you want to add something around that?

Caitlin Mackie:

No, but I think that the first reflection that you had that we have this financial perspective also when developing the sustainability plan, it's important because I think that what we see is that... Our business is doing business. Yes, of course. But if you don't do it right, there will be no business on a dead planet, right? So that you have to have the long term perspective where you take into account all the different aspects. It's not only the financial, because they're also interlinked. I think that also the risks that are connected to, for example, climate change for business operations, so the inbound risks that the surrounding is posing to us are becoming more and more clear. I think that it's also becoming evident that if you don't have sustainability integrated in your operations, you will no longer have a license to operate in 2021 and beyond. I think it's just a smarter way of doing business, to be honest.

Rebecca Griffith:

We can all acknowledge that climate action is one of the biggest global challenges for our generation. In recognizing that this is one of your key priorities to address, how do we take these challenges and frame them in a way of opportunity?

Ida Bohman Steenberg:

Well, this is the beauty of being a tech company. We have the luxury of not having lots of goods that we need to take care of cotton or food or so, so we can go straight to the point, I think, and start to listen to what our customers need and create services and solutions that support them in their journey to decrease their carbon footprint. It sounds very easy when I say it like this. It's not that easy, of course. It requires a lot of hard work and everything, but that's what we should do. I think that when you look at the crisis that is emerging, the tech industry is also seen by the other industries as the great enablers. I think that we have a key role to play. I think that we have a responsibility to our stakeholders to be there and to be in the forefront.

I think that's what we've been doing. For instance, for the last year, the guest team has been working on a very interesting solution called the sustainability hub, which actually addresses this spot on. Would you like to...

Ulrika Lagerqvist Von Unge:

Yeah. Yeah. Definitely. I totally agree with you, Ida. The tech industry, it's really an enabler and that also means that there's a lot of business opportunities. As you said, the sustainability data hub voice, one of our responses to these kind of business opportunities that we see out there, so what happened was that we were sitting and discussing and realized that one of the biggest obstacles for companies to actually integrate sustainability into decision making, into risk management analysis, et cetera, is the lack of data as you have now produced your own ability report, the big hurdles that comes with actually collecting the data for that report, it sits in shattered data sources.

The collection is often manual. The data might not be in the right shape. Most companies actually collect the non-financial data once a year for their annual sustainability report. That means that when you have that data, you are actually steering through the rear view mirror because you are not steering proactively by taking fresh data into account when you take your decisions or plan your operations. What we did was that we started to develop a solutions, which builds on automating the data collection of sustainability data by helping customers to identify where does the data sit? How can we actually automate it? Is it via automation, via IoT solution? Who will use the data? Which KPIs and metrics do we want to map it against? How often do we want the data to be updated? Then, visualize it in real time? A modern way of an ERP system for ESG data, you could say, so that it is actually possible to equate non-financial inform and with financial information.

That should give the opportunity for companies to treat the data in the same manner and actually integrate sustainability into the decisions that they take. For example, let's think about the impact of us going from working at the offices to now working hybrid. What are the actual impacts? Can we see that the sick leave has increased or decreased? How has the carbon emission been impacted by us not traveling back and forth to the offices? If we have that data, we could also use that to decide whether we should continue with hybrid working, or if we should force our employees to come back to the office, or if everybody should be working from home. If you can get hand of that collective view of the activities that you take, you could also make more holistic and informed decisions. That's one response kind of how we try to treat sustainability as a business opportunity and identify which are the pain points that our customers have in terms of co-creating a sustainable future, and where can we tap in into that? That is the kind of beauty, as you said, our industry.

Ida Bohman Steenberg:

It is.

Rebecca Griffith:

Really interesting looking at it in real time, as you said, as opposed to a retrospective assessment of the data, which really, you can't change.

Ulrika Lagerqvist Von Unge:

Exactly. Yeah.

Ida Bohman Steenberg:

Yeah.

Rebecca Griffith:

What's the point in waiting another 12 months to then look at it again when you have completely done [crosstalk 00:18:32]?

Ida Bohman Steenberg:

Yeah. Both sustainability.... Yeah. Sorry. Both sustainability and tech is moving extremely fast. I think we need to work like this. I think customers are going to require... We see more and more before they wanted us to report once a year, but now so many of our customers, they want us to report different types of data related to the solutions or our delivery to them on a quarter basis. The more we can have real time data, I think it's going to be the new normal very soon.

Ulrika Lagerqvist Von Unge:

Me too. That will be a huge game changer for companies. When the data is there, you can get it black on white. There is no excuse for taking bad decisions, right?

Caitlin Mackie:

Yeah. Yeah.

Rebecca Griffith:

Quite exciting.

Caitlin Mackie:

Exactly. I don't know about you, Beck, but I'm definitely sitting here being like, "Wow," at all, like this would've been super handy 12 months ago.

Ulrika Lagerqvist Von Unge:

Yeah.

Ida Bohman Steenberg:

It's out there. Yeah.

Ulrika Lagerqvist Von Unge:

Yeah.

Ida Bohman Steenberg:

It's on the market, so you're more than welcome.

Caitlin Mackie:

All right.

Ulrika Lagerqvist Von Unge:

I think that's also typical from sustainability that you have to understand that the solutions to all of these kind of complex problems, they can't be solved by any actor. We need to work in ecosystems and everybody will have to bring their expertise to the table. Then, we can get things to actually be solved. I hope that that logic will also impact other areas so that we more try to cooperate instead of having the cake ourselves, because then there will be no cake left over. That would be sad.

Caitlin Mackie:

It's so, so refreshing to hear you say that. I think for so long businesses have always had this idea about, "Oh, competition," and like, "Keep what's yours. Keep it to yourself. We're going to succeed in this area." But moving into this space, it's just not about that anymore. It's about how we can collaborate together to reach those solutions. I think that's so powerful.

Ida Bohman Steenberg:

For sure. No. Sustainability is horizontal work. As an organization, as an entity, as a company, we are not stronger than our closest stakeholders anyway. Our performance is very much reliant on their performance.

Ulrika Lagerqvist Von Unge:

I think it's so interesting also because since we come from that kind of background, Ida and I also always working across all silos, across all kind of company functions. We also get a special role in our company because we don't have the legacy of working in silos, so we just totally break them all the time because we're not aware of them. That's just what is needed to be able to get the job done. I think that it's really interesting to see how the organization actually appreciates that.

Ida Bohman Steenberg:

Yes. Sometimes, they don't.

Ulrika Lagerqvist Von Unge:

Sometimes, they don't. Exactly. Sometimes, they don't. Yeah. That's true. Yeah.

Ida Bohman Steenberg:

But we have our battles internally. If you're a sustainability professional working in a big organization, you must be very prepared to have those tougher discussions as well, but we all get there, not always on time from our perspective, but that's the way it has to be. Fearless and just...

Ulrika Lagerqvist Von Unge:

Stubborn.

Ida Bohman Steenberg:

Stubborn, and don't be too bothered about silos or hierarchies or so, because then you will never get anything done.

Caitlin Mackie:

I wanted to highlight or expand on the idea of opportunity and the fact that we constantly need to be exploring new and better ways of doing things so that we can move forward. It would be great to get your thoughts on the role of technology in advancing sustainability. I know you've touched on it, but it'd be great to elaborate.

Ulrika Lagerqvist Von Unge:

If I start, then you can build on it.

Ida Bohman Steenberg:

Sure.

Ulrika Lagerqvist Von Unge:

I think that some of the business opportunities or the solutions that we can develop are cross industrial. For example, the need for data and the need to get hold of it and to visualize it and to be able to act on it, is of course, something that all companies in all industries could make use of. But then, I think that for many solution, they are industry specific. For example, logistic. They need certain solutions to be able to optimize their logistic, their rooting, or to better pack their lorries and trains, et cetera. But I think that... There are both this industry specific solution and this cross sectional business opportunities stuff that you have, and also one of the hidden gems within the IT sector is the side effects of digitalizing services or solutions.

It's also important to understand that even though a solution might not be developed and deployed for the use of mitigating or climate change, for example, the actual impact of its implementation might lead to less carbon emission. Let's think about we have a solution that is called patient engagement. It means that you could engage with your doctors and nurses over your phone, which means that you don't have to take the public transportation or your own car to the hospital or to the medical clinic, which of course saves that transportation and in turn, saves carbon emissions if you travel with something except for an electric car. Many of the digital solutions actually have that positive hand print impact or effect, I would say. Of course, the opportunity of expanding on those is also massive and to identify them, perhaps it's the possibility. If you have a patient engagement app, could you use it for other purposes for other users to increase the impact.

Rebecca Griffith:

At Easy Agile, one of our goals was to establish a baseline and publish our very first sustainability and diversity report, which I believe we've shared with you. We'll also share that report as well as the TietoEVRY annual report in the show notes for our listeners. But what advice would you give to organizations to ensure that these kind of documents don't turn into a stagnant document or a mere check of the box exercise? How do we use these reports to encourage conversation and continually seek ways to improve?

Ida Bohman Steenberg:

Okay. I get so many thoughts now. First of all, keep up with an upcoming frameworks. Don't get stuck in all the good old GRI for instance. In the European Union, so we are now approaching the taxonomy reporting or TCFD or so on. Go for those new ones. Also, of course, everybody has to do the ground work. You have to do your stakeholder engagement, the dialogues, the materiality analysis in order to know that you focus on the right things and so on, and you have to have really concrete goals and action plans and KPIs and everything, so you can measure your performance against the goals that ultimately what sustainability reporting is about. But then, I think the opportunity with reporting, because reporting can be a little bit boring too, in a sense, and it can feel stagnant in a way. It is that it's such an important tool in the strategy work.

This is where you get the attention from the leaders like, "What goals are we going to have and how did we do and so on?" That's where you can have the good discussions or you can also raise the ambition level as you go along. That I think is really crucial. Use it as a strategy tool as well, and then never get stuck in like, "Oh, yeah. It's good. We met our targets. We moved 3% forward or whatever." Don't think so much about that. Think about lie what are the major challenges right now? What is your role as an organization? No matter what organization you are, find your way to be part of the solution instead. We have that discussion sometimes internally. People are like, "Oh, but you're doing so good. You have a good results and so on."

But for me and Ulrika and our sustainability professionals, we're like, "Yeah. Okay. We move forward. That's good." But from a greater perspective where we are reaching the tipping point for the planet, so we feel other pressure in order to move forward faster. Don't end up in like, "Yeah. We move forward. We're keeping the pace." Full on power ahead, and speed is of essence going forward.

Ulrika Lagerqvist Von Unge:

Yeah. No, I fully agree. I think that's really good reflections to hook the sustainability reporting up on the challenges to understand. What are the purposes? What are we actually trying to achieve by this report? We are trying to contribute to minimize the negative impact and to increase the positive impact, and the sustainability report is a tool for that. I think another thing that is really important is to actually also engage with the organization to get them define their own targets and their own metrics to report on, so that they feel ownership. For some of the areas that we have in our sustainability report, when we have an engaged partner within the organization that themselves have ideas on targets, we develop their own KPIs.

They feel that, "I really believe in this. I want to work with this." Then, the follow up and the continuous reporting is much easier than while we have perhaps other parts of the organization where there isn't so much clear targets internally, so that the sustainability report is more felt like something that is done on an annual basis just collecting the data, but not making use of it actually. Just create that commitment and build on the company's own targets and own KPIs that are useful. Then, of course, sometimes if you do report according to a sustainability framework such as the GRI standards, which is commonly used in Europe, then you, of course, need to report according to some of the metrics in that standard, but then add your own key guides, your own metrics, because that will make the organization feel engaged, I could say.

Ida Bohman Steenberg:

Yeah. Yeah. Basically to summarize that, so three things, do the groundwork according to the upcoming and fresh frameworks, and then two, use it as a strategic tool to have those important discussions with management and make it a part of the overall strategy, so you don't end up with the sustainability strategy and an overall strategy. Then, three, be bold. Look at the challenges and not only what's doable or keeping the trend or whatever. Those three things, I think is important to have in mind.

Rebecca Griffith:

Spot on.

Caitlin Mackie:

Yeah. I love that. I think that's great advice, especially the idea of you're mapping out what you're doing internally and what that looks like, but being able to take that step back and say, "Okay. But what does this contribute to in the big picture? What are we actually helping and what are we doing to move in the right direction?" Something that I often think about is things like the UN sustainable development goals and looking at those and being like, "Well, what can we do to of map where we are at and where can we offer? What can we be doing in this space that helps reach those targets?" Yeah. Great advice. I love it. But I think just to wrap us up, our last question for both of you is looking forward, what keeps you hopeful?

Ida Bohman Steenberg:

It keeps me hopeful. Well...

Ulrika Lagerqvist Von Unge:

For me, I think the younger generation, to be honest. I think that seeing my brothers' daughters that are teenagers, or to see [inaudible 00:31:19] and the commitment that she's able to steer up, I think that gives me hope that things will move faster in the future. I think that's positive.

Ida Bohman Steenberg:

Yeah. I also second that. I think I visited the school last week with students like 18, 19 years old, and I've been doing that every year for a couple of years now and I always ask them, "What do you know about sustainable? What do you think about it?" Before, it was like, "Yeah. The environment or recycling maybe," but now they were like, "Yeah. The UN SDGs..." So the level of knowledge has increased so much. There is huge interest and when I gave them, "What can you do on a practical level if you want to live a more sustainable life?" They were like, "Yeah. Don't buy a new party cup for the Friday night. Borrow from your friends, or there are these sites. I can text you these sites where you can borrow dresses and stuff like that." They are doing it in real life in such a good way where they combine technology and sustainability, so they're much more tech savvy than we are. I was very inspired by that.

Ulrika Lagerqvist Von Unge:

They're also willing to actually sacrifice stuff. It's like, "No, we don't fly. We don't do this because we would like to have a future to live in." I think that that is something which we are so comfortable and so used to having a certain lifestyle, but they are perhaps not and they are challenging that lifestyle that we have been having, which has also led to where we are today.

Ida Bohman Steenberg:

I think also to add to that, I think that finally the leaders of our countries are getting it, at least getting close to getting it. I think things are changing, so that's good, but my hope stands to the young ones still.

Rebecca Griffith:

It's nice to feel that it's becoming a normal part of consciousness for the newer generations where it's something that we had to learn to appreciate and respect and to take action on, but it seems to be a part of their upbringing and a way of life now, which is great.

Caitlin Mackie:

Well, I think that's great. I think it's great to leave the episode on such a high and leave the audience with a bit of inspiration moving forward. Thank you both for taking the time to chat with us and sharing your expertise with the Easy Agile audience.

Ida Bohman Steenberg:

Thank you so much for having us. It was fun to talk to you, and it's nice also to talk about the perspectives from the Nordics and from the tech industry. Thank you very much.

Rebecca Griffith:

Thank you.

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

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

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

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

So many golden nuggets in this episode!

Be sure to subscribe, enjoy the episode 🎧

Transcript

Henri Seymour:

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

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

Matt Reiner:

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

Henri Seymour:

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

Matt Reiner:

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

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

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

Henri Seymour:

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

Matt Reiner:

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

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

Henri Seymour:

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

Matt Reiner:

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

Henri Seymour:

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

Matt Reiner:

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

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

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

Henri Seymour:

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

Matt Reiner:

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

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

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

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

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

Henri Seymour:

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

Matt Reiner:

Exactly.

Henri Seymour:

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

Matt Reiner:

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

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

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

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

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

Henri Seymour:

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

Matt Reiner:

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

Henri Seymour:

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

Matt Reiner:

That's right.

Henri Seymour:

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

Matt Reiner:

Exactly.

Henri Seymour:

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

Matt Reiner:

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

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

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

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

Henri Seymour:

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

Matt Reiner:

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

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

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

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

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

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

Henri Seymour:

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

Matt Reiner:

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

Henri Seymour:

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

Matt Reiner:

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

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

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

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

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

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

Henri Seymour:

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

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

Matt Reiner:

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

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

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

Henri Seymour:

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

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

Matt Reiner:

Yeah.

Henri Seymour:

That's great.

Matt Reiner:

Yeah, absolutely. Yeah.

Henri Seymour:

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

Matt Reiner:

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

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

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

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

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

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

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

Henri Seymour:

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

Matt Reiner:

Exactly.

Henri Seymour:

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

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

Matt Reiner:

Wow.

Henri Seymour:

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

Matt Reiner:

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

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

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

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

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

Henri Seymour:

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

Matt Reiner:

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

Henri Seymour:

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

Matt Reiner:

Exactly.

Henri Seymour:

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

Matt Reiner:

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

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

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

Henri Seymour:

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

Matt Reiner:

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

Henri Seymour:

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

Matt Reiner:

Yeah.

Henri Seymour:

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

Matt Reiner:

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

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

Henri Seymour:

I think I missed that one.

Matt Reiner:

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

Henri Seymour:

Now, where do I even start on that?

Matt Reiner:

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

Henri Seymour:

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

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

Matt Reiner:

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

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

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

Henri Seymour:

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

Matt Reiner:

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

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

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

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

Henri Seymour:

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

Matt Reiner:

That's right.

Henri Seymour:

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

Matt Reiner:

Oh, cool. Oh, cool.

Henri Seymour:

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

Matt Reiner:

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

Henri Seymour:

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

Matt Reiner:

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

Henri Seymour:

Yeah.

Matt Reiner:

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

Henri Seymour:

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

Matt Reiner:

Yeah. Yeah.

Henri Seymour:

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

Matt Reiner:

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

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

Henri Seymour:

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

Matt Reiner:

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

Henri Seymour:

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

Matt Reiner:

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

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

Henri Seymour:

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

Matt Reiner:

I guess so.

Henri Seymour:

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

‍

‍

"Thoroughly enjoyed my conversation with Jon, he shared some great perspectives on the impact of the Agile manifesto" - Amaar Iftikhar

Amaar Iftikhar, Product Manager at Easy Agile is joined by Jon Kern, Co-author of the Agile Manifesto for Software Development and a senior transformation consultant at Adaptavist.

Amaar and Jon took some time to speak about the Agile Manifesto. Covering everything from the early days, ideation, process, and first reactions, right through to what it means for the world of agile working today.

They touch on the ideal state of an agile team, and what the manifesto means for distributed, hybrid and co-located teams.

We hope you enjoy the episode!

Transcript

Amaar Iftikhar:

Hi everyone. Welcome to the Easy Agile Podcast. My name is Amaar Iftikhar. I'm a product manager here at Easy Agile. And before we begin, Easy Agile would like to acknowledge the traditional custodians of the land from which we broadcast today, the people of the Dharawal speaking country. We pay our respects to elders past, present, and emerging. And extend that same respect to all Aboriginal, Torres Strait Islander, and First Nations peoples joining us today.

Today, we have on the podcast Jon Kern, who is the co-author of the Agile Manifesto for Software Development and an Agile consultant. If you're wondering, you're correct. I did mention the Agile Manifesto for Software Development. The Agile Manifesto. So Jon, welcome for being here and thank you for joining us.

Jon Kern:

Oh, my pleasure, Amaar. Thank you.

Amaar Iftikhar:

Yeah, very excited to have you on. Let's just get started with the absolute basic. Tell the audience about, what is the Agile manifesto?

Jon Kern:

Well, it's something that if you weren't around, and I know you're young, so you weren't around 21 years ago, I guess now, to maybe understand the landscape of what software development process and tooling and what most of us were facing back then, it might seem like a really obvious set of really simple values. Who could think that there's anything wrong with what we put into the manifesto? But back in the day, there were, what I practiced under as a... I'm an aerospace engineer, so I was in defense department work doing things like fighter simulation, F-14 flat spins and working with a centrifuge and cool stuff like that. And subject to a mill standard specification, which makes sense for probably weapons systems, and aircraft manufacturing, and all sorts of other things. But they had one, lo and behold, for software development. And so there was a very large, what I would call heavy handedness around software development process. We call it heavyweight process. Waterfall was the common term back then, and probably still used today.

And there were plenty of, I would say the marketing juggernaut of the day, IBM and Rational unified process, these large, very much like Safe. Where it's a really large body of work, awesome amount of information in it, but very heavy process even though everything would, say you tailor it, it could be whatever you wanted. I mapped my own lightweight process into REP for example. Sure. But the reality was we were facing kind of the marketplace leader being heavyweight process that was just soul crushing, and from my perspective, wasting taxpayers' money. That was kind of my angle was, well, I'm a taxpayer, I'm not going to just do this stupid process for process sake. That has to have some value, has to be pragmatic. So lo and behold, there were a handful of us, 17 that ended up there, but there are a handful of us that practiced more lightweight methods. So the manifesto was really an opportunity for coming together and discovering some of the, what you might think of as the commonality between many different lightweight practices. There was the XP contingent. I first learned about Scrum there, for example. Arie van Bennekum, a good friend, he taught us about DSDM. I don't even remember what it stands for anymore. It was a European thing.

Alistair and Jim Highsmith, they had, I forget, like crystal methodologies. So there was a fair amount of other processes that did not have the marketing arm that erupted, or didn't have the mill standard. So it was really all about what could we find amongst ourselves that was some sort of common theme about all these lightweight processes. So it was all about discovering that, really.

Amaar Iftikhar:

You all get together, the principles kind of come to fruition, and let's fast forward a little bit. What was the initial reaction to the original manifesto?

Jon Kern:

Yeah, it was even kind of funny that the four values, the four bullets is as simple as it was. The principles came a bit later. I want to say we collaborated over awards wiki, but the original... If you go to Agile uprising, you can see I uploaded some artifacts, because apparently I'm a pack rat. And I had the original documents that Alistair probably printed out, because he was the one... He and Jim lived there near Salt Lake City. So it was like, "Hey, let's come here." And we like to go skiing, so let's do it here. So he arranged the room and everything. And so there's some funny artifacts that you can find. And the way that it actually came about was an initial introduction of each of us about our methods. And really I think a key, we left our egos at the door. I mean I was a younger one. Uncle Bob, some of these, he was at Luminar, I know I have magazines still in the barn that he was either the editor of, or authors of for people who don't remember what magazines are. Small little booklets that came out. So Uncle Bob was like, Ooh, wow, this is pretty cool.

And I wasn't shy because I had a lot of experience with heavyweight methods. So I really wanted to weigh in on... Because I had published my own lightweight method a few years earlier. So I had a lot of opinions on how to avoid the challenges of big heavyweight process. So the culmination as we were going out the door and after we had come up with the four values was I think Ward said, "Sir, want me to put this on the web?" And again, this is 2001 so dot com and the web's still kind of new so to speak. And we're all like, yeah, sure, why not? What the hell, can't hurt. We got something, might as well publish it. I don't think to a person, anybody said, "Oh yeah, this is going to set the world on fire because we're so awesome." And we were going to anoint the world with all of this wonderful wisdom. So I don't think anybody was thinking that that much would happen.

Amaar Iftikhar:

Yeah. So what were you thinking at that time? So how would the principles that you had come up with together, was that maybe just for the team to take away? Everyone who was there? What was the plan at that time?

Jon Kern:

I think it was a common practice. Like I said, there were other groups that would often meet and have little consortiums or little gatherings and then publish something. So I think it was just, oh yeah, that's a normal thing to do is you spent some time together and you wrote things down, you might as well publish it. So I think it wasn't any deeper than that other than Bob, I think Bob might say that he wanted to come up with some kind of a manifesto of sorts or some kind of a document because that's I think what those sort of... I was never at one of those gatherings, but you know, you could see that they did publish things. I have a feeling it was just something as innocent as, well we talked, wrote some things down, might as well share it.

And then the principles, there were a lot of different practices in the room. So some of what I would say the beauty of even the values page is the humility at the top is it's still active voice. We are uncovering not, hey all peasants, we figured it all out. No, we're still uncovering it. And the other thing is by doing it, because I'm still an active coder. And plus we value this more on the left, more than on the right. Some people might say it's a little ambiguous or a little fuzzy, but that's also a sign of humility and that it's not A or B. And it really is fuzzy, and you need to understand your context enough to apply these things. So from a defense department contracting point of view, certainly three of the four bullets were really important to me because I learned... Sure, we did defense department contracting. But it's way more important to develop a rapport with the customer than it is... Because by the time you get to the contract you've already lost, which goes along with developing a rapport with the customer, the individual.

And one of Peter Codes, when we worked with customers and whatnot, one of our mantras was frequent tangible working results, AKA working software. You can draw a lot and you can do use cases for nine months, but if you don't have anything running, it's pretty, I would guess risky that you don't have anything, no working software yet. So it really was I think an opportunity to share the fact that some people thought two weeks and other people thought a month. Even some of the print principles had a pretty good wide ranging flexibility so to speak. That I think is really important to note.

Amaar Iftikhar:

Yeah, no, absolutely. And it makes sense. Did you or anyone else in the room at that time ever imagine what the impact downstream would be of the work that was being done there?

Jon Kern:

Not that I'm aware of. I certainly did not. I remember a couple times in my career walking in and seeing some diagrams when I worked with the company Together Soft, and we'd build some cool stuff and I'd see people having some of the... Oh yeah, there's a diagram I remember making on their wall. That's kind of cool. But nothing near how humbling and sort of satisfying it is. Especially I would say when I'm in India or Columbia or Greece, it almost seems maybe they're more willing to be emotional about it. But people are, it's almost like they were freed by this document. And in some sense this is a really, really tiny saying it with the most humility possible. A little bit like the Declaration of Independence, and the fact that a handful of people... And the constitution of the United States. A handful of people met in a moment of time, never to be repeated again and created something that was dropped on the world so to speak, that unleashed, unleashed a tremendous amount of individual freedom and confidence to do things. And I think in a very small, similar fashion, that's what the manifesto did.

Amaar Iftikhar:

As you mentioned, there was a point in time when the manifesto was developed and that was almost over 20 years ago. So now the way of working, and the world of working has drastically changed. So what are your thoughts on that? Do you see another version coming? Do you think there are certain updates that need to be made? Do you think it's kind of a timeless document? I'd love to hear your thoughts on that.

Jon Kern:

Yeah, that's a good question. I personally think it's timeless and I welcome other people to create different documents. And they have. Alistair has The Heart of Agile, Josh Kerievsky's got Modern Agile.

There's a few variations of a theme and different things to reflect upon, which I think is great. Because I do believe, unlike the US Constitution, which built in a mechanism to amend itself, we didn't need that. And I believe it captured the essence of how humans work together to produce something of value. Mostly software, because that's what we came to practice from, is the software experience. But it doesn't take a lot of imagination to replace the word software with product or something like that and still apply much of the values that are there with very, very minor maybe adjustments because frequent tangible working results.

There might have to be models, because you're not going to build a skyscraper and tear it down and say, "Oh, that wasn't quite right," and build it again. But nonetheless, there are variations of how you can show some frequent results. So I think by and large it's timeless. And I would challenge anybody. What's wrong with it? Point out something that's somehow not true 20 years later. And I think that's the genius behind it was we stumbled on... And probably because most of us were object modelers, that's one of the things we're really good at, is distilling the essence of a system into the most critical pieces. That's kind of what modeling is all about. And so I think somehow innately, we got down to the core bits that make up what it is to produce software with people, process and tools. And we wrote it down. That's why I think it's timeless.

Amaar Iftikhar:

Yeah, no absolutely. I think that was a really good explanation about why it's timeless. I think one of the principles that comes to mind in a kind of modern hybrid or flexible working arrangement is one of the principles talks about the importance of face to face conversations. And in a world now where a lot of conversations aren't happening physically face to face, they might be happening on Zoom. Do you think that still applies?

Jon Kern:

Yeah, I think what we're finding out with... Remote was literally remote, so to speak, back 20 years ago. I was working with a team of developers in Russia and we had established enough trust and physical... I would travel there every month. So kind of established enough of a team, and enough trust in the communication that we could do ultimately some asynchronous work because different time zones. And me being in the east coast. 7:00 AM in the US was maybe 3:00 PM in Russia if I recall. St. Petersburg. So we were able to overcome the distance, but it's hard to beat real life. And I would often sometimes even spar a little bit with Ron Jeffries that on the one hand you could say the best that you can do is in person. But on the other hand, I could argue a little bit of some of the remoteness makes things... You have to be a little more verbose, possibly a little more precise, but also a little more verbose. A little more relaxed with... You might take a couple of passes to get something just because, I mean there are two time zones passing in the night. But that was based off of some often initial face to face meetings, and then you could go remote and still be successful and highly effective.

So I think it's important that teams don't just say that they can still do everything. And zoom is way better than 20 years ago, admittedly. Zoom gets, at least you can see a face. But nothing replaces the human contact. And I think also for wellbeing, I think human contact is important. So I would still say that the interaction aspect in the manifesto is still best served with a healthy dose of in-person. And that's kind of the key about most things in Agile. It's to me it's about pragmatism, and not just being dogmatic but rather, what might work better for us? And even experimenting with try something a little bit and see how that works. So even how you treat the manifesto, you should treat it in an Agile manner so to speak.

Amaar Iftikhar:

Yeah, no absolutely. That's a great point. On that note, as an Agile consultant or the Agile guy, what have you seen are the best practices or what works, what doesn't work for distributed teams?

Jon Kern:

Well I think the things that are most challenging that I've run across big companies and even smaller ones is that... I don't know if it's natural, God forbid if it's natural, but tendencies that I've seen in some companies to set up silos where you're the quality control, you're the UX, you're the front end, you're the back end, makes my headwater explode. Because that's building in a lag and building in communication roadblocks and building in cooperation which is handed offs from silo to silo, versus collaboration. So I've seen more of that. And I get it, you might want to have a specialty, but customer doesn't care. Customer wants something out the door. If I showed up and I'm going to pull a feature off the stack, what do you mean I can only do part of it? I don't get that. And yeah, I know I'm not an expert in everything but we probably have an expert that we can figure out what the pattern is. So I find that sort of trend, I don't know if it's a trend, but I find that's a step backwards in my opinion. And it's better to try to be more cross-functional, collaborative, everybody trying to work to get the feature out the door, not just trying to do your little part.

Amaar Iftikhar:

Yeah, a hundred percent. I think knocking on silos is a big part of being agile, or even being digital for that matter. And often the remedies for it too are there at hand, but it's a lot harder to actually be practical with it, to actually implement it in an organization, a living, breathing business where there's real people and there's dynamics to deal with, and there's policies and processes to follow. So I guess as generic as you can be, what is your thought as an Agile consultant to a business that's kind of facing that issue?

Jon Kern:

One of the things that... Adaptive is what my colleague John Turley has really opened my eyes to. I tend to call it the secret sauce, or the missing piece to my practice. And it has to do with individual's mindset and what we call vertical development. So it might sound like weird wishy-washy fluffy stuff, but it's actually super critical. And I've always said people, process, and tools for, I want to say since late nineties probably, I mean a long time. And the first I've been able to realize why sometimes I would have just spectacular super high performing teams and other times it'd be just really, really well performing but not always that spark and sometimes kind of like, eh, that was a little meh. And a lot of it comes down to where people lie on in terms of how they make their meaning and what their motivational orientation is, command and control versus autonomy.

So what we do is we've learned that we can help people first off recognize this exists, and help people with what we call developmental practices. Something that, even the phrase, you probably heard it, like safe experiments. Failure, or trying something and failing. Well if you chop someone's head off for it, guess what? They're just going to probably stay pretty still and only do what they're told, not try to... I have a super high dose of autonomy in me, so I've long lived by the, better to beg forgiveness than ask permission, and always felt as long as I'm trying to do the right thing to succeed and do the best for the company, they probably won't fire me if I make a mistake. But not everybody has that amount of freedom in the way they work. So you have to help establish that as management, and that's a big thing that we work with, with teams.

And then we also start with the class. If you've ever watched office space, and if you haven't you should, but the, what is it that you do here? So there's a great, the consultants Bob and Bob coming in, the efficiency consultants, "So Amaar, what is it that you do here?" But literally that's something, whether we're helping teams build a new product, is okay, what's the purpose? What's the business purpose of this product? What is it that you do here? What do you want to do with this product? What value does it provide? Same thing with anything you're working with as a team. And that's why whether it's software, producing some feature that has an outcome that provides value to the customer, or some product. But the point is if you don't understand that, now it's making, the team is going to have a real hard time being able to make decisions which are helping us move forward.

So if you help everybody understand what it is we're here to do, and then try to get the folks that might reflect all the different silos if you're siloed, but all the different elements. How do we go from an idea to cash, so to speak, or idea to value in the customer's hand? And have a good look at that. Because there are so many things that just sort of... Technical data often creeps into software code bases. And the same thing, we sort of say the organizational debt, the same thing can happen. Your process debt. You can just end up with, all right, we want the development team to go faster, John and company, can you come in and help coach us? We want to go agile. Sure, okay yeah. All right. We roll up our sleeves, we look around and after an initial kind of value stream look, like, wait I'm sorry but there's a little tiny wedge, it's about 15%, that's the development. And then you spent the 85% thinking about it.

Let's pretend we could double the speed of development. Which was initially the... Yeah, we need the developers to code faster or something. That's a classic. And no you don't, you need to stop doing all this bullshit up front that's just crazy ass big waterfall project-y stuff with multiple sign-offs. And matter of fact, one of the sign-offs, oh my gosh it only meets once a week, and then if you have a typo in it, you get rejected. You don't come back for another... Are you insane? You spent eight months deciding to do eight weeks worth of work. Sorry, it's not the eight weeks. So things like that, what I recommend anybody self inspect is try to... If you're worried about your team, how you can do better is just start trying to write down what does your process step look like and what is a typical time frame?

How much time are you putting value into the... Because a lot of times people batch things up in sprints. That's a batch, why are you putting things in a batch? Or they have giant issues. Well that's the big batch. So there's lots of often low hanging fruit. But to your point, it's often encrusted in, this is the way we work and nobody feels the ability to change or even to stop and look to see how are we working. So I think that's where we usually start is let's see how you actually work today. And then while we're doing that you can spill your guts, you can tell us all the things that hurt and that are painful and then we'll try to design a better way that we can move towards, in terms of working more effectively. Because our goal is to help teams be able to develop ways to do more meaningful and joyous work, really. Because it's a lot of fun when it's clicking and when you're on a good team and you're putting smiles on the customers' faces, it's hard to almost stay away from work because it's so much fun. But if it's not that, if it's drudgery and you're just a cog in the machine and stuff takes months to get out the door, it's a job. It's not that much fun.

Amaar Iftikhar:

Yeah. A lot of the points that you mentioned there strongly resonated with me, and the common pain points. It sounds like you've kind of seen it all. And by the way if you haven't seen office space, definitely need to watch it. It's a really good one. You've mentioned now a lot about of the element of the challenges that a distributed team faces. Now I want to flip it over and ask you what does the perfect distributed team look like today that lives and breathes agile values?

Jon Kern:

Yeah. I don't know if you can ever have such a thing, a perfect of any kind of team. So I would say harking back to the types of distributed teams that I've worked with, and this goes back to the late nineties. So I've been doing this for a long, long time. Only really done remote, whether it was with developers in Russia or down in North Carolina, or places like that. And I think that the secret was having a combination of in-person... If you want to go somewhere as a group, there are things you can do to break the ice, to establish some, what you might call team building type activities.

And not just, hey let's go do a high ropes course and be scared out of our wits together. But rather also things that are regarding why are we here, what are we trying to achieve? And let's talk about whether it's the product we're trying to build, and take that as an opportunity to coalesce around something and get enough meat on the bone, enough skeletons of what it might look like. Because there's good ways to start up and have a good foundation. And that's part of what I've been practicing for decades. If you get things set up properly with understanding that just enough requirements, understanding... And I do a lot of domain modeling with UML and things like that, just understanding what the problem domain is that we're trying to solve to achieve the goals we're looking for, have a sense of the architecture that we want. So all those things are collaborative efforts.

And so if you have enough of a starting point where you've worked together, you come in and, let's say you even had to go rent someplace, because nobody lived near office, so you all flew somewhere. I mean that's money well spent in my opinion. Because that starts the foundation. If you've broken bread so to speak, or drank some beers, or coded together and did stuff, and then you go back to your remote offices to take the next steps and then realize when you might need to meet again. So that's really important to understand that the value of establishing those relationships early on so that you can talk bluntly. And I have some good folks that I run a production app for firefighters since like 2006.

Amaar Iftikhar:

Yeah, very cool.

Jon Kern:

And that friend that I've worked with, we are so tight that we can... It makes our conversations, we don't have to beat around the bush, we don't have to worry about offending any, we just, boom, cut to the chase. Because we know we're not calling each other's kids ugly. We're just trying to get something done fast.

And building that kind of rapport takes time and effort and working together. And that's what I think a good successful distributed team, you need to come together every so often and build those relationships and know when you might need to come together again if something is a problem. But that I think is a key to success is it shortens the time. Because you may have heard of things like the group forms, if this is performance on the Y axis they form and they're at some performance level, then they need to storm before they get back to normal, and before they start high performing. So it's this form, storm. You get worse when you're storming. And storming means really understanding where we're at. When we argue about, I don't think that should be inheritance, Amaar. And then you're like, "Oh bull crap, it really..."

And again, we're not personal, but we're learning each other's sort of perspectives and we're learning how to have respectful debates and have some arguments, so to speak, to get to the better place. And I've worked in some companies that are afraid to storm, and it feels like you're never high performing.

Everyone's too polite. It's like, come on. And I love when I worked with my Russian colleagues. They didn't give a crap if I was one of the founders. And I'm glad, because I don't want any privilege, I don't want anything like that. No let's duke it out. May the best ideas win. That's where you want to get to. And if you can't get there because you don't have enough of a relationship, and you tend not to say the things that needed to be said because you're being polite, well it's going to take you really long to succeed. And that's a lot of money, and that's a lot of success, and people might leave.

So I think the important thing is if you're remote, that's okay, but sheer remote is a real challenge. And you have to somehow figure out, if you can't get together to learn how to form and storm, and build those bonds face to face, then you need to figure out how to do it over Zoom. Because you need to do it, because if you don't, if you never have words, then trust me, you're still not high performing.

Amaar Iftikhar:

Yeah, I kind of feel like being fully remote now is being offered as almost a competitive advantage to candidates in the marketplace now, because it's a fight for talent. But if I'm understanding correctly, what you are saying is that in-person element is so important to truly be high performing and those ideas kind of contradict each other, I feel.

Jon Kern:

Yeah. And again, having been remote since the late nineties, I've been doing this a long time. And commuting to Russia is the longest commute I ever did, for three years. I mean that's a hell of a long flight to commute there over seven times, or whatever the hell it was. Anyway, I used to say that that being remote is not for everyone, because it really isn't. I mean you have to know how to work without anybody around, and work. I mean it has its own challenges. And yeah, it might be a perk, but I think what you need to do is look at potentially what the perks are and figure out too, can I fold them into... It doesn't have to be all or nothing. And I think that can be a easy mistake to make maybe is to, all right cool, we don't have to have office space. That's a lot of savings for the company. Yeah, but maybe that means you need to have some remote workspaces for occasional gatherings, or figure it out.

But yeah, I think even... And certain businesses might work differently. In the beginning of building a product, I want to have heavy collaboration and I want to get to a point where it's almost, I feel like the product goes like this where once you get things rolling and you kind of get up, get some momentum going, now the hardest thing to do is be in front of an agile team, whether they're in-person or remote. Once things are rolling and rocking and kicking and it's like everything's clicking, you can just bang out features left, like boom, boom, boom. Yeah, okay then we probably need to be...

Unless we've got ways that we're pairing or things like that. I will say when we're together, mobbing is easier. I'm sure there's ways to do it remote, but being in a room, I don't know, it's a lot easier than coordinating over Zoom. You just, hey there's this problem, let's all hang out here after standup because we're just going to mob on this. So it doesn't take a whole lot versus anything remote, there's a little extra, okay, we've got to coordinate, and even different times zones, gets even worse. So yeah, don't get carried away with remote being the end all be all. Because I have a feeling there's going to be a... I would wager there will be a backlash.

Amaar Iftikhar:

And I'll take that back coming from the Agile, the person who does this day to day who helps teams become agile, I'll definitely kind of take your word for it. Plus with my experience too, I've seen nothing really beats a good white-boarding session. That is really hard to replicate online. I mean we have these amazing tools, but nothing quite mimics the real life experience of just having a plain whiteboard and a marker in your hand. That communication is so powerful.

Jon Kern:

Great point. You're so, right, because I had just with the one company that I was with for five years, we were doing high level engineered to order pump manufacturing sales type tool for... So it was my favorite world because it blended my fluid dynamics as an aerospace engineer, plus my love for building SaaS products, and building new software and things like that. And even having a young, we would interview at Lehigh University and we'd have some young graduates that would be working with us, and being able to bring them into the fold, and there was a room behind where my treadmill was and we'd go in there, we'd have jam sessions on modeling and building out new features. And man, you're right. Just that visceral three dimensional experience. Yeah, Miro's great. Or any other kind of tool, but yeah, it's not the same. You're absolutely right. That's a great point. You're almost making me pine for the good old days. [inaudible 00:42:04]

Amaar Iftikhar:

I think the good old days very much still exist. I think even now, it's kind of been a refreshing time for me to be with Easy Agile. I've only been here for just under two months now. And there's a strong in-person dynamic. And again, it's optional, where if people are remote or they're hybrid or they need to commute once in a while, it's a very understanding environment. But once you're in the office or you're in person, you kind of feel the effect you were describing, you're motivated to deliver for the end customer. You just want to come back. It's an addictive feeling of, I want to be back in person and I want to collaborate in real time in person.

Jon Kern:

That's beautifully said, because that's... One of the companies that we're beginning to engage with in South Africa, they're at this very crossroad of struggling with, everybody's been remote, but boy, the couple times we were together, got so much done. And you're describing the flame of, the warmth of delivering and let the moths come to the flame. I mean nurture it and then fan the flames of the good and let people opt in and enjoy it. And still sometimes, yeah, I got to say home, I got the kids or the dog, that's okay too. But giving the option I think is where we're going to head. And I believe the companies that are able to build that hybrid culture of accepting both, and neither mandating one nor the other, but building such a high performing team that basically encourages people to opt into the things that make the most sense at that time. And I think that those companies will rule the day, so to speak.

Amaar Iftikhar:

Yeah, absolutely. It's been so nice to chat with you John, and I've really enjoyed this. I want to leave the audience off with one piece of advice for distributed agile teams from you. We've talked a lot about the importance of in-person collaboration. We've talked about the principles of the agile manifesto. Now, what would the one piece of advice be when you're thinking of both? When you want the agile manifestos to be something that's living and breathing in distributed agile teams, what one piece of advice can you give businesses today right now who are going through the common struggles? What can you tell them as that last piece of advice?

Jon Kern:

Well, I think kind of a one phrase that I like to use to capture the manifesto is, "Mind the gap." In my sort of play on words, what I mean is the gap in time between taking an action and getting a response. Whether it's what do we do about the office, what do we do about remote, what do we do about this feature, what do we do about this line of code? The gap in time is, it's sort of a metaphor about being humble enough to treat things as a hypothesis. So don't be so damn sure of yourself one way or the other about the office or remote or distributed. But instead, treat things as a hypothesis. Be curious and experiment safely with different ways and see what works. And don't be afraid of change. It's not a life sentence to, you got to run your business or your project or your team one way for the rest of your life. No. Don't tell the boss, but work is subsidized learning. I never understood people who just keep doing the same thing because they weren't given permission. Just try it. So that's what my departing phrase would be regarding making those decisions. Mind the gap and really be humble about making assumptions, and test your hypotheses, and shorten the gap in time between taking actions and seeing a reaction.

Amaar Iftikhar:

Oh, that's awesome. Thank you. I really wish we could let the tape roll and just keep talking about this for a couple more hours, but we'll end it right there on that really good piece of advice that you've left the audience off with. Jon, thank you again for being on the podcast. And we've really, really enjoyed hearing you and learning from your experiences.

Jon Kern:

Oh, my pleasure. Any time. Happy to talk another couple hours, but maybe after some beers.

Amaar Iftikhar:

Yeah.

Jon Kern:

Except it's your morning, my evening. I'm going to have to work on that.

Amaar Iftikhar:

Yeah.

Jon Kern:

My pleasure, Amaar.