The Best Leadership Lessons I’ve Learned as an Engineering Manager

Engineering management is often described as a technical leadership role. But most of the job is not about code. It is about people: understanding them, giving feedback, handling conflict, building trust, and helping a team do its best work.

Several books have shaped how I think about this: Surrounded by Idiots, Surrounded by Bad Bosses, Radical Candor, and How to Win Friends and Influence People. Here are the lessons I find most useful.

People need different things from you

Surrounded by Idiots describes four broad communication styles using colors. Some people are fast and direct. Some are social and full of ideas. Others are calm, patient, and supportive. Some prefer detail, structure, and clear facts.

The labels are not perfect, and people should not be placed into fixed boxes. Still, the main lesson is valuable: the way you prefer to communicate may not work for everyone.

As an engineering manager, I try to adjust my approach.

A developer who likes detail may need a written plan before starting. A fast-moving engineer may prefer a quick decision and the freedom to act. A quieter team member may need time to think before sharing an opinion.

Good communication is not only about being clear. It is about being clear in a way the other person can understand.

Do not become the bad boss you once had

Surrounded by Bad Bosses shows how leadership problems often come from a mismatch between the manager and the employee. A manager may think they are being helpful, while the employee feels controlled, ignored, or rushed.

This is an important reminder: your intention matters less than the effect your behavior has on the team.

For example, checking progress every few hours may feel like support to you. To the engineer, it may feel like a lack of trust. Giving someone complete freedom may feel empowering, but they may experience it as a lack of direction.

Ask simple questions:

“What support would help you most?”

“Do you want advice, feedback, or space to solve this?”

“Is my level of involvement working for you?”

Strong managers do not assume they know what people need. They ask.

Be kind enough to be honest

The core idea of Radical Candor is simple: care personally and challenge directly.

Feedback should not be cruel, but it should also not be hidden behind vague language. Saying “Everything looks fine” when someone is struggling does not protect them. It prevents them from improving.

Useful feedback is clear, specific, and focused on behavior.

Instead of saying, “You need to communicate better,” try:

“When the release date changed, the rest of the team did not hear about it until the next day. Next time, please post an update as soon as the plan changes.”

It also helps to ask for feedback before giving it. A manager who welcomes criticism makes honesty safer for everyone.

Make people feel seen

How to Win Friends and Influence People teaches a timeless lesson: people respond better when they feel respected and understood.

Learn what matters to each person. Listen without preparing your reply. Give honest appreciation. Admit when you are wrong. Avoid embarrassing people in front of others.

In engineering teams, recognition does not always need to be dramatic. Thank someone for improving a test suite, helping a teammate, writing clear documentation, or raising a risk early.

People are more likely to accept your feedback when they know you also notice their good work.

The main lesson

The best engineering managers are not the ones with all the answers. They are the ones who stay curious about people.

Adapt your communication. Check the effect of your leadership. Give honest feedback with care. Listen closely. Show appreciation. Admit mistakes.

Technical knowledge may help you earn trust at the start. How you treat people determines whether you keep it.

What We Learned About Building MCP Servers That Hold Up in the Real World

 

We recently spent time with two excellent posts on MCP server design: GitHub’s guide to secure, scalable remote MCP servers and Block’s playbook based on building more than 60 of them. Both gave us plenty to think about—and, honestly, they also confirmed a lot of what we’ve been seeing in our own work. 

The biggest takeaway is that a good MCP server is not simply an existing API with a new wrapper. Block makes a strong case for designing from the user’s workflow backwards. Instead of exposing dozens of small endpoints and asking the model to stitch them together, it is usually better to offer a smaller set of well-named, higher-level tools that complete meaningful tasks. Tool names, descriptions, parameters, and outputs all act as instructions to the model, so clarity really matters. Fewer calls, concise responses, and actionable errors generally make the whole interaction more reliable.

That matches our experience. Long chains of tiny tool calls may look flexible on paper, but they add latency, consume context, and create more opportunities for something to go wrong. The best results often come from keeping the interface simple while handling the real complexity behind the scenes. It also helps to design around what language models do well—such as querying clean, structured data—rather than forcing them through unnecessarily complicated plans or oversized payloads. Block’s advice to watch token budgets, truncate or paginate large results, and separate read-only tools from higher-risk write operations is especially practical.

GitHub’s post adds the equally important production perspective: security and scale need to be part of the design from day one. Remote MCP servers can sit between agents and sensitive systems, so authentication alone is not enough. Tokens must be validated carefully, including their intended audience; permissions should follow least privilege; and every database query, cache lookup, and downstream request must stay scoped to the correct user. GitHub also recommends established OAuth patterns, dedicated secret-management services, workload identities, and strong observability instead of custom security shortcuts.

This strongly reflects what we have learned as well. Once an MCP server moves beyond a prototype, the less visible details become the most important ones: rate limits, caching, circuit breakers, secret rotation, structured logs, traces, health checks, and useful alerts. A gateway can centralize many of these concerns and keep them out of the core business logic.

Our shared conclusion: successful MCP servers are workflow-first, security-first, and deliberately boring—in the best possible way. When the tools are easy for the model to understand, safe for users to approve, and straightforward for teams to operate, MCP becomes far more than a demo. It becomes dependable infrastructure.