Reading experience: Lateral Leadership

Recently, I’ve been reading several books focused on soft skills in the workplace. Engineers often feel reluctant to engage in communication, coordination, and collaboration, unless you plan to freelance until retirement. Learning these skills can make your future career much more manageable.

One of the books, titled "横向领导" in Chinese, is called Getting It Done - How to Lead When You're Not in Charge in English. It describes how to lead a team effectively when you’re not in a managerial role, guiding them in the right direction.

This concept may seem abstract—why should one learn to lead if they’re not a manager? However, it’s precisely because you're not in a managerial position that you have a clearer understanding of the project and how the team operates, since you are the one executing the tasks.

The book succinctly summarizes its content on the back cover:

• Participative Leadership: Ask Questions → Provide Ideas → Lead by Example
• Work Elements: Set Goals → Systematic Thinking → Plan Adjustments → Motivational Management → Seek Feedback

Here are a few key points that I find particularly important.

What to Do When Work Hits a Bottleneck?

According to the steps outlined in the book, the process is quite clear: gather data → analyze potential causes → choose methods → create an action plan → start taking action → document problems → analyze causes → adjust methods.

It's Hard to Get Others to Reflect on Their Thought Processes

Pointing fingers and corrections often lead to worsening situations, as people find it hard to admit their mistakes, especially when positions are equal. Statements like “You shouldn’t do this...” can make the other person feel attacked and escalate tensions.

In such situations, a few strategies can help break through:

• Use questioning techniques, for example: “Do you think this might cause an issue with xxx?”
• Ask for evidence and assistance: Request the other person to provide supporting information, such as, “You mentioned that the active user count decreased this month; do you have any data to share?”
• Present hypotheses for the other person to consider. “If we do it this way, what could go wrong?”

These methods may seem ordinary, but they are often more effective than direct accusations. They also signal to the other person that you’re not targeting them, but rather the issue at hand. Although you are indeed targeting them.

Documenting Problems

I once encountered an issue at work when updating static assets. Although I followed the documentation to upload them, I found that I couldn’t successfully update them. This took me two weeks to resolve, only to discover that iOS and Android had different configurations, and permission issues also prevented certain updates from displaying.

Situations like this are worth documenting and storing in a shared company file. This way, the next person won’t stumble into the same pitfalls. While it might be hard to remember, at least you’ll have solved problems for yourself and others.

Avoid Giving Orders

When offering suggestions to others, it’s crucial to clarify that you’re not issuing commands, but rather offering advice for them to consider. No one enjoys being criticized or lectured. When you have thoughts to share, avoid using a commanding tone. Instead, communicate your ideas through various channels, such as internal sharing sessions, blog posts, or documents, and describe specific plans for colleagues to discuss together.

Especially in discussions, the key is not just the discussion itself, but whether the discussion is initiated at all.

Reflection

In Scrum, there’s a meeting called the retrospective, which allows everyone to share what went well and what didn’t during a sprint. However, this can easily devolve into a session for seeking validation and criticizing others, where everyone lists areas for improvement but nothing changes in the end.

This is a very unfortunate situation, as repeated lack of change can lead to pent-up dissatisfaction, causing work to become increasingly unenjoyable.

Defining Goals

Without a clear understanding of the company or product goals, conflicts can easily arise among colleagues. For instance, one person might want to deliver the product quickly, while you may prioritize properly refactoring and fixing bugs. If both parties have different perceptions of the product, chaos can ensue. The other person’s code could be a mess, and you might hesitate to ask them to rewrite it for fear of missing deadlines.

The quickest way to resolve this issue is to define the goals. If the objective is to launch new features quickly, then a choice must be made between code quality and development time.

Conclusion

If you’re genuinely reflecting on your career and seriously considering your work, the points mentioned above should have become second nature to you. For more experienced workers, this can serve as a review and a more systematic organization of the tasks we typically handle.

However, there is always a gap between reality and ideals. Even if you strive to implement these principles, you may still encounter stubborn, opinionated team members. In such cases, I highly recommend the book Driving Technical Change. It categorizes difficult team members and teaches you how to handle each type effectively.