In a business, and particularly in early-stage startups, there can be enormous pressure to go as fast as you can. In these environments, making fast decisions, and pushing code or building a design to get to the closest stated objective, is prioritized over a more contemplative process.

Famously, Facebook put it this way: "Move fast and break things." Get your code out there, big picture be damned. A few bugs here and there, or mounting technical debt, are acceptable collateral. Over at OKCupid, CEO Mike Maxim put it in strategic terms: "we can’t sacrifice forward momentum for technical debt."

Six years ago, Facebook moved away from this motto to the far less catchy "move fast with stable infra". As Mark Zuckerberg explained at the time, "what we realized over time is that it wasn't helping us to move faster because we had to slow down to fix these bugs and it wasn't improving our speed." Moving code around quickly so you can close out a Jira or GitHub ticket quickly and move onto the next thing isn't anywhere near as helpful as it feels. The right thing to do is take a step back and ask questions about what you're doing with a bigger picture in mind.

"There were plenty of cases where people would rush software out the door and learn something, but never put that learning back into the program. That analogy was borrowing money, thinking that you never have to pay it back."
~ Ward Cunningham

The same is true outside of product development. A 2010 study published in Harvard Business Review found that teams that took time to slow down, consider the impact of what they are doing, and have debate within the team moved faster - perhaps counterintuitively - than those that concentrated on running as fast as possible.

It's not enough to write code, build a design, or make a decision. To be effective, you need to think about how your decisions affect your community: your team, your customers, the other teams in your company. Software development is a people business more than anything else, and your decisions, fundamentally, should make the next set of similar decisions easier. 

Are you designing a page, or are you designing a way to empower your team to design subsequent, similar pages in the right way?

Are you fixing a bug, or are you taking the time to make sure this kind of bug never shows up again?

Are you just building a new feature, or are you also laying the groundwork for subsequent, similar features?

Are you making a strategic decision, or are you hardening the principles and process by which future strategic decisions will be made?

Are you doing work for yourself, or are you empowering your colleagues?

There are certainly more questions to ask. Hemant Taneja, Managing Director of General Catalyst, has some excellent questions that every management team should ask themselves. The core questions for each business, and each team, will vary.

Velocity is not the same as effectiveness. By stopping to think about how we can be more effective in our work and decisionmaking, we can move faster, have a better working life, and do better work.

Slow down. Think about what you're doing. Build for systems and principles, not individual goals. You'll get there faster.