As my time working in team development continues, I’ve found myself questioning my own behavior and what a team should look like, so I decided to pick up the famous O’Reilly book, Team Geek.
This book isn’t just a technical manual; it’s packed with the mindset needed to build the “best team” that delivers great products and services. It is summarized into roughly six sections, and since it is not overly long, it was a very easy read.
Today, I want to jot down my personal takeaways, the topics that struck a chord with me, and some daily reflections as a sort of memo.
1. You Are Not Your Code: HRT and Escaping Ego
The first thing that comes up is the individual attitude of an engineer. The basic principles presented are the following three:
- Don’t hide your code
- Be conscious of HRT (Humility, Respect, Trust)
- Don’t fear criticism
Among these, the sentence “I will say this as many times as necessary: You are not your code” resonated with me a bit. You simply must not conflate your self-worth with your code. As engineers, we tend to do exactly that. When I think about getting depressed and feeling personally denied just because my code was criticized in a review, I realize I might have been getting a bit too emotionally attached to my code.
Furthermore, the warning “Do not underestimate the power of interpersonal relationships” hits a sore spot. Relationships will inevitably last longer than a project. I’ve definitely had the experience of aggressively wielding pure logic in a code debate, only for things to be a bit awkward when we show up to the office the next day.
It is easy to say, but subtly difficult to practice. I tend to try to solve things with solo plays, so I really need to straighten up here. Respecting others sometimes means swallowing your ego and bending your own thoughts. For someone like me who tends to be stubborn, this was quite a tough pill to swallow.
2. Fostering Team Culture: Communication and Handling Failures
Building a shared culture helps engineers with the same values gather and stick around. That’s exactly why we should strictly select engineers with a similar personality at the hiring stage. As part of building a great team culture, the approach to failures is also discussed.
- “Fail early, fail fast, fail often”: If failures are properly documented as post-mortems, you and others can learn, and we can avoid repeating the same history.
I was reminded that a culture of learning from failures while maintaining psychological safety is an indispensable foundation for a robust team.
Along with this, the advice “To focus, you must decide what not to do” shouldn’t be overlooked. It notes that determining a mission statement and limiting the scope is crucial. This idea also appears in design-doc thinking; by defining what is in-scope and out-of-scope, it points the way for design and implementation, preventing the scope from ballooning out of control. And a mission statement is essentially the team version of that.
Related to this, what I found particularly interesting was the strategy around communication.
- Reduce the number of people involved in synchronous communication (like meetings)
- Increase the number of people involved in asynchronous communication (like emails and chats)
Meetings thrown together with a “let’s just invite everyone involved” mindset are simply a waste, usually resulting in people doing other work in the background. Hold meetings only with necessary people, and broadly announce decisions via chat. Open information sharing is exactly what’s essential for each engineer to understand the situation and make autonomous decisions. The logic makes total sense to me, but there is probably a certain number of higher-ups who really want to hold those kinds of meetings, which probably makes things difficult. Please, someone handle this top-down. I beg of you.
3. Escaping Micromanagement: The Role of a Leader
The book emphasizes that the traditional role of a manager is outdated; instead, one should be a “servant leader” (like a butler or servant) who serves the team. The leader’s job is to manage the technical aspects and team relationships, dirtying their own hands to remove obstacles so the team can proceed smoothly.
While traditional managers think about “how to get the job done,” a true leader asks “what can I do?” and clears the path for the team to figure out “how to complete it” themselves. A leader doesn’t need to know all the answers; knowing the “right people” who can remove obstacles is far more valuable.
The traps that new leaders often fall into were distinctly verbalized as clear “anti-patterns” and “good patterns.”
[Anti-Patterns Never to Follow]
- Hiring pushovers: This happens when leaders feel insecure about their role and hire people who are less smart or simply say “yes.” Do this, and the team won’t move without your instructions, meaning you can’t even take a vacation. You should hire people smarter than you who could eventually replace you.
- Ignoring low performers: Wishing for a miracle while ignoring the problem is the worst response. It steals time from excellent members, lowers team morale, and eventually drives your best people away. You must coach them or make the tough call to let them go.
- Treating the team like children: This is the clearest way to convey that you don’t trust them. If you hired trustworthy adults, treat them as such and avoid micromanagement, which does more harm than good.
[The Ideal Leader]
- Lose ego and become a “Zen master”: You don’t need to instantly answer every question or know everything. Honestly apologizing for a mistake earns respect. When consulted, instead of giving the answer, guide them by asking, “What do you think?” so they arrive at the solution themselves.
- Be a catalyst and clarify goals: Product development is like “everyone pulling a massive truck together.” It is the leader’s job to show a clear mission statement so people don’t pull in different directions. You must become a “catalyst” that removes organizational walls and fosters a culture where it’s safe to take risks and fail.
- Be honest and pursue happiness: Avoid the “compliment sandwich” (wrapping a critique in praises), as the real message gets lost. Convey facts frankly but with compassion. Regularly ask, “Do you need anything?” to track their happiness, career, and learning.
Furthermore, to raise the productivity of creative engineers, relying on extrinsic motivation (like money) won’t make them happy or productive. You need to draw out “intrinsic motivation,” which requires three things:
- Autonomy: Giving them a general direction and letting them figure out the “how” on their own, rather than micromanaging.
- Mastery: The opportunity to learn new skills or improve existing ones. An engineer’s skills are like a knife; if not sharpened regularly, they become dull and useless.
- Purpose: Feeling how their code helps the company or the world. A leader should actively share user feedback to show the impact of their work.
True to the saying “People act the way they are treated,” if you treat a team like children, they will behave exactly like that. Trusting them and treating them as adults is what truly matters. I strongly agreed with all of these points.
4. Assume No Malice: Dealing with Poisonous People
There is a rather raw chapter on dealing with “poisonous people” who destroy team culture. Very few act maliciously to destroy a culture on purpose; most issues stem from ignorance or misunderstandings.
The quote “Do not attribute to malice what is adequately explained by incompetence” is profound.
Leaving aside whether the concrete coping strategies are easy to pull off, they do seem practical. I’ll list them out here, but they are hard to explain out of context, so I highly recommend reading the book for the specific anecdotes.
- Point perfectionists in a different direction: Assign them different tasks like code reviews, letting them contribute without hurting feelings.
- Do not feed the trolls: Completely ignore those who simply try to provoke you.
- Find the truth in grumpiness: Prickly words can hide “useful wisdom.” Ignore the emotion and extract only the facts.
This is a survival skill worth keeping in mind.
5. The Gap Between Ideal and Reality: Navigating the Organization
Another fascinating takeaway was the technique for navigating large organizations. Ideally, everyone takes on more responsibility and reduces the manager’s burden, but reality is often plagued by managers who withhold information and rampant office politics.
This is where the fantastic phrase “It is easier to ask for forgiveness than permission” comes in. If you ask for permission every time, you will likely be told “no.” If it is the right thing for the company, proceed first and report it later.
It also provides the realistic advice that “Those who are recognized win.” You won’t be evaluated purely on defensive work (like refactoring), so you must strike a balance with “offensive” work. I constantly find myself doing refactoring, so this made me reflect a bit. It’s not necessarily a bad thing, but I might have been putting myself at a disadvantage.
There are many practical hacks introduced to overcome these realities.
- Run an economy of kindness: Help with others’ work to build up a “trust bank account.”
- Get connectors and administrative staff on your side: Never anger the key players.
- Requests to busy executives should be short: Use “three bullet points and one call to action” to keep it brief.
- Be ready with Plan B (Escape): The fact that you have powerful “choices” provides immense mental freedom.
It’s quite a practical way of thinking, and I found it very helpful.
6. For the Users: The User First Principle
The final chapter touches on our relationship with users, coming down to the user-first mentality: “Focus on the user, and all else will follow.”
It’s not just philosophical; the following concrete guidelines are presented.
- Measure “usage,” not users: The true metric is not simple download counts, but “active users” who actually use the product.
- Marketing basics: Under-promise and over-deliver.
- Usability and speed: “Latency” is fatal in systems.
Do not look down on users; build trust by treating them as human beings. Ultimately, it reminds you that it’s humans building the systems for other humans to use.
Conclusion: It All Comes Down to HRT
To create the “best product,” writing excellent code is simply not enough. I was reminded that interpersonal relationships within the team, navigating the organization, and how we face users are all indispensable parts of the equation.
In particular, I want to immediately be conscious of the HRT (Humility, Respect, Trust) principles and “not identifying myself with my code.” Admonishing my stubborn self, I want to take this momentum from finishing the book straight into tomorrow’s work.
