What are the differences between a CTO and a Software Lead at an early stage startup?

Jimmy Jacobson Full Stack Developer and Cofounder at Wedgies.com

September 29th, 2014

I was going through this article from Fred Wilson that talks about CTOs vs VPs of Engineering. But it strikes me that at the very beginning of a company and for the first year or so you really need a lead developer. I wanted to better understand from the other entrepreneurs if you a) agree with that assessment and b) how you characterize the difference between Lead Developer and VP Engineering?

Tim Scott

September 29th, 2014

I'll take a crack at this, although I'm sure there are others much more qualified than me to give an answer.

At first you only want a technical co-founder. He or she can write good code fast, set up low scale technical operations, and do an adequate job of UX, all without much technical help. You might need him or her to find an manage some contractors. So a technical co-founder is "lead developer" but should be much more, including very engaged in all early product and business decisions.

The ideal person will be able to become CTO. But maybe not. Once you reach product-market fit, you might need to bring in a CTO who is more experienced, or technically strong, or managerial, depending on what you need. The technical co-founder might then transition to be head of engineering or product. It helps if he or she has the maturity to reckon their limitations. Avoid naming anyone VP of anything until you start to silo your operations, which should be no time soon.

Basically, for a good long while everyone should be King of Getting Shit Done and hung up neither on titles nor even precise lines of responsibility. Every so often, when the shit that needs to get done is beyond the capacities and abilities of the current team, bring people in who can do it and realign people (including yourself) on what they are good at. Everything else is a trap.

Ajit Gupta Entrepreneur

September 29th, 2014

Jimmy, Big difference. A CTO is more strategic in their thinking. They aren't just thinking about your immediate needs but also what you might need that is around the corner. A software developer will usually do the minimum required for what you need now. That might sound like a great idea, however you could end up having to reo everything a few months down the line, whereas if someone had thought about what might be required it might not have been that much more effort building it in. It is a tough call, but everytime I have trusted a software developer to make decisions, in the long run I have regretted it. Just my opinion though! Cheers, Ajit Sent from Windows Mail

Sam McAfee Building better technology leaders and teams

September 30th, 2014

I also liked Tim Scott's answer. I think the key thing is in the beginning you really need just a co-founder, and it's best to avoid titles like VP and CTO. They just confuse everything.

The kind of code you are writing, the kind of product development you are doing, is very, very different in the beginning of a startup. If you are lucky enough and persistent enough to build an initial product that people actually want to pay for, you will need to do two things. Replace most of the early stage code you wrote to "get shit done," and hire some people to help you do that and extend the systems' capability to capture more of the market.

In my experience, the CTO role is really a strategic one, while the VPE role is a management and process role. You establish these roles when there is enough risk and complexity to manage those responsibility. If your technical complexity exceeds your organizational complexity first, you may end up establishing / promoting / hiring a CTO before a VPE. Conversely, if your system is relatively straightforward, but the organization is growing in complexity faster, you might bring in a VPE first to manage the team and execution process, and not need a CTO until later. That's how I would see it evolving. Plenty of companies have gone quite far with only one of those two roles in place.

Mark Suster also has a really great article on this: http://www.bothsidesofthetable.com/want-to-know-difference-between-a-cto-and-a-vp-of-engineering/

Elizabeth Charnock CEO at Chenope

September 30th, 2014

The CTO title came into existence initially so as to have a nice-sounding title to give to technical founders who until then tried to be VPE but often failed due to lack of management experience/ability. It stuck around because it sounds nice, and nature abhors a vacuum, meaning that now that the title exists, people understandably want it.

Indeed, as others have already amply commented, what the responsibilities are for CTO varies dramatically according to what is being built. This is unlike say, a VP of Sales position in which the primary job responsibility is always the same no matter what it is that is being sold: revenue generation. A CTO may be great at giving talks or writing papers - or talking to customers - but may not have actually written code in a decade. Or a CTO can be a highly introverted top technical guy who maybe owns one tie. Both are valid archetypes. It just all depends on what the business needs.

Now if the person is expected to actually code / make shit work, you are talking about either a CTO of the coding variety or an architect/lead developer. You are not talking about a VPE because the primary skill of a real VPE is managing people and building organizations. Not unless that VPE will have both budget and time to assemble a team.

The difference between a CTO and a lead developer is what unusual and highly valuable skills they bring to the table. In my view, these skills should be technical; if they are too much on the business-side, then perhaps that equity should be going to a VPM or such instead. The old, but still very pertinent, engineering pay scales at Sun Microsystems required 'demonstrable recognition as an industry expert in a specific technical area' to move beyond a particular pay grade. Think of that as the bar for a CTO, at least for anything that is serious product development as opposed to mostly a business execution play.

A final thing to keep in mind is that while titles may be free in startups as the old adage goes, the cost of having to take a title away from someone who still has significant value to the organization is anything but. (Indeed, that's how the CTO title came about in the first place :-)

Michael Calleia Helping companies build better products and teams. UX and Product Management.

September 29th, 2014

Not being flippant, but in an early stage startup, there are two takes on this:

Either:

CTO = a founder

Software Lead = employee or contractor

Or:

You realize you are an early stage startup and really do embrace that titles mean nothing at this stage, so the highest level title at your startup is _____ Lead. Everyone is doing everything, but the _____ Lead is the one main responsible for ______.

Seth Caldwell Creator SnapChallenge

September 29th, 2014

I really liked Tim Scott's answer. I've had all 3 titles at various points. Typically I'm the king of getting shit done, and knowing how to get others to get shit done in the case that we want other people to get it done because there's only one of me. A CTO may not know how to get shit done, or how to motivate others to do so, but will know the correct technologies and best practices, be able to think about how technology choices affect business decisions and direction. A VP of engineering may not see the business decisions as much as how to implement them (but should be discussing them), and a lead developer should not be in meetings that involve anything but developing.

Ali Ghafour Founder at Viafoura, Entrepreneur, Creator of Technology Products & Former Canadian National Taekwondo Team

September 30th, 2014

Agree with Tim, Ajit, Seth and Sridhar above. They are sound in their logic and I can confirm through my experience.

I wrote two posts about this topic as well:

alighafour.com/2014/07/vp-engineering-vs-cto-role

alighafour.com/2013/07/what-is-the-role-of-a-cto

Sridhar Rajagopal

September 29th, 2014

The article in question is VP Engineering vs CTO . Here is a pertinent excerpt.

"Startup companies in their earliest stages will have neither position. The ideal web/mobile startup will have a CEO/founder who will also wear the VP Product hat. It will have a technical co-founder who will wear both the CTO and VP Eng hats. And it will have a few more engineers. And maybe a community manager."

I really like Tim Scott's answer. In the beginning, you have the "King of Getting Shit who can also think of technology and code", and he will be the lead developer, VP of engineering (of a team of one), and a CTO, Product Guy, IT guy, as he dons different hats. As you bring more people on board and hire employees, you'll have separate departments like engineering. You'll have a Lead Developer then who is an individual contributor and can also act as the go-to person who knows about various stacks and is experienced. The VP of Engineering is more of a team builder and manager, worrying about execution of the team and getting the work done on time (with help from the Lead Developer).

Mark Lythgoe

September 30th, 2014

I think it boils down to product size/complexity, target market and funding. If you are looking to build a smallish/simple MVP then you probably need a lead developer.

If your product is targeted to enterprise customers, has significant funding or is complex then you will most likely need a VPoE at minimum. Building robust, scalable, reliable, fault-tolerant software effectively and efficiently takes a holistic view of IT, PM, Dev, and QA.

Furthermore, that lead developer is likely not going to be your future CTO and may not even be your VPoE. Putting together a MVP is substantially different from building and leading a team. IME 70+% of lead developers won't make an effective VPoE or CTO and many don't even want the management responsibility. You can and most likely should separate ownership from responsibility. Mostly I see openings with something along the lines of 'possible future CTO/VPoE,' which sets the right expectation. Realizing when you need to bring on more experienced talent into critical leadership roles is key to growth.

Troy Gardner Chief Technology Officer, Chief Brewing Officer at Cloud9 Brewing Systems

October 1st, 2014

CTO's can mean just about anything or nothing... no two are exactly alike. A CTO of a game company is different than a CTO of a financial company, and a 10 person company CTO has almost nothing in common with a company CTO of one of 500, 1000, 10K. A solopreneur might be CEO/CTO/CMO and have multiple business cards depending on which role he needs to be.

CTO's and developers are not the same thing. A good CTO may understand but not code at all, where a lead developer is 80% coding. Both may be expected to manage others, but generally a CTO has more focus on building teams, or using outside agencies.

CTO works on the bigger picture and risk management of technology as a whole, what hosting and what rate, redundancy, backup, what technologies to use, who to integrate with, as well as other technical but non-product related infrastructure and agreements: credit cards processors, analytics, dropbox, sms providers and the like. In bigger companies this might be multiple roles, Chief Information Officer, VP of Engineering, Director of R+D. They like or at least tolerate meetings with other C-suite people, and have to have solid social skills for doing presenations, negotiations, wrangling politics, getting patents. You don't need one of these often in year one, in fact from a cash allocation it's better to get a mid level programmer + project manager.

Lead developers are typically already steeped in a particular technology, and often will have limits in what they can do well, for example, needing to be paired with a Designer, Ux and QA types. They tend to be mostly coding, some can lead others but many prefer to be coding and left alone, anti-social outside of geek subjects. Live breath, eat code.

Now as to what you need in year one, either can work. Long term you need to have someone wranging the tech, but there are so many factors. A year one CTO is often not the right one for when you're 100 people.

Product wise, I'd suggest think MVP (minimal viable product) could be that hiring a contractor who's pricy and skilled will get you to market first. Could be an agency who can do design and testing as well. You might find a lead developer who wants to grow into CTO, and will work for sweat equity, but if they aren't really able to grow into those shoes as the company grows (hopefully), then you'll be searching for a new CTO in a year or 2 anyway.

Question stats