Recently, I've been reading a few books about soft skills in the workplace. Sometimes, engineers are reluctant to engage in tasks such as communication, coordination, and collaboration unless they plan to work as freelancers until retirement. However, learning these skills can make your future career easier.

The book "Getting It Done - How to lead when you're not in charge" describes how to lead a team when you are not in a managerial position, which may sound abstract. But because you are not a manager, you understand the project and how the team operates, as you are the one implementing it.

The book can be summarized by the description written on its back cover:

• Participatory leadership: Raise questions → Provide ideas → Lead by example
• Elements of work: Set goals → Think systematically → Adjust plans → Manage motivation → Seek feedback

Here are a few important points I found:

What to do when encountering obstacles in work?

Following the steps mentioned in the book, it is quite clear to me: Collect data → Analyze possible causes → Choose a method → Create an action plan → Start taking action → Record the problem → Analyze the cause → Adjust the method.

It is difficult for us to think about how others think

Blaming and criticizing others often worsens the situation because people find it hard to admit their mistakes, especially when their positions are equal. Saying things like "You shouldn't do this..." will only make the other person feel like you are being confrontational, making the situation more difficult.

In such situations, there are a few ways to break through:

• Use questioning, for example: "Will this approach cause any issues?"
• Request evidence and assistance: Ask the other person to provide evidence, for example: "You mentioned a decrease in active users this month. Can you show me the relevant data?"
• Propose assumptions and let the other person answer your questions. "What would be the downside if we do it this way?"

These approaches may seem ordinary, but they are much more effective than directly accusing the other person. They also let the other person know that you are addressing the issue, not targeting them. Even though you are targeting them

Document the problems

I once encountered a problem at work where I needed to update static assets. Even though I followed the instructions and uploaded the files, I couldn't successfully update them. It took me two weeks to realize that the configuration methods for iOS and Android were different, and permission issues were causing some updates not to display.

Issues like this are worth documenting and storing in the company's shared files to prevent others from encountering the same problem. Although it may not be easy to remember, at least you have solved your own and others' problems.

Avoid giving orders

When providing suggestions to others, it is essential to make it clear that you are not giving orders but offering advice for them to make choices. No one likes to be criticized or lectured. When you have ideas, instead of using a commanding tone, convey them through various means such as internal sharing sessions, blog posts, or documents. Discuss the specific plans with colleagues and engage in the conversation.

In particular, the important thing is not the discussion itself but initiating the discussion.

Reflection

In Scrum, there is a meeting called a retrospective where everyone discusses what went well and what didn't during the sprint. However, this can easily turn into a blame and criticism session, where everyone writes down things to improve but nothing actually changes.

This is a terrible situation because if there is no change after multiple retrospectives, people tend to keep their dissatisfaction inside, and their job satisfaction decreases over time.

Define goals

If you don't know the goals of the company or the product, it is easy to cause conflicts among colleagues. For example, one person may want to deliver the product quickly, while another person wants to refactor and fix bugs. If there is a difference in understanding the product, chaos can quickly ensue. The other person's code may become messy, and you may be afraid to ask them to rewrite it, fearing it will delay the deadline.

To solve this problem, the quickest way is to define goals. If the goal is to deliver new features in the short term, then choices must be made between code quality and development time.

Conclusion

If you are genuinely thinking about your career or seriously considering work-related matters, these things should have become habits to some extent. For more experienced professionals, it serves as a review and systematic organization of things we usually do.

However, there is always a gap between reality and ideals. Even if you make an effort to do the above, there may still be confrontations, stubbornness, and pigheaded teammates. In such cases, I highly recommend the book "Driving Technical Change." It categorizes pigheaded teammates into different types and teaches you how to deal with each type.