To most engineers, fixing support bugs is a task to be dreaded or avoided. Not for Bobby Brown, a senior engineer at Mavenlink. His passion for the role has helped create a support team that’s not only backlog-free (most days) but genuinely enjoyable for the engineers that rotate onto it.

Tell us about your background and how you ended up at Mavenlink.

In college, I learned both useful things and useless things — when I left, I didn’t really know which was which. Then I got an internship at Mavenlink, and that started to change right away. I was pair programming with engineers who were senior to me, so I was learning a lot from people who had much more experience. I loved Mavenlink’s pairing culture; everybody was social and there was this warm, communal feeling in the office. I know everyone loves to say they are “collaborative,” but at Mavenlink I learned what that word really means.

Now — four years later — I’m a senior engineer and I get to work on the problems that interest me most. A lot of those come from the support track, which I manage, but I also get to dig into fun challenges beyond that role.

What are the support team’s responsibilities at Mavenlink?

We deal with 90 percent of client-facing issues. When some part of the software isn’t working properly, a client will create a ticket, which we audit. We work through as many bugs as we can, as fast as possible. The goal is to complete as many bug-fixes as we receive, so there’s not this ever-growing backlog. That’s the battle every support team is fighting.

“I loved Mavenlink’s pairing culture; everybody was social and there was this warm, communal feeling in the office.”

One way we keep on top of bugs is with the help of our team of support staff in the Philippines, who are available to our clients 24/7. They address user errors and help categorize the tickets they receive. If they verify that the issue is actually a bug, they work through preliminary steps with the client, then present it to us on the support team.

We’ve also revamped the support team processes significantly to keep up with the product’s growth.

Tell us more about the changes to support you’ve been part of.

Our support track started about four and a half years ago, before I joined Mavenlink. The team realized it was becoming difficult to solve bugs because, since we pair and rotate so frequently, they didn’t know which engineer had written the problematic code — and could therefore help fix it. The solution they came up with at the time was to designate a pair of engineers for support, and they would rotate every couple of weeks.

That was the strategy for about three years, during which time the company grew from 20 to 160 people. Eventually, two engineers wasn’t enough, and two weeks wasn’t long enough for them to pick up context from the pair before them. It was like every pair was starting over every time they rotated onto support. It was not a great situation.

How is Mavenlink’s approach to support different now than when you started?

About a year ago, I partnered up with Katherine Scheer, who was a product manager at the time and is now Director of Product in Irvine. We reworked the support process from top to bottom. We knew we needed a new way to handle bugs, a new way to communicate priorities, and a new way to manage from a product perspective. We worked closely to make sure every story in the backlog was audited by her, by me, and by other team members.

“People used to dread their time working on support — now it’s a completely different experience.”

Instead of two engineers inheriting someone else’s mess and spending half their rotation trying to figure it out on their own, we now have a support team that keeps up with ongoing issues. We kept the rotation structure, but now my team brings each pair up to speed and gives them context and concrete, actionable problems to solve. People used to dread their time working on support — now it’s a completely different experience. Team members know they are helping a customer with an important problem, and because some engineers stay on support continuously, there is a new level of consistency and much less frustration.

Most engineers dread support. Why are you drawn to it?

Software bug-fixes are something I’ve always been passionate about. It just always struck me as a waste to invest in new features when we have a huge backlog of bugs. We need to maintain our current features before we build more that could cause new bugs. Ultimately, that means Mavenlink can’t make progress without support. It was something I really cared about, so the leadership trusted me to come up with a solution and take ownership of the problem.

I think the reason engineers don’t like support at a lot of companies is they feel like they’re cleaning up other people’s garbage. Most of the time, you’re working on bugs you didn’t create; you have to dig into somebody else’s code and get to know it better than they did. That’s a stressful process, and it can be frustrating for engineers. But it’s not an issue anymore at Mavenlink because there’s a team of people doing a bunch of that work ahead of time. By the time it gets to our support pair, we’ve narrowed in on what we call “actionable bugs” and can give them enough context to quickly understand the problem and how to fix it.

“Pairing is one of the things that helps the support track the most.”

Like any quickly growing business, I’ve seen Mavenlink struggle to prioritize support — there are just so many other things going on. But I’ve always believed having a bad experience in support can be particularly detrimental to the success of a product. This is a key interaction point that sticks with people. Whether a client will recommend Mavenlink often comes down to the quality of their experience with support. And at the end of the day, it doesn’t matter how nice our support team is if we don’t have engineers solving problems effectively on the backend and closing the loop.

How does pairing affected the support track here?

Pairing is one of the things that helps the support track the most. The team leads have a weekly resource planning meeting where we figure out who should be on which team, including who will be rotating on or off support. Because we plan who’s coming up and adjust that rotation, we can solve for a lot of requests, like pairing a more junior person with someone more senior. That helps us ensure that support is a learning experience, rather than a chore.

Being on the support team also gives engineers a two-week vacation from their usual activities, and they get to pair with people they normally wouldn’t. That helps distribute good ideas, because pairs always end up sharing what what they learn with each other. It’s also contributes to this warm and fuzzy Mavenlink feeling — at some point, everybody pairs with everybody.

Interested in joining the team?

Check out Mavenlink engineering roles in S.F. and Salt Lake City, or reach out to JB Steadman at

This story was created in conjunction with Job Portraits, a San Francisco based employer brand agency that helps startups hire at scale.

Mavenlink Product Development

Musings from the Engineering and Product Design team at Mavenlink

Mavenlink Product Development

Written by

We’re the team building Mavenlink — Product, Design, Engineering, QA, DevOps and Technical Writing

Mavenlink Product Development

Musings from the Engineering and Product Design team at Mavenlink

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade