Meet A ServiceTrader
Eric Burns, Senior Software Engineer
Eric is part of the Engineering team, which builds the software for the ServiceTrade application.
He is one of the five original ServiceTraders from the founding of the company.
What do you do at ServiceTrade?
I’m a senior member of the software development team. We make all the features associated with the software that ServiceTrade customers use. We build everything from the ground up, we add new features, we fix bugs, we make sure it scales as we get more customers and larger customers as well as scale with the growth of the company. We’re always looking to raise the bar in terms of making the overall user experience more consistent, more intuitive, and just a better experience. Every year, we are making the app better than the year before. Hopefully, our software is growing with our customers and becoming more polished and more sophisticated.
What’s a typical day like as an Engineer at ServiceTrade?
We start the day with a morning stand-up. We are broken up into sub teams, so we meet with our team and talk about what we did yesterday and what we are planning to do today. We talk about anything that is an impediment, a difficulty or a concern, so problems get identified early and so we are aware of what other team members are working on as there might be a way for us to help each other.
It’s kind of a solitary exercise to do development work, so a lot of our day is just spent fingers on keys, creating functionality, fixing a bug, or whatnot, but, there are touchpoints where we interact. The tougher problems will often result in conversations between different members of the team. We’ll do code reviews of all the work so whenever we have something ready, another developer will look at it, and a lot of the time that will result in a conversation around how to make the code better, so the initial set implementation of the code isn’t always the final version. Sometimes there’s ways to iterate on what we did to make it better, to make it hold up better, scale better, be less buggy, or maybe we know some problems with it.
We also coordinate with QA when our code is with their team for review. QA stands for Quality Assurance. They’re responsible for testing our work and determining whether it’s ready to deploy. They find a lot of issues before our customers ever see them, so our deploys are ready to be used by our customers. We also coordinate with product managers to make sure that the business desires are being met by what we’re doing, so business questions will come up during our work.
We follow Agile, so we try to plan close to when we work. Agile is a methodology used by many development teams. It focuses on a self directed and iterative approach to managing work for a team. We want to deliver and get feedback in as tight a cycle as we can. We also give feedback to ourselves as a team every three weeks in a retro. This gives us an opportunity to continually improve. This is contrasted with older management techniques, called waterfall, where work gets planned out in meticulous detail months in advance. Agile recognizes that no plan like that holds up. It’s a way to embrace change and respond to new information, while continually delivering new working functionality every sprint.
Once a week we do a grooming, which is where we look ahead at work that is not being worked yet but might be next sprint. We do 3-week sprints right now. A sprint is like a segment of time that we plan out self-contained work. It’s supposed to be a smaller segment of time because people are better at planning during smaller amounts of time. Three weeks from now, we’re going to know a lot more than we do now, so trying to plan out 6-weeks ahead in meticulous detail doesn’t really make sense.
During the grooming meetings, the product owner presents his vision for some upcoming work – some of it might include some user experience (UX) designs; there’ll be stories with acceptance criteria on it like, ‘the user needs to be able to do this, this, and this on this page’ and then we’ll have discussions about implementation. First of all, we have to make sure we’re on the same page in terms of the business need but also in terms of implementation. The QA team is very valuable during the grooming meetings because they ask a lot of questions in terms of how they’re going to test the work, which often informs us on questions we should have thought to ask. It’s really helpful for that all to be one meeting and for everyone to be talking to each other.
Then, the other part of Agile that is really important is once a sprint is complete, we’ll do a retro. We’ll get together and talk about what went well and what didn’t go so well in the past sprint. The goal is to not point fingers about the bad things, it’s completely forward-facing about how we make the next sprint better than the last sprint or what was good about this sprint that we want to keep doing for the next sprint. We want to always get better as a team.
What has your ServiceTrade journey been like?
I wasn’t hired by ServiceTrade. I was hired by DunnWell. I guess technically I was re-offered my job, and I accepted when we became ServiceTrade. I came on to be an employee of DunnWell, and this was sort of an nascent spark within the company where DunnWell had created this software for itself, which was the first version of ServiceTrade’s software. We call this LSN, which stands for Legacy Service Net. Service Net was the name of DunnWell’s product. There was some thought of maybe we could market it and sell it to other people in our space – in DunnWell’s space. Brian Smithwick did just about all of the software work. He created this thing. He made that first product that showed what was possible. Because it was so good and was so effective for what DunnWell was doing, the idea was “hey wait a second, let’s start from scratch and build this from the ground up, using best practices and make something that we could sell to other companies. Let’s get really serious about this.” So they hired Billy Marshall to lead that effort.
So, I was one of the initial people in the room. We were like, “oh ok, we’re our own company now.” I thought, “oh gee, I hope this works out. I’ve got one small child and the other on the way”, but fortunately, it did work out. We were able to develop the product to the level where we could get customers. Those early customers really elevated us because not only did they trust something completely new for their business, but some of the feedback they gave us was so critical to our success.
It was interesting times. I’m really happy it worked out. It’s been a fun ride.
Kara on the left is the first baby born to a ServiceTrade family.
Clark on the right was just turning 1 when I joined DunnWell.
What’s it been like to see the company grow from zero to more than 100 employees?
So, the engineering team was originally a little footnote in a larger company, and then we became a very important part of a new company. It was kind of on us to get this product ready – fast enough – so that we could start making money before we ran out of money. We were a small team, and we were tiny for years. It really wasn’t until last summer when the partnership with Frontier Growth and Bull City Venture Partners started – that’s when our team started growing really fast. We used to be a really small team trying to be really effective with really senior people – but not many of them – working together and collaborating closely on one single team. That’s changed for us; there’s two teams for the application now. There’s a team for mobile and a team for integration. And, it’s going to split off into more teams. We’re growing, and the teams are going to get too big to be a single team and with that will come specialization for teams.
We’re in a time of enormous change right now. We’re hiring more junior developers than we have before. We’re open to different levels of experience than we had before, which is cool because it gets kind of boring with mid-career people. It’s great to bring in fresh blood and younger people with more energy. It makes things more interesting for everybody.
Which of the ServiceTrade culture values is the most important to you and why?
I think collaboration is important for everybody, and it’s important for Engineering. We collaborate with each other a lot; we collaborate with other teams like Support, and the fact that at ServiceTrade, there’s an assumption of respect – everybody at the company has credibility and standing – like in terms of someone speaking within their field. For example, if a QA person says, “this release isn’t ready.” That’s taken seriously. If a developer says, “we can’t do that in 3 days. We’d have to rebuild this in order for it to be the right architecture,” they’re listened to. I can’t think of an experience in my professional journey where there has been less push-back when someone speaks in their expertise. Just in general, it’s important to us as a company that people are valued and respected and that we focus on communicating well, respecting people for what they can do, and not getting distracted by other foolishness. Everyone who’s been in the workforce long enough has had bad experiences where some of the other stuff gets in the way, and we’ve been very successful so far about not letting that happen here. We really value and respect people.
But having said that, I think even more important to our team is curiosity. It’s easy to do something the way you know it can be done. If we’ve done something like that this way, and if we squint, we can sort of do it the same way here. I mean that’s the easiest thing in the world, but it’s not always the best thing in the world. We want to take our time and reexamine our past decisions. We’ve got a 9-10 year codebase at this point, and if we just keep doing things the way we always did them, then it wouldn’t take long for that to catch up to us in a bad way. We always want to reexamine what we did and whether there is a better way to do it. Not only do we have people on the team with that attitude and with the attitude that they want to learn more, but we have support from management to do that, which is incredibly rare in my experience.
There’s manager buy-in to go back and rework stuff, and it’s like “ok we want to make the page work the exact same way it did before but better behind the scenes.” That will make it a little faster, it’ll definitely scale better, it’ll be easier to work on, but the user won’t right away notice anything that’s improved. And for projects like that to get prioritized and to get minimal push-back, it’s fantastic. It’s a great environment to work on if you like to take pride in what we produce as a team because there are a lot of other environments out there that are so feature-focus that it catches up to them. If you’re always making features and you’re never going back and working on technical debt, you end up having a really poorly performing app with a lot of bugs that costs a lot to change, so ultimately, it’s the right decision. It’s not always the easy decision, but it’s the right decision, and it’s very gratifying as a developer to have that kind of support.
As a veteran ServiceTrader, any advice?
Yeah, for those junior developers, every senior person you work with was junior at some point, and if you stick around, you’re going to be senior. Don’t limit yourself. If someone is talented and they’re excited about learning, they can improve very quickly – both in general and in terms of learning the specific code environment of the company that you’re in because when you join a new company, that’s a big deal.
Whenever you join a company as a developer, you learn the stack and the codebase, and that all comes with time. Look for opportunities to be taught how to fish and not receive a fish. The people that we look for already have that in their DNA and their mindset. We want people that really want to understand how things work. “Ok, how do I do this? Ok why?” Ask those “why” questions. If someone gives you help with something and you don’t understand why the thing they gave you helped, don’t let them in the conversation until they explain it to you.
Be self-directed, too. Don’t depend on managerial guidance to make calls all the time. If you know something is an issue that needs to be looked at, maybe you’re the person that needs to speak up for it or you’re the person that needs to look at it. That’s the kind of spirit we try to have on our team. We do have management – and management does matter and does help – but we don’t want to completely lean on management. We want to be self-directed and proactive. If something seems a little off, we want to investigate it without necessarily waiting for someone to tell us to do it. We also want to be dependable; that kind of mindset is something that if a junior developer gets, they’re going to learn very quickly. That path is going to lead them to maturing very quickly in their craft.
What do you do in your free time?
Oh, well I play the guitar very badly. I do a lot of board games; I’m a big board game fanatic. Our family has a board game night once a week. Back before COVID, we had a board game club during work. We still kind of do, but we haven’t worked out the online board game playing. Yeah, I love board games a lot. I spend a lot of my time playing them and reading about them. Those are my two main hobbies other than having two kids.
I read a lot, too. I like reading SCI-FI and fantasy. I read a lot of Jack Vance, and my vocabulary improved from the experience.
