#6 What teams are for in the Knowledge Economy?
This article explains why teams in the Knowledge Economy are very different from previous epochs, why they have to be managed differently and what managers and team members individually need to focus on in comparison to the Industrial Age and before. The key thing is that teams in the Knowledge Economy must be collaborative, not competitive, and the people must complement each other, so instead of fighting their weaknesses, you have to grow their strengths.
Reminder about what the Knowledge Economy is.
To put it short, the reason for the Knowledge Economy is that the knowledge required to make a product, component or service does not fit anymore into a single human head. That’s it. It’s that simple. But it has serious consequences.
Let’s compare it to the Industrial Age and before. Suppose you have a factory producing hex nuts. Or a coal mine. Or a piece of agricultural land growing wheat, strawberries, potatoes or apples. In all these cases the same statement is true: get ten times more people, give them the equipment and the place, and you’ll get ten times more of that product or the same amount of the product ten times faster. Actually, this was true since the ancient slavery societies. Occasionally it was not completely true, because for example in feudal societies you needed ten times more peasants and ten times more land, but historically production of food and goods by humans was ultimately scalable. Put ten times more resources, you get ten times more product.
There is a reason why another name for the Industrial Age is “mass production age”. Mass production requires scalability, and all examples above are scalable. So ultimately scalable production required the kind of management created by the Industrial Age. The management with fast layoffs and hiring cycles to adapt to the market changes, the performance system to raise individual contributions, fairly cheap to train workers and so on.
Not in the Knowledge Economy.
In the Knowledge Economy:
- Knowledge workers are really expensive to train. Entry level IT engineer (“college hire”) requires 15-16 years of studying if you count school.
- Knowledge workers are very expensive to find and hire. On average a headhunter’s prize for finding the right person, who is actually hired by the company, starts from about 15% of that person’s annual salary, and in especially tough times may reach 100%.
- Knowledge workers are very complex to manage and expensive to maintain. If you mismanage them you end up with the costs for sick time, EAP programs, PIPs and more, because your people are burnt out and squeezed like lemons.
- But most important is that knowledge workers teams are not scalable. As Fred Brooks put it in his “Mythical man-month"(1) in 1971 “The bearing of a child takes nine months, no matter how many women are assigned.”
That’s the key thing you need to understand about the Knowledge Economy to understand the message of this article. The knowledge to produce the product does not fit into a single head, so you have to make people to work together instead of competing with each other.
Why do we need teams in the industrial age and knowledge economy? What’s the difference?
Consider the examples above. People in the Industrial Age don’t have to interact with each other much. Their supervisor just puts them on different parts of the field, different metalworking machines or different places in the mine, and they just do their job. You can even make them compete with each other: who gathers more apples, who produces more hex nuts or who mines more coal.
In fact, the purpose of teams in the Industrial Age is to scale, to make more stuff.
Not in the Knowledge Economy. There, you get people together to make them work together, because not a single one of them can make the thing you want. They had to work together to make it. They have to collaborate.
They have to fit together like pieces of a puzzle to produce the result. And if you make them to compete with each other, they won’t fit. Not because they could not be managed to fit, but because you make them not to fit, to compete.
What does it mean for managing the team’s performance and people's development?
Again, in the Industrial Age team, you want each team member to perform in the same manner. If they harvest apples, you want each member of the team to harvest as many apples as they can. You can even make them to compete with each other and reward those who collect more apples. And if one of them walks slowly and it prevent that team member from harvesting as many apples as others, you to fix that weakness and make him walk faster. That’s the Industrial Age.
Not in the Knowledge Age. Think of your car. You want your engine to push the car. You want the headlights to light the road. You want the wheels to provide traction with the road. You don’t want your engine to rub the road or light it, right? Trying to explain it to an Industrial Age manager, tt’s not the engine’s weakness, it’s just not what the engine is for. Don’t try your engine to fix its weaknesses, or you won’t drive too far. Makes sense?
They work together and they put together their strengths, not weaknesses. So, if you want to improve the team's performance, you grow people’s strengths, not fix their weaknesses.
Back to the car analogy, don’t make your engine rub the road, don’t make your tires light, these are normally considered a bad thing. And definitely, don’t make your headlights to push the car, after all it’s not a photon starship!
Caveat emptor!
You may think, “that's easy!” After all, there is a job description! Yeah, right. Let me quote the question from my lecture I did at my Alma Mater more than 15 years ago. “Which language, do you think, is most important for a software engineer? C++? Java? Python?” The answer is simple and evident, but most people don’t get it. English!
Don’t forget, your teams must be collaborative! And for that people must communicate. Not in C++, not in Java, not in Go, not in Python. In English! Or whatever language your company uses.
Even a junior engineer has to do a lot more than just writing code. Junior engineers need to:
- Write clear design docs.
- Present their design in a precise, clear and easy to understand manner.
- Being receptive to feedback from more experienced peers.
- Communicate timeline expectations and changes.
- Constantly learn, especially new systems and tools that are needed on new projects.
- And much more.
And that’s just junior engineers. What about the senior ones? If you think about strengths and weaknesses of a senior enginner, you get an instant list of very different senior engineers who do very different things. A senior engineer may be:
- Good at communicating up, sort of PM.
- Good at communicating with partner teams and making them happy to work with you whether you need something from them, or they need something from you.
- Making great top-level system designs and capable of smelling a trouble in other people’s designs long before they become code, sort of an architect.
- Making the team stick together and communicate, providing advice and helping people to reach each other when needed.
- Run agile methodologies like SCRUM and make people stick to it and feel good about it.
- And more.
And all that fits “senior software engineer title and job description”.
- Do you think anyone can be good at all of this? And if not, the person is just a bad engineer?
- Do you think that if anyone spends a lot of time doing one of these things, probably, because no one including you does it, would have time to write a lot of code? And if not, the person is just a bad engineer?
Or maybe you just a bad manager, who does not know all the things needed to run the team and not seeing or appreciating their contribution?
Think. Some people say, it helps.
1 The Mythical Man-Month. Essays on Software Engineering Paperback – by Frederick Brooks
Comments
Post a Comment