What’s in a role: JJ Fliegelman, CTO and Cofounder of WayUp
By Amanda Mulay, Senior Talent Manager
In this series, “What’s in a role,” we ask portfolio company leaders about their career paths, the best way to break into their vertical, and what operators should know about hiring for their position. Past posts profile a COO, Internal Recruiter, and a VP of Brand and Customer Experience.
Early-stage companies across all sectors bring on an engineering leader to help their technology scale. In the early days, that person might be a technical founder or cofounder but if not, hiring someone to fill that role is usually a top priority. Technical needs can vary greatly by company and founders without a technical background tell me they’re unsure of what to look for in a candidate. So I sought out an expert to share some insights into what founders should know about hiring their first engineering leader.
JJ Fliegelman, cofounder and CTO of career discovery platform WayUp, was the perfect candidate to help break down the CTO role, having built his own engineering team at WayUp over the past five years. In our conversation, JJ shared his nontraditional route to CTO, weighed in on whether founders should use off-the-shelf tools or build their own, offered insight into emerging enterprise technology trends, and much more.
(The following interview has been edited and condensed for clarity.)
Amanda Mulay: Tell us a bit about your background and how it led to your current position as CTO and cofounder at WayUp?
JJ Fliegelman: I studied International Studies and Business at UPenn’s Wharton with a heavy focus on Operations and Information Management. I didn’t formally study computer science, but I got into programming at school mainly through hobbies and finding opportunities to automate stuff for other classes. I got more serious towards the end of school by participating in hackathons, and I met Liz Wessel (my cofounder at WayUp) through one of the hackathons.
After I graduated, like everyone else at Wharton, I was freaking out about careers. I knew I needed to get comfortable with the idea of being uncertain about my future, so I made a plan to not have a plan for the next year — and I bought a one-way ticket to Spain for two days later. I didn’t have enough money just to survive, so I needed a job of some sort — and I needed to find a way to make money that I could do over the internet, where I could make enough per hour to have time both to work and to explore, and in a niche where I seemed to have a competitive advantage. That was when I really got into programming.
Like all good nomadic backpackers, after returning to the U.S. a year later, I joined McKinsey as a management consultant. I wasn’t building things, but I was in a group where I would help tech companies with management consulting — like helping large companies leverage big data to bring in more revenue. After two years, I left McKinsey and started WayUp with Liz as its cofounder and CTO.
Mulay: What does your combo role entail and how do you typically explain it to people?
Fliegelman: I have two sets of responsibilities: one as a founder, and another set as CTO. Something that’s often confusing for people is that the CTO role, VP, Engineering role, and other tech leadership roles can vary tremendously from company to company. Because of that, I tend to describe and think about the overall set of technical responsibilities that need to be fulfilled by someone in the company, and then explain how at our company or in our leadership configuration who is responsible for what (based on skillset and desire). Werner Vogels has a great blog post on this on the different types of CTOs that there can be at different companies and how their responsibilities and skillsets can vary.
At a high level, some examples of my personal CTO-specific responsibilities currently include: overseeing Engineering and Product teams, Engineering and Product P&L, including external tools, and high-level architectural review and guidance.
Mulay: What should founders consider when deciding between building their own custom technology versus using off-the-shelf tools?
Fliegelman: Paul Graham (I think) has a quote I like that goes along the lines of “if the first version you ship is perfect, you waited too long.” Particularly in tech, everyone feels like they need features and tools customized exactly to them. The truth is that no matter what problem you’re facing, other people probably have encountered this before or fixed it before, and there’s probably a way that you can benefit from what they built or learned to solve that problem.
The classic answer is usually unless it’s a core differentiator for your product, you should strive not to build it yourself. However, there are lots of nuances to this — if you find yourself bending over backwards to make an external tool fit your use case, building it yourself probably makes sense.
That said, my preference is usually an option that a lot of people don’t mention: Use as many well-understood, off-the-shelf, “boring” open source tools as possible — and if you need tight control, run them yourself. If it’s well-established, open-source software, you have the most freedom of all: you can find a hosted service, you can run it yourself, you can patch it, you can benefit from the community’s continued development of it. Then it’s no longer “build versus buy,” but rather more of a sliding scale of “how much of this do I want to be responsible for myself?” Intercom has a pretty good post on building less stuff yourself, and also one on choosing boring technologies.
Mulay: Any advice on building an engineering team?
Fliegelman: You really want to align your engineering values and your company values, and a focus on building those engineering values (just like you would your company’s values) is really important. As your team grows, it becomes harder to keep track of what people are doing at your company. It can be even harder with engineering, where you can’t be reviewing every line of code. You need to make sure that your team shares your philosophy of how to build, and to achieve that you need to be thoughtful about what conventions and processes you care about, and document and build a culture around that.
Mulay: How is your engineering team structured and are you still actively coding?
Fliegelman: Our engineering team is pretty flat. The most important structures we have are: (A) “chapters,” where, biweekly, anyone involved in an area of the codebase (backend, frontend, devops) gets together to discuss best practices and make decisions, and (B) “pods” or “teams,” which are dedicated to specific areas of the product, no matter where they fall in the stack. Today we have a “Candidate Team,” an “Employer Team,” and a “Data Team,” but this has changed many times over the past couple years. These days, I don’t code that much, but I probably still do a bit more than I should. I consider it a negative thing for me to own a feature, and I do everything I can to avoid hero mode.
Mulay: As you look to the future, what are some broader enterprise technology trends that particularly excite you?
Fliegelman: I’m really excited for the trend I’m seeing across all industries of the return to the human touch mixed with technology. In many situations, people value the human touch, whether it’s getting a personal video tweet from your Warby Parker customer service rep or a human answering the phone rather than forcing you through a phone tree. But in order to get the human touch to the scale most companies need it to be, technology needs to play a key role, and I’m really excited about that.
Our approach to technology in HR is to use machine learning to help you as a candidate and to use as much technology as possible to help increase the human touch efficiently and scalably. For example, WayUp’s Source and Screen product enables something that until now was seemingly impossible: our clients can quickly phone screen hundreds of candidates, give every single candidate personalized feedback on their interview, ensure only qualified candidates make it through, and have every candidate feel like they’ve really gotten to know the company because they spoke to an actual person.
Mulay: What should a founder or hiring manager look for if they want to bring on a CTO or VP of Engineering?
Fliegelman: Hiring for tech roles might feel difficult for founders because they don’t have the engineering skillset, but often those same people don’t have a problem hiring people in other skillset areas they don’t have, like accounting or marketing. To me, it’s the same process, and you can apply the same strategies you would use to hire any other technical role you couldn’t do yourself to make your first engineering hires.
What you’re looking for will really depend on the stage of your company, the make-up of your founding team, and your product. If you don’t already have someone technical on your founding team, even if you do hire a CTO, you’ll still need a founder to be responsible for that area of your company — technical or not — as one day you may have to replace this person or role. Rather than focus on title, I’d focus on what skillsets you need.
At the seed stage, you’re probably looking for someone who can build quickly and hire a few other decent engineers to build with them. Later on, you’ll be looking for someone who can build and manage a small team — and past the Series B, you’re looking for managers of people and architecture, which is an entirely different skillset than what was needed to get you to that point in the first place.
Mulay: What advice would you give to anyone interested in getting a job as a CTO?
Fliegelman: I think it varies tremendously based on the company size. It’s the same as asking “how do you become a CEO?” If you want to be CEO of a startup, start one. If you want to be a CEO of a Fortune 500, it’s a very different path. It goes back to what do you actually want to be doing, and the exact title matters less. If someone told me they wanted to become a CTO, I would guess that it meant one of four things: “I want to start a company,” “I want to call all the technical shots on a project,” “I want to run a team,” or “I want to just build awesome stuff and not worry about people management.” Each one of those is a valid desire, but you need to identify which it is that you’re aiming for, and then go seek out a company that has that role available — and often the title might not be CTO, but it’s exactly what you want to be doing.
Interested in a role at WayUp? Check out current job openings here.
