Book Review: Lateral Leadership

The books I’ve been reading recently have all focused on workplace soft skills. Engineers are often reluctant to deal with things like communication, coordination, and collaboration. Unless you plan to freelance until retirement, picking up these skills will make your future career much easier.

This book, titled Getting It Done: How to Lead When You’re Not in Charge, describes how to steer an entire team and move it in the right direction when you aren’t in a management role.

It might sound counterintuitive—why learn how to lead if you’re not a manager? But precisely because you aren’t in management, you often have a clearer view of how the project and team actually operate day-to-day, because you’re the one on the ground doing the work.

The blurb on the back cover pretty much sums up the entire book:

• Participatory Leadership: Ask questions → Offer ideas → Lead by example
• Core Work Elements: Set goals → Think systematically → Revise plans → Motivate others → Seek feedback

Here are a few key takeaways that I found particularly important.

What to Do When Work Hits a Bottleneck?

The steps outlined in the book are quite straightforward: Gather data → Analyze possible causes → Choose an approach → Create an action plan → Take action → Log issues → Analyze causes → Adjust the approach.

It’s Hard to Make People Rethink How They Think

Pointing fingers and offering unsolicited corrections often marks the beginning of things going downhill. People find it hard to admit their mistakes—especially among peers of equal rank. Saying things like “You shouldn’t have done it this way…” only makes the other person feel attacked, turning a simple issue into a confrontation.

In situations like this, a few techniques can help break through:

• Ask questions, for example: “Do you think doing it this way might lead to [issue X]?”
• Ask for evidence and assistance: Ask the other person for backing data, such as: “You mentioned monthly active users dropped this month—do you have the data handy so we can take a look?”
• Pose a hypothetical question and let them answer: “What would be the downside if we did it this way?”

These approaches might seem simple, but they are far more effective than direct criticism. They also signal to the other person that you’re addressing the issue, not attacking them personally. Even if you kind of are.

Document the Problems

Once at work, I encountered an issue while trying to update static assets. Even though I followed the instructions in the documentation to upload them, they wouldn’t update properly. It took me two weeks to figure out that iOS and Android had different configurations, and differing permission levels were preventing certain updates from showing up.

Issues like this are worth documenting in shared company docs to prevent others from stepping on the same landmines. While this kind of work rarely gets you the spotlight, at least you’ve solved the problem for both yourself and your team.

Don’t Give Orders

When offering suggestions to others, make it clear that you aren’t barking orders; you’re providing options for them to consider. Nobody likes being criticized or lectured. When you have an idea, avoid using an authoritative tone. Instead, communicate your thoughts through various channels—internal sharing sessions, blog posts, documentation, etc.—and lay out a concrete proposal to discuss it together with everyone.

When it comes to discussion, what matters most is not necessarily the discussion itself, but the act of initiating it.

Retrospectives

In Scrum, there’s a meeting called the retrospective, where the team reviews what went well and what didn’t during the sprint. However, it easily devolves into a venting session or a blame game where people eagerly list out things to improve, yet nothing ever changes.

This is detrimental. When retrospective action items consistently go unresolved, team members tend to bottle up their frustrations, making work more and more miserable.

Define the Goal

Not knowing the company’s or product’s goals can easily spark conflict between colleagues. For instance, someone might want to ship the product as fast as possible, while you want to properly refactor and fix bugs. When two sides have misaligned priorities, chaos quickly ensues: their code might be a mess, but you’re afraid to ask for a rewrite for fear of missing the deadline.

The quickest way to resolve this is to clearly define the goal. If the priority is shipping a new feature in the short term, trade-offs must be consciously made between code quality and delivery speed.

Conclusion

If you’re someone who actively reflects on your career and work, these practices have likely already become second nature to some degree. For experienced professionals, this book serves as a good review and a structured framework for things people often do intuitively.

Still, reality often falls short of the ideal. Even if you do all of the above diligently, you might still encounter difficult teammates who are argumentative, stubborn, or obstinate. In those cases, I highly recommend the book Driving Technical Change. It categorizes difficult colleagues into distinct types and teaches you practical strategies for dealing with each one.