On the wall above my desk are five rules, and they are the framework for how I get things done
I revisit these rules every year, and they are subject to themselves. Always iterating, words paired to only those most important, without fear of criticism and at whatever pace necessary. They are also in a deliberate order. First and foremost, they must delight you, the customer.
I’ve not found anything more succinct to enable highly productive teams than these five rules, and it should come as no surprise that when I founded CloudZero, I built our culture with these rules as its foundation. Even as I’ve worked at very different organizations, with different philosophies, cultures, and processes, these rules (in all their iterations) have been my guide.
Understanding the Rules
To live by these rules requires a lot more than printing them out and hanging them on the wall. You have to practice them every day, spend time reflecting on their meaning, and hold yourself and your peers accountable. In many ways, I think this is the shortcoming of most software engineering dogma in general (of which there is legion).
The agile manifesto is a great example. Everyone in software engineering has heard of it, many organizations swear by it, yet how many of us have found our organizations valuing people and interactions over process and tools, customer collaboration vs. contract negotiation or rapid response to change vs. rigid top-down planning? How many of you have worked in an environment where delivering customer value was the prime directive? You have to practice what you preach.
1. Delight the Customer
Get closer than ever to your customers. So close in fact, that you tell them what they need before they realize it themselves. — Steve Jobs
This one sounds straightforward, but it is easy to lose your way. You could confuse this to mean that you should listen passionately to your customers and do whatever they ask. If you are a consultant, that’s perhaps good advice, but if you are building a product, this will not satisfy your customers. Jeff Bezos, for example, often points to an obsessive-compulsive focus on the customer at the primary driver of Amazon’s success; however, how often do you hear Amazon doing exactly what customers asked for?
Focusing on the customer is only part of the solution. To delight a customer, you have to exceed their expectations and go beyond their imagination in what you deliver. The way you get there is an obsessive-compulsive focus on solving customer problems. The challenge is that the problems your customers want you to solve are very hard to identify. Sometimes the real problem worth solving is buried behind a dozen other problems that your customer won’t pay for but are required to get there. Other times your customers will send you down the wrong path by pointing out problems that they don’t have. That’s what makes delighting the customer so hard, and you need to be ready to commit to the journey. Use your time with customers to listen intently, and build empathy and understanding by using the 5 Whys. Once you are convinced that you understand your customer’s problems, spend some time trying to prove yourself wrong and seek out people who disagree. From there, the rest is on you, your intuition, and your willingness to commit and iterate.
2. Commit and Iterate
Art is never finished, only abandoned. — Leonardo da Vinci
Software, much like art, is also never finished, only abandoned. Unlike art, however, great software and great software companies are always a team effort. Sometimes getting a team to commit, however, can be hard. Lots of opinions will (and should) compete for attention until a decision is made, but once that decision is made, you need everyone to commit. So how do you ensure that happens? You get religious about iteration.
You have likely heard the phrase “Disagree and commit,” something often attributed to Jeff Bezos or more accurately, Andrew Grove. The idea being that disagreement and debate is welcome upfront, but once a decision is made, disagreement is put aside, and you commit. I think that disagree and commit is a powerful concept, but its intentions are misplaced. Instead of focusing on what comes before the commit, along with the implied negativity of disagreement, it is what happens after you commit that is far more impactful. Effective teams don’t just disagree and commit, they iterate.
Don’t let perfect be the enemy of the good enough
When a team understands that iteration is not just expected, it is required, commitment happens faster. You have removed the penalty for changing one’s mind. Both for those that might have disagreed with the initial direction, but also for those making the decision. When your team understands that it must both commit and iterate, you remove the pressure to get it right on the first try.
Be warned, however! Other parts of your business will claim victory the moment any customer appears delighted and push you to stop iterating. Don’t let this happen! The first signs of delight are often based on your customers’ perception of future value, not actual value, and you still have a ways to go.
If something you build has the great fortune to delight someone, don’t stop there and abandon it, stay committed and keep going. If it was worth doing, it’s worth refining.
3. Less is More
Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.
I have made this longer than usual because I have not had time to make it shorter.
— Blaise Pascal
Less is more. This one is so hard to get right. Blaise Pascal was the first to observe this when he wrote those words. Since then many similar quotes have been said throughout time all with the same claim: to do less, one has to spend more time. That time is so crucial to spend because less is more.
But why is less, more? This concept can be applied to almost all aspects of a business:
Engineering: Every line of code is a liability.
Sales: A smaller, more qualified, pipeline will close faster.
Marketing: The more concise your message, the easier it is to understand.
Product: Fewer features, better focus, happier customers
Finance: Spend on only what matters. Show me your budget and I’ll show you your priorities.
Enforce this by pushing the team to devote a certain percentage of time every iteration to refactoring. Refactoring is also an excellent opportunity to remove features that don’t delight. Be ruthless when refactoring and abandon the parts that your market won’t care about, stay committed to the parts that delight. As Steve Jobs said, “Focus is about saying no”.
4. Nothing is Sacred
Sacred cows make the best hamburger — Mark Twain
Your most unhappy customers are your greatest source of learning. — Bill Gates
There are no sacred cows. Regardless if it’s your code, business plan, marketing, or product strategy. If you want to create an environment of high psychological safety, you must also create an environment that seeks out feedback at every turn and is comfortable with negative feedback. You must be ready to listen without getting defensive and be mentally prepared if it is soul-crushing. You must learn to be very suspicious of positive feedback as well, using the five whys can help you here, but it requires discipline. This will not be easy, it takes practice, and you will not get it right on your first try. You very likely will get defensive, you will look for the exit, and you might very well convince yourself right there to give up, don’t!
My advice? Approach it as an out-of-body experience. You are not there, but your representative is, and they have no skin in the game. Their goal is to ask objective questions, get to the root of the issue, and learn as much as possible. The goal is to enable you to be emotional later when its time to empathize and understand where the feedback was coming from.
So how do you know when you’re done? For this, you have to use real data, not intuition. Are your customers using your feature as often as you think they should be? Survey them to find out how they feel, ask them how much time and effort you feature is saving them. Observe what they actually do.
This style of recursive refinement is even more critical in this era where cloud providers like Amazon are eating the world. I’m often asked if I fear that the product I’m building will be one day be threatened by Amazon. While I generally offer many reasons why a company like CloudZero is in a better position to delight its customers and deliver functionality that Amazon won’t, the real answer is “Of course they are going to compete with me if I create something of value!” The counter to that competition is a relentless commitment to iteration. Believe it or not, you can move faster than Amazon, but you can not sit still, they will absolutely overtake you if you do.
Don’t be afraid to throw your solution out the window when your customers just aren’t embracing it
How do you know they aren’t embracing it? You could point to sales as the ultimate indication, but even bad products can make money in the short term. By the time you are really hurting it might be too late to change course. The leading indicator of product failure is lack of engagement, both from customers and from your team. The problem for startups is that founders are hopeless optimists, they build passionate teams, and no one wants to accept they might be wrong.
You must seek out and telegraph loudly that you want critical feedback. When you get it, prove that you wanted it by resisting the urge to become defensive. If you aren’t getting pushback, then something is wrong; you need to be highly suspicious of positive feedback. If product praise it’s not complemented with actual product engagement, you are fooling yourself in the worst possible way.
5. Wait for No One
If you spend too much time thinking about a thing, you’ll never get it done. — Bruce Lee
No-one is more empowered to solve your problems than yourself. If you are blocked, ask for help; If no one is listening, raise your voice; But if the job isn’t getting done, be ready to take matters into your own hands. The keyword here is decisiveness, no one will ever be upset with you for getting something done vs. nothing, in particular, if you are working at a startup.
As your organization grows, you need everyone to embrace the notion that they are fully empowered to do whatever they see fit to get the job done. The agile development tenant would be valuing working solutions over comprehensive documentation, but this concept isn’t limited to engineering, whatever your team's focus, don’t wait, just do it.
You might be thinking that embracing this philosophy is going to step on a lot of toes. If that’s true, you might be working for a company that does not have clear roles and responsibilities (always bad) or one that has intentionally chosen to limit the rate of change (sometimes good). It also might mean you haven’t made an investment in trying to figure out how to get things done. Don’t confuse this concept with the idea that “It’s better to ask for forgiveness than approval”. Knowing how to get things done is an important part of getting things done, you do, after all, have to work on a team. Just don’t wait for an invitation.
Lastly, if you are a leader or manager on the other side of this you have an equally important role to play. If you see other teams embracing this and moving fast but you now find yourself resenting that they didn’t wait for your input, stop yourself right there. It’s also your responsibility to not wait for them. If you think your team's input is going to be critical to the mission, don’t wait for the ask, give it proactively.
Wrapping it all up: 5 rules, 1 goal
Delight the Customer
Commit and Iterate
Less is More
Nothing is Sacred
Wait for No One
I designed these rules for startups and fast-growing software companies with one goal in mind: Build outstanding, fast-growing software companies. That’s exactly where I’ve put them to the test, sometimes with success, other times with failure. I’m still learning as I go.
These rules might not be for you. They aren’t perfect, they likely never will be, but when applied recursively to themselves and with constant care and feeding, I think it’s possible they could approach perfection.
These rules will change and I’ve published them on GitHub to track those changes at https://github.com/silvexis/5rules.
Lastly, If you choose to put these rules to work for you or think I got something wrong or right, I want to hear from you!