Hello and welcome to uh A from a players to an A team. This is an opportunity to reflect a little bit on what it is like to grow.Um And where those transition points are as we go from a players to an A team, what I mean by that uh to level set a little bit and a player is uh somebody who is so fantastic that there is no question of their skill, their prowess, their contribution, for example, I am not a basketball fan in the slightest.

Um but I have heard Patrick Ewing's name, I have heard his reputation. I can be pretty confident that that is an example of an A player. I similarly, there are a teams and these are the teams that win championships that check the boxes that achieve the goals and that really come together to uh deliver what it is that you want, your team and your business to be accomplishing. Now, I think there can be a tendency in tech in particular to focus in on a player. However, when you get a large enough group, it does not matter how fantastic your individuals are trying to have 50 people all accomplish the same goal with no co ordination, probably not going to get anywhere close to what is needed. So with that in mind, let me take a step back and just lay out a few assumptions because without these assumptions, the rest of what I'm gonna say, may or may not follow. So the first thing I would like to say is that you can have an, a team without individual a players. This is a variation on the whole can be greater than the sum of the parts.

Um The notion that with the right collaboration with the right complementary skill sets, you can really achieve uh success, even if any one individual may not shine in their own star light. And sometimes all you need is a players. Sometimes all you need is one person who can hit it out of the park, uh who can really achieve those milestones. Um who can be the 10 X programmer who can really do all that you have on your to do list your goals, your objectives. Also, I would like to note that process is not a swear word. I think it is really common for process and structures and this notion of constraint to get shunned or pooh poohed in the tech sphere. And this is to me somewhat ironic because everything in coding and technology, uh really everything you are instructing a computer or system to do follows something very rigid, right? We have a lot of creativity and freedom within these rigid systems. And the same is true for an organization processes are what enable us to collaborate together effectively as we get into these larger collectives over processing can be incredibly painful. And I would also like to suggest that the likelihood that a players are going to be enough is inversely proportional to the size of the team said differently when there's just a few people, a players are much more likely to be all that you need.

And when you have a large team, that's where it becomes much more difficult to accomplish that a team championship winning outcome when all you have is a bunch of a players. So what does it look like when it's not enough? Well, it means that your velocity is slowing down. It means that you are missing your targets, missing your goals. It means that you have work that's being duplicated and not intentionally. And it often means that you have chaos and conflict scattered around your organization so really quickly, who am I? Why am I talking about this? Uh I'm the owner and founder of Bellevue consulting. And I describe myself as an organizational efficiency engineer, I have engineering degrees.

That's where my background is and what I've realized is that you can apply engineering concepts in these organizational context and that's part of what I really love to do. So let's look a little bit at how that might work starting with roads and maps. I have spent a surprisingly large percent of my career working on maps of various forms for various companies and that includes creating high definition maps that are used by autonomous vehicles. Those maps can look something like this, uh where you have information about the roads and the lane lines, um and potentially even vehicles on the road and even on something as straightforward as a couple of lanes going off into the distance, you can have errors. Now, in HD mapping context, the way that we addressed errors uh had to be scalable because when you start looking at more complex situations, you're going to have a lot more errors. And there's a lot of roads, even if you only look at highways, even if you only look at the United States, never mind all the other roads in the rest of the world and the country. And so you need to be able to communicate, not just what the map of the road is also a level of confidence in that map. So this is an additional layer of information you can read in to this high definition mapping data.

Um In the case of, of your technologies, this is something that they have in their product. It is literally called the quality index. It is a confidence indicator that is put on something like an overpass to tell the vehicle. We think there's an overpass here and we are this confident about it. Now, what the heck does that have to do with people and with teams? Well, imagine you have an idea, you want your team to help you execute it and there's three other people on your team. You can have a pretty high level of confidence that you only need the skills and support of two of your team members to be able to execute. You don't really need to have any additional information uh beyond what's on your, let's call this your sensors, what you can see on the road ahead of you. But when you have an idea and there are a dozen other people on the team, it becomes much more difficult for any one of those people to really know what each of the other team members are bringing to the table, what their skills are, what their strengths, what their confidence is.

And so you have to figure out how can I understand which of these relationships is going to be valuable to me in this context? Where's my confidence indicator about this person's fit into the project that I am trying to deliver? The good news is there are structures to the rescue. And when I say structures, I take a very broad definition of that term. So for example, titles uh are actually a form of structure and then titles often go hand in hand with org structures. Uh One of those cases where we use the same words, whether we're in an engineering mechanical context or an organizational context. Values are are actually a structure because values in an organization. And when I say values in this case, I mean, the lived values regardless of what the stated values are, but the lived values are going to shape how people interact and anything that constrains or guides those interactions. I consider a structure. You can even have goals and incentivized behaviors that are driving how people are approaching their collaboration and their own individual deliverables and overlaying all of it is going to be communication. But let's start for now with a deeper dive into how uh an ORG chart, our titles might be able to help provide that map to understand relationships within an organization. When I showed you that diagram, that was a bunch of people in a circle.

You had no additional information about what they do, what their roles, what their skills might be. But when I put people into this very classic org chart configuration, I'm willing to bet that your brain and immediately made some leaps and I'm also a big believer in nontraditional org structures. However, in those circumstances, you are not uh you have to be really clear about how all of this information is communicated. So sticking for now with our pyramidal hierarchies, most organizations use uh org structures to communicate information like domain expertise, people who are members of this team are likely to be engineers, for example, whereas this team are likely to be product managers, could be marketing, could be sales, whatever it is, we use our structures as a way to immediately provide information about what someone's skill set or domain expertise is likely to be.

Similarly, many organizations also use or structures to indicate the degree of tactical versus strategic work that an individual is doing on a day to day basis. The closer to the front lines, an individual is the better we can expect for them to have a tactical awareness of the work in their domain as we get higher up the levels of the hierarchy, we're more likely to be seeing strategic thinking at play. Now, how much confidence you have about somebody in my engineering team at the front lines thinking tactically is going to depend on how your organization is structured. That's kind of that meta information that you pick up in the broader I day to day existence, the culture of your team. Let's take another example. And in fact, let's look now at how some of those behavioral norms can shape collaboration. So this is an illustration that I found to emphasize uh how introverts versus extroverts might process information. If we're gonna run with stereotypes. Once again, we may have our engineers and our product managers. Now, this has in my experience led to quite a bit of conflict when it comes to team collaboration because there can be differing expectations and what I've found as the easiest way to communicate these expectations is actually to talk about pull oop and push information systems.

Basically, I rather than taking the introverted engineer as somebody who is unwilling to go out and talk to the product managers, you can think of this as somebody who has a pull mentality around information. Uh This mentality expects that the person who needs information is the person who's responsible for going out and finding it. On the other hand, you can have a push mentality around information. And so, rather than uh being somebody who is constantly talking, even when no talking is necessary, this is somebody who believes that they, the fact that they have information makes it their responsibility to communicate it when there's one or two people, a handful of people.

Five on your team, it's pretty easy to know who operates in a pull mentality and who operates in a push mentality. When you have those 15 people, it becomes much harder to keep track. And this is where we start to need organizational structures and norms to guide uh whether we should be following our natural inclination, whichever that may be or whether the expectation of everyone around us is either pull or push. So let's put this into uh practice for a moment and talk about the implications of how these structures might play out. So for example, this is an organization, a company that has one product and they've decided to organize their engineering uh division into a couple of teams that they have broadly shaped around the front end in the U I. The what I'm calling the product secret sauce and their back end and infrastructure. Uh As many tech companies do, they have also created individual uh and product performance metrics that feed into the bonus calculations pretty successful company. And they decided it was time to spin out a second product line. This model works so well for them that they just duplicated it again.

They decided that it would be easier to mitigate the risk if they had a whole new front end team, a whole new backend team that was dedicated to supporting the new product secret sauce. Uh And they decided to keep the incentive program focused on those products rather than including uh an overall company multiplier and in fact, that worked well. So they did it again. So now we have all these organizations, these divisions within this company and something interesting starts to happen because even if you want to lean into that introverted engineer, stereotype, the backend engineers start talking to each other even across the different products.

And the front end engineers start talking to each other across the different products and the product secrets. So folks may also be talking to each other. But for now, let's focus in on what happens to one of those back end engineers. Well, she is being directly motivated by her performance uh bonus which is structured around her individual performance and the product performance. Since her manager is in the same product division, her manager is also being motivated by individual product performance. So chances are pretty good.

Her individual metrics are shaped around that product being pulled that way. And at the same time when she talks to her colleagues, she realizes that every now and then there are some pretty small tweaks, she can make that support her colleagues in the work on their products on the back end. But that's gonna take away from time that she uh could be spending delivering on her individual and product metrics. These opposing vectors can lead to inefficient execution and low morale. When we take a step back for a company like this, we may need to say we're going to actually unify our entire front end organization. We may need to take a step back and motivate them to act in the best interests of the entire company. So with their individual goals and their company performance is how we want to make sure everything is laid out. And the same approach can be taken for the back end metrics and it does not have to be one size fits all. Many organizations uh will then copy paste the same thing to the product secret sauce teams. But perhaps this is a case where there really isn't much that these teams can do to help each other.

And in fact, these are uh engineers who we really want to keep focused in on their individual products. This will create its own separate sort of tension when there are dependencies across, for example, the product secret sauce team, a and uh the front end engineering team. And this is the kind of question and consideration we need to ask ourselves as leaders in uh any sort of field. But let's come back to our backend engineer now that we've made this reorganized and re incentivized change. Now, when she helps her colleagues with uh extensions that are going to support their products across the back end, it is in line with the overall company performance and that's going to raise her efficiency. Uh It's going to raise her morale and her motivation. So let's come back now to my basketball slide from the very beginning. I mentioned that I am not a basketball fan. And so what I did not know is that Patrick Ewing has never won a championship and he's retired. So he's probably never going to win a championship. It does not change the fact that even I know who he is and know that he was a fantastic basketball player, but that was insufficient for him to ever get that championship ring. And at the same time, this particular championship team, these uh 2000 Pistons, they won a championship without anyone who was flagged as an all star.

So we can have our championship teams that come together and succeed that truly are greater than some of their parts when we give them the structures and the support that they need. Thank you so much for joining me today. I'm Belle Locker with Bellevue consulting. Please reach out if you'd like to talk further about how you can take your organization from a collection of a players to a truly high performing a team. If there are any questions now, it's a great time to put them in the chat. Uh And I believe we'll be closing the webinar shortly. Uh I do see one question around. How do we know when it's time to make that shift? And I would say when you start to have questions, when you start to feel that circle pull, when you no longer have that high confidence in the uh knowledge flowing back and forth across each of those relationships. When the person to person contact is insufficient for your needs, it's time to start bringing in some more formal structures that your whole team can rely on to up level that collaboration. All right. Thank you very much for joining me today.