Project Teams Without Project Managers: Exploring The PM Dilemma

Read The Transcript:

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

Galen Low: Self-managing project teams. That phrase alone is enough to trigger an existential crisis in any project manager. But is it a threat to our existence? Or is it the key to elevating the project manager into a decidedly more strategic role?

If you've been ruminating on the future of project management and whether digital project managers will continue to be relevant, keep listening. We're going to be lifting the hood on how one organization is successfully building complex software solutions using distributed, self-managing squads and what that means for digital project management at large.

Thanks for tuning in, my name is Galen Low with the Digital Project Manager. We are a community of digital professionals on a mission to help each other get skilled, get confident, and get connected so that we can deliver projects with purpose and impact. If you want to hear more about that, head over to thedigitalprojectmanager.com.

Hey everyone — thanks for hanging out with us on the DPM podcast.

My guest today is an IT professional based in Kiev who has been pushing the envelope on business process management and digital product management for over 15 years. She's been a business analyst, she's been a PMO director, she's been a product director, a customer success director, working with brands like Heinz, Yandex, Adidas, and Zyxel to implement enterprise business systems at scale.

Today, she's a product manager at Railsware, working on the Coupler.io team where she oversees squads of remote, self-managing Agile teams that are creating highly-adopted products that are now household names, like Calendly.

Outside of work, she teaches business process and project management at Lviv Business School and is raising her new baby to be the next generation of women in tech.

Folks, please welcome Julia Ryzhkova. Hello, Julia!

Julia Ryzhkova: Hi! Hi everyone!

Galen Low: Thanks for joining us today. Thanks for our chats recently, I'm really excited about this episode today, because I think it digs in on something that we're all a little bit self-conscious about as project managers, which is — will project managers continue to exist?

So we'll get into that, but I just thought I'd ask you — how's life? What's been inspiring you lately?

Julia Ryzhkova: That's actually 2 different things. So if we are talking about something or Railsware related, that's a BRIDGeS framework. We open, that's kind of decision framework when you can, on a high level, describe your problem and then turn it into a solution.

We opened it recently and currently I'm involved in spreading a word-of-mouth about it. And that's a really great stuff and I'm really excited about it. So we crafted it for more than 15 years. Yeah, and this is like, you know, beginning of, for opening to public and that's really inspiring.

And from personal perspective, I'm also involved in as you mentioned, I'm working with Lviv’s business school and currently we are doing public online training course about the business processes and I hope that this will improve for overall maturity of business process culture of Ukraine.

And that's also inspiring.

Galen Low: I love that. Both of those things are very cool, great accomplishments. Congratulations!

If people wanted to learn more about BRIDGeS framework, where can they go?

Julia Ryzhkova: Railsware site, we have a dedicated sub-domain for it.

Galen Low: Awesome. Very cool. Very cool. And then, I mean, when we're recording this, it's December. We're about to exit 2021 or about to enter 2022, I'm just wondering — what are you most excited about in 2022?

Julia Ryzhkova: Oh, you know, everyone is currently talking about AI machine learning can know recently we had a meeting to discuss product visions of our products and knew we have this idea to use AI in my product, Coupler.io and I'm really keen on trying that and see how it goes.

Galen Low: So cool.

All right, let's get into it. So, today we're talking about how small squads of remote agile teams can manage themselves and self-organized into swarms to create complex software solutions without needing a project manager at any point. Is it a threat to us project managers? Is it an opportunity for project managers to be more strategic? Is it surfacing all of our listeners' existential angst?

Well, we're going to explore all of this in detail and we're going to lift the lid and really dig in.

But first of all, I wondered if you could maybe just tell us a little bit about your own career path. What is your role today and how did you get there?

Julia Ryzhkova: So today I'm a product manager, which means that I'm managing products development, marketing, pricing strategy, and sales force.

I have tech education, which helped me a lot computer science, but I actually didn't like coding, you know, and I when I was looking for careers opportunities, I was looking for something when you can create some algorithm, but let someone else to code it. And that is how I became a BA. Then they shaped the leadership skills became BA team leader, project manager, head of BA department.

But I noticed that results of my work really rely on the product that I'm working with. That is why I decided to switch to R&D as a product owner and be a part of the product. That was actually, you know, the first time when I felt at the right place. Then our product grew, team grew, we had more product owners and I became deputy product director with management of half of the scrum teams and they wanted to go farther.

And as we already had product director, then I decided to, and I still wanted to go to the board. I I became customer experience director and I was manage in support, everything related to services, support academy and so on and so forth. I managed to build their great processes and show great results.

That is why we decided to use these skills and build processes on that, in other departments and I became PMO director. Then maternity leave happened. And actually after I finished the, that important part of period of my life, I wanted to return to product management.

That was important decision and maybe you're wondering why product not project management? That's because I wanted to focus on benefits for customers while leaving process management somewhere outside. So that's the difference between product and project management for me there are a lot of similarities there.

However product managers can focus on most product and customer, and project management, they are focusing on a process and outcomes of it, right? So, here is when self-organized teams are crucial and that is why when I found the Railsware and I heard about it and read about it, I knew that it was a perfect fit.

Galen Low: I love that arc. I love the tech background. I love that you have the customer experience background, the PM team leadership. And I think that's probably a pretty inspiring for folks in our industry, for sure.

I'm wondering if you can tell me a little bit about Railsware, about the team structure that you oversee, maybe just the types of projects that Railsware tackles.

Julia Ryzhkova: So, yeah, let's start from the projects, because team structure depends on the project types we're working in. So we are product studio, which means that we are creating products for ourselves and for other companies. At Railsware, we like to automate everything, and sometimes we can't find some tool on market that actually will do some part of what we need.

That is when we decide that we can develop something for our our purposes, then we use it and then we launch it publicly and share with the market because we know that we're not the only one who needs that. That is why we usually start as a small team because we are looking for market team.

And sometimes it's even a part-time developer, for example, one of our product, the Smart Checklist for Jira, we launched the, it was developed to, part time by one developer and only after 50k MRR we just decided to allocate full-time developers there.

At small products, like Coupler.io, we have 1 development squad, which is four or five developers and 1 marketing squad, which is also four or five different specialists.

Everyone else is working part-time, like data analyst support manager even me as a product manager, I'm engaged in this product and the customer's products. But then product grew and as, for example, it was for Calendly we extend the development team and then divided into several squads because we believe that it is more efficient to work in a small squad.

So for example, Calendly currently has a three teams on our side and a lot of developers in their side. Yeah that's how it works.

Galen Low: That's really cool. I like, I really want to dig into this notion of squads and swarms. I like that marketing is a squad. I know I kind of framed it earlier as, you know, Agile teams, but Agile doesn't necessarily mean engineering or development.

It could mean a lot of different things, which I think we will get into. And I thought, maybe I'd just ask you — what is the biggest challenge that you face in your role today from a product development perspective?

Julia Ryzhkova: I guess it won't be surprised. The usual challenges every product manager has in a startup product that's — find your golden mine on the market.

So yes, we usually solve some pain of the customer and that is why our customer base is growing KPI's are growing and but we want to keep the pace and double it. That is why we need to find some other pain that customers are ready to pay double to get rid of it.

Galen Low: You are problem solvers. What I like about it is it sounds like, you know, you're solving problems for yourself and then radiating that outward to, you know, other people who have that problem. So it's kind of like an internal product that goes outward. And then you're also like a services organization, helping other organizations build the products of their dreams to get rid of that pain that they can't bear anymore.

That's very cool. Awesome.

So let's give our listeners their bearings. So in my circles, the folks that I talked to, the circles I travel in, the concept of self-managing teams is kind of a double-edged blade. Like on the one hand, most project managers want their teams to be independent so that work can get done without a PM becoming a bottleneck. But on the other hand, most project managers also wants to still be relevant and continue to have a job.

But the notion of project teams without project managers isn't really anything new, I suppose. So for example, in a Scrum Agile team, there isn't really mentioned of a project manager role. It's just a product owner, a scrum master, and the development team. So in a way, the writing has been on the wall for a little while, but we're still kind of trying to figure out what that writing says and who it applies to.

So, I mean, in some ways it is a threat. I mean, who needs project managers if project teams can manage themselves? But in other ways, it's actually project management nirvana, a lot of project managers talk about wanting to be more strategic and closer to the product, and closer to the customer, and less in the weeds with managing the work.

So, I guess the question is there a balance to be found? But I thought maybe we can start with a bit of an anchor points, our, our baseline. I'm wondering if you can explain how this notion of self-managing squads works at Railsware and on the Coupler.io team.

Julia Ryzhkova: That's actually, so the answer is bound to our concept of the developer's product mindset.

We made a separate webinar around that notion recently. So what this is about, we are looking for mature developers who are T-shaped, like I am, you mentioned that I have a lot of different experiences, so that's kind of the person we are looking for. And they can actually start working with customer as a developer PDM, PM during the MVP period.

We shaped our hiring process for ages to be able to find that kind of person, because obviously it's not easy. We onboard the talents in our internal products so before any developer can actually go to the customer product he spent some time on our internal product, just to hear the craft share approaches be able to develop this product mindset inside.

And then he can actually work with customer like all in one one-man orchestra. However like, the same is true about other roles right? Not only developers — each Railswarian (that is how we call each other here) can work separately. Most of us had the managerial experience or even manage their own businesses like, HR, designers product managers, of course that and others, so pretty much everyone.

However, none of us are the direct manager of the team and the way you become an authority is via "lead by example" principle. So you lead the product and that is how you show to the team that you are worth leading the team also. You can't just tell what should be done, you can, you just do your best to make an impact on the product and the, on the overall result, and that is how team trust you and start to do the same.

Galen Low: I really love that. I love, the the notion that the team, what you're prioritizing is a team that is T-shaped that's bringing a lot of different experience in. And I hear you, I would love to dig in later on the hiring and onboarding process.

But yes, that hiring process, not necessarily just for those engineering skills necessarily but that managerial experience, folks who have had their own business and run their own business and lead their own teams. That experience is rich and important, even though they're going into a role where it's actually quite flat on the team, which I think is really interesting.

We talked earlier about the fact that you have a project management background, you used to lead a PMO as someone who comes from that background, did you ever find this notion of self-managing teams a little bit off-putting or maybe even a little threatening?

Julia Ryzhkova: Yeah that's fun that you asked. I did actually, during the trial period here in Railsware. It is easy, you know, to evaluate your necessity to the company when you're the one hero and without you, everything spins out of control and you're safe for the day, each day you work. However, when things are great, even without you, you can't feel the impact the way you used to.

So you make some changes, implement a new process, make some improvement and things change, but a little. And yes, it is an improvement and your presence makes things better, but you feel that you can actually take 2 weeks' vacation and nothing is going to fall apart. And so, why do they need me then? However, at some point it happens that after a while you stop trying to control everything, and with all that free time that you have, you find different ways on how to make that impact.

You focus on product. You focus on customer. You focus on strategy and you can actually make even bigger impact with the time that you have. Even more, when you give the team more space, they can craft something incredible in the guild. So, we have this squad and squad is 4 engineers, 1 QA. However, we have guild engineers guild, the QA guild, product management guild.

And for example, product management guild build to that BRIDGeS framework that I mentioned at the beginning. It is impossible to build something like that if you don't have space to do that you think you need to do without any improvement. Oh, approvement, sorry.

Galen Low: I really like that. I mean, I think that's it's so key and everyone I've talked to, who's had like a great experience with a team, like their best projects have always been teams that are in some way, like independent or self-managing. Not necessarily cutting out the project manager in those scenarios, but actually just being empowered enough to kind of get direction and run with it. And I think a lot of the time as project managers, you know, we described the like micromanagy parts of it, as we all do, right?

We're herding cats, you know, we're making sure things get delivered, but really, I think it's about giving guidance and giving direction and inspiring a team and empowering them to do their best work. So in a way, it sounds like that's what that culture is. Not necessarily that, okay, well, we don't need Julia anymore and we can probably get rid of her.

It's actually, now we can lift Julia up or we can lift where we would have had a project manager. We can lift that up and be more strategic. And I really liked that in terms of like getting the team to feel independent and empowered. And then also just being able to take a vacation, right? It's like, I think that's huge.

And then I'm just wondering, I mean, I kind of see your role as now, I mean, because you're not, oh you know, you're not a project manager, you're a product manager. And in some ways you are a bit of like the conductor of the orchestra, I guess I kind of picture it. And...

Julia Ryzhkova: Yeah, you can say that.

Galen Low: So, do you still find yourself using any of your project management skills?

Like, do you think you've benefited from your project management background as a product manager?

Julia Ryzhkova: Sure, I do. So, I can't imagine that someone can be a product manager without any actually project management background. That's the crucial part of the fish. So, as I mentioned to, the technical background gave me benefit but project management skills are crucial for product manager as far as I can tell.

So, as a part of our skill metrics all senior roles at Railsware have project management skills, so that's crucial, like communication, that's same for us. We found them useful for overall result.

If we are talking about some specific skills, as far as I recall, PMBOK areas so what was there? I almost don't do integration and communication management, that's true, that's a part of self-management, otherwise it won't be called self-management. Right? But the scope, cost, schedule, and definitely the stakeholder management are still there.

So what else? Quality. Yeah, quality is a part of QA and engineer's area. I almost don't do that. Risk management is spread among all team members as long as procurement. So for example, if you need some something for work, you just create a purchase request and explain why do you need that?

I can't imagine how and most importantly, why I need to understand why we need this outreach tool for marketing, or that specific dev library. And that's cool that I don't do that.

Galen Low: I like that. I mean, I, what I really like is that you said all senior roles have project management skills. And I think, especially, you know, we sometimes take for granted yes, the scope, cost, and schedule, and then also the stakeholder management aspects of things.

Because you know, it's naturally part of a role, but it's actually or naturally it's part of business and getting things done in a sort of sustainable and responsible way. I mean, is that part of the hiring process or if there is someone entering a senior role, do they go and get some project management training?

Julia Ryzhkova: So when I'm talking about senior roles, I'm talking about also engineers and QA, so that's not about office managers, right? However for all roles there are contributing to products and the projects. They need to at least manage themselves — their scope, their schedule, their cost, their procurement, and that is something we are expected from from a person. That is why we're looking for mature developers and mature other team members.

If, so we do not expect to see some basic dedicated project management training or background or something. However, that's a, there is something everyone is doing without even realizing it. And we just, we can provide extend those skills, right? But do not teach them from zero.

Galen Low: I like that, and folks that know me know that I'm a huge proponent of that. I mean, as digital product and project managers, we have to learn so much about these crafts of the team around us. And I think a lot more can be done for us to share our craft with them as well, in terms of getting things done, managing ourselves, managing the collaboration aspect of things and being savvy about the business side.

And not that we're just building stuff for fun. We're building it for users, we're building it for customers. You know, we have our constraints and how can we operate responsibly within those constraints? I like that a lot.

All right. Let's double click on how all of this works and especially, let's double click and help folks who are listening, like if they're a part of an organization or if they're leading an organization or team that's exploring a model like this, let's talk about what they need to consider.

So the thing that strikes me is that clusters of small self-managing teams working together probably requires a lot of clearly defined processes and as you talked about, really solid onboarding. So, I'm just wondering — how do these squads communicate and stay aligned for one another?

Julia Ryzhkova: That's probably a part of the culture. So you when there were only two founders at the Railsware they defined processes, managed them as simple to-do lists, but still they did that, right? They had the structured approach and they documented everything. That is and obviously they were looking for someone to join their small company for people who are sharing the same culture. And this is not common for small companies.

Usually everyone is starting thinking about processes, only when you're, things are falling apart, resolve them and they hear it was not they started it right from the foundation. And that is why that became a part of the culture, right? So yes, we have a great onboarding as a process and also this principle "document as you go".

So any meeting can sync has a shared to some doc file or Figma board where everyone who is in this meeting is actually putting down notes before or during the meeting, not after. You know, that meeting minutes that you need to spend a lot of time to prepare after meeting is finished. We didn't do that. So we prepare notes before and if someone starting sharing something outside of that documented to things, everyone else is putting down that notes just to be sure that everything is there.

And that is why, like, after two weeks of vacation, I can just open a several documents read them. And I know what is, what was going on there. Where are we now without any additional synchronization, like, you know, tell me what was going on here. Do you need me? I see that. And nothing is left outside.

Also that's about, so that's a part of transparent culture, right? And as a part of that transparency or communication is done in the public channels, Slack channels, we have more than three hundreds of them, almost no private work conversations. So everything is raised publicly and everyone can just read that and maybe answer quicker than the person you're addressing this question to.

And you can just read the channel and understand what was going on during your absence or, or whatever.

Galen Low: That's very cool. And I think that's like part of what a lot of groups that I'm talking to are trying to master, right? This is kind of asynchronous kind of communication, where to your point, you could go and catch up on all the conversations, cause they're all there in front of you.

It sounds like Railsware was actually quite progressive from day one with those two founders, simple to do lists. It doesn't have to be anything extensive, just having it written down somewhere in a way that other people can understand.

I think it's really cool.

Julia Ryzhkova: Yeah, I admire this. So I used to teach on my business processes trainings that at some point of time you need business processes, but not necessarily from the beginning. So if you're a one person in your company and you know how to do things, you don't need them.

However, after getting familiar with the Railsware history, I decided to change that. And now I'm telling that you need to do that right from the beginning and it can be something pretty simple. It could be just checklist however you need to do that. Naturally, that's true.

So when you even doing some personal stuff, like, I dunno, you are you try to find new job, you create the list of companies and in each company you're going through funnels. So you need to put somewhere, where are you? What is the next step? So whether you send to that documentation or not, and that's also to do list and you need it, otherwise it's not manageable at all.

So I I started to think that you can't use you can't miss processes if you want to do business.

Galen Low: I like that. I'm just wondering, I thought, I wonder if we could touch on like metrics for the team.

I mean, in this model, I think a lot of our listeners are probably wondering, okay, well, what are the most important performance metrics to look for and to know that things are on track? You know, you've got this team kind of running on their own, it's a flat structure in terms of accountability. It's almost shared.

And you know, I think a lot of us in a project manager mindset will be like, okay, well, how do I know that things are going the way that we planned? How do you know that things are on track? What are you tracking?

Julia Ryzhkova: Yeah. Again, that's fun question. I do not track performance metrics at all. Maybe it sounds unrealistic or it is like it is. I track product metrics instead.

So, we are tracking how we grow whether our SaaS metrics are performing well. How, whether we have good conversion, good revenue, and forth. Okay, so actually I track team velocity, but not as a performance metric, right? So, I need to do that in order to predict what I can do within this release what I can do the next three months that as I mentioned, schedule management is still there.

So I track velocity and apply it to the future epics and estimations to receive a predicted earliest dates. However, when you deliver on production every day, or as a minimum, once in two weeks, it's, it is okay to see something two weeks later, you know. No one will die after another two weeks.

And that's that is when you decide that you can give more space to the team. Squads are doing, but squads are managing their performance, right? How do they do that? They're doing pair programming with newbies cross-testing, code review. So they track their own performance and clearly articulate to each other what needs to be improved.

And I see that. So, during stand ups, during great retrospective, you know, that stigma that stakeholders and even product owners should join the development team retrospective. We don't have that. So I was involved in the retrospective for right from the beginning, and we involve customer to our retrospective. And team shared though that inputs about each other performance clearly and transparently.

So this feedback culture is really on a high level and any newbie receives feedback from all team members, and anyone can point out the performance problem, some quality problem, as well as a newbie itself can share some own feedback about our processes, about company, about me as product manager, how can I improve myself.

And therefore, like there is only, there are only two options. You can either do not pass trial or you're performing great and we don't need to check performance anymore.

Galen Low: Very interesting. Can that get intense at times?

Julia Ryzhkova: It could be. Actually but usually everyone is aligned.

So, if someone sees some problem, everyone sees it and we shared this feedback and the it's, it, I didn't see any problems there, like, you know, is a problem, problem.

Galen Low: And I mean, and to your point, it's like, it's baked into the culture and it's baked into how you are hiring for your teams. You're bringing on folks who are in a way, already already thinking this way, already ready to have these conversations and grow as a team and provide feedback and share feedback and receive feedback so that the team performs well in that flat structure.

Julia Ryzhkova: Yeah, that's actually is something that we check during the hiring process. So we have, we spend a lot of time and we invest a lot of time in that.

We, for example, for product managers who have full day allocated when we collaborate together on some problem eight hours of, for pair working with product managers and you this product manager is doing something and you share a feedback and you see how a person reacts to it. That's a huge investment from a company's perspective because a C, a C level, one C-level executive and one product manager spend the full day to do that decision.

And it's a lot of efforts from candidates, right? So you don't receive any offer before you actually allocate full day of your time to pass this process. But it, the result is great, you know. They feel us and they understand whether we have culture fit and we feel them not only from technical ground perspective, but also how how we give feedback, how they hear feedback, how we react to, whether we have same sense of humor.

And so, that's a pretty cool results based on that part of our hiring process. And yes, as a result, we receive people who are who can be a part of that feedback culture.

Galen Low: I like that because I think there's a lot of, like in, in, in current hiring practices, I think there's a lot of these kind of arbitrary tests, right? But what really shows that you're invested in getting the right, you know, fit or culture add for your team is that yeah, you do have a product manager and a C-level execs spending like a day or two to actually spend time and do work with the candidates to really make sure that working dynamic is going to like it was going to pan out.

So I think that is, is huge. I know not every, some people are listening going, wow, we really couldn't do that because of the way we're structured. But when you have to be sure about the people, that's a great way to do it. It's...

Julia Ryzhkova: That's actually, so that's how you can for candidate, we explained that it's an investment from their side also they do not invest three months to go through trial period and understand that's not company they can actually work in, you know? And that makes sense. From our perspective, we don't do that with all roles, right? We have this kind of collaborations for any role, but not full day.

It can be two hours, four hours, depending on the role. However, we still need that to fill each other.

Galen Low: Yeah. Yeah. That makes sense. I like that. One thing you mentioned earlier is that, okay, well, you know, if we are trying to deliver something in two weeks and it gets pushed out by two weeks, you know, nobody's going to die necessarily, but I'm wondering as a product manager, you're sort of managing the product roadmap, you're making promises to customers on features, I'm just wondering — what happens when things change?

What happens when you update the product roadmap or when you reprioritize the backlog or when you change the delivery date? Like what are the team behaviors that you want your teams to have when they're faced with change?

Julia Ryzhkova: Probably you will be surprised, again, but actually nothing happens. So we I can take something out of sprints called, bring something some other task, explain why give a context so for example we needed to, or right now and we just discuss it and that's it. So I can change backlog even in the middle of the sprint and we do not stop it if it's if it's just one or two tasks or whatever.

We just plan meeting to discuss what needs to be done provide estimation session and then everyone syncs and that's it. I don't do a big changes in roadmap so frequently. I usually revise it once a month to update with new insights, new metrics whatever I have seen in our dashboards to be included there.

And the team is actually aware about that, they aware about product vision. They are engaged into the strategy syncs with the C-level executives to share from technical perspective whether we need to rethink something or change some our priorities they even share, so, that's my favorite story.

When we changed the pricing model one of our engineers shared the information about one of the systems who are integrating with with a lot of customers. So we receive from from them that they also changed their pricing model and now our pricing and there are not consistent. And we need probably to, to include this somehow.

And maybe rethink our limits to include that information. And that was amazing, like, you know, we're discussing pricing model and that is input from engineer. That's awesome. I didn't expect it at all. And that's the team I'm working, right? Always and team is okay with any changes, like, for example first, during the first six months of my work here, I changed the, to a project management tool three times.

From, we moved from Trello to Coda, from Coda then to Pivotal Tracker and then to JIRA until I found the two that actually can cover all our needs. And they were like, okay, do you need our help in that? Or just give us 15 minutes training about new tool and that's it?

That sounds amazing, but that, that is why I'm so inspired about them.

Galen Low: Yeah, it really does sound amazing. I mean, especially changing project management software, I know that can be like pulling teeth for a lot of folks and people really like anchor to this stability of what at least I know my tool. But I think that really highlights for me is like, you know, when you talk you spoke earlier about finding people with a product mindset, even at the engineering level, even at the design level, even at the marketing level.

And I, you if we were to kind of start unpacking what that means I think it is that business the business mindset as well you mentioned, as long as you go and explain to them why it's changing, why we need to change the pricing model, why this feature is more important than the other, then they're a team that really is wired to understand that and go, okay, it sounds like that is the best thing for our customer or the end user or a business for our product in general. And as a result, it's not just like, oh, but I was already halfway through making that thing. It's actually like, no, this is for the greater good.

And you know what, product is change. And I think that's what's really coming through in this conversation is that, yeah, sometimes, I'd even argue that sometimes with projects in project management, you know, there is this tendency to try and achieve stable perfection. And I think a lot of folks think that, thinks that's what their job is.

Or it's actually what the job is both on project and product side is to respond to change, is to look ahead, right? You need, right? Like things like velocity to plan and make a bet on the future. You do need to, you know, be organized and communicate effectively and have scope but things will change, right?

And things are always changing and in this world, you know, we can't just rely on the fact that a plan we made six months ago is, you know, perfectly fine and absolutely accurate, six months later it's actually about how we respond to change and how our teams respond to change that really helps us be successful.

Julia Ryzhkova: One more thing. So while you were talking, I was recalling my recent conversation with one of the developers so he said to me that he actually felt this stability based on that we actually have backlog for next several sprints. However, he doesn't care if it changes, like completely. So he just know that I have something and he sees that.

So I have four in JIRA sprints three, four sprints for the future and they are back to fully with some tasks and they don't even care what is zero. So they look at their roadmap, they know the vision and they need to understand that we also know the vision and we share with them that on the high level we're going to do in next year and next several years, something like that is where we go.

However, it doesn't matter for example, how exactly we're going to go there. And having fully backlog back through these tasks, we just discuss them on the grooming right before the start of the sprint, but they know that I have something and that fulfills that a necessity of some stability and safeness.

Galen Low: Yeah, no, I think that's like a trust through transparency I think is really strong in terms of what you're talking about, where it's like, well, we shared with them, like the vision. We've shared with them, you know, the plan. We're letting them in. They're not just a set of hands that are doing the work.

They're part of the overall team, the product team that is actually navigating this. And that builds that trust to say, well, as long as there's stuff in the backlog, and I've seen the product roadmap, I know where we're heading that gives the team, you know, enough direction to be independent, self-sufficient and have that feeling of stability. I think that's very cool.

Oh, one thing I wanted to return to, it was, you know, we've been talking about this notion of, you know, the backlog and pivoting mid sprints. And yes, we can change things we're measuring velocity. I think some of our listeners will be like, okay, well, we're talking about Agile software development here.

And of course, some of those things are going to work. Some of them are flexible enough, but in your opinion, does this only work with agile software development, or do you feel that this model could be used by any cross-functional teams creating any sort of product?

Julia Ryzhkova: So one thing you need to be Agile for sure, but the Agile the, from Agile manifesto, you know, and it doesn't tell you that you should actually create the software, right?

So all our squads are similar use similar approaches. So marketing squad, finance squad, operations I have taught them how to estimate. We do grooming, we do roadmap management where estimating HR projects, we story points and plan and track velocity, and they actually use that to manage their processes. And that's, that is something everyone can can use.

Galen Low: I think that could be a whole another podcast episode, because I know a lot of folks listening are going, oh, I wish my marketing team was Agile working from a backlog, working in sprints. I know we're getting there on, on a lot of teams in a lot of organizations, but I still know that's an area of resistance, you know, non-development and non-design teams.

You know, sometimes they just think Agile is not for them. They work in a different way, but you know, I think it's worth challenging in any organization to see, because what you're talking about is being nimble, right? It's like being Agile and being nimble on being able to react to change, which I think any department or any team in any organization can benefit from.

Julia Ryzhkova: As you mentioned, so for example, yeah, engineering team is working on Scrum as well as a design team. However, for example, marketing are working on Kanban, so they have roadmap Kanban board and that's that's used better. However all of that are Agile approaches, right?

Galen Low: No, absolutely. No. That makes sense, because in some ways it's like operational and ongoing. That's really neat.

All right. Let's dive into the juicy stuff, because there's some implications here that we're kind of walking around and I know that our listeners will have questions. So I think that a lot of the folks having this conversation about like project manager led projects versus self managing teams, they'll put one or the other on a bit of a pedestal, but I think we all know that like no model is perfect.

So I thought for the benefit of the folks listening who are like considering moving to this model, and I think it's going to be easy and perfect, it's going to be this utopia. I thought that I'd ask, well, when things go wrong in this model, what are those things that go wrong?

Julia Ryzhkova: Tricky question. I guess, so we have this high level problems.

So what I mean, so a squad is not always aware of what is going on in the inside the other squad, right? So for example we have two products our own products, Mailtrap and Coupler.io are my product. While Coupler.io dev team developed a lot of new features that our small marketing team wasn't able to cover by content and landing to spread the a word among the market.

In Mailtrap where things were going vice versa. So, there is when actually management decided to switch teams and allocate part of marketing team from Mailtrap to Coupler.io, and part of engineering team from Coupler.io to Mailtrap to boost each of that products. And those kind of decisions is not possible to do inside the squad because they do not see the high level picture and you still need to make company-wide decisions by management.

Galen Low: That's fair. And then in terms of the individuals making that decision, cause I agree. It's sometimes you need to be able to have that perspective outside of a squad in order to understand how things can be reallocated or redistributed. Is that typically part of your role? Is that someone in an ops role?

Julia Ryzhkova: That's actually a kind of C-level role, I would say because so I'm, I am aware about my product and I share during some strategical syncs there, we are ahead a lot in development and I need more marketing resources. And the same is done by Mailtrap so a product manager who is a talent that they are ahead of marketing and they need more development resources.

And as the C-levels are not engaged into any micromanagement. So the only here the, this kind of stuff for once a month they can, they are free to make the decision, right? They are not overwhelmed with any kind of details and they can see it clearly. Yeah, okay guys, switch teams. Go ahead.

Galen Low: And then was that a permanent change? Did it introduce the notion of like people being shared between squads or was it more just a temporary thing just to deal with the capacity side of things?

Julia Ryzhkova: That's a camp thing I would say so, but there are two options, right? How to end this. You can either hire from market, new developers like the Coupler.io and a new marketing members to Mailtrap, or you can switch team back.

Currently we're doing some, mix of that I would say, but we didn't finish what we need to do as for now, and we're still working on that change the change teams. But we are okay with that. I mean, we're Agile, as I mentioned, and if we are okay with changing to three, three tools within half a year team is okay to be relocated to another product for half a year, even for a year. That's not a problem.

Galen Low: And I think it even comes down to root cause. I know I took it in a direction of staffing, but root cause is actually what you started saying, which is that the squads need to be aligned, right? So as long as the squads are aligned and the marketing team isn't, you know, gearing up to promote a bunch of features that won't be ready or the opposite where there's lots of features that have been developed in the marketing team can't keep up.

I think the root cause and the problem, probably the place to solve the problem is going to be about kind of alignment between squads. And do the squads, like for example, the marketing squad and the engineering squad on something like a Coupler.io, like how often are they talking to one another?

Julia Ryzhkova: It depends. So we surely have for demo where when engineering team is demonstrating what has been done for the previous iteration and what we are going to release. We have a weekly synchronization when I share what we are working on and what, what is going to be released in the nearest iteration.

Was there a need to update somehow lending stories, or we need to publish release notes. So what should be done from marketing perspectives? They just put that in the shortlist to include so they have the global roadmap, right? Some big marketing projects and some part of their capacities are spending on supporting career development team and same for the development team. Right?

So we have this input management process. Anyone from the team can create some input to, to be included in anyone's backlog, and we'll review them once a week.

If they are not aligned with vision, we put in icebox if they are not prioritized and we include them in the roadmap.

In the nearest sprint for example, or in the next one just to improve things somehow. And that is how teams are aligned. So marketing team can create some inputs like, Hey, let's change our design of our website or let's improve somehow over landing templates or whatever. And we include that into the development and vice versa from the development team.

Any developer can create an input that I need to this email template, for example, to be included as the part of the development of the application, we need to send an email and I need the template. I need the nice copy, nice template please provide me with that. And that's how it works.

Galen Low: That's really cool. I really like that. One thing that we haven't talked about a lot, but it's implicit and how we started this out is geographies, time zone differences. So you've got squads of team members who are actually distributed across geographies and across time zones. In fact, they're all over the world.

I'm just wondering for folks, you know, who are really trying to nail this like global workforce thing, are there actually some inefficiencies that need to be compensated for using like this like, do you have to be hyper efficient in order to actually become efficient with a distributed team or is it kind of a non-issue in your perspective?

Julia Ryzhkova: I would say it's vice versa. I mean, remote work allows you to spend more time and be more efficient. Of course it's, sometimes it's hard to have a call when you have a developer from Argentina and product manager from Thailand. Yeah and you need to adjust your work and schedule to have the ability to synchronize with others in convenient way.

However, probably that's the only issue I can think about.

Most part of our team is working remotely, like more than 80% I would say. From more than 15 countries but all of the processes and that stuff like shared documents public channels it allows actually to organize that greatly pretty well.

So you don't need, as we are working and communicating asynchronously, you don't need too much time to plan meetings, online meetings on international schedules.

Galen Low: I love that and I think that is, it provides a bit of a important distinction on two things. One, asynchronous work doesn't mean don't meet ever, right?

You can stop the meeting and - to your point, which I think is huge. And I think that people don't really realize because, you know, in some ways we are self-centric or like, oh, it's so hard to schedule a meeting with my designer in the Philippines - sometimes it means that you have to be flexible with your schedule as well, and maybe it's outside of your normal business hours to have that meeting, which also makes sure that it's an important meeting to have.

But in other words, asynchronous doesn't mean no synchronous communication ever. And then I like the other thing, which is that, you know, I think during the pandemic we've blurred remote work and work from home, but they're not the same thing. You can still be working remotely. You can have a remote team and you can still be in an office.

And I think what you said earlier, right? Is that documentation and that culture of transparency is key, which means that you don't necessarily need to have tons of meetings that require all this scheduling that's gonna make people inefficient. It's actually about having the paper trail in some way, shape or form that everyone can kind of access this like ledger of communication that makes it actually really work.

I'm also wondering, I'm wondering if in these self-managing teams — is project management a bit of a bit of a stigma with these teams, like, are they kind of averse to having a project manager?

They're like, actually that is not something that we ever needed and we don't need to be managed. And how dare you even consider that, you know, project management is a thing that we need. We are just, you know, a team collaborating, like, is it a dirty word? Project management?

Julia Ryzhkova: Okay. So I don't think that there is anything that I can call stigma here.

As I mentioned, we love to experiment. Also there is no obligation to do anything. I don't think they need actually to go through full PM training. So we prefer to share some important stuff during guild syncs as a part of craft shaping. So as I mentioned, I did training for operational team, how to estimate, how, what is story points or I can share some Kanban or scrum basics wisdom.

It is okay if you need, like, if you feel that you need some basic PM training, you can take this educational budget and go through on. However, we think that it is more efficient to share some part of knowledge right when it is needed.

Galen Low: I like that. It's like, yeah, sharing bits of the craft, not necessarily, you know, trying to make project managers with people, just like project managers wouldn't try to become engineers necessarily, but what are the skills that help us all work together and deliver really good work.

I like that. I thought I'd land out on the big question. The big question is — as someone who was a project manager and who led a PMO, but is now enabled to be arguably a much more strategic role as a product manager, do you see self-managing squads as the future of project management, like across the board?

Julia Ryzhkova: I guess it's the future of successful product companies, for sure.

So self-managing teams allow project managers to focus efforts on strategy, on product, on customer, as I mentioned, and it is here when you can actually finally reach the nirvana of being able to work with the "important, not urgent" part of tasks.

And you know, that usually you don't have time to do that, right? While the team is doing their best to clean up the "urgent, not important" that is usually taken a lot of efforts and time of project managers. However, you can't expect that all of people around are going to be self-managed especially right after their graduation and at the beginning of their career paths, right?

So junior experts require not only mentoring and coaching for sure that they just need direct people, classical management at the beginning. And there's also a specific type of people who can't set up deadlines for themselves. And at the same time they cannot work effective without that deadlines. And it can be true even for senior technical-level experts.

So there will always be a space for classic project management.

Nevertheless yes, I believe that every company or team that would like to receive some outstanding results in product they should reach the point when self-management will displace direct project management and therefore free project manager time for strategy and improving the processes in general, rather than fixing every specific problem.

Galen Low: Awesome. I like that. And I love that like urgent versus important. I think that's the complaint I hear so much from project managers who are doing yeah, more of a classic project management role where they feel bogged down and they want to be more strategic. And I think the answer is actually, you know, the people you have on your team and the culture that you instill and yes, some of the processes that you instill to empower that team can free you up.

And it doesn't mean you're out of a job. It actually means you can probably do something a little bit more strategic, the important stuff and not necessarily the urgent stuff which might be taking care of...

Julia Ryzhkova: Project management is also important stuff, right? So I can be less project manager as they used to be because I'm working with self-management team, however with other type of teams, it, the, so the main role of project manager is getting things done, right?

So he's responsible that project will be finished with within the schedule and within the budget. That's that's the main goal, right? Those are all. And it was all self-management team, you can't receive that. Therefore it's crucial. However, when you do have that self-management team, you can actually get things done without so deep involvement and you can think what needs to be done rather than trying to figure out how it should be.

Galen Low: I like it. Elevate it and be proactive.

Julia, these insights are all super valuable. I think the one that really resonated with me is just this notion of a product mindset. I don't know if I was thinking about it right beforehand, or I was thinking, oh, a product mindset thinking about, you know, like product, like an ongoing life cycle, you know, releases, et cetera, et cetera.

But really what it is actually this sort of adaptability, it's this sort of openness to change because our modern understanding of a product is not that you create something and it stays that way, but that it's driven by end-users. It's driven by customers. It's driven by the market and all of those things change constantly.

And actually, the product mindset is not necessarily about you the capacity to think about a product, but also the capacity to respond to change and be Agile and be nimble and be okay with it because you're understanding the why not necessarily that things are changing and it's being done to you, but it's important that if you want this product to be the best thing that could possibly be, we need to pay attention to some of these signals that are always changing.

And that's going to mean your job is going to change. The backlog is going to change. Your release schedule is going to change, your project management tools are going to change maybe three times in a year. But that is the thing that we mean with a product mindset. And it's so important for a team that is going to be self-managing to have those qualities so that they can adapt to change and evolve the products in a dynamic way, in an Agile way, in a nimble way.

One last question for you. What advice would you give to an organization that is trying to move towards small self-managing teams?

Julia Ryzhkova: Probably like do not try, just do. Start from one team, from small team. However, start. Do not try to implement this approach to your whole organization if you have a large one, right?

Gather your best people, give them authority they need and ensure results, because they will come there is those results. When you see the benefits, you do whatever it takes to transfer this approach to the whole company, because you need success. And in order to receive that success, you need to try and you need to try with the people that best fits that picture that I just describe.

Galen Low: That's awesome. Julia, thanks for, thanks so much for joining us today. I really enjoyed our conversation. I think it's fascinating learning about how your organization has tackled this problem, how your self-managing squads are working, how the whole Agile process is working in terms of developing products in your product studio.

I think our listeners, I hope our listeners have learned a lot and I think it's probably inspired some ideas of how their teams can get more towards self managing sort of self-managing culture without the sort of underlying threat that maybe project managers will no longer exist in the future. But it's been very interesting.

We'd love to have you back to talk more about how some of these things are shaping up and we'd love to hear more about how AI is going to work its way into the Coupler.io product, but more on that...

Julia Ryzhkova: Hope I will be able to share with you this whole insights.

Galen Low: It's very cool. It's very cool. Awesome. Thanks again.

Julia Ryzhkova: Thank you. Yeah, it was really nice to talk and share because those, all of that part are inspired me a lot, and I hope that this will inspire someone else to do the same stuff and enjoy the results.

Galen Low: Amazing. Thanks again.

Julia Ryzhkova: Thank you.

Galen Low: So what do you think? Are self-managing teams the way of the future, or do they have limitations that make them unsuitable for certain types of organizations and industries?

Tell us a story. What is the most self-managing project team that you've worked with and how did it go? On the other hand, what has been your most frustrating experience with having to herd cats instead of being strategic? Tell us your thoughts in the comments below.

And if you want to hone your skills as a strategic project leader, come and join our collective!

Head over to thedigitalprojectmanager.com/membership to get access to a supportive community that shares knowledge, solves complex challenges, and shapes the future of our craft — together.

From robust templates and monthly training sessions that save you time and energy, to the peer-support offered through our discussion forum, community events, and mastermind groups, being a member of our community means having over a thousand people in your corner as you navigate your career in digital project delivery.

And if you like what you heard today, please subscribe and stay in touch at thedigitalprojectmanager.com

Until next time, thanks for listening.