Why You Should Use Tickets for Everything

When I first started Wallaby Financial, I spent a lot of time thinking about what the work environment and processes should look like. We didn’t set out do things differently than other businesses, or to innovate on culture and product. My initial reaction to this was that founders were just making it harder on themselves. Starting a business from scratch and building new disruptive products is hard enough. Why make it more difficult by sharing your team’s salaries or letting everyone get every e-mail in the company?

Since I started in technology jobs in high school 16 years ago, I have worked alone, at startups from founding, and in some of the world’s largest organizations (AT&T—280,000 employees, Deloitte—140,000). I have read my fair shares of articles about unique corporate culture and businesses innovating both with their product and with their team. This has given me a clear sense of how I want to run a company, and it seems like we are innovating in both areas.

Like many startups, Wallaby Financial develops its payments software in a lean and agile way. While not orthodox adherents to either methodology, we run two-week sprints, do extensive testing, and strive not to overbuild our product too early. We are heavy ticket users and have created some great developmental processes using modern cloud-based tools like Asana, GitHub, Evernote, and HipChat.

We don’t just apply these software product development lifecycle techniques to our product development team, however. We use these methods across our entire business for finance, business development and marketing. Everyone has tickets assigned to them and participates in the daily ‘stand-up’.

We didn’t set out to create a new culture at Wallaby around this, but as a former product manager and developer, it seemed only natural to me to organize around tickets and the associated process. It’s not natural to the business team however, and the process is teaching us all a lot about working together.

Take our marketing video for the Wallaby Card as an example. Our first version was put together in about ten days and we were pretty proud of it, but let’s just say that it has a higher-than-average use of stock clip art! Seeing the success of the viewership and the number of times we’ve used the video, we’ve applied developments in other videos and products back to this video and published a new version.

Another great example is business development. When you think about lean methodologies in software, you think about deploying an MVP—minimally viable product — and testing it with users. You then see what they react to and engage with and build out the product as you learn. We use MVPs on the business development side as well—minimally viable presentations. It’s not to say that the slides look bad or the content isn’t thought through, but there might be fewer of them, or they might describe a topic to a lesser detail. Sometimes this is all we need to move the relationship forward. Other times, we need to follow-up quickly with new, more detailed slides. Like any MVP there’s a risk we under deliver (what precisely is “viable” is always the question) but we more than make up for it in time saved.

We run daily stand-ups at 10:30am, spring kick-offs every other Monday, and demos and beer every other Friday afternoon. While these may primarily be for product development (and most of the company is in product development), everyone attends, and everyone contributes. The stand-ups can be a bit disjointed, we admit:

Developer: “I deployed a fix to the master branch and updated the integration test suite. Today I am going to import the logs into Hadoop and see how the scoring has changed”

Business Development: “I met with three possible partners yesterday. Today I am completing NDAs with each, and updating a cold call list for next week.”

Developer: “We found a flaw in the iPhone menu management system yesterday, so today I am rewriting that and adding new assets for the dashboard screen.”

Given our time in software development, writing tickets and stories is second nature to my co-founder Todd and I. However, for some of the team it’s not, even if they have been in technology for years. Most companies do not share business and software development methods. We think it’s critical to our success to do so. The principles apply across the entire business, so why apply them only to software?