Cube is a real-time Financial Planning & Analysis (FP&A) platform from the comfort of your spreadsheet!

Want to join our growing engineering team? Check out our open roles here!

Below are some of my core thoughts on managing teams / creating products / building startups / life overall. Inspired by this post. This document will change over time as I encounter new situations and come across new experiences.

Hire smart people, provide high level direction, then stay out of the way and help remove roadblocks

This is the foundation to my management philosophy and one of the reasons I enjoy startups. It provides the opportunity to find smart people, give them a common goal, and then stand back, help where needed, and watch it unfold. As a manager I see one of my main jobs as shielding the team from various distractions and roadblocks, and clearing a path for the team to get the important work done.

Balance

"Everything in moderation, including moderation" ~ Oscar Wilde

Most problems that arise within a team or product can be solved through some reasonable middle ground. Some examples:

• Have a particularly nasty bug in your product? A quick bandaid fix to make the customer happy followed by a longer term, more robust fix is probably the best approach.
• Accumulating a lot of tech debt? Start mixing in work to pay down tech debt alongside of new features. Generally I've found you don't need as many new features as you think, and your customers will be just as happy with a stable, simple product than one with too much functionality anyways.
• Need to add a large, new feature? Breaking it down in to separate, smaller features that can be released over time will always be better than spending numerous months without shipping something. Many of the general approaches outlined in Shape Up (specifically around managing "appetite") are useful here.

It's worth noting that this is also true for work/life balance. Sometimes life gets in the way of work and sometimes work gets in the way of life. Occasionally, extra hours are needed to get a large release out the door, but those times should be the exception not the rule.

Raw honesty

We're all adults. Both giving and receiving constructive feedback with raw honesty is crucial to having a mutual understanding and working towards working better together. Egos should be left at the door.

Stable and boring is better than flashy and new

I'll almost always opt for tried and tested components of software over something that may be new and flashy. Most problems (scalability related, bugs, etc) that would come up with pieces of software that have been around longer will most likely have already been solved by someone, somewhere with useful information readily available online.

Use the right tool for the job

This sort of goes hand in hand with the previous point. Using a new NoSQL technology might sound exciting and fun, but I'd rather use a relational database if that's all that's needed to solve a particular problem.

Keep it simple, stupid (the KISS principle)

Simple solutions to problem makes everything easier and less stressful. Onboarding new engineers won't require learning large, overly complex systems. Your product will be more stable with less downtime and late night on-call situations. This applies to everything from how an infrastructure is configured to how code is organized.

• ☕ A refreshing cold brew
• 🥃 A smooth whiskey
• 🏃 A tough workout