An Inside Look with Codeship: Madison May, CTO of indico

Madison May is the CTO of indico, which provides developer-friendly tools and APIs that turn raw text and image data into human insight. We had the chance to catch up with Madison and talk about the challenges of a fast-growing company, fine tuning a development workflow, and the future of machine learning.

An Inside Look with Codeship is a regular series providing an insider's perspective on founding and building a tech company. Each session, we chat with some of the most exciting voices in tech and ask them where they've been, where they're going, and what we could all be doing together. You can read all Inside Look interviews here.

indico was originally founded by Slater Victoroff and Alec Radford, two fellows from the undergraduate university I attended, a tiny school called Olin College of Engineering. After a series of successful consulting jobs, they decided to take the tools they had developed while consulting and produce a product designed to give developers easy access to machine learning tech. When the fall of 2014 rolled around, indico was accepted to the TechStars program, and they made the tough decision to put their undergraduate education on hold to pursue the idea. I had a keen interest in machine learning and developer tools, and I have an incredible amount of respect for Alec and Slater, so I decided to follow suit and joined the company as CTO. It’s been a wild ride ever since.

We looked at the landscape of companies that provided machine learning APIs, and it was painful to see the amount of hype and buzzword-filled language that had come to dominate the market. We saw an opportunity to provide a very straightforward, honest alternative, and Alec had the expertise required to translate some of the more recent advances from the academic community into a form that is usable in industry.

The idea of automating a process that is typically reserved for humans appeals greatly to me. In many ways the field of machine learning represents a frontier -- the machine learning community is just beginning to put together bits and pieces of the theory required to automate some surprisingly complex tasks. I’m convinced that machine learning is going to play a critical role in tomorrow’s society, and I'm excited to help move the tech forward.

One of the major challenges over the past nine months has been finding balance in the amount of process required to keep the company running smoothly. In the beginning, none of our schedules were aligned. Some of the night owls among us stayed until five in the morning and took the morning train home, while others got into the office bright and early. It was all very organic and undirected. We planned days ahead rather than weeks or months ahead.

When we first decided to address the problem by introducing more structure, we ended up overshooting a bit in the other direction. For a while we were definitely bogged down by some of the project management tools we had introduced, and we obsessed over processes that felt productive but may have actually been primarily a distraction. We were checking off boxes on checklists for the simple reason that checking off boxes on checklists felt productive. Processes and tools that make sense at larger companies don’t necessary provide value at a tiny seed-stage startup.

It took us a while to find a happy medium, but I feel that we’ve now arrived at a good balance between structure and flexibility.

When I first joined indico, I expected the CTO role to be what most companies would call a “technical lead” and anticipated spending most of my time coding and informing software architecture decisions. In fact, that’s the role I ended up playing for only the first few months of indico’s life.

It took me a while to realize that often my time is better spent taking a step back and looking at the bigger picture. Trying to make sure that our team functions effectively is often more valuable that having an IDE open and my hands on the keyboard all the time.

I don’t think we've completed that transition yet. I would say about 50 percent of my time is still spent coding, and I still derive pleasure from the mechanics of software development. But I've also come to accept many other roles as well.

With regards to motivation, I'm very much a person who is driven by the end result rather than the process. Being primarily motivated by helping the company to build a product, rather than the intricate details of code, has helped to make that transition easier.

Good communication skills are crucial, perhaps even more valuable than technical aptitude. We’ve interviewed quite a few individuals who are clearly extremely technically competent but who have had difficulty clearly communicating the reasoning behind their decisions. They very well might be able to churn out an absolutely brilliant solution if they are left alone for a long period of time, but that’s not necessarily valuable to us. Collaboration is key, and code written in isolation is code that’s liable to become a problem. It's difficult turning down people who are very technically qualified, but we feel it’s best in the long run.

We are also just looking for passion, like every company. One of the strongest indicators is when someone comes in and communicates how they think indico could be made better. That’s a huge positive indicator.

In our development workflow, one problem I’m focusing on is the time between hypothesis and the result of an experiment. Oftentimes you'll make some initial guesses as to what the proper model is for a given problem, and then you'll wait several hours before you get a result. We want to cut down on that response time. We want to minimize the time between developing a hypothesis about why something is wrong and evaluating whether or not your hypothesis is correct. When turnaround time is too long, the development process becomes very frustrating and very inefficient.

We are putting significant effort into making sure that turnaround time is short. The same goes for deployment cycles. We want to be able to go from initial conception of idea to something that we can test and validate with real people as soon as possible. For these reasons, continuous integration and continuous deployment are incredibly valuable to us.

There are definitely times where the engineering team will feel that something is very intuitive, only to get feedback that our design decision is confusing once the product has been shipped. I think one of the best decisions we’ve made recently was hiring a user-experience lead to ensure that doesn’t happen. Every company needs someone with an ear to the ground to tell when users are happy or are frustrated.

I don’t know if you would call it a philosophy. We test what we feel is necessary. We shoot for coverage standards, and we shoot for other related metrics, but we don’t test merely for the sake of hitting coverage metrics. There is real value in knowing when a test is being written for the sake of increasing a number and when a test is being written for the sake of helping us identify a problem and to prevent problems in the future.

We split all tests into two distinct groups: unit tests and functional tests. Functional tests ensure things look right from the user’s perspective, giving us the confidence we need to ship an update. Unit tests ensure that we are able to quickly identify and fix problems that do arise and help nip potential problems in the bud. These two styles of testing play two very different roles, and it's important to separate the two.

Infrastructure still feels very broken. It’s a very fragmented industry, and although a community seems to be growing around the use of containers for simpler infrastructure, there’s certainly no universal solution. I’m hoping that the community will unite around a single approach over the course of the next couple of years, but time will tell. It’s also one of the reasons that the services indico provides are so valuable to people -- it’s difficult to run many machine learning algorithms at scale, so we handle hosting and infrastructure so our users don’t have to.

It's very important to listen to and gather feedback from the rest of the team. One of my main roles is aggregating opinions and information. Oftentimes, it's not myself that’s the most qualified to make a decision. It is my role to aggregate that feedback and learn what the organization believes is the best solution. It's also important to very quickly understand that your own productivity should not be measured by technical output. Measuring the productivity of a CTO by measuring code output is a very, very poor metric. Productivity, for me, means enabling people to function uninterrupted and helping to break up work into components that are easily handled.

Communication is key. It’s my job to be able to communicate our company’s technical aspects to people who perhaps don’t come from a great technical background. Learning to cross that language barrier has been tough, especially when you're working in an industry like machine learning. Learning to communicate some of the same concepts in everyday language is critical.

Communication is always a huge barrier for any new idea.

I found that there are a lot of analogs between software architecture and good methods of running a company. A lot of the red flags in architecture are similar to the red flags in an organization.

Like the idea of spaghetti code -- the idea that there are too many components responsible for a single function as opposed to having each component be responsible for a single action. That was a pain we felt in the early days of indico. It wasn’t clear who was responsible for what aspects of the company. It took a while for us to figure out how to effectively route tasks throughout the organization and to ensure that the proper people contributed to decisions. Having everyone have a say in every decision doesn’t necessarily contribute to a good decision-making process. It just contributes to confusion.

There are also similarities in the principle of redundancy. We have been working hard on knowledge transfer, so that no knowledge resides in the head of a single person. Knowledge should spread out across our organization so we can continue to function in the absence of an individual.

I would want to communicate to my former self that you should approach urgency in a different way. Early on, I felt a lot of urgency to get things done and to ship products, to make rapid decisions. That feels rewarding because rapid decisions lead to rapid change. But in reality, it's also very important to make well-informed decisions. Don’t confuse short term growth with long term sustainability. The things that are good indicators in the very short term are not necessarily good indicators in the longer term.