ScreamingBox Technology & Business Rundown

SUMMARY KEYWORDS
team, people, product, individuals, code, product owner, slack, important, role, alert, interesting, email, development, tools, context, build, channel, measuring, communication channels, engineering team

SPEAKERS
Myron McMillin, Dave Erickson, Botond Seres

Dave Erickson 0:32

Welcome to the ScreamingBox technology and business rundown Podcast. Today we're here with Myron McMillin and we're going to get deep into team ops. Myron, welcome.

Myron McMillin 0:44

Thanks. It's great to be here.

Dave Erickson 0:47

Myron, can you give us a little bit of background and your start in team ops and let us know your experience?

Myron McMillin 0:55

Yeah, absolutely. So, for the past 20 odd years, I've been leading design, product management and software engineering teams. I got my start initially on the design and development hybrid side as an individual contributor, working on front end and CD ROM based interactive design and development. Then throughout my career, I started leading those teams. For the last three years, I've actually been working on tools to help software engineering teams be more effective, engage in collaboration, and really focus on that team ops aspect of things. It's largely been, for me personally, a redemption arc, because early in my career, the resources didn't exist. The tools and processes and techniques weren't available to make me a really great leader and manager. So as opposed to going back and writing apology letters to everybody, I managed early in my career. I wanted to help build the tools and bring those processes to people who could use them, so that they don't repeat the same mistakes that I made when I was coming up in my career.

Dave Erickson 1:55

So how was working on product development different 20 years ago versus now?

Myron McMillin 2:01

At some places that I've observed, it's not any different. I think that's problematic. We've had the benefit of over the last 20 years of a lot of different tools, heuristics, frameworks and methodologies that have come to bear different agile frameworks, different ways of introducing lean processes. I think the biggest difference is, I can remember early in my career, building these huge wall based Gantt Charts, where we were trying to predict every single possible permutation of things, every stage, every dollar and the capacity of every individual person. And now we can be a lot more responsive, and reflective on how things actually get done and we can do it in a way where individuals have more ownership, and hopefully have more empathy about the problem that they're trying to solve, so that it's not just some giant dictating that you're a cog in the machine. That, I think, is probably the biggest thing. However, what it's going to look like 20 years from now is another question. There's no right answer for any way to do these things. It's very personal and it's very context sensitive.

Dave Erickson 3:09

Do you think the productivity of software development 20 years ago is similar to the set productivity that we have now? Does it take about the same resources or do you think it's much more efficient now than it was 20 years ago?

Myron McMillin 3:23

Yeah, I think that there are a number of things that contribute to the differences in efficiency now, but if you're looking at output simply as the kind of heuristic or the or the measure for productivity, then the amount of work that a person can do in the in a day, I don't think has changed. What makes us more efficient is the actual value of the work that we're able to deliver and the ability to actually leverage libraries and the thinking of other people. So, we didn't have a lot of these things that allowed us to pull in and build on the shoulders of giants or even small individuals, like packages, containers and things where you could take the work of others and extend it. Beyond that, if you say, Hey, we're going to do a project, it's going to take us a year to get it done, we're going to be heads down, and it's going to be a skunkworks.Then after the year, we're going to come up. You have essentially got a balloon payment on potential failures and all of those risks. Whereas now, with the ability to continuously build, deploy and to test, we can deliver iterative, more valuable, incremental changes. I think that's definitely been valuable, especially because it's going to increase the amount of data and that conversation that's coming in from the market and from customers way more quickly than if you're going to say, Hey, we're going to build the world's best spork and we're going to get it to the market.Then you get into the market and you find out well, nobody wants a spork and all of those costs are wasted. You could have been incredibly efficient at building the world's best spork. Your team was highly productive. Everyone was working at the right amount of capacity, the machine was humming, but in the end, was that valuable?

Dave Erickson 5:05

On your LinkedIn profile you have that development is a team sport. What do you mean by that? Why does that sentence mean a lot to you?

Myron McMillin 5:15

It's a good question. There is an obvious difference between the roles of people when you're talking about a design resource versus a development resource versus someone who's coming from product versus someone who is strictly on QA or test automation. What I'm talking about specifically, is even within a discipline within a team of just software engineers, it is more like a team sport than it is like an interchangeable unit,where each person is an interchangeable gear in a machine in which they all fit the same role and they all do the same thing. So, an example would be if you're looking at something like American football; if you try and build a team, that's all quarterbacks that all have that same skill set, you might get an interesting experiment, but it's probably not going to be a highly competitive team, where you've got different players that are playing different roles. So, when you're building a team, even if it's a self managing team of generalists, they're going to be individual humans and they're going to have different strengths that they bring to bear in service of the team. The way we look at it is, Hey, what are those human-like soft and core skills that people bring and when we're measuring them, let's measure them in the context of the team and really amplify the strengths of individuals, so that they really are playing to their own strengths in service as a team, as opposed to trying to create this ladder or this rubric where everybody is measured on the same thing. An example would be, we're trying to build a team and we're trying to ensure that communication is great on something like, let's say, you request a code review and some individuals on the team might be really responsive to other members who are saying, Hey, can you take a look at my code, but others on the team might not be as responsive, because they're really effective in the feedback that they give. They're really thorough, they're thoughtful and the expectation can't be, Hey, we want everybody to take all of this time and be really, really thorough on every code review or we want everybody to be really, really fast and get them over with, you need to have MCs, a mix of different things coming from the individuals on the team that are going to contribute to the success of the team overall. So when you try and make everybody the same, you get that Harrison Bergeron effect where everybody regresses to the mean, and you get a bunch of mediocrity, everybody's average. But if you treat it like a team sport, Hey, let's get the people in the right roles, let's not have an orchestra where everybody's playing a triangle, let's not have a Dungeons and Dragons party where everybody is just going to be a barbarian. Let's have different roles within those teams and really optimize individual strengths. And that's when you get something that's interesting, and really singing, even if the technical skills underlying it are relatively similar. You want to have humans still live into the thing that makes them human.

Botond Seres 7:57

I just want to build upon the answer that you gave about portray requests and responsibility. That's something that I personally have experienced. It's, such a great, profound experience that you shared with us, because I'm sure that every developer and every team worldwide has experienced this, that even if they ask other people to take a look at their code, they might actually need to go and personally ask others to take a look, because if they just say in the group chat, Hey, take a look, please. 24 hours later, nothing. So yeah, that's quite the insight. Anyways, in larger teams, such as 10 plus people. Do you think there's a productivity difference between a large team or a small team?

Myron McMillin 8:49

Yeah, the short answer is yes, but it depends on, again, taking a step back and how you're measuring productivity. You know, there are some things that are common. I'll say it again, like the common heuristics that you look at when you're constructing a team, when you get over a certain size, you're going to naturally have it where five to eight people on a team where the amount of human bonds that we can have, the amount of deep connectedness that we can have between individuals on the team is naturally going to be stressed. So if you get to a team that's at about that 10 size, again, this is not one size fits all, but you should really start thinking about, Hey, is there a natural, organic way for us to actually split off this team so it can be a smaller independent unit, so that they can not have it where relationships and the actual engagement between individuals on the team is going to fall off. I do want to circle back and talk a little bit more in a second about what you're saying about PRs and code reviews, because I think there's an important point there. But, productivity based on just pure output, when you're talking about a small team versus a large team, is really a hyper variable. So I would say whenever possible, it makes good sense when you hit that five mark, for the number of people who are on a team to start thinking about, Hey, once we get to eight, nine to 10, can we organically pull this off and make it into another team? Then the next worry is, Hey, now that we've done this, have we just done it on paper? Kind of like, We're agile now, because we have two week check-ins versus being waterfall. Have I actually created two independent teams that are able to self govern, self manage and get things done or have I just created a big team that has this artificial barrier between them? Am I creating weird organizational overhead that I don't need? So you have to also make sure, Hey, are these teams actually able to have an interface between each other where those relationships between teams as units are defined as well? So the short answer is, I'm in favor of always having smaller teams,not tiny teams, but teams that are about that five to eight size, that are going to actually have well defined boundaries for what makes them a team. Those teams too are going to have to operate in their own universe, but still have collaboration with outside teams. There's a lot of additional thought that has to go into it, because there's a cost every time you create a new team, right? There's a cost that, that team has to gel, they have to go through that forming, storming, norming period before they're actually going to be productive. So sometimes you might have to deal with the overhead of having a larger team, as opposed to cutting a team up midstream, because it'll put a project or something else at risk. Really quickly let’s go back to what you're saying about, Hey, I have a code review. And I'm looking for somebody to review it. I have assigned people, I've asked people for help and I'm not getting anything. This was a big reason why we were looking at the types of tools that I've been working on for the past couple years, because there are different types of individuals on teams, who may have different feelings about certain tasks. One of them is, Hey, I understand the value of actually doing a code review and someone else on the team may be, Hey, I don't see the value of this, the code is good enough. Nobody ever finds anything, nobody's doing code reviews, for me, this is a chore. So there is that feeling where, Hey, I don't understand the impact of the work I'm doing or this is a chore. Why should I be doing that and really being able to get insights into the different things that you do as an individual throughout the day that are helping other people on the team is really important. So being able to say, Hey, Botond did a code review for you last time, you should do one from for them, because the notion of reciprocity, is critical, it's important to know people are doing things for you; you should be doing them as well, just to be a good team member. But the flip side of this is, Hey, that's purely interpersonal, what is this doing in service of the team, do I know what is expected of me and what those norms are? Then being able to know that people on your team are doing these code reviews, because they are doing X and they're doing them within this time frame and these are the expectations, but also protecting maker time and allowing them to get the like heads down work done. It's a really interesting and critical balance as you know, as you're going through, and I feel like that's the that's the really the most important part of being able to have a really healthy team ops ecosystem is how do you balance all these different data sources with all these different people with all these different responsibilities, and still get work done in a way that keeps people engaged and actually satisfied and happy doing their job? It is a tough balance. So I've rambled on for a while there.

Dave Erickson 14:18

Yeah, and I assume that the longer a project goes on, the more difficult it usually is for the team ops to run as smoothly, or it could be the opposite. It could be that everyone's so used to each other that it's like a natural fit, but it also could be that everyone's going in different directions and the project's been going on so long, they don't know where they are in it. So there could be all kinds of things related to that as well.

Botond Seres 14:45

From my point of view, as I said, it's really a tight balance between protecting creative time and review time. And I definitely do feel that every day. It's always a chore to switch from creating something new and interesting to just reviewing someone else's code. The way I try to look at it is there are very few things that I am the foremost expert at and I try to focus on those small, tiny things that they can spot immediately. So that's what I tried to focus on. But there are other people who tend to try to understand the whole VR in general, especially the big feature that can take a long amount of time. So I'm not sure if that's, that makes no sense. ,

Myron McMillin 15:44

It definitely makes sense. I think that it highlights, you know, a difference between individuals. If you feel that your power, the contribution that you have when you're reviewing someone else's code is to look for possible issues with the code or to find things that might be quirks or ways that are different from the kind of established norms within the team, I think that's valuable. It doesn't make you necessarily more or less valuable than someone who's going to go through and do a real deep, thorough analysis of everything. Which again, is great, it comes at a cost, because that means that they're probably not going to be able to focus as much time on the creative maker work that they need to be doing to write code and it also means that they're probably going to be looking at less code reviews. So there is a balance there. Even in the size of the pull request, or whatever the changes that you're checking on takes more than an hour for someone to actually do a code review, based on the actual size of the code, I think the general change set size is at about 250 lines when it starts to top out. If you get above 400 lines of changes, then things rapidly are going to go downhill just in the human capacity to stay engaged and interested and actually look for defects and look for issues. I think you catch as many as 86% in that first hour as an individual, and then it rapidly goes down. So for someone who's going to invest a lot of time in a really big change set, it may have diminishing returns. So it could be another size or rather, it could be another sign of this dysfunction where people are checking in huge changes, they've been a blackbox, nobody knows what's going on, then boom, this huge change comes out and the expectation is, Well, people need to go and look at my change because I look at theirs. While the balance just isn't there, like you're doing punitive duty, because you're checking in this huge set that nobody's had a chance to look at and you're expecting them to review your giant change set the same way that you would look at a small one. So having those kinds of insights and being able to tune and get norms across the team where people understand, Hey, here's where we're going to be operating and here's how we're going to do it. It goes a long way towards creating a healthy environment where you don't feel resentful towards people on your team, because they're not acting in good faith. It might be just purely accidental. They just don't know.

Botond Seres 18:25

For the topic of how different team members interact and how they may be different, or how they may be similar, do you feel that in launch teams, as you said that tops out at around 10 people? Are there any recurring personality patterns that tend to emerge within the team? Or within the teams that you've managed? So far?

Myron McMillin 18:48

Yeah, I think that there are a number of, I don't know if I call them personalities, but there are behaviors that start to become more and more present, depending on factors that are both internal and external of the team. So one that I see a ton of is this notion of glue behavior. So if you have a team and the team is missing something like, they haven't come together, and they aren't as cohesive as they need to be, or there's something external that they're not getting from someone who's servicing the team, like let's say a product manager, or the actual people manager for the team isn't doing what they need to do, there can oftentimes be people who step up into a role and it's a dangerous place to be where they're acting as the pseudo manager or fixer for the team. So they're this ethereal role where they're the fixer, and they're like, Hey, we don't have this information, or we don't have this process or we don't have this thing and they'll start to do these human and project and process management tasks,that especially when you're looking at engineering, they're not going to be measured, and they're not going to be seen by the people who are responsible for helping them through their career downstream. So it's like the adage that if a product manager doesn't do their job, someone else will. Well, generally, it's just a management construct. If a manager isn't doing their job, or the team isn't managed, well, someone might step up to do that and the secret insidious truth is, by virtue of doing that, they can end up hurting themselves because nobody is measuring. Are you making others on your team better? If you're an individual contributor, they're measuring, what is your output? What is your productivity? How many lines of code have you written in the worst case scenario, most generic scenario?

Botond Seres 20:40

You know, Myron, I feel like I, I tend to eagerly step up to the throw. I can confirm it is the most dangerous place to be in anything.

Myron McMillin 20:49

Yeah, and it's one too where it also has an outsized number of women who step into that role. They'll come in, and they'll be like, Hey, I want to be an engineer, I want to be this technologist and then they find themselves being a fixer on a team and it actually stunts their ability to actually grow throughout their career, because they're not doing the thing that they're being measured on. And it's something where it's a critical role. There's a reason that they're doing it, but not having a get measured and recognized as part of what the danger is; also not having it be something that raises a flag, so that a manager or other people can actually build the structure to make it so that they don't need to be doing those things. It's like putting a bandaid over a bullet wound. You might not see that it's bleeding, but it's not going to get better by virtue of that band aid there. So they're masking the fact that they're hiding the symptoms of this underlying issue that actually exists, that needs to be fixed, and they're not going to be able to do it alone. There are instances where the people who take on that role really love it and they want to move into human management or program or product management. But again, it's not where they are right now so it's difficult. So that's a role where it's kind of self harming. The other one is where you get the kind of Rockstar person, someone who is always right, who might have outsized productivity, and they might actually be a great technologist, but they're a jerk. And when you get teams of a certain size, they can be toxic, because you're not looking at, Hey, how do we get a bunch of rock stars who are going to... you know, they want to be always right, they want to be on the stage, as opposed to people who want to be a part of a band, right? They want to actually work together and make something that sounds great and is great together. They tend to have this outside influence because, Oh, well, I'm the only one who knows how to do X, or I am, the whole reason that this product is great. The secret with them is if they aren't trainable you have to get rid of them, because they are going to actually make the team much worse. And that's one too that can be harmful. When you get to a certain size, especially if you're bringing on people who are more junior, people's egos can get inflated and then they can become this toxic force on these teams, which is another reason why it's good to try and have it where you've got teams that are of a certain size, just so you can limit this negative impact. If you do have folks like that and you can better manage and mitigate around it. But yeah, I also think there are cultural differences. You know, when you have teams of a certain size, and they're distributed, there might be differences between personalities and cultures that are just inherent with how they grew up, how they were raised, where they're from and I think that fundamentally, it's less about personality, and more about, Hey, can we trust each other? Can we have open conversations with each other? Can we provide feedback in a way that's actually going to help people grow? If you deliver feedback that is going to be too direct and too lacking in tact, it's going to be just as bad as if you leave feedback that is going to be just sugar coated, and not actually get to the root of making things better. So there's an interesting balance.

Dave Erickson 24:33

Yeah, we experienced that. One of the things that we do is, we do a lot of personality behavior assessment, surveys and testing to make sure that the people who are on the team kind of communicate in a similar way in their workflow. We don't want everyone to be exactly the same, but the people leading the team have a certain work style and can accept other flows easily. And we also do the same with our clients to make sure that the teams and the clients work out together. So I definitely agree with you that that's a critical point. One of the other questions I have is, as you were saying, most of your product development conversations have been orientated towards the actual product development. But we also know that once kind of, particularly with digital products and SaaS products, once the product has been launched and released, there's almost like a second wave of development, which is all the maintenance development, like these products, once you kind of get it finished, it's never finished, because there's all these maintenance chores, they're changing platforms, and there are bugs that are getting found. When you're putting together a team to do this kind of software maintenance, maybe you can talk a little bit about how maintenance development and initial product development are similar or different. Maybe you can give a little insight on how managing those teams are different, if they are, or what's your view on that?

Myron McMillin 26:05

Yeah, I mean, there's definitely a difference between greenfield and brownfield development and being able to manage a product throughout its lifecycle. And you know, one day... Hey, we need to sunset, stabilize and put this thing on the shelf. But I think that as it relates to how you manage the team itself, there are some underlying truths that you want to have, regardless. If you're maintaining a product in perpetuity and there is no new feature development, it's a little bit more of a challenge than if you're going to be bringing something new to market that's going to be, Hey, this is interesting, we get to choose new technologies off the shelf; we get to put whatever process into place that we want. But still fundamentally, you have to have interesting problems that you need to solve, and you need to bring through the customer voice and have empathy that is being shared throughout the team. I think fundamentally, if you've got a product, and you don't have interesting problems to solve for the individuals who are on the team still, and they're not able to grow, it's going to be much more challenging than if you do still have those problems to solve, and it's becoming more similar to maintain a product over time because you're going to be able to iteratively deploy it. You're going to be able to do things that are going to relate very rapidly to get you feedback. It's not going to be wildly dissimilar, it's just a difference of scope, it's a difference of, Hey, here are all the different moving parts that we have to manage, because it's something that's been built out and it's got this complexity. But you know, I really think, fundamentally, it comes down to philosophy and what you're actually going to be bringing to market because if you're saying, Hey, we've got something that in these six months time, we need to bring something brand new, and it needs to look exactly like this as written down and essentially, you're doing something that's waterfall, it's going to be very different than what maintenance looks like, because even if you do have set times for when you're going to be deploying, maintenance is going to be largely dictated by the truths of, Hey, here's what the product is actually doing, here's how available it is, here's how secure it is, here's what we're hearing from customers, here are these things that are brittle and here are libraries that are no longer being maintained. That is externally influenced and you can use something like, Hey, we've got a simple Kanban board that we're using to kind of bring these things through and do them as they come in. Versus Hey, we need to timebox this and deploy this and it needs to have a certain amount of features and we need to have all of this there because there are marketing and sales efforts that are reliant on it and other pieces. But as it relates to the individuals on the team and how you manage them as humans, I don't think it's much different. You need to have those pieces in place that are going to keep them happy and engaged regardless. The challenges obviously are different. But...

Dave Erickson 29:26

Yeah, I think maybe for a lot of people it's very easy to think about the product development and getting the product built and you know, there's an end or kind of a statement that we are going to have at this revision and people are working towards a goal. Whereas maintenance, if they don't plan it and design what they want maintenance to look like, it could turn into some boring, monotonous thing in which the developers all leave to go get more interesting work. So companies have to really focus on the maintenance side. How do we make it interesting for the developers? How do we make sure they have new features to work on? And how do we make sure we're addressing customer requirements and changing customer requirements? So the maintenance team seems like it has its own challenges versus product development.

Myron McMillin 30:14

Yeah. And honestly in my experience, and again, it's been a long time since I've been working on the agency side, in the SaaS side, there hasn't been a huge difference between, Hey, here's the team that has a value stream, and is bringing a feature to bear within this product and then the team that's going to maintain it over time. They still are responsible for maintenance, they're responsible for having fighter duty and triaging and what have you. Their deployments to fix those things follow a similar kind of cadence for the types of future work they do. We've gotten interesting new ways within the last 10 years plus to be able to actually do them in a more fluid way, that's going to still be safe when you deploy. We've got the ability to use feature flags, and interesting continuous deployment. The way to bring value and get telemetry and other data back that allows for it to be safer and more meaningful and to no more than before. I think, if you're looking at it as, Hey, there's been a strict handoff, and it's gotten to maintenance and these people are responsible now for maintaining something they didn't build, and it's not going to be incorporating, those interesting data points, and they don't really have ownership or autonomy to be able to like improve, it becomes more of a challenge.There obviously are times like that, because it's just Hey, it's not cost effective, or we're sunsetting this thing, or we got like, one customer that's still on this legacy product, and we can’t move them off, and we want to keep them happy, but they're not critical to our business. In which case I think that it's probably a discussion around, Hey, is this where you want to be? Do you want to be able to maintain this product forever in perpetuity? Are there opportunities that we have to actually elevate you or pull you out of this team? Or is it going to be something where it's personal based on the individual that you're working with? But yeah, I've had teams where we had to sunset products and we had new products that were coming on and the thing that we tried to do as quickly as possible is make sure that we had folks who were able to maintain that, but that was no longer their full time job, just because it was not the interesting work to do anymore. So how can we get this product as stable as possible so we don't need a lot of hands and a lot of eyeballs on it in case there is an issue? Let's make it so it's not brittle, let's make it so that we've got all the alerting and the kind of service fabric that we need wrapped around it to keep it going and then yank them as much as possible onto the new work so that they can continue to grow and feel professionally engaged and be happy. But in reality, it's not always the case.

Botond Seres 33:08

Since we are discussing the differences between greenfield and brownfield projects, from my side, I'm more interested in the context of greenfield, but it will also be very interesting to hear the answer in the context of brownfield projects as well as to what you feel like the ideal team split could be between analysis and or architecture, developments and QA.

Myron McMillin 33:39

Yeah, you know, it's interesting, I think it's less about split, because if you're looking at it as, Hey, we've got a, a team that's a certain size, we're going into a new project or new product and let's say we're a brand new company, and we've got three engineers; those three engineers are going to be architecture, they're going to be development, they're going to be QA and I think there's a propensity, especially with a lot larger legacy orgs, to have what I consider to be a very big waste in software development, which is very black and white handoffs. It'd be like, Hey, I'm responsible for developing code, but I'm not responsible for the quality of my code. I am responsible for, let's say, the business analysis and that also means I'm responsible for dictating how the solution is going to get developed then, development just has to actually put down code that's taking my pseudocode and requirements and turning it into a thing. I think that's a dysfunction. The ideal team ownership should be that everybody regardless of who they are, should be aligned in terms of the value they’re trying to deliver and should own the quality of the solution, the availability of the solution, the performance of the solution, the security of the solution, the value and the delight that it brings to users as a solution. So an example for me would be, I believe very firmly that the business side of things, the product management side of things should be focused on defining what the problem is, as opposed to dictating downstream to designers and engineers, what the solution needs to look like and how it needs to act. Part of that job is going to be helping to bring the voice of users and customers through to let them know, Hey, here's who we're building it for.That gives the developers and designers the ability to actually do their job, which is to create solutions that are going to be innovative and interesting, as opposed to just acting as a kind of automaton that's just doing the thing. Then, as it relates to actually sending it over to QA, I'm a firm believer in the DevOps kind of paradigms around, Hey, you should own the quality of your code, you should be responsible for the actual building and downstream performance of your code and there, I think that QA is, Hey, how can we actually build test and automation that's actually going to help the developer experience this so that they don't have to dig in too heavily. I don't think that there is an ideal team split. I think that teams themselves should be generalist enough in their ability that they can do many of these things. Within an engineering team, let's say,for once you reach a certain scale; you need to have certain things that are going to be there that are going to serve the product at scale. So you can't have it where every engineer is expected to do every possible task without having some sort of support fabric around as some sort of support structure. So I don't have a good one size fits all answer. The exciting thing is that product is evolving, product development is evolving, and it's at a rapid rate. So the tooling we have now, the context of everybody working from home, and remotely, if you would have told me that it looked like this three years ago, I would have thought you were crazy. But then we have a global pandemic, and it changes everything. So...

Dave Erickson 37:36

Yeah, we've been doing it since we started in 2012. So for us, it's kind of natural. I do have another question that kind of comes into this context of team format. One of the things I think people really don't think about or integrate or utilize, is the concept of product owner. How do you feel about the product owner? Who should be the product owner? How do they fit within a development team? Should they be exclusively outside of the team? Or should the product owner be part of the team? How do you see the product owner in that relationship with the development or development team?

Myron McMillin 38:20

It's an excellent question. I think that, in general, if you're looking at any role on a team, and even any kind of ceremony or artifact around a team, and who's going to be involved, I always like to look at it through the lens of how value is being delivered and is it bi directional? So if you look at a product owner, where they live, how they're participating, and what they're doing day to day, it really is a question of where is his value going to and where is it coming from? So I think that product owner as a role, is really great, especially on very complex products that have multiple features that need to be owned, that need to have some way of actually getting fidelity down to the feature capability level that can't be served by having like this central product conduit that exists over top of it. If you're looking at it as, Hey, I want to have a single chokable double throat from a business perspective, because we need to have someone who actually understands the business side and the actual implementation side, and is responsible for that. I think that it makes sense as well. But, the question of, Hey, where do they live and what are they involved in should be, Hey, are they getting value from actually being involved here? Is the business getting value? Is a customer getting value? And then is the engineering team getting value from them being there as well? So if the answer is no, then there's some sort of dysfunction there. Either. They're not doing their job to bring forward you know, Hey, what is the problem that we're solving? Why is it important what our customers say, providing that context? They could just be serving as a taskmaster for some arbitrary imagined internal thing for the business. I think that that's not helpful at all. But if they're actually doing their role and bringing through the the things that they need to do, to help prioritize and estimate and understand value that is going to be delivered and put it in order, and they're able to take back the concerns of engineering team to stakeholders upstream, then it becomes a really powerful role. There's just a lot of work to do when you have big projects that are highly complex. So having individual product owners over teams is helpful. The flip side is if you have one product owner for many, many teams, they can often get stretched thin, and they just become like weird traffic cops, and they start to lose the value of their role as well. But it's just like with a meeting, right, like Hey, should I go to this meeting? Am I going to provide anything valuable? Am I going to actually get anything out of this meeting? If the answer is no to one, or all of those, then probably don't have it. If you're looking at it as a product owner, are they going to bring any value to this team? What should they do? Is the team going to get value from them? Are they going to think it's fine to structure it that way? If you're going to do a traditional Agile Scrum methodology, if you need to leverage that type of framework, then not having a product owner and trying to overload a scrum master with that role, I think is a good recipe for failure.

Dave Erickson 41:38

Yeah, it's one of the areas that are a challenge in all types of development. So one of the things that you also kind of touched on a little bit was the communication and the flow of communication. When everybody was working in an office or development teams were all in some kind of office, communication channels were relatively simplistic, you could walk over to the next person's desk and have a conversation with them or there's some group meeting presentation. With remote development and with the remote work environment, obviously, that's changed dramatically. And one of the things that it seems to be a challenge for teams who are working remotely, is what communication platform and what kind of channels do they use, how do they communicate? Some people don't like email, they'll only communicate through slack and some people only communicate through Google meet. So in managing a team remotely, which is going to be the reality for a lot of people now, what's your experience with communication channels and dealing with how do you keep all the different types of communication needed for a team to actually move forward on a project?

Myron McMillin 42:53

Yeah, I mean, the short answer is, it's really, really difficult. And that's why I've been focused on building tools to try and solve the problem. I mean, there's so many different things that are coming at people. And the reality is, you've got this feed of information that's constantly coming to you via email, or slack, or what have you, that if you're not there to look at it synchronously, then it's going to get buried, and it's going to become part of this just, you know, alert delusion that's coming through where you've got all these different things you have to look at across all these different channels. So the best possible thing would be, hey, is there some way to actually mitigate that and have it where the most important information that I need personally is going to come to me at the right time and in the right context. That's not practical for everybody. So some interesting ways that I've seen people do it is they just simply publish, hey, here are times when I'm going to be available. These are like my personal open office hours, here are the ways that I like to communicate, and have it in a place where others don't have to go and try and figure out what's best for you, like, Oh, if I send you an email, you're not going to look at it, because you're constantly getting all of these emails from production systems and from other things that are, you know, just serve as this feed of, you know, constant noise that you just get alert fatigue, and you're not going to look at any more. So I want you to directly reach out to me on slack as a direct message. Well, I don't know that. So there needs to be some way of describing what your interface is as a human so that others can know. So I think that just being able to communicate that upfront, is important for each member of the team and having some sort of social contract that says, hey, here are the times when we're going to be able to be working together. And here's how we're going to communicate. There are times when we're going to be protected from doing maker work or creative work. In terms of having the best channel, I am not a huge fan of email. Personally, I like using something like Slack. So for me, you know Having these like synchronous, asynchronous blends works really well, it's not going to work really well, when I've got a team that's in India and a team that's on the east coast and a team that's on the west coast and a team that's in Poland or the Ukraine, like, you have to have some provisions for actually being able to deliver and hand these things off in a meaningful way. And, and they're, you know, there aren't tools right now that really do a great job of lifting and shifting work and making sure that it actually is going to be like communications following the sun. So people need to be really good and mindful about, hey, we've adopted a channel for being able to communicate things that are long lived, like documentation, or plans. And then we've got channels for more synchronous communication. But we have to plan around overlap, it really comes down to more of a human problem than a communication channel problem. And, and then it comes down to, like what I was talking about previously, like, Is there value in me getting this communication? Like, why? Why are people not sending their email? Well, there's obviously a mismatch between the value that they're receiving via those emails. And, you know, the time it's going to take them to actually go and dig through them to find this value, even if it means they miss the email that says, hey, you need to re-up for health insurance this year, or whatever, something that's truly valuable, it gets lost. Because they've just given up on it, because they're getting all this like BS, that doesn't apply to them. So it's a balancing act. But there's all of this noise that comes from non human channels, too, that people don't account for that is part of the reason why, like engineers tend to like things like Slack, because it's going to be giving them a real time feed of information, or a, you know, even if it's not real time, it'll give them a feed of things that are coming in, that are tightly integrated with that platform. So hey, I'm getting alerts from Century or robar, or production systems, I'm getting alerts from GitHub, and I'm starting to rely on it for my day to day work. And now you tell me, I have to go and look at an email or I have to go and check this other thing. And that's where it starts to become, you know, maybe for a business person, like they don't care about those things. So that empathy, but there's reality to the value that they're actually going to get out of that channel.

Dave Erickson 47:29

Yeah, and one of the challenges on communication channels is that, you know, people are kind of one of the fatigues that I find that people are having business people as well as developers is, they're having to learn a new platform every month, right? There's a new technology that all of a sudden, people are using a new SAS product, a new something, and they're all different. And you all need to spend time trying to figure out, how do you do this, and, you know, in your head, what you want to do, but trying to figure out how to do it on a new platform takes a lot of time. And eventually you use it enough where it becomes second nature. But one of the biggest barriers to different communication channels is that there doesn't seem to be a stability of tools. Although you get some like Slack, which kind of become, you know, the mainstream of the development community, until a new one comes along in three or four years, it's better. And so people start migrating over to that one, except for those people who are now used to slack. And they don't want to learn a new one. And so they're going to stick with it as long as they can. So there's always that kind of push and pull between the different people on communication challenges. But I agree with you, it's definitely a challenge for the future. And it's some interesting projects. What kind of tools do you think are that you've been working on to deal with this problem that you think are worth exploring?

Myron McMillin 48:54

Yeah, there are tools that exist out there that serve only as an intermediary to bring those communication channels together. You know, Hey, we're going to translate this message from this platform to this other one, so you can get it where you want it, but the things that I think are most interesting are, Hey, you've got this workflow that goes in and, and there are all these different moving parts, and all these different things that are happening that we're automating, and the actual signal gets lost because there are so many alerts and so many things that are vying for your attention at any given time. So the tools that actually are going to go through and say, Hey, here is the most valuable thing that you can do right now to help yourself to help your project to help your teammates. Those are the things that I get excited about; things that are going to actually augment our ability as humans to focus on the stuff that's really important and not have to worry about the administrivia so things come prioritized to me, come directed to me and come tailored for me. So I know, Hey, the most important thing I can do right now is respond to Dave's email or do a code review for this person or to go and respond to this production alert and to do it in such a way where you don't have communication channels and products that are competing for each other. So they go through a central kind of conduit. That's really interesting to me, that's what we've been working on. Because even with tools like Slack, the counter example to what I was saying before, like, Hey, we get all these alerts in Slack, or to Batanes example earlier, where he said, Oh, you know, I had to ask someone to do a code review on the channel, and nobody did it. So I have to go and reach out to people individually, we get this kind of like, bystander effect thing, where an alert comes into this shared channel, and everybody thinks someone else is going to do it, it's just weird. Like, Oh, well, somebody asked for help, but I thought someone was going to help them so I didn't help them. And, and it creates these weird things that are due to real rights and then to then you start to lose trust in the actual signal. And I see this pattern like, Hey, we've got a new system that's doing something that's helping us. And it sends us alerts and notifications to a Slack channel and we put it in our main Slack channel, then we moved it to its own channel, and then I muted that channel because you just stopped getting value from it. I see it too with like vulnerability and dependency bots, people are like, Hey, I keep getting all these requests to go and check on this code review that came from or this pull request that came from a dependency bot, but nobody's actually looking at it, or wants to do anything about it because just all of this noise happens. So a way that you can actually remove all of that and just get tailored communications for you from the central system so you can actually do your job. I think it's really interesting. Things like Hey, am I using Slack or teams or workplace or, you know, meet or what have you. I think that they'll all be ICQ, and AOL Instant Messenger, and you know, what have you 10 years from now? We won't remember Slack anymore than we remember Yammer, HipChat, or whatever the last thing was. The reality is, communication is still fundamentally having the way to get value out of synchronous/ asynchronous communication, especially now that it's coming from outside systems as well as humans, is going to be more important to solve than ever.

Botond Seres 52:35

I don't know, I would be really interested to see, just as an example of the build notifications, or the peer review request, or whatever else to just arrive in Microsoft Teams. That would be a huge upgrade from having to go on the DevOps websites, having to check everything manually, and deciding if something is actually something I need to take a look at. Yeah email especially, just so invaluable. The standard email, you must get like, at minimum, hundreds, but probably 1000s of emails every 24 hours. And the average value of those emails is nil. There's just no value there whatsoever. That's kind of the nature of our universe. I mean, the nature of information is to get more and more diluted over time. That's kind of something we discovered through physics.

Dave Erickson 53:37

Yeah, I feel sorry for any of those people doing email campaigns for marketing, because I get up to 300 emails a day. I'm getting pretty good at being able to just scan through emails and pick out the ones that actually have value to me, and all the others, I don't even look at them, because I can just tell that they're not emails I need to look at. If I was only getting 10 emails a day, then I probably would look at all those marketing emails. But when you're getting 300, it's just too much. And so you enter your email inbox, just to see what email do I have to look at now? What email do I have to focus on? You just start getting used to scanning and picking out the others. Same with Slack, sometimes channels get so full of stuff, and there's so many people on a channel that you have to kind of just go through it and try to figure out which ones really apply to you. And they haven't really come up with a lot of good AI that's been able to do that for people. But we will see what happens in the future. It could be a future project.

Myron McMillin 54:42

Yeah, I think that that's largely, especially for engineering teams, what we're looking at as a problem that we're trying to solve with botany. So to even the earlier point that Bhutan had about, hey, I have to go and look at a website to know what the next thing is for me to do. So I have to go, and have to deliberately switch my context from what I was doing to something else. I have to go and spend all of this brainpower and cognitive load on trying to dig for just one source. This is like, I'm just going to the Azure DevOps site or I'm going to GitHub or GitLab or Bitbucket, or what have you. I'm just going there to look and see, Hey, does someone need me for this specific thing? Not to mention, Hey, are there alerts that are coming from other production systems? Is there an alert that's coming from JIRA or Asana or a shortcut? Is there an alert that's coming from somewhere else? They all fit into the same workflow, but in a perfect world, we would all have the kind of secretaries that you'd see on the TV shows, you know, sitcoms from back in the 60s, 70s and 80s, right? Boss, you need to do this thing next, like, Hey, your appointment is here and this is a really important thing you need to do now. So having a system that takes all of these different signals and says, Hey, I am your executive assistant, this is the thing that's most important for you to do next and here's why. That's where I personally think things need to go. I know, right now, that I need to be working on writing code, or I need to be in a meeting, or I need to be doing a thing. But when my context changes, I want something to tell me, Hey, now that you're looking for the next thing, here's the next most important thing, here's who needs it from you, here's the timing that it takes, generally speaking, these types of things get done within your organization in this amount of time. Here's the impact that you're going to have and so we've put it in this rough priority order. It's really going to be valuable for being able to remove all of that, like, Hey, can somebody help me type the notifications that you get. If I can help, it is the same as the team, I see I'm assigned to this, but so are 30 other people, somebody will get it, it won't be me. And then just rinse and repeat over and over again until everything takes three days to get done, as opposed to, you know, an hour, it becomes problematic. Anyway, I'm passionate about that specific piece.

Dave Erickson 57:12

Well, maybe now's a good time to ask, what are you currently working on? What are you looking to do in the future? What are you thinking about for your own kind of career path moving forward?

Myron McMillin 57:27

I know, from my own career path, I love the craft of product. I love working with engineering teams. I love working with design teams. So I feel like my career to date has been pretty fulfilling. You know, the ability to continue to provide actual impact either socially or through products, to be involved in a good culture, to have opportunities to receive and to provide mentorship are all critical for me wherever I end up. For me, personally, what I've been working on is, I've been leading the product at Botani. IO, which is a product that is designed to do many of these things that we've been talking about, to help to keep the teams engaged and keep them effective and working together by making sure that people know where they're needed next, and what their impact is going to look like. Whether it is at Botani or somewhere else, I think that it's really important for me, that I am able to continue to shape what that looks like with the organizations and more broadly, how can you? How can you improve your team? How can you make it where you know you're better for coming to work every day and the people you work with are better for you having come to work today? So you're actually getting that value and you feel like you're improving and growing and staying satisfied in a meaningful way. And ultimately, you deliver awesome products that make people happy. That keeps your company going and you get giant bonuses and the world keeps turning but yeah, that's it in a nutshell, what I hope for.

Botond Seres 59:06

So you said that, ideally, you think things need to go in a direction, I'm paraphrasing here, but everyone has their personal assistant at the same level as Charisse and Ira man.

Myron McMillin 59:21

Yeah, that's a good way to look at it. If you think of every human as an actual individual, as opposed to one size fits all for everybody and if your expectation is that people have different needs, they're going to be different things that motivate them. There are going to be different strengths that they bring to bear. Asking everybody to do the same thing in the same way at the same time is not going to be effective. So if you've got distributed teams that have different contexts, whether they're working in the office or not, they're across different time zones. So if I send you an alert that says, Hey, right now I need you to respond to this ticket and you're asleep, what good is that, because by the time you wake up, there will be 50 other messages that have buried it and there's nobody that doesn’t actually have experienced that, right? There's nothing that's going to actually tell you like, Hey, here's why you've been selected, here's why it's important, especially if it's just like a blanket notification that goes to a channel. So I think it's much more important to say, Hey, based on your strengths, based on the things that you do every day, based on what your work context is, right now, you're asleep or you're awake, you're available, you're actually writing code, or you don't want to be disturbed, here's the thing that I think is important for you to do next and here's why it's important Hopefully, it helps drive some internal motivator for you. It's important for you to do this, because you're going to learn something interesting, or because you're helping your team out or because it's necessary for this other reason. I think that's better than just Hey, there's an alert, it went to an email, it went to 30 people, and hopefully somebody grabs it. Nobody knows why it's important, no chairs and I don't think it requires Jarvis level yet, but it definitely will be better once it gets to Jervis' level understanding of who you are. where you are, what motivates you and protects actual maker time. I don't want to have it where you're getting a notification either where you're heads down trying to solve a problem and it says, Hey, somebody mentioned you in a comment on a JIRA ticket about what color the button should be and you don't care about that. I'm not working on that, right? But you might care when you're this way and they tell you're working on the button.

Botond Seres 1:01:48

No, sure. Yeah. So how far do you think are we from that level? I mean, naturally, I'm not asking how far we are from a workable prototype, but how far are we from your ideal scenario that you will be satisfied with?

Myron McMillin 1:02:05

So what we've been doing with Botani doesn't have any really super sophisticated AI around the word context and I think that's what the most important piece is, how do we actually know exactly what you're going to be working on right now? What state of work, not necessarily, are you? You know, we're not measuring mouse movement and keyboard clicks to know whether you're working but it is now a good time contextually, for us to actually let you know that there's something else you should do. Because there are interesting things we can do around helping to habituate behaviors, stalking habits and doing other things that I think are really interesting. I think the fundamentals though, you know, Hey, here are things that are important, that require your help based on certain attributes we can pick up are currently something that exists in Botani. I see other products that are coming on the market that do similar things. Maybe not quite as well as what we've got, but I think we're there. I think we're on the cusp of these data driven engineering management, like developer experience, workflow and team ops tools, that are going to start to revolutionize things because it's going to be hyper personalized, hyper targeted, and hyper contextually aware of you as an individual, what is meaningful for you, and what has the highest impact on your projects and your teams. So I think it's where, team management and where project, workflow and process management is going. Cool. This has been a blast. I really appreciate getting to talk with you. It's always great to talk with you, Dave and Botond. I love meeting with you and getting to talk with you. So let me know any other questions you have. It's an absolute pleasure.

Dave Erickson 1:03:53

This has been a really great conversation for ScreamingBox technology and business rundown. I hope all of our listeners will join us next month for the next one. Thank you very much for taking this journey with us. Join us for our next exciting exploration of technology in business in the first week of every month. Please help us by subscribing, liking and following us on whichever platform you're listening to or watching us on. We hope you enjoyed this podcast and please let us know any subjects or topics you'd like us to discuss in our next podcast by leaving a message for us in the comment sections or sending us a Twitter DM. Till next month. Please stay happy and healthy.