Las Vegas 2019

Shift Happens - Do You Have the Right Team for Managing Work by Product

Do new ways of working have you wondering how to structure your IT teams? As more organizations start managing work by product, some long-standing roles will become less important -- and others will become mission critical.


In this talk, you'll learn which roles are at risk and three new roles to consider for your IT organization. You'll also learn a useful tool that helps you hire for these new roles -- by starting with your own people.


Dominica DeGrandis is the foremost expert in Kanban Flow within the IT industry today. Her work shows technology and business organizations how to optimize workflow across value stream networks. Her passion involves the use of visual cues and transparency across teams and organizations to reveal mutually critical information. Dominica is a regular speaker at global DevOps and Lean events and has recently published her first book: Making Work Visible: Exposing Time Theft to Optimize Work & Flow. Along with being a sought-after speaker at industry conferences, Dominica writes articles for industry publications such as Cutter IT and TechBeacon.

DD

Dominica DeGrandis

Director, Digital Transformation, Tasktop

Transcript

00:00:02

This talk comes in response to many people asking questions about how should they organize their teams when they're moving to a product centric way of working and it questions revolve around what roles do we need, what skills do we need? You know, what kind of knowledge do we need to bring to the team? And as I've been working with these large enterprises, as they start this journey and go through this transformation, I'm, it's just become evident that there's new roles that are emerging out there to help make it run smoother and faster and all around easier. And that's what this talk is about today.

00:00:41

So I spent a good amount of time facilitating exercises and designing experiments to improve flow, to enable change, right? Nothing provokes a good conversation. Then putting some data up there and having people try to prove it or not. And that's what I do in my new role. Now, as principal flow engineer at Tasktop flow adviser at Tasktop oh, the engineer stuck in there. Didn't so the project of product movement is clearly cooking about half the talks that does London in June, mentioned it in some fashion one way or another, the project, a product pivot, it's becoming a movement and it's a movement that's useful to transform the way that organizations work. And it's one that CEO's are see are starting to see as critical to their success. But what does project a product really mean? There's this fantastic book that Mik Kersten wrote on the topic, but I'm going to give you my 92nd summary of the takeaways. And the first one is that the product team's job is to create business value and by value. I mean, whatever it is that makes your company successful, right? It might be profit might be revenue might be risk reduction might be the number of lives saved. You know, Mark Schwartz wrote this book called the art of business value that goes into every detail about what value means. So you can dive deep in there, but to me, it's whatever matters to your company.

00:02:17

And so this is very different than optimizing for scope, budget, and schedule the way that project centric work projects are managed. Second up is that with products, work is brought to cross-functional teams that stay together over the long haul, right? They're not split up to go work on another short-lived project. Once a, a bit of functionality has been delivered. And lastly, but maybe most importantly, is that shifting your thinking from project to product allows you to shift your thinking on your cost centers. When you move from project to product, you move from cost center, thinking to product center, to profit center, thinking where the teams that actually build and deliver and deploy and maintain the product can be invested in. So there's an investment there. There's a couple of other good reasons for the shift. Here's two of my favorites. Uh, one is that there's fewer dependencies from pure conflicting priorities.

00:03:19

And two is that the focus is on business outcomes and not activities. Our activities essentially involve counting. So let's look at this because projects come and go. You've got a relatively big batch of work that gets handed off to a different team and they need to sustain it while the project, the previous project folks run off to work on another project that they were probably supposed to start working on two weeks ago. And unless there's really good documentation that handoff isn't smooth or the details tend to get lost. Raise your hand if you receive really good documentation when you're handed off work. Yeah. Okay. So now people are wondering where do I find the configuration settings? And they have to go interrupt the previous project people to get that information in there. And there's a lot of interruptions that occur, you know, should I work on the old project or the new project where what's my production supposed to be?

00:04:19

And so then you have three out of the five thieves trolling you after projects get handed off because of context, switching, unplanned, work, conflicting priorities and invisible dependencies. When you manage work by product, you can get to, you get to keep that domain knowledge in house because you keep the team together, right? It's not handed off. There's fewer dependencies. I'm not saying we're going to get rid of all the dependencies, but we can reduce some of the most costly coordination type of dependencies and keep in mind, every dependency reduces the risk of starting something late or finishing something late by 50%. So with projects, people are brought to the work, right? They're treated sort of like fungible interchangeable resources versus on when you bring the work to the people, the people, you know, they're treated as knowledgeable workers with their expertise and you know exactly who to bring the work to. You bring it to the product teams, the product group, they have the expertise needed to modify and maintain the product.

00:05:30

Next step product teams live and die by generating business value, right? And as such, we measure product value streams by business outcomes. When you make value visible, it's going to provoke these necessary conversations for change. And from a visibility perspective, the metrics that we capture for a product value streams, focus on what really matters and that's the business needs. They need to go fast. They need to deliver it so that it works right, and they need to not burn their teams out wide while doing that right. We need to maintain sustainable work so that people can remain happy. Versus if you look at the red, yellow, green report, it represents opinions. I think it's a, I don't want to get yelled at opinion, too. I used to work in, I did a stint at a PMO for a very large telecom. I was a project manager and I once submitted a project report that had red in it, a VP promptly called me into the, you know, the office and embarrassed me, or, you know, pretty much shamed me in front of a lot of other leaders saying that it really wasn't red. And that's why they call these watermelon reports because a lot of people know they're red on the outside, on the inside, but green on the outside. Right.

00:06:53

So did I mark another project deport red again? No, I updated my resume and I think there's a lot of change happening in PMO with the way things are getting reported. I mean, we do still see a lot of red, yellow, green reports, but I was doing a talk at an event just last week and there were a couple of project managers there and they voiced a concern, a feeling like their jobs were at risk, right? It's sort of like PMO is walking through a minefield having to justify their value. And I was just talking to somebody this morning, who said they were talking with their director or senior director of their program management office, who is terrified, right. That those teams are terrified of losing their jobs with this new shift from project to product. And I can surely empathize with that because my job went away.

00:07:47

I think the writing was on the wall back in 2006, 2007, 2008, as the build and release team, you know, we were pretty much automating our way out of work. We're automating builds, we're automating deployments and our releases are smaller. And so, and you know, we had consumed a lot of our time with branch and merge strategies and our configuration management tools, and that was starting to go away and that expertise was no longer needed. I think this is the nature of working in technology, right? We constantly have to reinvent ourselves as jobs change as evidence here by this world, economic forum chart about the future of jobs surveys. And it shows how new technology changes the job market. So if you're a PM, are you have PMs and project manager, or you have project managers that report to you, what are you seeing? Do you see fearful, nervous people updating their resumes.

00:08:48

But if we do look at roles, they come and go, you know, the full stack engineer roles only been around for about what 10 years. And according to this stack overflow survey developers who consider themselves full stack engineers has doubled over the last six years. Right? But now that seems to be changing. There's a new white paper that was just published on it, that I was delighted and honored to be part of on why the full stack engineer role can be problematic. What we found was that, um, you know, the probability of finding people who actually have knowledge of the entire stack is not very high. And when you do find them, they have no availability because they're all at Netflix. So cognitively we, you know, we know the human brain just can't do it all at the same time physicians, they don't have all the knowledge and experience that you need that is needed to know everything there is about the human body, right?

00:09:54

You have to go see a specialist, a medical specialist, you know, do developers really know everything there is to know about today's stacks in a large enterprise. So that guidance from the paper basically is, you know, we need, we need better cross team communication and just avoid making one person responsible for everything. So what does this mean for the PMO? Remember the whole point of project to product is to improve business value. And so it makes sense then that if you're going to transition from a scope based outcome to a value based outcome, that PMO would transitioned to effectively optimize business outcomes at the program level. And so we're starting to see organizations, their PMO is transitioning into a VML, a value management office value management organization. You know, PMO can be part of this shift, right? Because they bring strong business relationships, business knowledge to the table, and they've got skills that transfer over. They've got skill, you know, they know vendor management, they know risk management, cost management, revenue management, these skills make a difference. And I think they can be applied in a product model. That's focused on driving value.

00:11:14

Kristin bid off has a talk out there on making product work, making work product centric upon YouTube, where she talks a bit about their journey and how they sort of looped in other people upstream of their teams to optimize their workflow. So I think there's opportunity for project managers, program managers to make a move to product. And I think these new emerging roles are going to offer some of that career growth. So there's three new roles, bay stream architect, phase stream, product lead, and product journey owner. And they always, you know, when we first start out, you know, we've got the team together and we're doing some exercises and people want to know like who's supposed to be on the team. You know, who should I bring to this workshop Dominica? And I say, bring your, bring your team. Or if it's too huge, bring a nice representation of your team.

00:12:21

Bring people who are upstream from you and people who are downstream from you, bring somebody who knows the product really well, bring your customer, or bring somebody close to your customer. And that's a really good start. And then as they sort of continue on this journey and they start to invite teams that are further upstream and further downstream, we discovered that there's these gaps on the team that the, these new roles start to fill. So value stream architect, finally, a role that's focused on optimizing the flow of the value stream, right? Of the tools that are used to develop your products. It's not an architecture role in the sense of how to structure software components or identify implications of new tack. It's just, it's a role. That's more about optimizing the pipeline itself, right? But it's not just about speed. I mean, there is an emphasis on speed.

00:13:13

We heard a talk earlier this morning that said, it's all about speed. Speed is very important, but it's also about visibility because what's one of the number one complaints we hear from our customers upstream. Like, where's my thing. I can't see where my thing is. It's invisible. So it's bringing this business level visibility into the flow. And that's something PMO has been asking for ages about getting more visibility because a lot of the work's been invisible. So I would think that'd be a dream come true for PM's to have this kind of visibility, the VSA role. It's also about ensuring good feedback occurs so we can catch problems earlier and then driving these experiments for improvement. The stream architect is an optimizer for sure. They study buddy bottlenecks. They're familiar with the theory of constraints, but they're also an influencer because in order to get something, they're going to be putting stuff in the product backlog.

00:14:15

But in order to get that approved and prioritized, you've got to have support upstream from product owners or business people. So they need to be in a position of influence to do that. And then they're part consultant because they're working with product owners and product managers to drive change and, you know, higher level decisions about workflow tooling. For example, if you have multiple value streams in a product value stream that are dependent on each other, but if they use different tools, how you get visibility, the relationship between parents and child work items across that value stream, here's a picture to sort of represent that, you know, you could have a application platform and the output of that is a product that is used by your external consumers, right? Or used by other developers to build upon. So quote from Satya Nadella here about the most important thing for an engineer to work on is the system that drives productivity.

00:15:26

It's the tools that we use to develop all the business on that. The important product at BMO hall. It's the plant. That's the most important product. It's not the cars. It's how, it's how the cars come off the assembly line. They need speed for them. Okay. Next up is product journey champion. Don't put too much weight into this tie, this name, this job name, you know, these are emerging. These are going to change over time. But what we're recognizing, if you Google that you'll get sports ball caps there's but so w we're out working with these large enterprises and the CIO is all bought in yes, a hundred percent. We're going to move from project to product, but we start working with all these program managers and project managers who for most of their career have managed work by projects. And so there's really nobody that we can partner with on that side, on the enterprise side.

00:16:30

And that's what this role, we hope that this role can build up so that organizations, all the horses can have a product journey champion on their side. You know, there's somebody who's able to help these help the enterprise on their journey, make this transition. So they work with executives, they work with managers, it's sort of a cross cutting con consultative role. It sits above all the, all the product value streams, right? So actually that role could maybe be part of the VMO, the value management office. They've got a bit of political savviness, obviously, because they need to influence not just leadership, but also practitioners, somebody, you know, the famous quote from Carmen. Diardo what we're trying to do. Like you have a process, are you in control of it or is it in control of you and then need to treat your delivery pipeline like a product? So, I mean, not that you could ever replicate a Carmen Diardo in your organization, but you need, I think it's so valuable to have somebody on the inside who can work versus just having an external coach, try and guide you through somebody dedicated to coach and champion, move things forward. You know, somebody's not afraid to point out that if you want to move faster, you know, think about your tool chain as a product.

00:17:53

And then we have the product ice stream lead. So the emphasis here is more about, there's a strong emphasis on the customer and team staffing. So it does come with budget responsibilities. They do have intimate knowledge of products and customers. They are working to staff and level up the skills on the team. They have an emphasis on team happiness. So this is team happiness of the product value stream. So it's not measuring team happiness of all the developers or all the testers or all the designers, right? It's everybody on that product value stream, how are they rating that their happiness factor? And that's an interesting number. And then we always get asked, well, what about the product manager? So tried to lay out the differences here that for the product manager, they're really focused on participation and feature design, and the product lead is more focused on staffing and setting objectives for the team and making sure that they're getting trained up and they may, there may be a little bit of overlap.

00:19:02

You know, product manager roles only been around for what, 10 to 15 years, the product value stream lead is brand new. It's emerging. And we're finding that, yes, we need both. Well, I mean, it depends of the size of your organization, but if you're working in a large owner organization, you need both. And even at our organization, which is relatively small, now we do have both. So these roles, I think that it's important. You know, we have these dojo's that spend time training our engineers on new technology to improve the pipeline. Can we add some of these roles, the skills and knowledge that are included in these halls into dojo training too? Can we have those classes? Maybe that's part of what the VMO implements.

00:20:01

Um, so this is my giveaway for you today. I always like to give the attendees something that they can take back to their organization and start using. Um, this is a skills matrix and on the left, it includes some skills and some knowledge that are useful for people who are moving to a product centric way of working and how it works is you hand this out individually to your team members and ask them to self rate themselves, right? Don't rate don't rate them, they self rate themselves. And there's a legend. So it's on a scale of zero to four. So zero would be a learner like a newbie. They're just a student learning this stuff. One is you could fly with the instructor. Like you could do something, but you, you need a partner. You to pair with somebody that can coach you to is you could fly solo.

00:20:59

You can do this on your own. Three is you can teach it. You can train others. You're an instructor. And four is, you're a master. You're like a blue angel. And as the individuals sort of rate themselves, then the product value stream lead could work with the value stream architect to compile all the answers, put this into this spreadsheet. And now you've got a heat map of where you need to train the teams up. So you can see like the second to the last horizontal role there. If you've got three orange zeros in a row, that's a visual indicator that we need to put some training on how to identify dependencies on teams, upstream and downstream from us. Or you can see on the right, in the third and the six vertical columns that there's folks who are zero at, you know, many of these skills.

00:21:56

And so there's an opportunity to train them up. And in blue, like in the first column, you can see, oh, we've got, you know, we've got somebody who's got threes and fours. So we have somebody who can instruct them. Right? The thing is here, it's, it's a little bit harder to cheat on these. If you ask people to fill that out independently and not see the others yet, then you may get a more honest answer, because I remember doing this once for myself and we could see everybody's scores. And I thought Julia only gave herself a to w if Julia thinks she's a two, then I'm clearly just a one. Right? And then there were the folks on the other side who maybe thought they were, they rated themselves a little bit higher. So on this, if you rate yourself as a three or a four, that means you will get put into a position where you're teaching or putting on a training. So you really do need to know what you're talking about.

00:22:53

It also gives the opportunity when it comes to organization changes to split teams into two, where there was only one. So as if you have at least two people who are at threes or up, then there's an opportunity to pull that one out and put them in a team with some other learners and fly with instructors. If you're growing, if your organization is growing and you need to bring more people on board, and up-skill, that's one way to build it up internally, this is an example of something that can be fed into the daily work and the general culture of an organization. It's an example, by the way, of one of the ideals in the unicorn project, and that's called improvement of daily work. So often we think of debt work as just technical debt, you know, refactoring software components or self-service performance testing, but debt work also includes training, you know, leveling up the skills of the teams, right?

00:23:59

Getting them to be able to shift into a new way of working. Uh, Jean talked about it in the Phoenix project, and he's talking about it again in the unicorn project as one of the five ideals. So spoiler alert, five ideals, but focus on not, or I'm looking, I'm focused on number three right now, right? Improvement of daily work. How do we enable improvement by helping these teams learn new skills? So what does it mean for org shifting to project to product? I mentioned the gaps in some of the knowledge, and there's a need to level up some of these skills. And that's why the skills matrix is so helpful. It makes the gaps visible, right? People can discover what knowledge is going to be useful and valuable. And you get to see potential in people with value. They're sitting right in front of you, right?

00:24:52

You could avoid attrition risk. If you don't want people upgrade, updating their resumes, you can take your valuable person with their valuable knowledge and give them the opportunity to level up their careers. You know, people like to know that their knowledge is valuable and it is as humans. We want to be good at something and we spend a lot of time mastering it, and then it gets automated. And you're what you were really good at five or 10 years ago, sort of disappears, and this is going to continue to happen. And so I think project to product is going to allow people to sort of reinvigorate and elevate their skills and knowledge and continue to be relevant.

00:25:43

And the new emerging roles offer an opportunity to do that. You know, project managers could move into product management and product managers could move into product ice stream leads and your senior people at the highest level with their skills and, you know, vendor management and risk management could move up into perhaps value stream architect, roles or champions. And if you're managing, if you're headed down the road, a product management, managing your work by product, then you're looking at profit centers, hopefully, which means you're going to have the funds to invest in training and teaching folks.

00:26:27

And with that, yes, I did bring more, no less swept stickers. If you want some there at the Tasktop booth, if you want a copy of this deck and a cup and a link to the skills matrix, and also the link to the full stack, not engineers send an email to dominica@sendyourslides.com, make sure you put flow in the subject and maybe check your spam filter. It seems like this is ending up in a lot of spam filters. And if you want to talk more about this topic, I'm going to be facilitating a link coffee table this afternoon. Those are going to be like right upstairs, outside of that area, um, where we're going to it's it's first come first serve there's room for about a hundred people and there's 10 tables. And so I'm going to facilitate one on the topic of what I discussed today.

00:27:20

So feel free to join me there today or tomorrow for questions. I, I, I want to know, are you, have you been talking with any project managers who are very nervous right now and are, do you have opportunities for them in your organization currently? Or is it looking like, oh, their writing's on the wall and we're just, we don't need those skillsets anymore. Cause I, I think there's a real opportunity here for folks who have a great desire to learn to upskill. I mean, I know I did when I saw that, you know, the writing was on the wall for me. I was very motivated to learn and study and become once again relevant. So that's it. Thank you so much for your time.