I’ve been thinking about the lessons startup engineering managers learn on the job. A great deal of our instruction is by making mistakes, and as leaders, those mistakes often cost us real opportunities: people who don't join the company, people who quit, projects that don't ship, sometimes even our jobs. These scars are useful reminders, sure, but it’d be better to have more managers with the full count of their fingers.
- Get your teams in the habit of releasing code as frequently as is reasonably possible. That may not be "continuous", but it probably looks like more than once a week. If your team is unable to release code frequently (barring stupid shit like Apple store processes), it is a sign of potential bottlenecks.
- Postmortem time? Try to make sure it is held the day after the incident, when it is fresh in people's minds.
- Look for ways to prove out ideas early. This includes your architectural and strategic ideas. Work them organically into the product roadmap, to show value early.
Choose your structure (or lack thereof) wisely. You may not personally be creating technical debt much anymore, but that doesn't mean you aren't creating organizational debt. When you roll out a half-assed engineering ladder, this new structure may actually make your life harder, because now you're going to have to negotiate with engineers eager to debate the finer points of broad and vague language. Early on, structure doesn't matter much, but at some point you have to address it. Interested in going the Holacracy or other self-organizing route? I highly recommend reading Reinventing Organizations. Because guess what? They also require some thought and process to work! Be prepared to be thoughtful about this and put some time into it.
The worst situation is having random titles, random pay, random equity. I have stopped counting the number of people who have told me that they discovered massive unfairness in the salaries and equity paid to members of their team. It happens easily. You pay early employees less, assuming you'll give them more valuable equity, but that does not always happen. As the company gets bigger and the market rates change, you hire new people in at higher salaries, but never adjust older people. Cleaning this up probably requires setting up a structure for levels, pay ranges for those levels, and actually increasing the salaries of many people to bring them up to level.
You'll probably get this a little bit wrong the first time, but in an effort to make your life slightly easier, if you decide you want to do an engineering ladder feel free to use the Rent the Runway Ladder that we shared as a starting point.
People can do more than they think they can. This goes for you, and for your entire team. I can't tell you about the failure patterns of people who overwork their teams because that's not my personal failure pattern (yet). But I do sometimes fail to push people hard enough. Engineers want to ship. This goes double for startup engineers. If they are not shipping much, they will start to complain of boredom, and go looking for ways to make trouble. This may result in you having overengineered systems in prod, engineers who quit to go to a new shiny company, or worst, engineers who first push overengineered systems halfway to prod then quit to go to a new shiny company.