On flytedesk’s Engineering Team, Ownership, Communication, and a Commitment to Users are Key
Engineers at flytedesk have no shortage of interesting problems to solve — they’re single-handedly building an end-to-end ad platform for the college media market. In this interview, Katy McNeill (Head of Product, above in photo) and Dan Newman (Director of Engineering, also above) dive into the technologies they’re using, the shared history that brought them to the company, and what they want to tackle next. And yes, they’re hiring. Learn more about flytedesk from CEO and Founder Alex Kronman here, see job openings here, or send questions to Kit Summers: jobs@flytedesk.com.
First off, what does flytedesk make?
Katy: We build the technology for advertising in college media — student-run newspapers, radio stations, campus billboards, you name it. We resist the term “ad tech,” though, because our main mission is understanding and helping student journalists. Journalists at 2,300 schools trust us, rely on us, and want what we make. And for advertisers, we’re the only way to reach college students at scale.
Dan: Before us, if you wanted to run an ad on 100 campuses, it would have taken 100 phone calls. With flytedesk, it takes minutes. That’s a game-changer for big brands, but Katy is right — everything starts with the students.
Tell us about your background, and why you joined the team.
Katy: I studied graphic design in college and started out at a small company in Denver called Scope Technologies. That’s where I met Dan. As my position there evolved into more UX and UI design, we worked one-on-one and eventually rebuilt the entire product. Back then, I’d give Dan, like, Photoshop files or JPEGs, and he’d do his dev work from that.
Dan: The JPEG days! We’ve come a long way.
Katy: I joined flytedesk a couple of years ago, and the main draw for me was the culture. I remember when I interviewed with Alex, he was in joggers and a flytedesk T-shirt — and he still is. It was exciting to hear him talk about the mission, and his vision for the future. I really liked the idea of funding student journalism.
Dan: I was a freelance developer before I met Katy at Scope Tech. There was a lot of working from the ground up at that job, and Katy and I actually built everything on a framework I developed.
“We’re bringing many different mediums onto one platform, which has never really been done.” — Katy
Katy left the company first and took a job here at flytedesk. She knew I was looking around and gave me a call. I already had another offer on the table, but I interviewed here anyway, and I liked that it wasn’t a typical, mundane interview — Alex asked some out-of-the-ordinary questions. I think Katy and I both missed working together, too — picking things apart together and finding the design and dev gaps in whatever we were building. Plus, flytedesk was a product I could get behind. It was an interesting opportunity so I accepted the offer here.
What kinds of technical problems are you solving at flytedesk?
Dan: No one had cracked the college media market before we came along. So even though there are thousands of specialist companies in the ad tech industry, we’re in this multibillion-dollar segment that’s pretty much an open field. We’re building everything from the ground up.
One current challenge is data and analytics, which we need to aggregate from a ton of sources. We’re pulling together popular college majors, demographics, and location data, then putting it in one place and making it easy to filter. And we’re always adding new data, so it’s constantly evolving. Scheduling is a challenge, too, because one buyer might place an ad across thousands of publishers. We’re looking at implementing some AI processes to help us optimize, by looking at demographics, locations, and data we find using analytics and feedback we’re gathering.
In the future, we’ll need people working specifically on data, and on our scheduling algorithm. Right now there’s a lot of opportunity for someone to carve out their own role in those spaces.
Another challenge is making sure the platform is super intuitive, especially on the student media side, where we get so many new users. We’re trying to build a UI people will naturally want to engage with.
Katy: That’s an interesting challenge on the buyer side, too, because many people only have experience purchasing digital, or print, or billboards. One of the fun things about flytedesk is that we bring so many different mediums onto one platform, which has never really been done. We’re figuring out best practices that we can apply across all of those channels.
What processes and tools do you use?
Dan: Our processes have evolved over time. We were doing agile and scrum, then sprints. Now we’re heading toward continuous integration. Instead of testing and releasing several features together at the end of a sprint, we’re building smaller features with their own tests and QA. We push them to production whenever they’re ready, which lets us move much more quickly.
In general, I think simplicity is important. We try to avoid over-engineering solutions. I also think things like linting make a big difference in helping new people get up to speed. When all the code looks like your own, it’s much more straightforward.
As far as tools, we’re building with Laravel and Vue.js, which are a lot of fun to use and make coding much easier. When we get into our maintenance period, we’re going to re-evaluate and re-implement all of our architecture. We’ll probably use Terraform, which will give us version control, and we want to containerize everything with Docker. We’re also planning to use Rainforest QA, which I’m really excited about. It’s a crowdsourced QA platform.
Katy: Rainforest is going to be amazing. With one or two in-house QA people, a full system test typically takes at least a couple of days. With Rainforest, we’ll be able to do that in 40 minutes — any hour of any day. It takes a lot off of our plates.
On the design side, right now we use Axure to wireframe high-fidelity prototypes. Everything actually functions, so we can walk through it in user testing and have our customers click through things as they give us feedback. That helps us flush out any issues early on, before dev starts working.
How do engineers collaborate, and who gets involved from other teams?
Katy: Early communication is key. We bring in the lead developer as soon as it makes sense, so they can get an idea of what the project is going to look like and help us understand the scope on their end.
“Simplicity is important. We try to avoid over-engineering solutions.” — Dan
When we developed our product for special editions of newspapers, for example, I started out talking with Piper, our VP of Growth. We went through a few iterations on design, and once we realized scheduling was going to be a major factor, we brought in Dan.
Dan: It’s always a balance. How much do you rely on process, and how much do you just go in and start developing? For complex projects, it usually helps to spend some time diving into the details before we start to code. At first, we didn’t realize that special edition product would need its own schedule, rates, and dates. That fundamentally changed our approach.
Katy: Exactly. Meeting and storyboarding early on can save so much time on a project like that. I love working with Dan because he’s always willing to give us the dev perspective. He won’t just build something he doesn’t think is right. If a design doesn’t make sense to him, he’ll come over and talk to you about it. That’s invaluable.
How would you describe the flytedesk culture?
Dan: I feel like I can be myself here. We accept each other’s nuances and quirks, and you can be open about problems, even if you’re talking to the CEO. You never have to be nervous about a conversation here.
We also spend a lot of time with each other outside of work. The team goes out together, and we get drinks for birthdays. We always bring Julian the Clown!
“You never work harder than the CEO. Alex told me that in my interview, and he’s never failed to live up to it.“— Katy
Katy: Yeah, people think Julian is made up, but he’s real. He’s on our team page for a reason.
Another thing I like about our culture is you never work harder than the CEO. Alex told me that in my interview, and he’s never failed to live up to it. If Dan’s here working late, so is Alex. He may not be coding or directly working on the same project, but the moral support means a lot.
How do new engineers get up to speed?
Dan: One thing that’s helpful is what we call the port-a-page project. We have some pages written in jQuery that we’re migrating over to Vue.js, and giving that work to new devs has been a great, quick way for them to learn the system and get familiar with expectations and best practices. I think code reviews go a long way, too. You do your thing for a bit, and then we’ll sit down and look at places where you can better use our platform. We’re also planning a big push on documentation during the next maintenance period, which will be a great resource for onboarding.
“Fresh ideas are not only welcomed, they’re expected. There’s a lot of opportunity here to make an impact.” — Dan
Katy: I think our effort to communicate early on in a project helps, too. I do weekly one-on-ones with everyone on the product team. They set the agenda, so it’s a good chance for them to give me input on designs. But it’s also an opportunity for me to bring up anything I see that needs to be fixed. I think it’s important to set that standard of, “You can talk to me about anything. Let’s figure it out together.”
What do you look for in a new team member?
Katy: I don’t ever want to work with a developer who comes in and builds exactly what I show them. There will always be something I missed, or something they understand on a different level. I want people to challenge the design — that’s what makes it better. So you need to be pretty strong-willed, I think. You need to have your own opinions, and be able to make a case for them.
This is a small team, and we’re all busy, so autonomy is also important. We’ll support you, but we want you to exhaust every resource you can to try to solve a problem on your own before you bring someone else in.
Dan: Absolutely. The most important thing is taking ownership. We’re looking for people who genuinely believe in what we’re building and will put in the extra time and effort to make it happen. Fresh ideas are not only welcomed, they’re expected. So there’s a lot of opportunity to make an impact. Our road map is years long, and a lot of those projects will be a chance for new devs to come in and introduce us to technologies. I want us to create a playground where we figure out the best, most efficient way to tackle features. The only limit is our own creativity.
Interested in joining Team flytedesk?
Check out open roles or email questions to Kit Summers at jobs@flytedesk.com.