At the end of the day, the whole reason that we are at work is to Get Shit Done. "GSD" is a great motto, but what does it mean in practice?

Unpacking GSD

Culture of Quality

The biggest lie of "Get Shit Done" is that software is never truely "Done". There are always tradeoffs between the time spent working on a project and the quality and future maintainability of the codebase. Our philosophy is that we need to continuously invest in quality in the preset to avoid getting bogged down in excessive maintenance in the future.

Scoping for Small Wins

If we never put our software in a box, wrap it up, and call it "Done", how can we ever GSD? Resolving this paradox requires redefining our basic unit of work. Instead of measuring how well and how quickly we can "complete" an entire application, we need to scope our units of work into smaller tasks.

Figuring out how to scope work is an art that requires a fair amount of trial and error to learn. Some good rules for scoping are:

  • Each task should specify a clear deliverable that provides some amount of business value to the company when complete. This value could be a new feature available to customers, a fixed bug that improves user experience, or improving performance and efficiency to use fewer servers.
  • Smaller tasks are better. Smaller tasks let us capture value more quickly, make us more agile, and provide us with a constant stream of small wins. There is much less risk of failure if we can frequently deploy and evaluate each small piece of work as it is completed instead of waiting for a large volume of work to be finished.
  • Ideally, tasks should take no more than a day or two of developer time. There will obviously be exceptions, especially for small bugs that can be easily fixed and initial work on a new application that requires a large amount of work before anything can be deployed.

Commitment to Discipline

There will always be more work that we could be doing than time we have available. Figuring out which work to do is just as important as doing the work correctly. As an academic example, choosing to build a system that provides half as much value as another is equivalent to working half as quickly on the more valuable system. Therefore, maximizing how much we GSD requires discipline to determine the best way that we can add value to the company and to not get distracted by less valuable tasks.

Project Management

Balancing all of the requirements of GSD falls under the umbrella of "Project Management". This section describes how we organize ourselves to best GSD. Like all of our processes, these should be followed in spirit, not necessarily to the letter. Don't be afraid to break rules and change things if they're not working!

Strategic Goals

At a company level, the executive team breaks our work down according to several strategic goals. These provide long-term (multiple quarters if not years) direction to product focused tasks. Additionally, some tasks will be engineering driven based around creating efficiencies in maintaining our current systems and building new ones.

Objectives and Key Results

As of mid 2014, we are in the early stages of rolling out Objectives and Key Results for the engineering team and, eventually, the rest of the company.

OKRs operate in a medium (quarterly) time frame. They provide focus to our efforts and a shared understanding of our goals.

An OKR starts with a single broad objective that serves as a guiding principle. It also contains several key results, each of which consists of a measurable goal that we can use to determine if we are fulfilling our objective. Key results should be aggressive but not impossible; we expect that most key results will be mostly but not completely achieved.

OKRs are organized hierarchically according to our team structure. Generally, the contents of each OKR are driven by individuals and teams figuring out how best to fulfill higher level OKRs. While all OKRs are mutually agreed upon by all stakeholders, they should not be imposed from above on subordinate teams and individuals. So, the company will have certain overall OKRs, which inform but do not dictate the OKRs of each department, team, and individual.

As OKRs are still very new at Bizo, this section will likely be in flux as we learn and gain more experience with OKRs in practice.


On a day-to-day basis, the engineering team organizes tasks according to a lightweight form of Kanban. A full discussion about Kanban is beyond the scope of this document; however, here are what we see as some of the key principles:

  • A task flows through stages representing scoping, design, development, review, deployment, or other discrete steps that form the overall creation process.
  • We should limit work in progress, as that represents time that we have invested but not yet reaped any benefits from. This is accomplished by limiting the number of active tasks. It is often better to focus on quickly getting a single task to completion rather than trying to slowly push multiple tasks forward at the same time.
  • Tasks are pulled into the next stage as we have capacity to continue working on them. They are not pushed out of their current stage when that stage's work is complete.
  • We are mindful about our processes and believe in continuous improvement.

If you are interested in a good book about Kanban, we recommend this one by David Anderson.


Our tasks are tracked in Asana. Typically, each team will have their own project. We use priority headers in the project to represent the stages in our Kanban flow. Tasks start at the bottom and move to the top.

We also use Asana for other types of communication that are best organized as lists. For example, we keep meeting agendas, conference topics, and lists of ideas for blog posts in various Asana projects. Don't hesitate to open a new Asana project if you think it will help you organize and communicate!