To Be a Good Engineer, Knowing How to Code is Not Enough

This idea deeply influenced me during my time at Facebook and continues to shape my expectations for engineers at Cooby. When I was at Facebook, performance reviews focused on four areas: impact, professional skills, direction, and people. Did you notice? Professional skills actually accounted for only a quarter.

This is because the issues you face at work far exceed what your technical abilities alone can handle. In a team, you will inevitably need to collaborate with others. How to work with people, achieve the goals set by the team, and make the experience enjoyable for others are not things that can be achieved without effort.

You will only shine if you have both hard skills and soft skills. Working with a super talented engineer who cares about no one else can be a very painful experience because "collaboration" necessarily involves some compromise and coordination. If only one party is willing to do this, the results will definitely be poor. I think too many engineers care only about their hard coding skills and forget that working with others is a big part of their job.

The most important medium for information exchange between people is communication, but good and effective communication requires a lot of effort.

I have seen too many ineffective communications, whether it's one party being overly emotional, saying things they don't truly believe, or both sides too focused on winning the argument rather than caring about the actual truth. Or when one party is just venting emotions, and the other tries to bring them back with reason. These communications, in my view, are a waste of time and do not achieve good results.

Setting communication goals is an effective way to solve this problem. Both parties can discuss what the goal of the communication is before it starts: Is it simply to exchange information? Is the goal to reach a consensus at the end? Or is it just to vent emotions? No goal is wrong; what's important is that both parties reach a consensus and have a chance to move forward together. And if it is discovered during the discussion that we are straying further from the goal, we can use it as a basis to bring both parties back on track.

The purpose of communication is not to throw everything in your head out, but to use listening and speaking to reach a consensus together.

Another area that Facebook emphasizes for engineers is Direction, meaning you can't just bury your head in the tasks you are assigned. You must also provide direction for yourself and your team. This doesn’t mean setting a quarterly or yearly product roadmap like a product manager, but making it clear to those around you the background and consequences of the projects you are working on. Even better, you could also specify the planning and goals at the execution level, making everyone feel confident about what you are responsible for.

A concrete example would be a clear and practical schedule and division of labor. Once you are no longer a junior engineer, your projects will inevitably involve multiple stakeholders, some even with cross-functional teams, like designers or PMs. How to work well with them and present a clear plan of the schedule so that your supervisor and other teams know what to expect from the project at what times, I believe, is not a simple task.

The biggest project I was responsible for during my time at Instagram was IGTV Ads. This project involved nearly 100 people, and even if we only count the engineering team, about 30 people had to work together to complete the task. My role was to work with our TPM and PM to lead the product launch. One of the first things I did was to coordinate with different engineering departments to clarify the division of labor and ensure that if there were any blockers between us, we would identify the sequence early in the schedule and set different checkpoints during the execution to ensure everyone was on track. The advantage of engineers doing these things is that compared to PMs or TPMs, you have a deeper grasp of the actual situation in the engineering department and can identify potential problems earlier. When you say there’s no problem, it also makes people feel more reassured.

A successful launch of a major project definitely has a senior engineer in the background who is very good at communicating, coordinating, and managing externally.