Ian Grabill is a lead developer at Ticket Evolution, a software company which he describes as “a behind the scenes tool that powers the secondary ticket industry.” Acting as the “pipes connecting ticket brokers to distribution sites,” Ticket Evolution has a strong development focus that supports ticket brokers across the web. Earlier this year, when they found that their teams were spending more time dealing with complicated back-end systems and less time growing new products, they realized it was time for a change.
In this conversation, Grabill talks to us about a recent organizational shift within their development teams, the role of buy-in across teams and how other organizations can put similar principles to work.
This interview has been edited lightly for clarity and length.
Q: A lot of the work that your team does is behind the scenes, creating the structure on which businesses are built. How do you organize your teams within your own company?
A: We just made a change. It’s early- we’ve been at it for about 3 weeks, but it’s interesting.
Ian Grabill, Lead Developer, Ticket EvolutionBefore, there were two main products: our API and our ticket management tool (a point of sale) for brokers. One is primarily a front-end based product, like a browser interface. The other is the API. We divided our development team into two: one served this tool, the other served the API.
The API is a bit of monolith. There are a ton of different products inside it, including a lot of legacy code. It’s really the backbone behind everything.
The point of sale, on the other hand, is like a wrapper around the API. It’s very lightweight and easy to maintain, whereas the API was very intricate and hard to work on.
What we found was we were trying to maintain the API so often that it was hurting forward progress. We were constantly getting bogged down.
So we took a step back and defined our three core targets: one is distribution, the ability to sell tickets through the API or a white-label distribution site, the second is fulfillment, the ability to buy tickets online, and the third is inventory, which is the idea of getting more tickets into our system and making sure they are priced accurately and are as diverse as possible.
So what we did was create three silos with connections between them—so one silo would be fulfillment, one would be inventory and the third would be distribution.
And we put inside each silo a project manager, a lead developer and a team of developers.
What that did was really consolidate the breadth of knowledge each person had. So I now lead the inventory team. We sit down, figure out a solution to a problem and then implement it end-to-end.
Q: How has the new structure changed the way you work?
A: It’s really closed this gap between engineering and product. In the short time that we’ve been doing it, it’s really cool how setting people on a similar mission and giving them less to think about actually creates more productive and more efficient problem-solving and teamwork.
It’s a breath of fresh air for me. Before, I wasn’t efficient enough in what I was focusing on. Now we’re asking the team to step up and be more involved in just their component.
The gap between business and tech is always one you have to overcome. By putting people in the same boat, no matter where you’re from, you just know you’re all in charge and accountable for the same thing. It creates this cool level playing field where anyone can add value. And whether we succeed or fail, we’re in it together. Hopefully more of the former.
Q: How have team members adjusted to their new roles?
A: For me, it’s been a little challenging. I have the most knowledge around a lot of the parts, so for me it’s been challenging getting people up to speed. It’s involved a lot of knowledge sharing with people who aren’t as familiar with these parts. It’s an investment. I’m investing a lot of time in teaching people how to handle different components. But you have to know that it’s all for the right purpose, and that once you get through this learning process you’ll be able to go so much faster afterwards. It’s a little weird not focusing on as many things, but it’s just refreshing being able to focus on something specific and make huge strides just on that specific part.
Q: What advice would you have for another team in a different organization for replicating this process?
A: I think it’s important that everyone is on board. It won’t work if you half-ass it. You have to be on board with the change and be willing to give it a shot. That’s probably most important.
Another thing would be that everyone needs to be on the same level. There’s no vertical structure here. You’re all in the same room, working with your team, trying to solve the same problem. No one is bigger than another person, no one’s ideas are bigger than another person’s.
Something we’re working through right now that we haven’t worked out fully is that there is a bit of ambiguity when something arises and it doesn’t fit completely in one silo. Say we’re building API permissions. API permissions are pretty broad and span across multiple groups. Who should be handling this? How should we divide this? You end up having a conversation around it and figure it out.
For now its been moving very well, much better than I had expected.
