People of WePay: Chris Conrad, VP of Engineering and Product
Can you shed light on the difference in your experience leading in a large corporation like LinkedIn and a start-up like WePay?
That is an interesting question, because I worked at LinkedIn when it was smaller than WePay is today, and I also worked at LinkedIn when it was over 9,000 employees. The simple answer is that in a smaller company, you have the opportunity to make a big impact.
Being at a smaller company creates opportunities, because the scope of the projects and size of the things you need to do need to are much bigger. There are fewer experts who are locked into one specialty– at a Google, Microsoft, LinkedIn, or Facebook, there is guaranteed to be an expert in a specific area. At WePay, you get the project because you are the person that is free. You may not be the expert, but you’d better become the expert real quick because the company needs you to get it done. It creates a lot of opportunities to catapult your career forward. This also generally reduces bureaucracy and decision-makers involved, and there is a higher willingness to take risks. This is why I find smaller companies to be more interesting. Your heightened impact applies at all levels of the company, not just to junior people. Senior employees also have a massive impact. When you have an idea, there are fewer roadblocks and you can turn the ship more quickly.
How should a technology-driven company approach building out an
effective engineering team?
There is a different answer for different stages in the company. In a smaller company, you need to hire people that you trust. You can’t just hire a random person. You need to know them intimately and trust that they can get things done. When I joined WePay, there was a solid core of talented engineers, but that was not enough to scale up the company. So the first thing is to identify the problem domain you are trying to solve for. Looking back, I hired several contacts from LinkedIn and other companies. I grabbed people from my network that I knew that were known quantities. I didn’t have to worry about what they would do when they got here. I also hired smart people who knew exactly who to hire. It was finding those key people. This strategy applies mostly to middle sized start-up companies. When it comes to large corporations, you need to build a great and streamlined hiring processes so that you can hire in large quantities that meet the quality bar.
You lead a number of teams at WePay. How do you juggle the cross-functional
nature of your role?
There is the elaborate way of trying to make it sound like I know what I am doing and I am super good at my job, but frequently it comes down to surveying the horizon and seeing which fire is burning the brightest and making sure it is being dealt with. In many ways, the challenge is to find which smoke has fire under it and what is just smoke. Prioritization and discernment are key. There are a lot of projects going on and a lot of areas that I would like to dedicate more time to. I try to effectively delegate the right projects to the right people and then ensure if things start to go wrong, that I can interject myself into the process early enough to ensure the overall success. Things can be as chaotic as they need to be inside the house, but you need to make sure that things are calm and stately outside the house.The challenge is finding which smoke has fire under it and what is just smoke. Prioritization and discernment are key.
What are some metrics you look at in your role? Maybe a good follow-up question is how do you measure success?
On the engineering side, there are the site operational metrics. If we are online or offline, that is the priority. Nothing else matters if the site is down. After that, other important metrics would be latency and error rate. Things of these nature indicate the overall health of the system. I have a personal dashboard that has current site latency, current error rate, and a few other metrics that I keep a very close eye on. There are also some product metrics that I monitor as the Head of Product. WePay is a different company as an enterprise company and we have less control over product adoption than a consumer company. The ability to drive mobile point of sale utilization is kind of out of our control. There are several layers between us and our end users.
Another important metric that people don’t always consider is how often your people are getting paged. You don’t want your people to get burned out. So making sure that if a problem is recurring and waking someone up every night at 2 AM, you need to escalate the issue. So you should track how painful you are making work for your employees. I know that happy engineers are much more productive engineers.
What advice can you offer startups and businesses working on growth?
From an engineering perspective, one of the most important things is scaling your software appropriately. You can fall into one of two traps. One trap is not scaling your systems effectively. That can destroy a company. Twitter fell into this trap early on, even though it managed to get out of it. On the flip side, another trap is that they try to recreate the systems and software of a Google or Facebook. That also is a fallacy that will hurt you long term because you spend so much time building software that is only necessary for the top 50 internet companies. A small company would probably be best off building the next feature.
The guidance that I give my team is to shoot for software that will last 12-18 months and assume that you will rewrite everything every 18 months. If we are lucky, it may scale beyond what is projected. On the flip side, it may need to be revisited sooner. You need to balance between how far out you project versus how much effort you put into the software. A lot of people do not want to spend time rewriting software all of the time and fear that it is wasting resources. My answer to that is no. It’s so hard to tell where you will need to be in the future and what you will need to do. For a startup to project out two to five years, the likelihood that you will be doing what you thought in the future is so small. You are better off making that assumption.
Watching LinkedIn scale is a good example. I worked on a piece of software for their social graph database and the six years that I ran that team, we rewrote it 4 times. The first time it was written, it was just me. The second time, there were four of us. The third time we did the rewrite, there were a dozen. The final time, there were 30 people. If you get it right, you can balance growth versus features. Features are ultimately what help you grow the company.
What are some engineering obstacles that exist within the payments
space that do not exist elsewhere?
There are a lot of them. One is that what we do is very real. You are dealing with real people’s money. This is not a game or social media network. If you go to the grocery store and your payment terminal doesn’t work, you are likely to abandon that shopping cart. If you abandon that shopping cart, not only is that revenue lost for the store, but now they need to pay an employee to restock those groceries. Mistakes result in a significant cost. The level of reliability that you need to build into your software is just phenomenally higher.
The second challenge is the regulatory environment. Most engineers can just sit down to write software and release it. A regulation like needing money transmission licenses can come as a big shock to a lot of people. There are good reasons why its regulated, but all of a sudden, you need lawyers and specialists to help prevent you from being put out of business by a regulator. Some regulations like OFAC are quite scary. You do not want to fund terrorism and the government does not take doing it lightly. Complexities and concerns like these are not something that you deal with in most other industries.
The last challenge is dealing with systems and technologies. There are many third parties that you need to integrate with. For example, most banks don’t have cutting edge technologies and they have standards or systems that have been around for a long time. Maybe in some ways this is good because high tech companies move fast and break things, which isn’t exactly the ethos that you may want when it comes to people’s money. But it does mean when you are a software engineer that you need to build something that is pretty and modern on the outside, but is interfacing with old and archaic on the back end. For example, I don’t know many software engineers who regularly interact with FTP servers, but our engineers do everyday.
With a complex product, how do you manage the different aspects
of the product and deliver them together?
It honestly comes down to good planning. It is manageable if it exists within one team. The second a plan expands between multiple teams, you now need to create interfaces between those teams. You need to define the contract by which those teams are going to operate together. Otherwise, it is very hard. Spending a little extra time to create a contract, define the interfaces, and put semblance of a skeleton around the project, what are the milestones, when do various people need different deliverables, that is really what it comes down to. Good program management is key.
What is your favorite software language or algorithm and why?
I kind of dislike most programming languages (laughs). Every one of them has at least one thing that is pretty terrible. My favorite algorithm definitely is the breadth-first search. This is mostly because I spent 6 years at LinkedIn trying to optimize the breadth-first search over a social graph of hundreds of millions of nodes, which was a very complicated problem to solve. For preferred programming languages, three come to mind. For the vast majority of server side programming, I would unfortunately say that it is Java. It is a generically good at everything, but not great at much of anything kind of programming language. For building actual web applications, I would say Ruby. Right now, my overall favorite programming language is Swift, but it is the most limited for me to use. It is limited in the scope of how I can use it and is the most recent that I learned.