Software Development

Leading the tech behind a new way to book business travel

Chief Technology Officer Emily Dresner of Upside Travel on why she hires people who are smarter than she is.

CTO Emily Dresner at Upside Travel.

(Courtesy photo)

For any company with teams on the move, the cost and coordination of business travel can be a logistical juggle.

Enter Upside Travel, a platform that allows companies to streamline the flight and hotel booking process and build customized travel packages, all while accruing those coveted miles and points and earning 3 percent cash back. The app — a 2017 realLIST honoree — fills the gap for small- and medium-sized businesses that don’t receive big corporate travel discounts. At Upside’s tech helm is Emily Dresner, the company’s chief technology officer who came aboard soon after its launch in 2017.

Before joining Upside, Dresner worked her way up through engineering roles and was last director of product engineering for Luminal, Inc. Today, Dresner leads a team of more than 50 engineers to power Upside’s REST-based Node.js and machine learning-powered work travel platform.

We sat down with Emily to learn more about the tech team at Upside and how she approaches this leadership position.


Tell us about the role of the CTO. How do you structure your days and where your attention is spent?

I reserve the first hour of my mornings to get my head around the day, look at calendars, read email, book meetings, and look at my to-do list in Todoist.

Usually my day is kicked off by our high-level engineering and product meeting to gather a good idea where current, in-flight projects stand. Then, my day is a mix of one on ones, interviews, engineering meetings and status. This is punctuated by updates on Slack and in email. I will collect work to do in Todoist as the day goes on, or harvest any useful articles to review at the week’s end on newest tech, AI or engineering operational research. We have a company operational management standup at day’s end.

I set Fridays aside for maker, reading and thinking time. Friday afternoons are when the magic happens.

As CTO, how do you make decisions on the core philosophies that lead your technical teams? What are your resources for discovering these?

My core overriding philosophy is that I hire super-smart people who are far smarter than me to do awesome things. My job is to enable my engineering teams, give them everything they need to succeed, ensure they’re well supported, and get myself out of their way. I fundamentally believe I am a bottleneck, and my role is to provide the teams coaching, guidance, tools, processes, techniques, and the support to make themselves successful.


My second overriding philosophy is that a diversity of viewpoints isn’t just good but fundamentally necessary to success. I consider both a diversity of background and a diversity of roles. We build cross-functional teams at Upside. Everyone has something important to contribute. You’d be surprised what you learn if you bring other voices into the room during product discovery or planning.

Tell us about the technology department at Upside. What’s it like to work there? How many deployments are your teams making per day?

Upside is an Agile with Scrum shop and we use a bleeding edge toolset. Github, Node.js, some Go and Python, VS Code. We have a machine-learning research and development program.

A typical engineer will join a Scrum team when they join Upside. That Scrum team will have a clear role — for example, they’re working on integrating rental cars in the shopping and booking flow. The leads and product managers will collaborate to build a product requirements document. The team will, collaboratively, break the product requirements into stories and perform standard costing and assigning in planning. Then we work on two-week sprints.

Engineers join standups for their teams which are rigorously held to 10 minutes a day. Everyone sits together with their team with access to both their lead and their product manager at a fingertip. Github pull requests are peer reviewed. Once code is in, the build system sends it off to the development environment for testing. Once signed off, the code goes to staging. Our quality teams will perform their testing plans on it — we have automated testing suites — then the code is flagged for production and it goes out.

New engineers at Upside typically get their first code accepted into the building two days after joining. We have spent years working on onboarding. I believe smooth onboarding of new engineers is mission critical.

We understand you’re a systems junkie. How does your systems thinking reflect in the organization you are building and growing at Upside?

I bring systems thinking into how I think about scaling the organization, how different teams act or interact, how engineers work with the infrastructure, and how we can smooth the path from laptop to production and get things done.

When I think about building a new team, I start with asking questions. What is the role of this team? Do we have enough work in that role to justify this new team? Do we know what that work looks like for the next several months? Do we have team members currently working at Upside who can seed this new team as an anchor? Can our other, sister teams with product and UX support the addition of a new team, or do they also need to expand? How will this new team interact with the other teams? In six months, what do I expect the product output of this team to look like? If I get satisfactory answers to these questions, we’ll start building.

Subscribe to our Newsletters
Technically Media
Connect with companies from the community
New call-to-action