On Building a Kick Ass Engineering Team -- Part 1

Donnie - 11 Mar 2011

We started Bizo just about three years ago with the goal of building a great business and a world-class engineering team. One of the first things I did was write down what I thought it would take to create a kick-ass engineering team.

I figured it would be good to share this list with others and discuss why I thought the items would help build a great engineering team.

Here is what I wrote:

Let's review these in a bit more detail...

Commitment to Discipline

"Commitment to discipline" is perhaps the most important characteristic for any super productive team. Software development is full of moments that try to pull you away from the task at hand or the problem that you trying to solve. Those weak moments where you get pulled into refactoring some sub-system end up being a huge time sink. Being able to recognize that while it would be great to refactor, it is not actually a requirement of "getting shit done" and can wait.

Must be cultural

I believe that the culture of any startup comes from the founders and early employees and more generally the culture of any business comes from the leaders. Therefore, it is absolutely imperative for these leaders to define what they want the culture to be and furthermore act on that definition. Culture is self-reinforcing: actions create culture which creates actions which strengthen culture. Just like a habit, once the culture is formed it is difficult to change it so it pays to be purposeful when creating your company's culture. You will have to live with it good or bad.

The 3 Cs

Communication, Communication Communication! (I stole this directly from my high school baseball coach Mr. Barden.) A major part of engineering success comes down to communication. What should we build, how should we build it, how can I plug into your system, how does this code work, etc. We spend an enormous amount of time communicating and it shows. We ensure communication through design reviews for all features/projects, and code reviews for every single line of code that makes it into production. Code reviews are an amazing place to learn, ensure quality and share knowledge. We even spend time communicating about non-Bizo related stuff that we find interesting through "Lunch and Learns".

I'll save how we go about managing all this communication for another post but the ramifications of our commitment to designs reviews, code reviews, and the like result in a team of engineers that are eager to get feedback, humble about their skills and strive to provide objective feedback to others. Objectivity is an extremely valuable characteristic of a great engineer and something that we look for in hiring and something that we strive to develop and promote.


Testing is a huge part of what we believe in here at Bizo. Beyond the obviousness of ensuring that your code works, testing has some great side effects. For one, it is an investment in future development making it easier to develop features on top of an existing product base and making it easier to "pivot" (I used the word "turn" 3 years ago before pivot was in wide use). Being a big believer in having some down time, I also consider testing an investment in one's weekend because things always seem to go wrong when you are not at work. :) Finally, extensive testing ensures a low amount of code debt which should be any dev team's goal. You always have to pay it off and upfront payments are the cheapest...


This should really be part of the 3Cs and I would expand on this even more today. Not only is it important for code metrics, build status and task management to be communicated widely it is extremely important for the efforts of engineers to be communicated. As a company, we have a business standup and an engineering standup where group managers can engage with the teams and get visibility into what is being done. We are also experimenting with bringing engineering earlier into the product development process at the scoping level.


Ownership is key to getting the most out of any team including engineering. I think productivity and motivation is a function of happiness and a lot of happiness comes from being trusted to do your job. At a certain point this comes back to hiring. If you can hire people who are great cultural fits and great engineering fits than you must trust them to do their jobs. That trust will make them better employees.

In Summary

To wrap this all up, I think we've done well staying true to what I outlined three years ago and I am extremely happy with the results. I've been around a lot of engineering teams and I've never been more happy (or proud) of what we've been able to accomplish both with the products and code we've shipped and with the culture of engineering we've built.

To Be Continued

In a follow up post I'll discuss what (if anything) I would add or remove from this list if I had to start over today and what I think we should focus on as an engineering team for the next few years.