Recently, we were fortunate to bring together top CTO talent from inside and outside the First Round Community to share best practices, challenges and insights. Key topics included how to create a great management team, introducing structure to your org, and tools for better technical productivity. Notes from this session are below.
- It's easy to build a management structure when things are early and small. But don't over-optimize this structure. It will change as you bring people on. For example, don't give out management titles until you have at least four teams.
- The best tactic is to have everyone start out as an engineer, then hire an engineering director and split the team in half. This is the cell-splitting model -- grow a team then split it into different cells.
- Don't promote people into management roles too early. It's better to hire a manager than to promote from within the ranks. The latter only causes conflict.
- Always remember, while someone might be a brilliant technical mind, it does not mean they will be good at managing people. When you promote a tech lead into management, you lose a great tech lead and gain a bad manager.
- Directors shouldn't be making technical decisions. They should be making people and organizational decisions.
- Early on, people are usually divided based on the product they are working on. When you get to 40 people, you want them to be divided by functional area. At 40 engineers, you also want to start thinking about hiring a VP of Engineering. This person doesn't have to report to the CTO. Sometimes better to have them both report to the CEO.
- Between 20-30 people, management can be light. After 30, you need to start getting serious.
- It's not important who reports to who. The important thing is organizing people's work so that they feel like it matters and that they have the right, meaningful purpose.
- You need to make it clear that senior software engineer is a destination, not always a stepping stone. Younger engineers think they need to break into management to climb the ladder, but there should be an option for them to have a lifelong career as a talented engineer. This will save you a lot of bad managers.
- Each team should be responsible for their own roadmap and have total control over it as long as it aligns with the company's vision.
- When teams feel like they have ownership over what they are doing, they have a better chance of being successful.
- Don't be afraid to organize people into teams. Building in structure too late is more frustrating for everyone. When you do this, listen to your quiet contributors, not just your tech leads.
- Really listen and ask probing questions in 1:1s, this is how you will learn where and when to move people. Ask people what they would do if they were steering the ship. This also helps defuse frustrations.
- Red flags to look for when creating teams: People saying they can't get their code shipped, that they can't get their stuff done, that someone else is blocking their productivity.
- You want to form teams with minimal dependencies and process to prevent roadblocks. Early on, you can have your tech leads set the direction for a team. When they start getting overwhelmed, it's time to bring in a manager.
- Eliminate cross-dependencies between teams as much as possible. You want them to communicate clearly but not rely on each other to the extent that they can't get things done.
- As you scale, people who work well on a team are going to start to become more valuable than the people who crank out code but who can't collaborate. You end up firing people who can't work with others or isolating them, even if they were the best employees at the beginning.
- 1:1s are important. Don't do lunch meetings because they are distracting. Instead, go for walks -- it opens people up. Your goal in 1:1s is making sure if people are happy. Pry the information out of them if you need them. It's easy to lose great people simply because your communication is bad.
- It's healthy to be transparent about compensation at every level. Engineers respond very well to this because they are action oriented. They like having a clear path.
- If early employees don't fit into your new structure, you have to lose them, and you cant' shy away from losing top engineers. You have to do what is best for the organization.
- Titles and structure exist to solve an organizational problem. You introduce a tech lead because you need to get more consensus on a team. Every piece of structure needs to be justified in a way engineers can understand.
- Culture is defined by hiring. Co-founders need to be involved in the hiring process as long as possible to make sure hires match the culture they want to build. People have to be aligned with the company's mission.
- In addition to technical interviews, have 1 or 2 product managers interview engineers to see if they can collaborate and work well with the rest of the team.
- You need to avoid monoculture as you scale. One of the best ways to tell if someone is collaborative is to challenge their answer to a problem repeatedly. If they debate effectively and aren't abrasive, those are good indicators.
- In an interview, recreate a situation that is a reflection of your team's culture and the situations the person would face. Have them analyze how they would respond in a contentious scenario.
- Diversity of thought becomes increasingly important as your grow. At first, it can slow things down, but then it becomes an asset, so be sure you adjust your expectations and stop screening out candidates with diverse or different backgrounds.
- If you want to make sure someone will be a fit in the future, look for humility. Ask questions about times people failed. Ask people to rank themselves from 1-10 in particular skill sets. Catch them in an off moment and talk about it.
- Make your recruitment process different and fun. Fo university recruiting, target schools that had hard interviews for admission (CMU and MIT are two examples).
- At a career fair, put up a white board that says "$20 to solve a problem." See how many people are drawn to that concept.
- Start a deeply technical blog where you discuss and work through really tough, interesting problems -- this will attract smart talent.
- Move incredibly quickly in the interview process. When you move fast you show tech hires that you are a company that gets things done.
- Spend the time to get to know candidates on a personal level, and be clear about the process. Communicate what the timeline will look like upfront.
- Personalize the process as much as possible. Top leadership should be involved with the whole process -- not just brought in at the end. Have them greet and initiate the candidate as well.
- For high-velocity mobile development, try New Relic for stress tests. They are able to connect the front and back end.
- uTest works but it can get really expensive really fast. Mando Group is great at providing manual testers for cheap.
- Trying to run and maintain a KIF test is really slow and brutal. It's much faster to hire a manual tester.
- QA teams can be really difficult to run if you want to deploy 5x a day. If you can get everyone to rally around releasing all the time and automating testing when you're a young company, you can build a culture of automation. If you can't automate something, you're pointing to a flaw somewhere else.
- If you bake automated testing into your company from Day 1, you can scale and stay QA free. You want to achieve a philosophy of continual deployment. There should be enough regression tests that every engineer is confident they can commit code and it won't be pushed unless it is perfect.
- One top recommendation for server configuration and deployment is Docker.io.
- Chef is another one -- it's powerful but the learning curve is steep. If you release it early on it works.
- Flynn is another project (the hip new entrant) to keep your eye on because it will be making great strides in this area.
- The ideal coach is someone who has been an engineering VP for a several 100 person company and who has now started coaching full time.
- The ideal setup is to meet with them once a week, outside the company in a private space. It takes about four sessions to get comfortable.
- It can be a really good forum to air out and replay frustrating situations and step back to plan out the next 4 to 6 months.
- Elad Gil, former VP of corporate strategy at Twitter, has anamazing blog with a lot of strong tactical advice for technical leaders.
- Check out Rands in Repose, written by Michael Lopp, who manages People Operations at Palantir -- he has a lot of practical advice for technical management as well.
- Highly recommended -- Drive: The Surprising Truth About What Motivates Us by Daniel Pink.
- Another great book on building high performance teams: The Score Takes Cares of Itself by former 49ers Head Coach Bill Walsh.