Technical Leadership: Building Great Teams and Products

31 Aug

Companies bet on people. They bet that the people they have hired will figure out the problems and their solutions. To make the bet credible, the golden rule is to hire competent people. Other virtues matter, but competence generally matters the most in technical roles.

Once you have made the bet, you must double down on it. Trust the people you hire. And by being open, empathetic, transparent, thoughtful, self-aware, good listeners, and excellent at our job, earn their trust. Once people are sure that you are there to enable them and grow them, increasing their productivity and growing them becomes a lot easier.  

After laying the foundation of trust, you need to build culture. The important aspects of culture are: 

  1. inclusion
  2. intellectual openness 
  3. technical excellence 
  4. focus on the business problem
  5. interest in doing the right thing
  6. accountability
  7. hard work  

To build a culture of technical excellence and intellectual openness, I use the following techniques:

  • Probe everything. Ask why. Ask why again.
  • Ask people to explain things as simply as possible.
  • For anything complex, ask people to write things down in plain English.
  • Get perspective from people with different technical competencies.
  • Frontload your thinking on a project.
  • Lead a meeting to ‘think together’ about projects where tough, thoughtful, probing is encouraged.
  • Establish guidelines for coding excellence and peer review each major PR. 
  • Lead a meeting where different members of the team teach each other — I call it a ‘learn together.’

To make sure that the team has a place to share and reflect on the understanding, I also work hard to build a shared understanding. Building a shared understanding of the space helps drive clarity about actions. It also provides a jumping-off point for planning. Without knowing what you know, you start each planning cycle like it is groundhog day. 

I actively use Notion to think through the broader problem and the sub-problems and spend time organizing and grooming it. Build something that inspires others to build that shared understanding.

I encourage active discussion and shared ownership. We own each page as a team, if not as a company. But eventually, one person is listed as a primary point of contact who takes the responsibility of keeping it updated.

To drive accountability, I drive transparency. For that, I use the following methods:

  1. Share folders. Shared team Google drive folder with project-level folders nested within it. I dump most documents that are sent to me in the shared folder and organize the folder periodically. There is even a personal growth folder where I store things like ‘how to write an effective review,’ etc.
  2. Be a Good Router: I encourage people to err toward spamming. I catch whatever failures by 1. forwarding relevant emails, 2. Posting attachments to Google Drive, and 3. posting to the relevant section on Notion.
  3. Visibility on intermediate outputs: I encourage everyone to post intermediate outputs, questions, concerns, etc. to the team channel, and encourage people to share their final outputs widely.
  4. Use PPP: Each member of the team shares a Progress, Plans, and Problems each week along with links to outputs. 

Culture allows you to produce great things if you have the right process and product focus. There are some principles of product and process management that I follow. My tenets of product management are: 

  • Formalize the business problem 
  • Define the API before moving too far out.
  • Scope and execute on a V1 than before executing on the full solution. Give yourself the opportunity to learn from the world.
  • Do less. Do well.

The process for product development that I ask the team to follow can be split into planning, execution, and post-execution.

Planning: What to Work On?

  1. Try to understand the question and the use case as best as you can. Get as much detail as possible.
  2. Talk to at least one more person on the team and ask them to convince you why you shouldn’t do this followed by if you are doing this, what are the other things I am missing here.
  3. For larger projects, write a document and get feedback from all the stakeholders.
  4. As needed, hold a think together with a diverse, cross-functional group. Keep the group small enough. Generally, I have found ~5—8 is the sweet spot.
  5. Get an ROI estimate and rank against other ideas.

How to execute?

  1. Own your project on whatever project management software you use.
  2. Own communication on where things are on the project, new discoveries, new challenges, etc.
  3. Ask people to review each commit. Treat reviewing seriously. Generally, the review process that works well is people explaining each line to another person. In the act of explaining, you catch your hidden assumptions, etc.
  4. Come up with at least a few sanity checks for your code.

Communicating Within and Outside What You Learn

  1. Share discoveries aggressively. Err on the side of over-communication.
  2. Contribute to Notion so that there is always a one-stop-shop around how we understand X. 
  3. Create effective presentations