vas3k's blog
IT is a team game. Sure, the ability to write higher-order functions on a mechanical keyboard is an important skill for a beginner. But the more experienced you are, the less important it becomes. Unfortunately, neither recruiters nor even some programmers realize it.
The industry has grown up but there's still a noticeable imbalance. The word "Team" still sounds like a buzzword from those bullshit PowerPoint presentations, and being a "manager" is considered "lame" among developers. Mostly because of these classical fairy-tales about "he was a good developer and became a terrible manager".
Well, don't worry, most of us were terrible developers too! :D
In this article I tried to compile my own experience in the industry and how I see the difference between a truly effective non-bullshit team and "the team" from HR's presentation.
⭐️ Buy offline version of this article
to support the author
Special thanks for helping me in this translation: Libfitz, Enchantner
😎 To understand yourself a bit better. First things first. Impostor syndrome is the most popular thing in IT right now. A remedy for it can be found in learning more about the reasons for all this and getting a real understanding of what’s going on.
👨👨👦👦 To build truly effective teams. Different objectives require different units. You should have a clear vision about which kinds of characters your party lacks, and which you have in surplus. Who will be a great collaborator and who is the breakthrough loner. Who's gonna leave the company soon, screaming about “betrayal”, and who's gonna take their place. Or maybe it is your turn to leave now?
💃 To hire people who are a good fit for that. Recruiters and HRs can't dig that deep. You have to help them.
🤦♂️ To build relationships with others. Understanding how to talk to that pompous dude who can’t add a single field into an API response for months, asking you to get specific permission from management, CEO, that cleaning lady… Well, damn!
👵To know how to stay sane in IT when you’re becoming an old shark yourself.
These are like your car's dashboard. You have to look at your speed and gas level from time to time to know your travel capabilities. Same with teams. Sometimes it's obvious, other times you have to "fly in a fog" using only your instruments.
My current theory will be built around these three indicators:
1️⃣ Project evolution stage
2️⃣ Character level
3️⃣ Character class
Each one is important. Let’s take a deep dive.
At the end of this blog post I’ll reference original books and models that formed the basis of the story. At the moment though I’ll try to avoid any overcomplications.
In personal conversations, we usually name companies using the stereotypes — Smoothie-Startups, Bloody-Enterprises, or Outsource-Bodyshops. Such simple classification is intuitive and warmly accepted in the developer's community, but, to be fair, not helpful at all.
In the real world, it's rare for a company to purely represent one of the extremes. A huge corporation will always have its own set of experimental startup-like projects. A product company can quietly turn into an outstaff-bodyshop serving one big client (or even its own investor).
That's why it's always more important to look at how a specific project looks. This leads us to the first key picture:
Any project begins as a "startup", moves through the "rapid growth" valley, ultimately reaching the plateau of "Success, Inc.", weltering slowly in "reorganization"; yet any stage isn't safe from "failure" or "crisis". The same applies to the whole company if it only has just one project.
The New cycle of a project's evolution is like a new world in an RPG game. The number of resources, types of units, their motivation, the whole adventure's goals are changing drastically
Knowing your map is incredibly vital.
Here’s a highly opinionated picture of some of the known IT companies on the map.
As always, the picture is based purely on my own feelings. No insights or anything. I only give it here so you can understand the concept.
Motivation: ⭐️⭐️⭐️
Team: ⭐️⭐️⭐️
Resources: 💩💩💩
Stability: 💩💩💩
The starting cell. We’re launching a project from scratch using any resources available. Literally.
The Goal Get together all opportunities and launch the product. No restrictions, complete freedom, but no stability and usually not many resources in your hands.
A startup’s main advantage is its speed and, of course, smallness. The idea of “Becoming a new Facebook” is a proven way to failure, and I’m not the one to tell you that.
99.999% of startups will shut down tomorrow. A good one knows that from day one. The worst thing to do at this stage is trying to think long-term, establish processes, write documentation, dream about millions, etc. The real gems are those who understand and approve of such a "slacky" approach.
The Team A bunch of hypermotivated folks. No "old men" (in the soul, not their age), as they can't do startups. Performance is key, and high wages aren’t. No bureaucracy, but no established processes either.
The Focus Do more, think less.
Motivation: ⭐️⭐️💩
Team: ⭐️⭐️💩
Resources: ⭐️💩💩
Stability: ⭐️⭐️💩
Our startup is now a growing to profitable product. We're in the expansion state, which is actually rushing between startup-ish "we need that feature asap" and "let's stabilize the success".
This cycle is nice and pleasant, people love to join such teams, but for every new iteration it tends more toward stability. People are becoming exhausted and their first burst of motivation from the novelty effect is coming to an end.
The Goal Reach the stable ground. Then start a startup again.
This is the point to start writing documentation, paying those technical debts (who would have thought that unit tests aren't useless, ahahaha), and hiring new characters for the upcoming adventures.
The Team First burnouts. Some developers are leaving and replaced with less motivated folks. Also, say hi to the first bureaucracy. It is small yet but is increasing with each iteration.
The Focus An even split between doing and thinking.
Motivation: ⭐️⭐💩
Team: ⭐️💩💩
Resources: ⭐️⭐️⭐️
Stability: ⭐️⭐️⭐️
The structure is stable, cash flow seems endless, processes are mature, and the corporation is unlikely to derail in the foreseeable future. Our founders are close to releasing their first book "Five secrets of our success" at the end of this year.
The era of stability begins. A broad middle management class emerges. No one wishes to change anything. Except for the number of their stock options, of course.
The only issue is that no company will settle here for long. Growing bureaucracy and inner disagreements will ruin everything soon. That's just human nature.
The Goal Just relax. No one will manage to get anything done anyway.
The Team Usually, by this time there are only a few members of the "old" team left in the company. The rest are done because of unbearable bureaucracy, so they cash out their stock options and leave sailing for new startups.
They are replaced by the market's average, and these people wish to follow orders, leave at 5:01 p.m., and attend team events to play some more dead ass pub quizzes. Well, at least they feel motivated.
The Focus Do nothing, change nothing, just continue thinking building bureaucracy.
Motivation: 💩💩💩
Team: ⭐️💩💩
Resources: ⭐️⭐️💩
Stability: ⭐️⭐️💩
The most unpleasant time. "We're not going to change that, we were doing that for ten years", some of them say, despite the company clearly flying downhill.
No one believes in the crisis yet. Any successful attempt of saving the situation is taken for granted, so don't expect any bonuses for that. On the bright side, the infrastructure is still great, and the money still flows.
The Goal Precisely find and neutralize any critical issues without making too much noise, which will otherwise be heard by bureaucrats.
The Team Demotivated. You can clearly see it from day one — people can't explain what they're doing and only can blame someone from another team for whatever reason.
The last "oldie" just left for FAANG. Everyone's competing in toxicity while scrolling LinkedIn. HRs are painting the walls with quotes like "success doesn't come easy", but even this doesn't seem to help. ORLY.
The Focus We seem to be doing something among the lines of thinking and explaining the need to change to the bureaucrats. They aren't listening.
This is the managers' time. An ordinary developer won't be able to push through with his ideas, because he'll definitely be beaten by bureaucrats.
Motivation: ⭐️⭐️💩
Team: 💩💩💩 (generally changes)
Resources: ⭐️💩💩
Stability: ⭐️💩💩
When reorganization fails and resources are over, the full-blown crisis starts. Finally, even the bureaucrats are aware of it.
The Goal Save the ship at any cost, including a full 180-degree pivot.
The Team Usually fully replaced, including management. Bureaucracy finally takes a step back and we can see good old startup times again.
That's the reason why "anti-crisis managers" are basically startupers in essence
The Focus Do whatever, change whatever, just survive.
A brand new company with refreshed products and goals may be born after exiting the crisis.
It also maybe not.
This way expansion or reorganization starts again. Microsoft once was a good example of that.
Nowadays, every IT company invents its own way of grading engineers. Apple has five levels, Microsoft went with thirteen, and Netflix has, well, one. Everyone's a Senior Engineer by default. Why? Because grades don't really mean anything.
One of the main reasons corporate grades exist is to artificially increase the number of steps that an ordinary developer should climb to get new bonuses.
Companies know that software engineers are getting upset if they don't promote them at least once a year, so they made up these steps to make careerists feel like they are "growing" all the time.
The presence of these levels has never ever in the history of the world stopped a company from skipping one or two if suddenly "this dude is really good and we need him". From the company perspective, it's just another way of cashless rewarding. Which is always good.
The biggest problem, however, is that these levels are totally incompatible between different companies, and looks like nobody managed to invent a "standard" model yet.
Well, I discussed this topic with all my management friends in IT. And I think I've figured out a model that suits us all. It is based on common grades like “junior-middle-senior”, but it draws a sharp line between them.
Minimal viable character. Knows basic algorithms and can solve a task if someone shows him/her how to do that. Usually just graduated from university or some "from zero to hero" programming courses.
A pretty popular fraud is to hire Juniors as interns. This may lead to people thinking that the Junior position is totally miserable, so everyone needs to aim for Middle straight outta university.
«I'm already a middle, so in a few years I can become a team lead, right?» That's where the path of broken dreams and burnout begins.
Well, sometimes you CAN jump over a Junior position if you have several pet projects or by doing freelance work during university. But now those guys are like endangered species because every modern student wants to start a youtube channel or a podcast instead of these boring hackathons.
Description? Junior knows things, but can’t do them alone. This makes him different from an actual intern, who you would have to teach basically from scratch.
Why does our team need one? Juniors are better to be hired at times of stability when your task management software is full of routine and non-critical tasks (low hanging fruits), which nobody wants to pick up. The company gets that Jira ticket closed; Junior learns by fucking up doing, gaining experience along the way. Seniors can mentor them and train their soft-skills, adding some new stars to their Performance Reviews. Win-win for everybody.
Experience 2-3 years
How to interview? Pay attention to the passion. A strong junior is always looking to learn and try something new. That can really tell the difference between someone who came to IT for high wages and someone who really loves it.
Ask him about the basic things in your field: how to make an HTML form on the web or compose a simple query for the database.
The main idea here is to not have that “oh crap, we’ll have to teach this guy a lot” feeling after the interview. Instead, it should be closer to “he/she’s alright and will probably handle some tasks that I can give”.
Independent unit, who able to solve any technical task alone. He knows how to ask questions and deliver working solutions. Knows dozens of languages and frameworks because he still considers programming the most important part of the development lifecycle. Don't disappoint him yet.
Description? I define middle as an engineer who is technically able to do anything that is asked of him. Middles are the foundation of any team. They haven't got snotty yet, but are already experienced.
Why does our team need one? To write code (ORLY?). Middles are independent, but not autonomous. So they work the best when being supervised by a senior or a lead. Without specific tasks, they tend to get bored and start replacing JS libraries with more shiny ones.
Experience 3-10 years
How to interview? Most articles about IT interviews are written specifically with middles in mind. Just read them and you're good to go.
That's because the middle is the last level that can be interviewed solely on hard skills. Questions like "how would you implement a system like that...", "what technologies would you use for...", and "why not something else" is perfect for a middle.
The goal of interviewing is to see if that folk is able to deliver on any task without showing off. Even by talking to others or learning something new during the process.
An intermediate stage between middle and senior.
Because it's not so easy to spend 5-7 years as a middle. The developer has grown a lot, but not his grade. HR's still call him "middle" but he's a completely different "middle" than 5 years ago. That's why smart guys usually divide middles into low and high.
Description? A high middle is almost a senior. Already autonomous, but maybe lacking some soft skills, or vice versa. There’s no specific title or workloads for "high middles", but these guys are always covering everyone's ass in different situations. You can't yet award them a "senior" medal, but you can at least pay them accordingly (that's what fair companies do).
Why does our team need one? This is your new senior when the company expands, sparing you the search for a new one. Hiring a new senior from scratch is usually expensive and takes at least half a year for teaching and integration. "High" middle can do it in two weeks.
Yes, I was a senior developer at my 23 too.
In my 30+ I'm more like a middle.
Fully autonomous unit with many years of experience and vast expertise. He's been to many companies and have seen every stage of the evolution. Programming is no longer art for him, but more like assembling LEGOs from known building blocks.
He developed soft skills and understanding that a lot of challenges can be solved without code saves a senior from boredom.
Experience is like good wine. You can't "work hard" and get it fast. It just needs time. It's the same with the seniors.
The main secret that not every company understand: you do not need to constantly try to hire only seniors. They cost 5x more and it's 10x harder to manage and lead them. The majority of modern IT challenges require zero experience — middles are just more profitable to have.
Juniors know things, middles can do things, seniors have an experience
That's my principal division.
Instead of thinking "which framework to use", seniors are more focused on business challenges and questions like "why we should do that at all". They don't give a shit and combine soft and hard skills pretty much equally.
Why does our team need one? To do everything correctly right away, not as usual :D
Experience 10+ years min (really depends)
How to interview? Here's when things become complicated. Seniors don't care about your AVL-trees and algorithms on a whiteboard. They think in larger blocks. It leads to the fact that recruiters are often rejecting good candidates, because they didn't have a full mouth of buzzwords.
It's always easier to assess someone's knowledge than evaluate an experience.
These are the questions I often ask those who supposed to be senior: "you need to build that abstract project, what are you going to ask your project manager and what resources you'll need (at least) for the next six months", "how would you choose between X and Y", or "what will you do if your team member fucks something up".
Of course, there's no simple answer to them. Expect to have a mutual dialogue for 10+ minutes to understand at least something.
0 I am Senior, not even 25 yet! 0 I am Senior, but older
aka. tech lead, team lead, squad lead, tribe lead, or "whatever methodology you use this summer" lead
This is a senior who still can code but fully is abstracted from it. Instead of committing his own PR's, he tells others how to do it, simply because it's more profitable for the company in the long term.
Why does our team need one? To scoop through obstacles on the team's path. To define that path. To be a liaison. To hire and to fire. To report. To dig through shit even further, for these and for those. For a broader skill set, take a look at Team Lead Roadmap.
How to interview? Purely by soft skills and culture fit, like Google does on their culture-fit interviews. High-level code questions are allowed, but that's about it.
The crucial thing is for the team to accept their new lead. I've seen several times when the leader was hired "quietly" and the team just treated him like another pain in the ass scrum-master, lost all productivity and a year later he was fired. A good lead will also understand that himself.
Good questions that I usually ask: "Imagine that middle-dev John came to you and asked to make him a "senior". What would you do?" (Bad answer: assess his skills, make goals, reviews, bla-bla-bla. Good answer: dig deep into the real reason for that — does he need more money? Is he jealous about his already-senior-fiends?), "what should be done when two team members made a fight about some new framework and don't talk to each other", and "describe an ideal method to evaluate developers' productivity".
It is also important for the team to hear the answers. It's quite common for the team to dislike those answers which are liked by managers. From my experience, this road leads to nowhere.
There's a long tail of techy-managerial "high grades" in a lot of companies. Managers of managers of managers.
Don't confuse with regular managers, a-la product ones, who can be hired fresh from a university. Tech managers are explicitly extending the engineering vertical. They solve the same engineering tasks, just a few levels higher. And dream of writing code again.
Because writing code is the simplest and most enjoyable thing in the whole development process
Somebody's got to really drag this train forward, right? Even if it means dragging these Jira tickets around, or schedule meetings because no one else can.
Further growth is purely tied to the company hierarchy. In the end, you either grow up to a CTO position (rarely) or you are hired by a competitor for a CTO position and 10 times more money (more often).
Yet HR masterminds are glad to invent some new titles like "Senior Exceptional Engineer". It allows:
✅ To keep core folks through large stock options, salaries, and high-level challenges. You're more motivated to get over things knowing you'll afford a new home in a year.
✅ To create an imaginary feeling of the "need for active growth" in mere developers in previous levels. Companies tend to make the promotion rules beneficial for themselves, like "should actively participate in guilds, write technical posts for corporate blogs, and organize meet-ups". Sure enough, the promotion itself will happen when there's a vacant spot, not right away. This provides the company with additional levers to push and ways to motivate. Oh, and free PR of course.
✅ To… erm… CULTURE. GOALS. MOTIVATION. Do you participate in our company's yoga classes by Zoom? It's soooooo funny you know))0))))
Classes define the set of skills, strong and weak points of every team member. Everyone has weaknesses, but in a good team members always cover each other.
Understanding classes is important to:
The key is to not overdo this or it'll all turn into a horoscope or a human-design sect.
It's like a new chainsaw. It's good that you have one but better keep it in the garage and don't use it on people. Even if you really want to.
Many HR systems divide people into 48 different dream classes like "Passionate Dreamer" or "Wily Artist". The main problem with them is that I can't remember them all, that's why I've never been able to apply them in real life. Only post factum.
Personally, I use a much simpler class constructor, where some are building blocks for others.
I always try to identify person's class of on the first interview
Questions like "what would you do in situation X" allow me to perfectly see that. I combine them with technical questions, of course. The goal is to hire a cool engineer, not to invent another abstract IQ test.
Every character may have more than one class or even none. The latter would be harder for everyone, honestly.
Those who do things. Call them workhorses, eager beavers, workaholics, it doesn't matter. These are the foundation of every society, like builders or miners. They just do their job (c). Seeing a list of Jira tickets, doer takes the top one and get it done. Take the next one when finished. Repeat.
Doers won't accept unorganized people. He's like your dad.
For them, any bad news is just another sign that everyone is lazy and should "just focus" and "work more". Doer doesn't know how NOT to work.
Why does we need one? To do all the work, of course! No kidding, someone in the company has to do it. Doer can write unit tests for two weeks and not go insane. Can you imagine that?
Cons Doers constantly buzy and don't have time. They are either up to their eyeballs with work, or burned out and depressed.
It's common for a Doer to grow and gain additional skills. Because having a pure Doer as your manager is literally exhausting, avoid it at all costs. It's pretty popular in poor countries, tho.
Finding common ground Give him clean tasks. Doer doesn't accept any ambiguity. But what can you do if you don't have a clear objectives (as often happens)? Then you should improvise or invent something. Doers not gonna help you here.
Don't forget to constantly remind them that this is a marathon, not a sprint. It really helps.
That folk over there with fifty new ideas in his head. Sure thing, each one must be done ASAP because "it's bound to succeed".
Every morning, he tries to convince the team to switch to that new fancy JS framework, which he saw this morning on Hacker News. The next day he forgets about it. His morning routine usually starts with thinking that NOW IS THE TIME to rewrite everything from scratch.
Not everyone in the team buys his candies, but people like him are usually the main source of inspiration. He knows all the trends, which can be really useful.
When does we need one? When launching a new product, or growing rapidly, or getting out of a crisis. Basically, everything that is not stability, because stability sounds like death for him. Explorers don't stick around for long in a big and stable companies.
Why? To inspire others, to introduce and test new ideas, to throw away those boring 2-month-old technologies into the garbage. No one writes code this way anymore! Everyone uses Rust now!
Cons Explorers love to start but rarely can finish. There's always something "more promising" on their horizon. It's hard for them to think long-term and they tend to leave after the very first crisis.
Finding common ground Explorers meet any of your ideas with YEAH-SURE-LETS-DO-THAT and they forget it five seconds later. That's a problem. If you're a manager, use generic supervising approaches like "could you create a task for that" and "ping me when it's done". It works, usually.
A bureaucrat doesn't care WHAT to do, he cares HOW. The process is God for him, and success will only come if you can make a plan and perform all its steps correctly.
Bureaucrats hate it when something's not in order. They wipe their monitor with a 96% wet cloth every Monday and put all their lovely blue pens ordered by their blueness underneath.
Why does we need one? To bring order and build processes. To protect the product from non-elaborate actions. Bureaucrat’s main goals are documentation, structurization, and dealing with technical debt leftovers after Doers and Explorers.
When? After we're past the startup stage, growing steadily, and the risk of losing a shitload of cash is not as unrealistic as before. Bureaucrats make the lives of others insanely hard, but they preserve the system as a whole. A paradox indeed.
Cons Absolute bureaucracy is like the heat death of the universe. It's as effective as a rolling ball marble machine on YouTube. It's fascinating to observe the balls move by complex paths, but there's no sense in the movement itself. Everything is a process now. You're dead.
Yet bureaucrats can be useful despite obvious downsides. Just imagine who you'd ask to fill in your tax declaration: a meticulous Bureaucrat or a creative Explorer, who's unable to sit still for more than five minutes at best? Exactly.
Finding common ground Bureaucrat's default answer to every question is NO. It's totally fine. Take a deep breath and continue with your reasoning. You may even keep your arguments unchanged. As you point to how this will improve the processes and organization, you'll eventually hear that sacred YES. That's how it works.
After that, you may be 146% sure that everything will be done by the due date. Don't even try to control a Bureaucrat after his YES, it would personally offend him.
Remember that funny guy who writes a very average code, but has friends on all teams? He is the first to answer all questions at Slack, he started that channel with coding memes and constantly goes to meetups and conferences. That's a typical integrator.
Why does our team need one? To connect people, of course. We really suck at this. To support exchanging information. To be a facilitator between different teams. Finally, just for the atmosphere.
In other words, even if he's not digging the trench with everyone, he's still useful to the team, because thanks to him the others dig much better.
When? Integrators really shine during reorganisation and crisis. They integrate newcomers and unite the rest. However, there are fewer opportunities for integrators in a startup, because there are fewer people. They usually call startups "boring".
Cons Integrators always tend to agree with everyone and look for a weighted point of view. It's good for negotiations, but it also means that you shouldn't expect any groundbreaking ideas from them. You need an Explorer :)
Like Bureaucrats, they’re more defensive players than offensive. The difference is that they're uniting people with relationships, not processes.
Finding common ground To lure the integrator to your side, you need to negotiate not with him, but with all those around him. He's moving towards them.
0 Looks like I’m an Integrator!
The above classes are not accidentally called base classes. Pure Bureaucrat or Doer can be found only among junior-students or (in very rare cases) in large company isolation. Because the basic classes are not able to survive alone, but their combination can.
Any specialist above middle level combines at least two classes
Our goal is to identify the mixture correctly. I'll show some of the most popular examples around me, you'll think of the rest.
A Doer, who generates ideas himself, immediately implements them and throws them away tomorrow to start a new one. Perfect striker. He solves problems faster than anyone else has time to understand them at all.
Startuper's main disadvantage is that he can't live in stability. The bureaucrats are causing him physical pain.
I’m very familiar with this class, because, well, I am the one. I try to gain Integrator’s experience points now because they might be very useful to level up in the future, but so far I always end up being a Bureaucrat :(
A Startuper's counterpart. A perfect guard. This character adores having a finger in every pie and contact in every company. He spends his life to "put things right".
Could often be found in the Security Team or any other department when it's more necessary to guard than to create. Sentinel ensures that not a single byte travels over an insecure connection. When he finds a breach, he looks for the one responsible and executes him personally. That's the joy.
A union of Explorer's love for experiments and Bureaucrat's structural approach. Every idea is noted, analyzed, and put on a diagram. Give an Architect an extensive research task, and you'll get a definite plan or a complete project's architecture after a week-long exile in his office.
However, he is not the one to implement it. He’s not a Doer after all. But he can develop that skill too.
Troubleshooter solves problems. Simply adores this shit. The only way to feel satisfied is to find someone else's problem and help with it. Your production environment went down during the night? Not an issue! Get ready to listen to the next morning about how he fought the bugs until 6:00 a.m.
He's kinda like a Startuper, but he can survive in a big company's bureaucracy for much longer. Thanks for the integration skills.
Having one class is nice. Two make an autonomous unit. But there are characters who lead everyone into battle. They are respected and followed not because they're bosses, but because of their insensible personal qualities. We call them "Leaders", but in our scheme they have a very simple definition:
The leader is the one who combines not two, but three classes at once
👩🔬 + 🏃♂️ + 🤝
👨💼 + 🤝 + 🏃♂️
...
Any of them. In various ratios. Sometimes without even knowing it.
Don't confuse The Leaders with team-leads and managers. Team-lead is a rank. It can be obtained through seniority. Manager is a vertical, parallel to engineering, you can become a manager straight after university if you read a few smartbooks and memorized magic Scrum/Kanban spells.
The Leader is a special character. Something similar to an "opinion leader".
I won't be diving deeper into leadership, this post is long enough already. I will, however, leave a few books for further study.
As I said, everything above is just my own interpretation of things. I'm totally biased, as any other person. Don’t take anything literally and never use it as a manual on how to deal with things in the real world. Compile your own.
I think it would make more sense for you to develop your own theories on the matter, from my side I can just recommend some good reading that I used. Some time ago my own Leaders recommended these to me as well.
This is where that system of company evolution stages was taken from. Michael even used a fancy word for it, so it’s named STARS. Looks like the coaches really love their motivational abbreviations, especially if they have something to do with the cosmos.
Besides all that, this book is pretty good at explaining how to survive during each of these stages.
I took the base for those character classes from this one. The only thing is, in this book, they are called Producer, Entrepreneur, Administrator, and Integrator, which gives us PAEI. The main value I saw was also in descriptions of how people from different classes can possibly interact without biting each other’s faces off.
This book is clearly aiming at managers, but I suggest most people who ever interacted with their colleagues should read it. Yeah, that pretty much means “everyone”.
There are many other models like these. From the top of my head, I can also remember DISC and a collection of personalities from Myers & Briggs. Not sure which of those influenced my views more. Most of these ideas were literally invented during the previous millennia, and you can even find Carl Jung himself if you dig deep enough.
But I guess you shouldn’t. Remember the chainsaw?
Oh, by the way, Team Fortress 2 also has a great collection of characters with unique personalities. No kidding! Also, board and table games like MTG and DnD can be helpful if you want to develop this way of thinking.
But yeah, I was one of those kids being constantly told by parents that videogames are pure evil. What if this was the main reason I grew up so unadapted?
