Conor Harris

Starting his journey

Hi, I’m Conor Harris. I’ve always liked math and building things, so I went to school to be a mechanical engineer. Halfway through school was when I first interacted with computer science it really resonated with me and I found myself excited for an 8 a.m. class and I knew I needed to shift focus.

I found a middle ground that wouldn’t set me back academically and finished out my degree in Electrical and Computer Engineering, but I went right into software after graduating. I started out at MITRE, and I can’t say enough positive things about that company and how awesome their support and training were. They supported me in getting a master's degree in computer science, so I was able to build out a comp-sci background and remediate some of the imposter syndrome I was dealing with.

Once I decided to move on from MITRE, I tried to be more intentional when choosing jobs and planning out career goals for myself instead of just taking what I wanted or could get. I had so much I wanted to do and, as the saying goes, “You can do anything, but you can’t do everything.”

When finding a new role, I knew I wanted to do something that was very different from what I was doing at MITRE so I could keep learning and expanding upon my coding skills. I decided the next best thing to try was working in a startup. I ended up at InsightSquared in mid-2013. I had to work very hard in that job just to catch-up with a different type of business and development approach and put a lot of effort into it, and I can honestly say that I got even more out of it. At startups, there is always the opportunity to make a big change and seriously affect the company with what you bring to the table, and that was the case for me at InsightSquared.

Learning and growing at InsightSquared

When I got to InsightSquared, the product was in an earlier form and focused on staffing analytics. Our biggest data source was Bullhorn with some other staffing ATS systems sharing some of the market as well. We would ingest the data and put it through our Data Analytics pipeline to then build it into data models and reports for our customers. As the company grew, we incorporated different verticals as well, using resources like Salesforce to start doing sales analytics as well and moving into more touch points besides staffing.

I came on as a senior data engineer right after they raised a series B and joined a team of about 15 other engineers. This job was a trial by fire for me as an engineer, because we were trying to integrate agile development at the same time they were bringing in the sales vertical. We completely redid the data transformation pipeline, which covered all of our providers and customers, and it was a very difficult process.

However, working on this pipeline and rebuilding it is what I am most proud of from my time at InsightSquared. What made it such a challenge was that we were working with so many different use cases. Each company had different workflows that we had to try and build into the business logic of the pipeline. It was a tough nine months, but it paid off and we reduced our memory footprint by 25%. It was one of those teams that I will never forget because it was like we were in the trenches together and moving mountains all at the same time to get the job done.

Management and leadership at a startup

I ended up in a management-type role about a year after I started at InsightSquared, and being a manager at a startup was a different world. I struggled the most with the sheer amount of conversations going on, hearing from up top what needs to happen, getting feedback from my manager, and trying to put all of these into effect while trying to find my voice as a leader for those on my team.

One of the biggest lessons I learned at InsightSquared, and one of the biggest career lessons I have ever learned, was how to be a leader while also being myself. I looked up to our CEO, Bryan Stevenson, so much and was always trying to be just like him. But, as I interacted with more people at different levels of management and in different roles, I saw how different people let their personalities shine through when helping and guiding people.

My style of leadership centers on setting clear expectations and making sure that I’m coaching instead of just telling everyone what to do. I get satisfaction from helping others and feeling that I am of use in solving problems. I’ve found it's better to approach problems and forks in the road together when working with someone on my team, and that way I can provide guidance along the way. I want to know their perspective and what they think so we can brainstorm and find a solution together.

Healthy hiring frameworks

If I could go back and do anything different at InsightSquared, it would be to have a more effective and healthy hiring process. Hiring is a two-way street because you have a clearly defined role that you need filled, but your job is also to figure out how close that fit is to what is going to make the prospective employee happy, too.

You want people to thrive and make sure that they can be the best they can be at whatever role you’re offering. As a hiring manager, it is all about the fit, not personal judgments. I would frequently check-in and make sure everything was good and make it easy to pull out if it isn’t working out, no bridges burned. Being able to be flexible, transparent, and clear helps to get through some of the frustration, hurt, and stress that can accompany the hiring process.

The first hire at Clora

When I was changing roles after being at InsightSquared, I knew I wanted to try being the founding engineer of a company, and I joined Clora as the first full-time hire. The founder of Clora came from a career in biotech, and Clora is a platform that connects life science teams, people working in biotech, and pharma companies to find contractors or new employees. There was no software built before I got there, and there’s nothing like not having a backstop. It was a whole new world to live in that involved a different way of thinking. It involved a lot of firsthand research and A LOT of networking. As I built confidence, I felt these new muscles being toned and found more and more comfort in these new processes.

My mindset walking in anywhere is that I know the least in the room, and this came out more as the first engineer. I didn’t need to have a consensus, but I wanted to try and get some validation before firmly committing to any huge changes. At Clora, I helped build an in-house engineering team of about five engineers with a design contractor and other remote contractors to help build the product. We were able to build out a two-sided marketplace for people in life sciences, and it was cool to operate in such a new field.

One of the companies that inspired me at this time was hired.com, and we were fortunate enough to have the founder as one of our early investors and advisors. Having his input was so much help because they were also a true, centered marketplace for developers. It was great to see how they built patterns and solved problems, especially from the tech side—when starting something from scratch, you take all the help you can get.

Working simply to work efficiently

One of the biggest lessons I learned from an engineering perspective at Clora was understanding when to pull back and simplify a process. The biggest example of this was the data science pipeline we built. Instead of trying to construct a huge data science recommendation engine, we would just take in a resume from a consultant and ask one question at a time using small classifiers. We were getting ready to put our heads down and get to work on a more extensive rec engine when we took a step back and asked ourselves what the actual value was and what the most useful thing to deliver would be.

So we built a machine learning classifier that had a high degree of accuracy to synthesize each area, ie. what is your role, where have you worked, etc. We would then take these little questions and build in what matters most in a profile and automate it to make everyone’s lives a lot easier. It allowed for a faster time when trying to fill a specific role, and we let the automation help us and make this speed possible. Overall it tied into the product vision so much better and got the information into the hands of the folks doing the work. It was one of the best engineering decisions I’ve made as a manager.

Organization and scaling at Privvy

I joined Privvy as VP of engineering early this year, and it has been a great fit. As Privvy expands as a marketing automation solution for small merchants, more and more small businesses also get to grow which is great.

In my first days at Privvy, the first thing I did was to understand how everything was organized. One of the models I stick to is the People Process Technology model to anchor myself. Breaking down everything into these three categories and then making a plan to deal with each one helps me gather ideas and group things to bucket my priorities. Then, when looking more specifically at each team, we use the “directly responsible individual” model from Apple that provides a good set of accountability frameworks and clear responsibilities when setting up roles. We are at an inflection point of growth where we can’t plan around individual expertise anymore, we need to look at the teams as the functional units to tap into as we’re scaling.

That’s also where having clear roles and responsibilities in the context of each team is key. Operating within ambiguity is one of the biggest things that will halt a team because people start shrugging their shoulders and diffusion of responsibility creeps in. This can lead to frustration, moral drag, slower development, and missing pieces of developing processes. Overall, setting up defined structures and frameworks has been the biggest help for me getting started at a fast-growing startup like Privvy, and I’m excited to see where we keep going.

Thinking about an incident program at Privvy

Building out our incident practices is something currently on our to-do list at Privvy. Right now we’re still documenting, quantifying, and building the accounting spreadsheet. So the goal is to add more metrics so we can have more visibility over our services. For reliability, it’s easier to go slow. Even if it is just getting one command or one metric up and running, that is still moving in the right direction. After cleaning up some of the noise in our systems, we can start routing some quality metrics to teams.

Another key aspect that we're building out so we can get more of a hold on incidents down the road is to see where the time goes. We’re trying to quantify our incidents and see how much time it takes us to respond, so we can inform our investment into the reliability space. So much of reliability hinges on being transparent and quantifying what the costs are, and it's going to be imperfect. But perfection isn’t the goal here. It’s all about building trust within your teams and with the PM about what is realistic. If there’s a problem and the fix involves migrating your entire system from Roku to AWS, that may not be a realistic investment to make and you should vocalize that. I know that’s an extreme example, but it demonstrates how that rust is needed amongst teams and that quantifying time is also an important consideration when dealing with reliability.

Conor recommends

When it comes to media, I’m all over the place, have a general interest in video games, TV. However, one podcast I’ve gotten into is called Anxious Achiever with Mora Aarons-Mele from the Harvard Business Review. It resonates with my style as a natural worrier and has a lot of great episodes that I’m still getting through. It’s very thoughtful, and a great listen. At the end of the day, I’m just looking to turn my brain off, so I also love having time with my wife and dogs to relax.