Were I to be so bold to write a book someday, I might expand upon my experiences and how I’ve “earned” each of these principles. For now, this is just a running list of some helpful ideas that have proven useful to me thus far (and may be underreported by other similar lists).
Tough for an individual contributor to learn out of the gate, especially if they’ve been trained for their career to simply “do” and do well. You need to develop an intuition for which problems need your direct, individual attention in the weeds, which should be passed off 100% to someone else, and which should be a conversation or collaboration with someone else. Easy to say, but challenging in a demanding environment like a startup where velocity can make or break a company. Read up on Keith Rabois to learn more, I especially like his thoughts around management as editing.
There’s no “one size fits all” approach to management. Each one of your direct reports has a different personality, skillset, and approach to communication. Some need daily checkins to be kept on course, others can go a week without contact and still be very productive.
Especially when having remote staff, it’s important to continually be providing context, giving updates on company meetings/developments, and hammering home any changes in process or philosophy. You can’t dictate a process change once and expect everyone to follow it right away, it’s just human nature.
It’s very easy to lose track of your day and respond to the latest fire rather than have a process in place to structure your time, especially as an executive. In the moment, it may feel like this fire or that fire take precedence, and some of the time they do, but they need to be exceptions not the rule. I’d love if Slack forced any DM’s to go through a checklist of questions first, i.e. Is this important enough to bother Joe? Is there a more appropriate resource to answer the question?
Every process should have a tightly-focused feedback loop. Engineers can’t be writing code in a silo for weeks only to find they were heading in the wrong direction. Frequent checkins, tight testing and iteration keep all parties on the same page.
When trying to do any type of planning, it’s important to estimate as conservatively as possible. I’m especially bad at giving estimates, I’d almost prefer if I had an outbound filter on my brain to automatically add 25% to any time estimate I’ve ever given.
Treat your team like a black box, with knobs and levers to turn that produces an expected output. Automate as much as possible their workflow so a) you as a manager are not in the weeds, b) your reports aren’t spending excessive time on overhead and c) there’s clear expectations and communications for all concerned parties.
When planning team work, consider grouping like tickets together to reduce context-switching. It’s more efficient, and makes for a happier developer
Equally applies to startups, which tend to have a few well-rounded A players who are dangerous in 3-4 areas. Typically an inflection point gets hit where you need to get away from having a bunch of people helping everywhere to having focused silos that have concentrated ownership.
If it’s not your core competency, then outsource it!
Creating something from nothing requires sheer will. You can talk about product/market fit and all of the other startup buzzwords, but if you don’t have the overwhelming desire to see your vision become reality, it won’t.
Reid Hoffman’s podcast intro mentions a quote about startups saying “You have to have A-players at every position”. I couldn’t agree more. Birthing a startup into the world is typically a herculean task. It requires a great deal of hard effective work, good timing, and contrarian thinking. If there’s even one weak link in the chain, it can bring the whole team down, especially when scrappiness, resolve, and morale can be so fragile in an intense environment.
I think in most startup situations, where you generally have to move fast to prove out your business model or get to market, you almost have to incur some technical debt. It makes no sense to rewrite the application using a fancy new front-end framework just so your codebase is cleaner if that doesn’t add bottom-line value to the business. In situations of scarcity (e.g. startups), every choice has to be justified.
All software will break, no matter what fancy language or process you use to build it. You must must must have proactive monitoring in place for everything that gets deployed, otherwise you’re flying blind! Ties into the cost of building vs. buy, you can’t skimp or ignore the cost of maintaining your own software vs. outsourcing that cost.
Any time you write new code, you’re expanding the surface area of a) things to maintain and b) things that can go wrong (increased DB or Net access). To scale, it’s important to manage any additional change in such a way that the cost to monitor and maintain the additional code is incrementally small or zero.
Even though from a technical perspective there are things that might be low lift or not very fancy, the perception of progress can work wonders when managing a client relationship. Important to keep that in mind when prioritizing work. Incremental wins can help salvage a business relationship!
When gauging the happiness of the client, it’s all well and good to ensure your project champion is happy. However, most times that resource is not the one making decisions. It’s important to understand the dynamics of your client and have a clear and open relationship with the actual decision makers, proving out your bottom-line value to them.
The value of a potential customer is NEVER measured solely in the dollar amount they bring in. There are other factors like prestige (was this a good get). Cost of maintenance (is there hidden costs behind that big price tag???). Integrity (is this really a true partner or will they throw us under the bus the first chance they get?). These all require much more imagination to think through.