Principles

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).

Management

Learn How to Delegate

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.

Know Thyself (and thy Team)

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.

Overcommunicate

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.

Organize Your Time

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?

Operations

Tighten feedback loops

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.

Margin of Safety and Estimation

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.

Take a Systems approach to teams and output

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.

Reduce context switching by grouping tasks/tickets together

When planning team work, consider grouping like tickets together to reduce context-switching. It’s more efficient, and makes for a happier developer

Strategy

Buy vs Build

If it’s not your core competency, then outsource it!

Startups

Will Power

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.

All Stars across the board

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.

Technical Debt

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.

Software Development

Monitor/Measure All The Things!!!

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.

Be mindful of surface area

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.

Customer Success

Perception = Progress

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!

Be Mindful of the Decision Makers

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.