Data literacy is one of the more underrated parts of the software engineering skillset. When you’re dealing with a complex, dynamic, evolving system, being able to reason about data is at times more important than institutional knowledge, which tends to become outdated. Understanding a single library or subsystem really well often isn’t good enough. And when you transition to engineering leadership, grow your team, and focus more on the big picture, keeping up with every technology change isn’t feasible.
After the team agrees on a goal and formulates an initial plan of attack, a team leader’s primary value is tracking project status, supporting people in achieving their goals, and helping the team course correct as necessary. The following is a non-comprehensive list of questions you might ask yourself to quickly determine whether the project is on track. On many teams, project leads (tech leads, PMs, and engineering managers) will shoulder the burden of identifying and removing roadblocks. However, the best teams have a shared sense of project health and distribute responsibility for ensuring the project is healthy.
When I first started growing tech leads, my biggest challenge was giving people sufficient support without being overbearing and dimishing their perceived ownership of their project. So I devised a list of questions to ask my TLs to give them a better sense of my expectations and help me quickly assess the health of the project. That document formed the basis for Metawork for Engineering Leaders. Over the years, I kept iterating on that list and it eventually became a list of all the things I expect project leaders to handle. Today, I use this list to train tech leads, distribute responsibilities among tech leads, managers, and PMs (product or project managers), and make role expectations clear to the entire project team so everyone can hold each other accountable.
Early on in my career, I assumed that being a great leader is about having the right answer all the time. After seeing several projects succeed and fail and reflecting on the reasons, I started to see things much differently. The most successful projects are almost never headed in the right direction and set up perfectly at the beginning. And the biggest train wrecks don’t always fail because of lack of knowledge. People often talk about good communication, project management, or execution being more important than ideas. To me, these are different ways of saying the same thing: establishing a healthy iterative loop is more important than having the right answer on day one.
When I joined a startedup for the first time, I was thinking purely about the opportunity to become a better engineer. Business fundamentals, company startegy, and exit strategy were of no concern to me. I assumed that every startup job was essentially a lottery ticket. But after paying close attention to the type of companies that are successful and watching friends advance in their careers, I realized there are a number of best practices you can follow to raise the expected return on your time investment. If you’re optimizing for money early on in a startup, I recommend the following