Part 1. How to Get Rich: general principles and the psychology of ownership (insights №1–17) — → read
Prologue
Part one of this series was about me — about how I think, where my decisions come from, and why money isn't the goal but a tool. This part is about the people around me. Because at some point I understood: for years I'd been covering other people's unfinished work with my own time. I didn't build a team — I carried the business alone and called it work ethic. It was the most expensive mistake I've ever made, even though I'd already put a version of this more briefly (here): the team a manager gets is the team they deserve, and if you look further out, that's also true of the product their company ends up building.
I also owe a confession here, one I'm not proud of. This whole time, “working on the team” mostly meant working with each person individually — one-on-one, separately, not with the team as a single unit. I wish it hadn't gone that way: the upshot is that I've probably never actually thought in terms of a team — just individual management, multiplied by headcount. If part one of this series was about the psychology of ownership, this one is about how to stop being the only engine and build a system that pulls its own weight.
Give a mediocre idea to a great team and they'll either fix it or throw it out and find something that works. Give a great idea to a mediocre team and they'll screw it up.
— Ed Catmull, co-founder of Pixar, “Creativity, Inc.” (paraphrased)
Insight №18Investors bet on the team before the product or the market
I spent a long time thinking that if you build a strong product and land in the right market, money and a team will follow on their own. Turns out investors — and, over the long run, reality — think exactly the opposite. At the earliest stage, pre-seed and seed, there's almost nothing to evaluate: there's no real product yet, and the market is a hypothesis on a slide. A Sequoia Capital partner, in one interview, laid out what the fund looks at in that situation: 60% weight on the team, 30% on the market, 10% on the product.
That could have stayed the opinion of one fund, if not for the wider statistics.
A large-scale survey of venture investors (889 investors across 681 firms) found: 47% name the team as the SINGLE MOST important factor in their decision — ahead of the market or the product taken separately — and 95% consider it an important factor at all. A separate part of the study looks at how investors explain outcomes after the fact: the team is cited as the reason behind 96% of successful deals and 92% of failed ones. Product and market can be changed. A team that can't execute on either — almost never.
I've seen the same thing play out dozens of times myself: a mediocre plan in a strong team's hands almost always beats a great plan in a weak team's hands. A plan can change in a single meeting. A weak team can't — which is exactly why it costs more than any plan. The plan will change tomorrow. If the team is strong, it'll stay and come up with a new one.
Insight №19A small team beats a big one
A simple rule I worked out for myself: payroll shouldn't outgrow the revenue that part of the team generates. The moment it does, the company stops growing and starts sustaining itself instead. Pavel Durov makes the point even harder — his teams, running products with tens of millions of users, have historically numbered a few dozen people: the fewer people it takes to run the product, the better it's designed. Which is why I'd add a short checklist here — “you don't have a team problem if”:
The result doesn't rest on you alone
Nobody's stuck in constant calls, reports, and syncs — and the results are still there
Everyone can make a decision without you: a decision made by an employee is a thousand times stronger than the same decision made by their manager
You don't see your team capable of more (and if you do, that's fine too)
You don't tightly control everyone — the more you control a team, the weaker it gets
The strategy isn't written by you alone, but by the middle layer too
A good extra test on that last point: is the team building the strategy together with you? If yes, you're evolving as one whole; if not, the strategy stays yours personally, not the team's.
There's a flip side too, also from experience: once a team gets too big, everyone's time — including yours — starts going not into building, but into coordinating a system made of each other. John Katzenbach and Douglas Smith, in “The Wisdom of Teams,” put the ideal team size at 5–9 people: past that, coordination eats the gains from scale.
PS: and it's even better if “small” also means “fast.” John Kotter, who studied dozens of failed corporate transformations, finds the same mistake over and over: leaders underestimate how strongly a team needs to feel that waiting isn't an option right now — without that sense of urgency, any new direction just sinks into the day-to-day.
Insight №20Who's on the team matters less than how the team works
This one calls for another round of self-inflicted honesty. At different points I've had genuinely strong, “star” people on my teams — and the results still didn't take off the way they should have at that talent level. For about three years I couldn't figure out why, until I ran into an answer that came not from my own instinct but from someone else's research: Google, in the work that became known as Project Aristotle, found that team composition isn't everything.
From 2012 to 2014, a Google research group studied 180 internal teams, analyzing over 250 different characteristics — from individual traits to the mix of tenure and specialization. The headline finding surprised even the researchers: WHO is on a team turned out to matter less than HOW the team works together.
The practical takeaway for insight №19: hiring strong people is right, but if the team they land on doesn't provide psychological safety — the single factor Google calls decisive — all that potential stays locked up, no matter what their résumé says.
PS: and honestly, I don't get why a team shouldn't also be fun. I've always felt a team should be as tight as the crew from the film “Rock Wave” (a Russian drama about a pirate radio station) — with the social media running like their on-air broadcast.
That same “how, not who” thread, Patrick Lencioni unpacks into a far more detailed model of cause and effect in “The Five Dysfunctions of a Team.” The most common mistake young teams make is treating conflict as a sign that something's broken. In practice it's the opposite: an absence of conflict almost always means the team is already broken — you just can't see it from outside.
At the base of the pyramid is absence of trust: a team that can't show weakness or admit a mistake can't move forward; the antidote is the leader showing vulnerability first (Go First!). The next level up is fear of conflict: without basic trust, disagreements either go unspoken or turn into personal grudges; the antidote is deliberately mining for conflict on the substance of an issue instead of avoiding it. Third is lack of commitment: without open debate, decisions get made on paper and nobody actually believes in them; the antidote is pushing discussion all the way to clarity and closure, not to a compromise that just buys quiet. Fourth is avoidance of accountability: if nobody genuinely bought into a decision, nobody's willing to call out a teammate for not living up to it either; the antidote is confronting the person directly about the problem they're creating.
At the top is inattention to results: without mutual accountability, everyone starts protecting their own status and their own patch instead of the shared outcome; the antidote is keeping the focus on the collective outcome, not individual metrics.
Insight №21Organization: rules of the game instead of hands-on control
There was a point when I had no “system” at all — just me and about ten fires a day that I put out personally. I built the system the hard way, through plenty of bruises, and only later found out it lines up almost exactly with the classic management functions: planning, organizing, motivating, controlling — roughly in that grouping. What follows is about organization: how to build rules of the game so the company doesn't run on hands-on control the way it once did for me.
The rhythm of meetings matters more than it seems. I used to run weekly one-on-one syncs with every employee personally — which was the same mistake I've already written about: that's managing individuals, not a team. What works better: short daily standups with the whole team, with one-on-ones as needed rather than a mandatory ritual. Meetings need to be a safe place to solve problems, without posturing: the goal is finding what's holding growth back and fixing it on time and honestly, because a problem admitted today gets solved twice as fast as one sat on for a month. Nikolai Storonsky, CEO of Revolut, takes the same principle to the extreme: with 60+ direct reports, he deliberately doesn't do one-on-ones at all — only group meetings, so the whole team stays in sync on tasks and priorities.
Retrospectives are an Agile practice that our companies generally misunderstand and, as a result, dislike: after a failure or a win, the team gets together and works through how to repeat the success and not repeat the failure. That's surprisingly foreign to our culture — without a built-up habit of reflection, these meetings turn into everyone trying to dodge blame and pass the problem along, or paper over it with a universal “it's all fine, let's keep moving,” — and the team hits the same wall again later, because no real conclusions were drawn.
Plenty of companies run on a cult of the mistake: mess up, and it's automatically bad, and the manager will be sure to note it — especially in larger structures, where everyone loves a win and happily piles onto someone else's, but nobody likes mistakes, even the ones people have actually reflected on. That's a surprisingly wrong instinct, because growing a business is a walk from mistake to mistake until you find the way forward; ideally, mistakes should be made fast and cheap. A team afraid of getting something wrong stops doing anything substantially new instead — just to avoid the mistake — and that means it stops growing.
Written, publicly known values only work if they're specific, not generic words on a wall. For me, that means things like: being honest (our relationships run on trust with colleagues, clients, and partners — we're not afraid to tell each other the truth constructively, and if something's bothering us, we say so right away; we're not afraid to own our mistakes and our role in them); the client comes first (if we promise a client a result, we deliver it; if there's a team-wide meeting and a client asks for a call, we take the client — though that doesn't mean the client is always right: we lead the client, not the other way around); strong solutions (if all we have to offer a client is a weak compromise, we offer nothing); and 1+1>2. Rules like these work best written down and made public — Amazon formalizes this in its 16 Leadership Principles, phrased in painfully specific, behavioral terms that people are literally evaluated against in interviews and reviews.
PS. If you work in commerce, it's worth also checking yourself against four questions: is the team willing to adopt new approaches and frameworks, even when it's uncomfortable; is it willing to let go of its own illusions instead of clinging to the old way; is it willing to launch hypotheses and tasks fast, instead of procrastinating for weeks; is it willing to build the customer journey (CJM) starting from the actual customer, instead of dreaming up ideas out of thin air just because that's more fun.
Insight №22Fire fast, and without regret
Firing is the one part of managing a team where hesitation costs more than decisiveness, and here I'll be as blunt as I can: if you can tell someone isn't cutting it, and you're keeping them out of pity, awkwardness, or hope that they'll “suddenly pick up the pace” — you're not being kind, you're being a coward, and the team reads that faster than you do. The longer you keep a weak performer, the more the whole team loses: strong people notice the bar is negotiable, and they quietly lower their own.
There's a technique that helps me decide faster than instinct does: run a little internal “poll” — if this person turned in their resignation tomorrow, what would I feel, relief or panic? If it's relief, the decision's already made; all that's left is to make it official. A second technique: ask the person you're unsure about to spend two minutes defending why they should stay. If the defense is a list of tasks rather than results, that's an answer too. It's also worth keeping cross-functional redundancy: at least two people should understand every critical process, so one person leaving doesn't stop the business.
Bradford Smart, who created the Topgrading methodology, starts from a blunt diagnosis: on average, only about 10% of people in the labor market are A players — in the top 10% for their role — another 25% are solid B players, and the remaining 65% are C players who, at best, just get by. Topgrading's goal isn't to accept that distribution inside your own team, but to use systematic hiring to push the share of A players in the company to 75–90% — many times the market average. Nikolai Storonsky puts the management version of the same logic even more bluntly: cut the bottom 25%, everywhere, no exceptions.
Insight №23Hire the right people… but how?
There's no point motivating the wrong people — there's a point hiring the right ones, and an even bigger point motivating them. Before hiring, it's worth analyzing yourself and your own competencies, assessing the team, its competencies, and its gaps — and only then figuring out the area of responsibility you actually want to hand off, and the competencies the person filling it needs to have.
Don't look for people who simply fit your worldview — collect people who actually deliver results. Those people often have a weak résumé, argue with you, ask uncomfortable questions, and know their own domain better than you do. The difference shows up in a simple example: the right person, sent out for bread, doesn't come back and say “I went, there wasn't any” — they check three stores, come back with bread, and probably do something else useful along the way.
In the interview itself, I ask two rounds of questions. The first round, early on: “Where were you steering the department? Why there? What did you do when the strategy stopped making sense?” The second round, closer to the end, once the first impression has already formed: “What were the numerical targets behind that strategy? Why that specific number? And how did you hit them?” That last question is the important one: if someone can walk you through it at the level of specific tools and steps, their success wasn't luck, and they can do it again.
Nikolai Storonsky sums up his part of hiring in a few words: hire talented people, ideally ones who share the company's cultural values. Separately, he singles out serious recruiting muscle — and in practice that means being able to track which recruiter brought in which employee and how that employee performed afterward, then parting ways with a recruiter whose hires consistently underperform the average.
Insight №24Onboarding is the first 90 days, and they decide everything
By developing new hires from the very start of onboarding, you build a team of strong players ready to push your projects and numbers toward the top. First rule: when someone joins, always ask about their motivation and remember it (or write it down), so you can use it as their main driver going forward — “Why did you take this job? Why did you apply? Why does this field interest you? Where would you like to be in a year? What's your motivation, and how does it shape what you do?”
Second rule: set goals in metrics separately for the probation period, six months, and a year out — and if that's hard for the probation period, define them for its end instead. If someone isn't performing, or isn't hitting 100%, you need to part ways without compromise: it sounds harsh, but what you need isn't someone people go easy on during this window — you need someone who uses their probation period to accelerate on their own speed and strength.
Third rule: use regular check-ins to make sure the person understands what's expected of them and how things are going — give them stretch tasks and projects (“you wanted X — here's a project where you'll be the lead”), agree on the skills they need to build next, stay attuned to how they're doing, and set things up so they achieve things themselves while still feeling supported.
Michael Watkins, in “The First 90 Days” — a book The Economist called “the onboarding bible,” and which has sold more than a million English-language copies — shows that a structured 90-day plan gets a new hire, especially a manager, to the break-even point — the moment their contribution outweighs what onboarding cost the company — up to 40% faster than without one. His model rests on four pillars: understanding the business you've landed in, building relationships with key stakeholders, aligning expectations with your manager, and assessing your own readiness. Gitelman closes this out with a practice of constant feedback: not an annual review, but short 15-minute check-ins every week — growth needs to be checked as often as a temperature, not once a year.
I have a separate letter that I personally send to every new employee on their first day: it spells out exactly what I expect — self-direction, being proactive, plan-vs-actual in numbers, wild ideas — and what I don't expect — lying, hiding problems, not following through on commitments (here it is, in full). It's essentially a condensed version of every rule above, in one document, that a person gets on day one instead of piecing it together over time.
Insight №25A high salary isn't motivation — it's a payoff
The highest salaries on the market are a kind of evil, and I mean that seriously. The best people are never motivated by a high salary on its own — what matters to them is the charge and the sense of fulfillment that comes from building something bigger. Those are exactly the people who should end up earning the highest salaries on the market — but only after they've earned it through results, not as an advance for staying put.
For strong people, a simple logic kicks in after that: if I become better and richer here, I stay. Daniel Pink, in “Drive,” backs this with research: money motivates, but only up to a point — once a basic need is covered, further salary growth barely moves engagement, while autonomy, mastery (getting better at what you do), and purpose (understanding why any of it matters) do. More than that, Pink shows that on complex, creative work, if-then money rewards (“do this, get a bonus”) often lower the quality of the result instead of raising it, because they narrow attention down to the most literal reading of the task.
Gitelman adds one more layer: shared goals need shared rewards. If the bonus system is built so that one department's win is another's loss, no individual salary will build a team — only competing factions inside the same company.
Insight №26Motivation: the area that's easiest to leave half-done
Motivation is the part of management that's easiest to leave at maybe twenty percent done: it doesn't burn as visibly as hiring or firing, and doing it properly, all the way through, is genuinely hard. The baseline — bonuses and recognition — needs to be clear and predictable: an employee should know in advance exactly what earns a bonus, not find out after the fact.
A practical example: tell the whole team that this month needs to jump from X revenue to 2X — and if it happens, we buy something for the office, raise everyone's pay, or take everyone to the sea.
Nikolai Storonsky described a similar practice at his own level: every day he finds numbers, facts, and articles that confirm the plan is going to work, and shows them to the team — deliberately immersing them in the sense that “the whole world is rooting for” the idea they're building. Some would call that manipulation — he sometimes calls it that himself — but underneath it, it's the same work of giving a team a sense of solid ground, just turned into a daily discipline. Daniel Pink, who I already mentioned in insight №25, applies here too, just at the system level rather than the level of a single hire: a company that builds motivation on money alone is competing on the one dimension that's easiest for a competitor to outbid.
Insight №27Do it yourself or hand it to the team — that's a formula, not a feeling
There's a management myth that delegation is a matter of trust or personality — some managers “know how to let go,” others are control freaks. In practice, it's a matter of formula, not feeling.
The formula goes like this: does the thing you could hand to an employee already work in some form? Is the employee reliable and resourceful enough to carry it from zero? If the answer to either question is no, you need to step in yourself, while keeping in mind that your job right now is to make sure the project can eventually run without your hands on it. As the manager, you're on the hook for handing over a project you actually understand: if it's starting from zero and the employee doesn't have the skills yet, they'll inevitably ask themselves the reasonable question — “why would I build this from scratch if the boss can just do it himself?” — and they simply won't take the area seriously. Only once everything's clear, something's already working, and the employee is delivering — not “can,” but should — you officially move that area of responsibility into the “handed to the team” column.
Getting it wrong in either direction is expensive. Do everything yourself, and you hit the ceiling of your own time, while employees don't grow because they're denied the chance to learn on real work. Hand everything off too fast, and you get hyper-delegation, and that manager's growth is over for good: complex, unproven processes land on people who aren't ready to hold them, and they collapse along with the result. The formula is simple: ask yourself whether it already works in some form, and whether the person is reliable enough to carry it from zero. Yes to both — hand it off. No to even one — do it yourself, but say so publicly, and explain why for now, and what needs to change before you can hand it over.
Insight №28“Know it yourself”: understanding isn't the same as micromanaging
Separate from “do it yourself or hand it off” is the question of “understand it yourself, or not.” These are different things, and people mix them up often. Most managers don't know how to build a strategy for real growth — the kind where results don't just creep upward, but jump multiples, not 10%. And on that front, most people go quiet.
A manager who doesn't actually understand the business runs a “strategy session” instead: sits the team in a circle and opens with “so, everyone, what are our growth ideas?” What follows is discussion, a vote, picking the “best” idea, and out comes a document proudly titled “strategy done” that nobody grows multiples from. The owner asks questions he doesn't know the answer to himself, just to look engaged — and the team clocks that instantly. Strategy isn't a group brainstorm for the sake of a checkbox, and it's definitely not a way to hand responsibility off to your reports.
Knowing it yourself is the only way to go deep into any part of your own structure and see that something's off, that someone's feeding you a line, or to find an obvious insight. If there's something you don't understand — go understand it yourself, and only then hand it to the people executing it. The worst thing you can do is skip understanding it and just “coach” instead: saying “mistakes are fine” and asking things like “so why does this matter to you.” Coaching questions are useful in business only once you actually know the right answer, say so directly — and coach only after that.
And knowing it yourself is exactly the line that separates micromanagement from hyper-delegation. You need to be able to run the analysis and lay out an action plan for any department yourself — it's important to be capable of it, and not to actually do it, because your team is supposed to handle it better than you. If the only thing you can do is bang on the table and get people moving that way, you're not a manager, you're a parasite.
Here's what that looks like in practice with effective managers. The bad version: hand someone a task and check it after the fact — which usually turns up a result that's nowhere near what was wanted, with the work looking nothing like what was expected — no result, but a great story about why there isn't one. A good manager acts like a tracker: they walk the employee toward the result, sometimes in a coaching mode, rather than just handing off a task and disappearing. That takes one-on-ones with employees where the whole list of their tasks gets worked through. The best results I've seen, in my experience, come from exactly this setup: when the manager isn't a “big boss” who assigns tasks, doesn't dig in, and then waits for a report back — but is instead the one setting their department's strategy, with every employee as the resource whose hands carry that strategy out.
There's also the rest of this role: know it yourself, but never stop developing the team and bringing it fresh resources — so people gradually become able to build new things on their own. Sometimes it helps just to personally demonstrate high-quality work, so others rise to meet it on their own, without being told to. And ideally, it's the team that should bring you well-reasoned growth hypotheses — though that doesn't mean you stop doing it yourself; you keep going, you're just no longer the only source.
Insight №29Control without choking the team
Control is the last of the four functions, and it's the easiest one to push too far in either direction. For me, it looks simple: a task tracker where status is visible in real time rather than on request, and a weekly Friday sync that goes through not “what did we do” but “what didn't work, and why.”
Gitelman frames the balance between control and freedom like this: control belongs exactly where the cost of a mistake is high, and freedom belongs everywhere the team has already proven it can handle it. It's essentially Andy Grove's idea of Task-Relevant Maturity, applied not to a single task but to a whole system of control: how closely you manage someone should track how proven they are on this specific kind of work — not their job title, and not a blanket policy for everyone.
BCG calls this “information processing” — a team's ability to spot a signal quickly and get it to whoever can act on it, without distortion at every layer of the hierarchy. The mature version of control isn't a manager checking everything personally — it's a manager who's taught the team to diagnose its own breakdowns, down to the level of a single specialist: the person on the ground should be able to say “this doesn't add up” before their manager even sees it.
Insight №30Don't just hand out tasks — sell a vision
A good manager, with a good team, doesn't hand out tasks. Sounds strange, but here's how it works.
It's not your job to create your vision. It's your job to have a vision. And it's your job to hire talented individuals, to hire talented artists who understand your vision. And you articulate it to them, and then they take your vision and they create it … Your vision is still a two-dimensional vision. They will take the different elements of your vision and make it three-dimensional. … You think you have to do everything and you don't. … You don't need to know something about sewing to have wonderful costumes in your film. You just need to express what you want to the costume designers. You don't need a degree in engineering to have wonderful sets … You need to have a vision, and you need to know how to express it.
— Quentin Tarantino
BCG, in its study “The Five Traits of Highly Adaptive Leadership Teams,” calls this “freedom within a framework”: the team gets clear boundaries (what's off-limits) and a clear goal (what's needed), and the method is entirely up to them. Teams that work this way, per BCG's data, respond faster to market shifts, because the decision gets made on the spot instead of climbing the hierarchy to whoever came up with the steps.
Sometimes it's fine to just say “that's not my job, that's yours” — but don't turn it into a go-to excuse; say it only when ownership of the process has genuinely already been handed over.
Insight №31Don't rush to promote someone into management
Managers often get appointed because they're good at selling themselves and their own importance to the people above them, and the actual skills of people like that are often secondary — it's not for nothing that I'm personally lukewarm on marketers in that role. Sometimes the person who becomes a manager is just the loyal one, the best individual performer, or simply whoever's been at the company longest — none of which is actually a sign of readiness to manage other people. And sometimes the manager themselves surrounds themselves with people who tell them what they want to hear rather than what's true: people are afraid to tell that manager the truth when it doesn't fit their picture of the world, and they'd rather stay quiet and call it flexibility — but it isn't.
Laurence Peter described a similar mechanism back in 1969, in a principle that's carried his name ever since: in a hierarchy, an employee keeps climbing until they land in a role they no longer have the competence for — and then they stay there, because there are no more grounds for promotion (success in the previous role), and demoting someone for failing in the new one just isn't done.
The reckoning comes when reality collides with a collectively invented fantasy world — and it comes fast: ignore the numbers, the facts, the risks, and the forecasts, and the team, happily hallucinating, flies straight off a cliff.
No extremes, though: it's hard to get a big result if the whole team is against you and arguing with you constantly — team loyalty matters. But loyalty needs to be kept separate from dumb yes-manning just to keep the boss happy: a team needs to be able to voice an opinion openly and without consequences, grounded in hard facts and numbers, even when it doesn't match the manager's own view. Ray Dalio, at Bridgewater, turned this into an institutional rule: if you disagree, you're obligated to say so directly, regardless of rank, and the weight of your opinion grows with your track record, not your title. It's a hard, unfamiliar way to operate — but it's exactly how decisions stop depending on who's loudest in the room, or highest up the ladder.
When it comes to talking about promotion — say “in proportion to results on this specific metric”: no results, no promotion, and your job is to help the person get those results. And praise rarely, and only when it's earned: an overpraised employee relaxes.
Insight №32Planning: from company goals to every employee's goals
I arrived at this one the same way — not from a book, but from frustration: I'd set the company an overall goal and couldn't understand why nobody down the chain could explain how their task for the week even connected to it. Planning that doesn't cascade down to every employee is a nice-looking document, not a working tool. Turns out that particular frustration has a name and a model: back in 1954, Peter Drucker proposed Management by Objectives — company goals should break down into goals for every department and every person, not exist separately from what people actually do each day.
Andy Grove, at Intel, turned this into a concrete tool — OKRs (Objectives and Key Results): a qualitative, ambitious goal plus a handful of measurable results that show whether it's been hit. John Doerr, who worked with Grove, brought OKRs into Google at a very early stage — and since then it's probably the most widely copied goal-setting format in tech. It only works under one condition: every employee's goal has to be traceably connected to the company's goal, or it turns right back into a document for reporting purposes instead of a tool for coordination.
I check this on myself with a simple test: if an employee can't explain, in one sentence, how their metric this week moves the company's overall goal, the cascading didn't work — and that's on me, not them.
Insight №33Never be friends with the people who report to you
A related, equally uncomfortable topic: friendship with your direct reports. The “don't be friends” rule sounds harsh, but it's not about being cold: a manager can be warm and human and still not build decisions on personal closeness to specific reports — that wrecks the objectivity of decisions faster than almost any other mistake. Kim Scott calls this trap Ruinous Empathy: you feel for someone, so you stay quiet about what they need to hear, and in practice you're just betraying their growth to keep yourself comfortable. I've written about this separately, with personal examples — the wine brought back from a trip abroad that doesn't help when you have to tell someone the plan wasn't hit; personal topics nobody actually needs; the status of “friend” that evaporates the moment there's a real conflict (here). The same rule holds with business partners: I've personally regretted, more than once, being too easy on someone specifically because I didn't want to damage a personal relationship. And the same goes for results: you can't let a lack of results or a slackening pace slide — say so directly, right away; anyone can mumble around a problem. Employees will respect you more if they see that you're not toothless.
Epilogue
Part one of this series ended on the idea that getting rich isn't about proving something to someone — it's about building something that doesn't run on constantly re-proving its own worth. This part arrives at the same conclusion from the other direction: a company that only runs on you isn't a business, it's a well-paid job with a genuinely toxic employer — namely, yourself.
Nikolai Storonsky, the founder of Revolut, puts it more bluntly than anyone: “I can't scale myself, so the only way to scale the company is through the people,” he said in an interview with Elizaveta Osetinskaya.