On the 15th October, Mint was confronted with its 10,000th case in FogBugz, an imposing visual landmark of four consecutive zeros across our computer screens. An outsider’s reaction might be that Mint has made a lot of mistakes in the last couple of years. Surely 10,000 bugs in roughly two years for a company the size of Mint Digital must be a bad thing, no?
At Mint, the 10,000th bug is not only a positive milestone, but also a time for reflection on our development process, our accumulation of collective expertise, our desire to involve all team members in all projects. Instead of a liability, it represents on one hand the accomplishment of the volume and diversity of Mint’s work. Perhaps most importantly, bug 10,000 captures the dogged commitment to a process that has provided a practical foundation for Mint’s core values.
At Mint, the concept of a bug is not limited to a software defect, but any task that a team member can take on. This can range from designing a homepage or adding a new feature in an application to writing a proposal or setting up a 401K. Viewed from this perspective, the 10,000th bug represents two years of industriousness and not sloppiness by a "bunch of incompetents".
Perhaps Mint’s core value is best expressed in our handbook for new hires:
In order to understand how we operate, the most important tenet to grasp is this basic principle:
Everyone works on all projects.
In typical consulting work, distributing work in this fashion is relatively rare. The common case is that the developers are divided up into dedicated teams that are devoted to a particular client or project. Typically, the developers become very well versed in the technologies/processes/needs of their assigned project.
So it begs the question, why would Mint choose to approach this problem differently?
- Mint wants to encourage the transfer of knowledge/techniques/processes across all projects. Invariably, working only on one project leads to the atomization of the company where developers on one project have little awareness or desire to know about other projects.
- Mint wants to build knowledge and support redundancy into the process where if developer A is on vacation or unavailable, anyone else can step in and fix a bug, deploy a release, or answer a fundamental client question. While these examples are common at Mint, many other consultancies find themselves in emergency situations in these cases.
- Mint wants to encourage best practices through the standardization of techniques and processes. Mint’s project management process is not possible if every project is completely different with varied deployments, testing frameworks, etc. At Mint, we collectively decide on what is best and use it as a team. We have developed a set of core collective expertise that we are constantly refining in the search of simplicity and efficiency.
- Mint wants to keep developers and designers from getting stuck on shitty projects with no chance of parole. We all know some projects are less desirable than others. We share the collective burden and provide our people with varied challenges and experiences on a daily basis. At most other consultancies, you spend three years trying to get off a project you hate. See if you can explain how that model could possibly encourage technical or creative excellence.
- Mint wants to encourage a sense of investment and knowledge about what is going on at the company in everyone. We feel knowing about all projects, the successes and the rough patches, allows everyone to feel a part of and influence the direction of Mint. Also, knowing about other projects helps you make the right decision when issues come up on what you are working on.
With that, we are off to the pub to raise a toast to 10,000.
And just in case you were wondering, bug 10,000 was a minor video frame grab issue on our site www.styleinsider.riverisland.com.
