The Soft Skills of a Startup CTO
Recently a colleague of mine, Carlos Ganoza, posted an article about the “Soft Skills of a Startup CEO.” In the same light, I thought of writing an article about the “Soft Skills of a Startup CTO”, since you would think that soft skills are associated with CEOs, but NOT with CTOs. Though CTOs are the ones who need them the most. Specifically, I wanted to share stories about the soft skills that I thought helped me in leading the tech efforts as CTO at a successful startup like Wanderu.
My path to becoming a CTO was not a straight one. As most tech folks, I had a severe disadvantage: I was an over-protected introvert. Migrating to the US (from Peru) was my defining event, as I had to learn to fend for myself and become assertive and independent. Going from Lima, a big South American capital, to a small liberal arts college (Ohio Wesleyan University) in the “middle of nowhere, USA” was a good training ground for entrepreneurship, I believe. I had to figure out how to be resourceful and sometimes find creative ways to make up for the lack of resources, mine and that of my school. I had little spare money and my school was a bit behind on equipment. On one occasion, I volunteered to be a system administrator, so that I could get my hands on a Unix system and learn everything about it.
Following is a list of the soft skills that I believe helped me in carrying the job of CTO. They are what I think, the skills that every aspiring startup CTO should have.
Communication
Speaking in public in a second language was one the hardest barriers I had to conquer. Going to a small college where everyone knew each other and where everyone addressed each other by their first name, helped me with my self-confidence. I even stepped out of my comfort zone by becoming involved in the student-run activities (ACM — Association for Computing Machinery). This was my training ground for community-oriented events many years later.
In a startup situation, there are two main types of communication (by audience), technical and non-technical. Communicating with my fellow team-mate was the easy part. I liked explaining things on a whiteboard, so that came naturally. Explaining a design, a solution, a plan, is critical in order to move the troops in unison.

Communicating something technical to a non-technical audience, on the other hand, took extra effort and did not come easy. In order to be successful, one has to be self-aware and avoid the assumption that the audience knows what you are talking about. I had my practice working for a consulting company (Cambridge Technology Partners), where I had to explain markup language concepts (SGML, the predecessor of XML) like tags, elements, attributes and style sheets to writers who where English majors.
In a startup situation, you have to communicate to your partners, investors, customers and folks on the business side. Sometimes it was easier to come up with analogies or real life examples to express some technical concept. For example, I often mentioned the diagrams of routes on the back of airline magazines to explain what a graph is.
Extroversion
Most techies are introverted, that’s a fact of life. We like to be left alone in a corner and work on your stuff. This is detrimental if you are in a position of leadership. It won’t be of any use if you hide in corner to be by yourself.
It takes “effort” to be out there and chit-chat at a cocktail party or at a conference after-party. Being social is important because it can connect you to your next partner, investor, or employee. Networking and community formation are two important side skills evolving from this. If you are not somewhat extroverted or become more extroverted, you won’t succeed at forming a community. Navigating thru a community is nowadays critical in an open-source oriented startup software industry. It took some effort to get used to this, because I (like many techies) naturally find it exhausting.
Leadership
A CTO must chart the course and your fellow tech team-mates have to follow. Two of the most important tasks at the beginning of a startup is picking a tech stack and hiring your founding engineers. Picking a tech stack is one of the most nerve wracking things to do. What if I pick the wrong stack? I would find out many years later, if I did the right thing. In my experience, I tended to be bold in my decisions. I picked technologies that had sound concepts behind them and made sure that had a solid community was behind them. My examples were Java (server side) and XML in 1998 for a personalization engine (Open Sesame) and nodejs, Python, MongoDB and Neo4j in 2012 for a ground transportation search engine (Wanderu). In the end, both picks turned up to be the excellent choices. One aspect of picking a tech stack is to attract fellow engineers. Most engineers like to work on interesting and leading edge tech. However, this has to be balanced with what the technology can accomplish and one has to be careful with the hype.
One of first things that a CTO will do at a startup is to hire a tech team. Hiring people whom you have worked before turns out to be the best. Two qualities that other engineers value the most are empathy and respect. If you have been an engineer yourself, it is easy to show empathy to other engineers. You just treat others the way you like to be treated, and don’t treat others the way you didn’t like to be treated. Engendering respect is something you have to learn to earn. Usually that comes from the decisions (technical or other) that you make, treatment of others and overall philosophy. If you manage to engender respect, you are on the way to inspire your team. That way, you can achieve the key to loyalty and high probability of success.
Organization
At a CTO conference (CTO Connection) I first learned about “Conway’s law.” The law, named after a programmer named Melvin Conway says, “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” I have found out that this has been true, in other words, your team organization is reflected in your architecture. For a startup in its early days, I favored a flat organization where most (if not all) members are full stack and “interchangeable.” In terms of architecture, you end up with a balanced one, where there aren’t any extreme points of weakness.
Two organizational points (for a startup) that I liked to take care of from the beginning were on-boarding and code repository/code workflow. By on-boarding, I mean the blueprint or playbook by which a new member of the team gets started. For example, I once had the whole installation procedure (of the system) documented. A new engineer was able install the entire system on his first day without asking me any questions.
Code repositories and code workflows are things that have to be setup from the get-go. Although workflow procedures are not really needed until you have a team (more than one person).
Curiosity
Curiosity of the intellectual kind is for me the driver for innovation. Tech folks always seek newer and better ways to solve problems. As CTO, you have to be ahead of the curve. You have to be constantly reading about the latest tech, going to meetups and conferences. Also, you have to be challenging your team-mates to read up of something new and try it out. Tinkering. Breaking toys to see how they work are qualities that you had as a kid.
If you are not “out there” being curious about the world and what others have built or are building, you’ll most probably reinvent the wheel and waste a lot of time. This is time that you could be using on your core tasks or product.

Engineers are like big kids. They like StarWars, StarTrek, Pokemon, comics, puzzles, and board games. Playfulness is a key element for an engineer to thrive. If you let engineers “play” with new technology, you make it possible for innovations to flourish from the ground up. We applied this playfulness at quarterly internal hackathons. And speaking of board games, we used to play Pictionary in the evenings. One time we had a even clients and other entrepreneurs play with us. It was great for team bonding, collaboration and “get to know you better.”
Imagination/Vision
Disney engineers are very good at this, they can imagine a new world and later make it “real.” Not for nothing they are called “imagineers.” Imagining the “ideal world” is something that a CTO has to bring to the table. The imagination transforms into vision, which will inspire and drive your team.
I first “imagined” modeling interactions between users and products (for Open Sesame’s personalization engine) using directed graphs back in the early 2000s. During those days, Java and relational databases were the technologies du jour, thus I had to be constrained with the technology of the day. I could not model user interactions without making costly conversions. It wasn’t until 2012 that I got hold of a graph database. This kind of database allowed me to model highly interconnected data like transportation networks. The result of this, was the work at Wanderu. We used a graph database to route disconnected segments of buses and trains. From day one I had “imagined” (or conceptualized) the system and two years later it came to fruition, almost as I imagined it.
In summary, for a “C” level person like a startup CTO, communication, leadership and organization are obvious skills to have. For me, extroversion was a trait that did not have, but was crucial. And finally, in order for a CTO to “boldly go where no one has gone before”, one must definitely have curiosity and imagination/vision.
