After reading Adam Wiggins’ and Brandur Leach’s Heroku Values I was inspired to make a list of my own during my time here at Charter.

I will borrow heavily from their posts, as I believe Heroku, along with many other digital-native software companies have a lot to offer in terms of culture.

If we are to borrow anything from these companies, it should be how they work and the values they work by, not just their open source technology.

I also believe it is important for those that I work with to understand my principles. These are the basis of how I make decisions in my work life. I was inspired to write these down and continue to iterate on them after reading Principles by Ray Dalio

My Principles

Make It Real

Take what you envision and make it real, don’t just talk about it. Write it down, build it, and share it.

Embrace Failure

Albeit cliché by now, this one is true to my heart. Everything great started from something that failed many times and has only become great by applying the learnings of those failures. If you have an idea, just start doing.

Trust Meter Starts Full

If you work with me, you have my trust from day one and it is yours to lose. If you break that trust, you can gain it back, but it will take time.

Limit Friction

Avoid what I refer to as “heat loss through friction”. Be open, honest, and collaborative up, down, and across the organization. We should spend more energy moving value through the system than arguing on how that system should work. Furthermore, we should focus on improving the flow through that system, always looking for the next constraint (friction point) and alleviating it.

Fruit O’Clock

Once a day, bring the team together for making coffee and sharing a piece of fruit (BYOF). Get in a game of ping-pong or discuss the latest new show on TV. Make sure there is an environment where everyone feels safe to GSD but also to build relationships with their peers through “non-work-related” activities such as these. Make sure these aren’t looked down upon, and that people aren’t afraid of being looked at weird, but rather that this is a natural part of working in a high-performance environment.

Be the Master of your Domain

Own your product. Whatever that product may be, e.g., a consumer facing app, a web service, an internal service, a wiki page… whatever it may be, own it through and through. Make sure that you always protect your customer. Dogfood your product, and if it sucks for you, don’t get discouraged, get excited and take the opportunity to make it better.

Resourcefulness as a core competency, not as a service

Being able to Google an error, use development tools such as cURL, Postman, Proxies, Debuggers, etc… should be a core competency of engineers in our organization. These abilities are not outsourced to other individuals or groups.

Well Thought-Out Decisions over Instant Gratification

Take the time to make well thought-out decisions. The time spent doing this will oft be much shorter than the time it takes to correct corners cut to enable instant gratification. There is a time and place to make quick decisions (perhaps to stop bleeding) but the default behavior should be thought out decisions. Do not race to be the hero the moment wants, have the patience to be the hero the organization needs.

Good Enough vs. Over-Optimization

Know when good enough is good enough and make sure this is known within your team. Particularly when you’re guiding others, make sure expectations are set both ways. Striving for perfection sounds great on paper, but hardly works in practice and can lead to teams feeling like they’ll never be good enough. Understand your drivers for optimization and only engineer it when necessary.

Build to Demand

Don’t build because you can, build because you must. Understand your customer to an exhaustive degree and build what they need. This is often harder than the engineering part itself. When you find yourself doing the same thing a third time for a new customer, it’s time to automate/build a feature.