Dom Scandinaro is SVP of Engineering and Data at Cameo. He has more than 15 years’ experience in engineering roles at a number of companies, such as Luxury Garage Sale, and has extensive expertise with Android and iOS mobile app development.
In our conversation, Dom discussed the engineering efforts behind an innovative product launch, Cameo Kids. He also talked about his approach for balancing innovation with handling tech debt and offered insights for staying up to date with rapidly changing technology.
Cameo Kids is by far my favorite project right now. We launched it a little under a year ago. Parents and loved ones can book personalized videos from a child’s favorite character.
The voices of the animated characters are based on recorded samples by voice actors. This project is especially close to my heart because it uses emerging technologies like generative AI that I enjoy working with.
We worked really closely with a company to do the voices. We have our own tech that glues it all together, takes the user input, creates the video, and sends it back to the customer.
Coming out of COVID, our company has been going through some retraction. This project was a bit hard to prioritize with a limited team.
A lot of work was needed to get it out the door, but its outcome was unknown. We didn’t know if it was going to have a really small audience or an absolutely massive audience.
In this type of situation, I often think it’s more convenient for a manager to get their hands dirty and do some of the coding themselves. I had an opportunity to work on the project quite a bit hands-on, and I’m continuing to work on it as we launch new characters.
As a small startup, nearly everything we do is a very iterative process. We usually release stuff in kind of an A/B test-type environment.
We didn’t do that with Cameo Kids because we wanted to be able to go to the press and talk about it. If you’re out there blasting that JJ from CoComelon is now on Cameo and then half the people who come to your website can’t find it, that’s obviously not a great experience.
We launched in December of last year with a limited number of characters: Blippi, a couple of characters from CoComelon, and a Santa Claus. It could have taken us a year or more to work out the business partnerships and implement all the technology to launch with 10, 20, 50, or 100 characters.
We saw great success in just the first few weeks, so that led to more resources and internal prioritization. We were able to iteratively add a few characters from Ryan’s World earlier this year, and some other characters that were in the franchises of the partners we’d worked with previously.
We have another exciting character launch coming up soon, as well. We continue to invest in and broaden the project over time as we see success.
Cameo has been around for a little over six years. That’s probably a really short time compared to large enterprise companies, but it’s an eternity compared to most startups. So at this point, we have quite a bit of technical debt.
Almost everything we build is built under a feature flag, and then we have to prioritize the work to go back and remove those feature flags. Similarly, we may have worked with a vendor or used a particular technology in the past to power something like search on our website before moving to a different option. Those are some examples of the sort of stuff that’s sprinkled everywhere in our codebase.
Given the amount of code that we have, any project that we can prioritize to pay down that technical debt is almost an innovation in itself. That enables us to make the site much faster, leading to higher rankings on Google and better SEO, and also just making it easier for our engineers in their day-to-day.
When engineers tackle a new project or fix a bug, they have to deal with the technical complexity of understanding all the code that’s around everything that they are going to touch. Having old, unsupported products in the codebase means there are more unnecessary feature flags there as well.
These things make it difficult for engineers to get their jobs done efficiently and with as few bugs as possible. So prioritizing this stuff actually helps us move faster over time.
We also have quarterly bug bashes. That’s a two-day event where engineers get to prioritize stuff outside their biweekly product sprints and instead focus on paying that tech debt down.
We have quite a few celebrities who have been working with Cameo for the duration of the company, and we don’t even have to ask them for feedback. They’re beating down our doors to suggest things or sometimes to complain about a new change we’ve made.
Some of these people are recording hundreds of videos a day, so just one change that we make could either really increase their quality of life or make it very difficult for them to get this task done.
About once a month, we kick off our weekly all-company meeting with a quick Q&A session attended by a celebrity or creator who’s on our platform. It’s really exciting to be surprised by a celebrity appearing in the meeting like they’re part of the company. This practice is both an employee benefit and also an opportunity for us to get feedback about the product and things we could be doing differently.
Exactly. In each session, one of the standard questions is, “If you were the CEO of Cameo, what would you prioritize changing about the app?” We always get really good feedback about something they don’t like or a new idea that we may not have thought of.
We also regularly interview creators and celebrities from our marketplace, as well on the product and design side, to get feedback from them. We collect customer feedback from App Store reviews and from comments that people submit to our customer service team.
A couple of jobs ago, I was at Luxury Garage Sale, an online luxury consignment company. Users could sign up to consign an item like a multi-thousand-dollar handbag, mail it to the company, and the company would sell it to someone else. The RealReal is an example of a much larger company that does this.
The issue was that so much of that workflow is very manual. The goods have to be received at a warehouse, then someone has to sort through everything, photograph the items, write ad copy, predict how long each item will take to sell, decide on a starting price, and then work out the pricing schedule over the consignment period.
This just felt like the type of problem that was ripe for machine learning. So we wrote an ML model to work on a lot of that stuff — everything from writing copy to suggesting the starting price.
The ML model was particularly helpful for setting the price of the item and for predicting how long it would take to sell. We used that information to inform the human-powered process that we were running there. There was still a significant human element needed for inventorying everything, checking for damage, and also checking for authenticity.
It was a really fun project to work on, and it kind of got my brain spinning about ML early in its adoption. Since then, there’ve been projects where I’ve had a chance to use it, like the Cameo Kids initiative we talked about earlier.
It’s really important to me to lead by experience. I don’t want to ask someone to do something that I haven’t done in years myself; I think that could lead to some level of resentment.
So one thing that I’ve been doing for almost my whole career is to have a sample project that I can keep rebuilding in the latest programming language or framework. This enables me to push myself to stay relevant.
I’m also involved in the technical specification docs that get written for everything we build at Cameo. This helps keep me in the loop with everything we’re building and how we’re building it.
It is — more than 10 years ago, I wrote a really small application to track the timings and schedules of Chicago Transit Authority (CTA) buses arriving at individual bus stops.
This was before there was an official CTA app. At the time, they had an API that they used at the different stops to show when the next bus was coming.
So I wrote a mobile website for that many years ago and now I rebuild that same website or app, depending on what technology is relevant for the service area as a way to try out different languages and frameworks.
I think that’s a pretty nuanced question because it really depends on the size and makeup of the team. I believe strongly in diversity of expertise on any team. Also, people do their best work when they can lean on their strengths instead of having to do things that they’re not good at or don’t enjoy.
Due to Cameo’s growth, I’ve had the opportunity to interview a lot of amazing engineers. If I had a small team of two engineers, I would document their strengths and weaknesses. Then, for a third hire, I would try to find someone who had the right pieces to fill in the puzzle around those folks.
With a bigger team, once folks have proven that they can tackle the engineering problems and pass those parts of the interview, I like to focus on the soft skills. There are so many people in this industry who can write code. I think it’s really important to enjoy working side by side with someone, whether you’re digging through a log file, dealing with a production outage, or working under a stressful deadline.
Hey there, want to help make our blog better?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up now
Learn how to implement one-way and two-way data binding in Vue.js, using v-model and advanced techniques like defineModel for better apps.
Compare Prisma and Drizzle ORMs to learn their differences, strengths, and weaknesses for data access and migrations.
It’s easy for devs to default to JavaScript to fix every problem. Let’s use the RoLP to find simpler alternatives with HTML and CSS.
Learn how to manage memory leaks in Rust, avoid unsafe behavior, and use tools like weak references to ensure efficient programs.
Learn more →
