Becoming a CTO | Hacker News Reader

Becoming a CTO

juokaz.com

361 pointsdjug101 comments

I'm going to sound like an old fart, but it might be better to wait to write a blog post like that after you've spent some time experiencing engineering management in depth. It's very easy when capital is flowing freely and you've managed a team of 5 engineers to think that it's always going to be like that.

Ever been through an acquisition where 50% of the team was to be let go and you had to decide who and then tell them? Kill off a product after the team had almost completed it? Perform a lay off when times got bad? Give a serious, reasoned, estimated answer to the question (from the CEO): "How fast could we rewrite our entire code base from $FOO to Java?" Fire someone 20 years older than you and wonder quietly to yourself if he'd find another job? Manage more than a handful of engineers? Figure out how to outsource part of your development to India for financial reasons? Deal with a rapidly expanding customer base with creaking code? Manage a multi-million dollar budget when VCs aren't throwing money at you? Handle alleged sexual harassment? Spend hours and hours flying from customer to customer to explain your technology?

The 'pick which technology' to use part is easy and fun. Now go make that work in a real environment with real constraints.

My advice on becoming a CTO: learn how to write. You'll be spending a very large amount of time communicating your ideas.

As an old fart myself, and meaning absolutely no disrespect to anyone, I don't generally think of small startup CTOs when I hear the term CTO. I think of medium+ corporations where the CTO is at the top of significantly larger personnel structure than a company with 10-50 people. In my experience a CTO position at a small company is much more comparable to a mid-level manager or director slot at a larger organization.

Again, not intending to disrepect anyone, but that was my impression when reading this article -- I didn't feel like I was really listening to what my idea of a CTO is.

Yes, that's very true. Perhaps a good place to start is by not calling yourself CTO.

In that case there are no C level offices for startups because the CEO for a 5 person startup doesn't have the same responsibilities as the CEO for Leidos.

I think it's tempting for people to just say, well yes that's true, but there is no great line that is crossed that makes the distinction obvious.

It would be revolutionary for startups to start their org chart at the bottom, rather than the top. Programmer and BizDev, who get promoted as the company grows.

So you could get a job as Software dev 3 at Google for 250k, or as Programmer1 as a startup for 75k at a new startup.. why would you do the startup?

Let's face it.. title is one of the currencies of a startup. You want me to work for below market wage? Sure. I want equity to profit if we succeed, and I want a title that keeps me from having people hired over my head as we grow.

"and I want a title that keeps me from having people hired over my head as we grow"

I don't think that just a title will protect you. If you can handle managing 5 people but don't have the skills to manage 50 people, it's not going to be in the company's best interests to keep you on as the CTO. So you'll be offered the following options:

- Accept a demotion and report to the new CTO

- Be fired from your job and get replaced by the new CTO

If the company wants to avoid this unpleasantness, they can call your role something other than CTO, e.g., "Director of Development". Then, if the company grows, they can either promote you to CTO or hire a CTO to be your boss, depending on how promising you are.

I don't understand what the advantage is to have a lower title in your examples though: if you were CTO and someone gets inserted above you then your choices for your resume in your two scenarios are (CTO, then Director) or (only CTO, left company), which are both better than the two scenarios if you didn't have the CTO title (where it would say Director only).

If your title is Director someone might reasonably even assume there was a CTO above you at the tiny company, and you were a "director" or "vp" by being actually the absolute lowest man on the totem pole.

Title inflation is a thing making "CTO" almost meaningless, as documented elsewhere. Technical cofounder skills are not the same as CTO skills, so either they can be promoted into the gig when the company grows big enough to need CxOs or they can hire someone with the experience, desire, or greater aptitude.

My latter point was that widespread title inflation has the property that if you "defect" and don't have title inflation it has an actual negative effect on your future employment since it is nearly impossible for a random observer to know whether or not there was title inflation at your company.

As meaningless as "CTO" is, having a title worse than that could be seen as non-meaningless as a negative signal.

I think "founding programmer" or similar would counteract negative signals. It would certainly be more accurate.

To be sure, as someone who is good a greenfielding and hoisting startups, I would never want to be a CTO. Hire people above me, make "cofounder" just a particular percentage of equity and maybe a salary band, an enhancement on whatever my title is. Of course none of this protects me from getting Blaine'd and pushed out, but I figure that's always the case.

That all depends on the definition of a CTO of course, and that definition wildly fluctuates. Most software companies, big and small, startup or very mature, have a CTO, so the title is not reserved for big companies only imho. That does lead to confusion of what the CTO role actually is :)

That all depends on the definition of a CTO of course, and that definition wildly fluctuates.

These two things together render the term nearly meaningless.

There's a reason every developer is now an "engineer", people pick what sounds best on their resume.

But the problem is there isn't a better title.

I want a title that indicates that I'm the manager of a group of devs and that I also have final call on the technical side of the company.

Any ideas?

Head of development.

Beat me to it. Using "head" is a good scalable title. It works for both large and small sized organizations and for people who care about titles, it looks good on paper as well.

Chief architect. Director of engineering. VP of engineering.

As one of those "not-CEOs" I agree completely. I find it humorous how everyone in this thread is a "CTO". It's an overly glorified term used to negotiate certain conditions in start-up environments, usually: lower pay, longer hours, increased responsibility.

I make it a habit of not telling people my official title, unless I'm emailing support at one of our service providers...

My wife refused the "CTO" title at a smaller SMB (~250 headcount) because (A) she felt that the company was so small that it devalued the title, and (B) the title has already been so devalued elsewhere that it's actually a marketplace liability. "EVP Operations" was both more descriptive and more valuable, though not a "C-suite" title.

Largely agree here. We're a few years in (nowhere near "old") but I have seen a lot of these questions and these end up being the most humbling, but rewarding, experiences.

There's large swaths of CTOs who are only hired to code at early stage startups.

CTO is a real title with many overloaded definitions.

The duties also vastly depend on the industry/vertical.

Eg: I'm a CTO for an infra startup that sells to large companies. Part of my job is technology direction, part of it is sales, part of it is keeping the engineering team happy, and part of it is coding.

I'm imagining a CTO for a more cookie cutter SAAS startup would have a some overlap but a lot of differences.

A lot of my job is just aligning code being written to revenue and attaching ROI to projects being done.

I've become a way better communicator over the years by sheer force. Otherwise you can't get much done.

Technology at the end of the day is about delivering value to customers. A big part of the CTO's job is making sure that that happens.

Duties tend to change as teams grow too. The CTO title is a moving definition. Company vertical/business model and stage matter quite a bit here.

I would say overall, when you're small, you're just doing what a founder does: filling in the gaps till you are ready to hire someone better than you for the role you hand off.

This, and more, is where reality lies.

The other day there was a thread about the Google CTO test. I thought the entire thing was nothing less than ridiculous. I've hired many engineers and management over time. I don't care about anything someone can solve by having two bookcases full of relevant books by their desk.

I care about how the person things and how they solve problems they never had to face before.

None of the technologies I've worked with during the last 20 years existed when I was in school. FPGA's, for example, required a deep dive into a new universe of hardware design. The foundation helped, of course, but nobody would have hired me at the start of my first FPGA project, yet I developed technology for my own business that resulted in millions of dollars in sales.

The case is similar for management. I've been CTO/VP a couple of times before launching my own businesses. Didn't know what I was doing. I thought it was a technical job. Eventually I would joke that I had more business books by my bedside than engineering books anywhere in the house.

A person who is good at problem solving can learn and become good at anything. Be it CTO or developing the next ground-breaking idea in AI. That's why I don't care about resume's and truly senseless programming quiz interviews. They are useless.

"If the team wants to do TDD, or pair programming, or staging servers - they get it all approved by the CTO. It’s up to him to consider the bigger impact of those changes."

As a CTO, my team knows I do not need to approve what the team wants in regards to TDD or how many environments they feel they need. We operate in a mode of "do whats best" and engineers smarter than me sure as shit dont need me to rubber stamp approval of writing unit tests. I absolutely create an environment that encourages high quality products and a robust testing process. How they accomplish that is up to them.

There are of course different rules at different scales for a company. But in general if you were engineer #1 becoming a CTO and your team can't function and govern autonomously once its reached a size where you step away from daily commits, you have failed to grow a competent tech lead for the role.

I think the more abstract point the author was trying to make with that statement was that teams should be allowed to define what they want to do, but the CTO is the one who should be keeping an eye on the impacts of those decisions with respect to the rest of the organization.

A good CTO is a bullshit deflector. And sometimes that bullshit is in the form of "Why should an engineer have to consider decades-long maintenance timelines including projects he or she isn't even associated with?" Sometimes the CTO needs to say "No" to a proposal, but the benefit to the engineer is the rest of the time they're isolated from having to think about impacts they don't want to.*

*All of this is only applicable to orgs past a certain size

Fair point. I initially interpreted it as overly draconian, perhaps incorrectly.

The trick is, IMO, when the team does not accomplish things to your satisfaction, you need to be capable of stepping in and changing things, even if your developers don't like it.

To me these sound more like VP Eng. decisions than CTO decisions anyway. I suppose if you're so small you don't have both positions, they would rise to the CTO.

This sounds like micromanagement, even from a VP of engineering. The CTO should be setting long term vision and roadmaps, VP checking things are progressing & handling the majority of the business side (hire/fire, sexual harassment + behavioural issue), then directors down deciding how to do things.

  > Sometime down the road legacy applications become expensive to manage,
  > but rewrites almost always deliver zero value to the customer.

What a weird thing for a CTO to say. Even in my role, I can justify a rewrite by identifying the savings in support, maintenance, and infrastructure, and balance that against the time for the project & make a call that in 6/12/X months, we will have recovered the cost of the rewrite & be saving the company month money (which then can be used to develop more user-facing features, improve performance, etc.)

>Even in my role, I can justify a rewrite by identifying the savings in support, maintenance, and infrastructure, and balance....

It's not all that weird for a startup CTO / technical cofounder to say, because in those companies velocity is king, queen and the jack of diamonds; rewriting code is a waste because you're only worried about the next milestone, which is no more than six to nine months out.

Mature orgs operate at a different cadence, where your analysis is spot on. (Unfortunately, it often doesn't hold for them either; I've had contracts where I ended up scoping in IT project valuation methodologies so CTOs and/or IT managers could learn how to translate savings into defensible balance-sheet numbers, since the business would only accept "real" savings or revenue enhancement as justification.)

It sounds like you basically said you don't do shit and you're not good enough to approve their decisions.

What do you do better than other people that justifies your title?

> I hate environments where the technology department is simply implementing what was envisioned by others. It might as well be an outsourced development team because it becomes independent of the decision making process.

I'd argue that the technology department should be very independent and empowered when it comes to the _technology_ decision making process. I'm less convinced that that's true for the product decision making process. I've worked in places where Product Managers and designers wrote all the requirements and dictated the look and feel down to the pixel, tossing it over the wall to developers to implement. I've worked in a place without independent, dedicated product professionals, where software engineering decided what the product should be. Both extremes have major weaknesses. You have to find the right spot on the spectrum between the two that works for the company and mix of talent you have. It's not all or nothing.

As usual, that gray area in the middle is where you find the right answer.

I am a product manager - I spend some days arguing, civilly but intensely with the architects and engineering teams on what should be done and why.

This conflict - these "battles" so to speak, ultimately lead to the best results IMO. I push for something, the engineers push for something else, and in the end we end up building the best possible product for the customer - it's both what they want and technically sound.

Keep in mind when I say this I don't mean an immature argument calling people names etc. - it's intense but it's always respectable and all parties know and recognize that the best idea wins - regardless of who it comes from.

Absolutely this. The best decisions come out of "My gut reaction is X", "Have you considered Y?", "No, I hadn't because it's outside my area of expertise. What about X'?", "That takes into account Y; agreed, let's do that."

Just a nit pick. I think the good IDEAS can come from that process, but the best DECISIONS come out of: "The data (from market research, A/B testing, etc.) clearly show that out of X, Y, and Z, X improves our KPI more."

Netflix found what I think is a happy medium. Back end services don't have product managers. The engineers decide what is going to get written and when and how.

Front end services do have product managers. But the product managers are really conduits between the engineers and the customers. They look at what customers are asking for, the results of focus groups, etc, and then create A/B tests for those things. Then they convince the engineers that it's a good idea based on their well researched ideas. Usually the engineer agrees.

So basically in all cases the engineers are setting the direction for the product, but for the front end services, the product managers help them by doing what they are good at, which is converting customer thoughts into engineering ideas.

> “The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas.”

As a CTO myself, I strongly disagree with this. Yes, a dev team needs to tend to it's own ideas, but no, it shouldn't be making product decisions. You should have product and design teams that tease out user problems and come up with solutions. In that sense, the dev team does simply implement the ideas of the company. They still make technical decisions of course, but not product or UX decisions.

As a CTO, I disagree with your disagreement :)

Engineers dont want a "script for implementation". They want to exhibit autonomy and creativity to the product as much as everyone else, especially product managers. I am not saying they should be product managers in a vacuum, but every good CTO knows the value of ownership and autonomy of a product is extremely rewarding to engineers.

You can have all the autonomy of technical decisions you want, but you can not make business decisions and UX decisions. You can have a word about it, sure, but not authonomy about it.

making "Product" decisions is a broad topic. Who is to say a FrontEnd engineer didn't start as an amazing UX person?

I think your comment is an (IMHO incorrect) blanket statement that is impossible to apply to all engineers.

And indeed, that autonomy and creativity is a skill to be practiced. The best practitioners are people who lead development efforts for a company and eventually mature into their own senior technical positions (be they directors of engineering, senior engineering managers promoted from technical positions, or CTOs).

I agree with both of you and tensor :)

Having dedicated people understanding what users want, what competitors are doing and what are the future directions of the market is probably necessary and worth dedicating serious time to.

It is just how people organize teams right now that seems a little broken; a Product Manager and 'their' team. This leads to the Engineers who like to innovate becoming bored and finding smart ways to get out of the 'typingpool'. This innovative talent is really necessary to scale product teams though, e.g. spotting common patterns across code bases. With that loss in innovation companies suddenly find a comparable feature that took 2 weeks taking 2 months.

Also as technology evolves new features previously impossible become possible. A Product Manager probably will not see this.

Perhaps there is a more 'ownership' heavy way of organizing Engineers. Something a bit more democratic like having a pool of ideas coming from Product Designers and Engineers. Self forming teams can come together to deliver whatever motivates them.

> With that loss in innovation companies suddenly find a comparable feature that took 2 weeks taking 2 months.

No offense to the mentioned, but the "ideas are like assholes, everyone has one" comment seems to apply extremely accurately to non-technical design and product teams who are blessed by management to throw things over to "those technical people" without any concern.

And why would a 2 week task not take 2 months under that structure? If your high-performing, creative engineers are sisyphean implementers of someone else's features without some empowerment, ownership, and accolades for the end result, good luck retaining them.

1. There's plenty of room to innovate on the implementation side. PMs don't tell you what algorithms to use or how to lay out the data in memory.

2. Not every engineer yearns to be a Product Manager. Sure, many want to make product decisions but don't want to do the other necessary work that comes with the role (like market research, metrics and analytics, managing the schedule and budget, writing PRDs, communicating with customers and partners, dealing with Legal, making sure the user manual is accurate, coordinating releases with ops and tech support, etc.) I think some techies think being a PM means merely sitting in your cube dreaming up a feature and saying "This Shall Be".

3. Good PMs most definitely need to stay on top of technology as it evolves. They need to know their platforms' capabilities and when new things become possible.

1> Yes there is plenty of room to innovate on implementation, but they still want input to the scope of what they are implementing.

2> Nobody is saying they should be product managers, I am just suggesting they want more direct input to the shape of the product itself (not suggesting ALL engineers either)

3> Agreed, and PMs should continue to be good at this, its a core part of their role, understanding the ecosystem

You beat my comment by 12 minutes. I'd add that the dev team should at least be part of the feedback loop. To bring up an example: I once worked on a project where the PMs and designers all came over from the Android project to bring up the iOS one. Many of the designs were specified to look and behave as the Android product did. A single button, if implemented according to their spec, would have meant developing a custom control + 200 lines of code-behind to mimic Android's behavior, where if we made some minor tweaks and used a native iOS-style control, it would be a one-liner (and by the way, would be more appealing users who expect iOS-like controls on their iPhones). Without this feedback, we'd probably still be building all those custom controls years later.

Oh absolutely. How to build a good product team is a challenging topic. But in my opinion a product team needs representatives from technology, design, and client facing sides. The main tasks are: collecting user problems, deciding which problems are the most important to solve and prioritize (product manager role), then design needs to come up with solutions, consulting with someone on the tech side to know what is feasible or for solution ideas.

Collaboration and communication is key, but responsibility is ultimately with each group, design with design, problem prioritization with product, and technical design with the development group.

Having separate product and design teams is certainly one approach.

However, separate teams for product and design easily leads to the organisational antipattern where every feature implemented has to go through handoff between multiple teams. First product teams decide what to do, then design teams design it and hand off to UX for testing and later hand off to dev with full specification for building. When dev find that the designed/tested approach won't work due to implementation realities then it gets handed back over to the other team and so on.

Changes can take a really long time to get implemented and often no one team is fully aware of everything from the tech challenges/limitations, the cost of different approaches, the design implications, and the value of different options. Each team also has different and often conflicting motivations. Ops teams want reliability, Product want to move fast, Design want consistency. It's challenging to make good decisions on the tradeoffs in this model.

An alternative to this is vertically sliced teams where each team has all of the specialities embedded within it in order to look after a product. That means Dev, Product, Design, UX, Ops etc specialities within the team. They can then work together to add value to the product rapidly without handoffs between teams.

When cross-functional teams work well they understand both the cost and value opportunities of things they could work on, and can propose and implement features quickly and without top-down command and control.

This is classic matricial org oriented towards delivery. I've tried plenty of different orgs, and this is the most efficient structure I've been part of, or led. It's one of the leanest way of building products in discovery mode.

We're doing this at Omada Health.

It comes with its own challenges, though, as every organization:

- the leadership team needs to accept a more bottom up approach to decision making (ie LT give direction and strategy, has a power of creating teams and defining their goal, but teams decide _how_ to reach these goals)

- goals and KPIs need to be clear to everyone in the org, and in the team themselves

- you need to be clear on the values of your teams at large or individually (focus on learning/exploration? Design "quality"? Timeliness of projects?)

- you also need a certain type of teammates. Ones that sometimes can accept unclarity, ones that want to be part of whole product development lifecycle

When you have these ingredients, it's beautiful to see unfold.

You are definitely a CTO. And as one I agree completely. Without creativity in the hands of the craftsman who actually make the product there is no craft, only a tool.

Many product designers don't understand the limits of the technology or the interface guidelines and patterns for a particular platform. It's up to the tech team to communicate any conflicts between the platform and the product decisions. Many designers try to shove an iOS ui pattern onto Android or a mobile app pattern onto mobile web, depending on where their experience and preference lies. There are also technical limitations in what can be done on UI threads or with network bandwidth or latency. These technical factors are very important to the user experience.

Having communicated these to the product and design teams, the devs must understand the tasks still get prioritized according to business needs and customer measured preference. No dev team should be implementing major UX decisions that aren't supported by data.

The technology group must be in constant dialogue with the product/marketing group to create a coherent and shared vision of a profitable product. Together they form the product decision-making team.

Removing the ability for engineers to have input on the product ultimately leads to the team feeling like a bunch of code monkeys. The good ones leave and then you just end up with the monkeys. No thanks.

Agreed, when I see an opinion like no product input from the tech team it just makes me think that the company in question would just be better off hiring contractors.

As a moderately senior consultant for small to mid-sized software companies, I discuss product plans even more than I do as an in-house developer. As an in-house developer, I get salary, and that is heavily protected by law.

But as a consultant, I want to actually get paid, and paid well. If I work on ill-conceived design put together by an incompetent product team or an inexperienced founder, I'm also much more likely to have to push hard to get paid for each milestone. So I only consult when it's clear that I can add strategic value and that my client really understands their market. Once I'm sure those conditions are met, I can help them on the technology side.

When I ask my clients probing questions about their product plans, they generally seem quite happy that I care. And yes, I have advised some of them that PHP would have been a terrible choice for their technical requirements. A large part of the value a senior consultant brings is knowing how far out on the bleeding edge is wise for a given company, product and team. You want a good balance of development speed and a reasonably mature ecosystem.

The contractors mentioned are not the same as consultants. They are hired bodies, typically employed via an agency, rather than people operating a business. Whereas you're paid to think and to optimize, contractors are paid to just do without objecting.

Having product and design teams be in charge of their respective areas doesn't mean that developers can't add their thoughts into the mix, they just don't get decision making power.

Why do you think a developer should have decision making power in the area of design? They are not trained in design and UX. Conversely would you be ok with designers or other non-technical people dictating technical decisions? Of course not!

Different cultures. I've worked in both. Personally I prefer cultures where the engineers are making decisions. It's harder, but most developers have a knowledge gap in the domain they are working in. Having them work on someone else's interpretation of a problem often leads to suboptimal solutions. If they instead increase their understanding of the business demands they can design more elegant solutions.

Having been an engineer in an environment where product occasionally fails to consider all aspects of their ideas, it's critical that engineering be more than just implementation. Product needs to know what's possible in a reasonable timeframe, what looks easy but isn't, and what's possible but crosses a lot of security and privacy lines.

Engineering can and should have an advisory role in addition to an implementation role.

How do you deal with the case of product coming up with a modal that needs to be scrolled even on a 1080p screen? It's certainly a UX decision and an incredibly stupid one. Should the developers implement it only to have everyone else realize how stupid it is after wasting hours or days? Or should there be someone who can stand up to product and tell them, hell no, we will not implement this stupidity? This is a real example from a real job I had. I don't need to tell you which way this originally went (we built it and of course tore it down a week later). The height or width of a modal is not a technical decision, but it's also not a product decision. You can have a dedicated UI/UX guy, but that adds a lot of cost most companies can't or won't afford. This is where the CTO, or in larger organizations, a manager under the CTO, would step up and tell product what a terrible idea their modal is and that they need to redo it before engineering considers it. If engineering can't make common sense decisions because its hands are tied and product can't make them because they're not qualified, where does that leave you with your system (the system you describe is extremely common)?

The answer is dedicated UX people. If a company decides UX isn't important to hire expertise in then I'd say it's not a company you want to work for.

Every product is designed, but if you have no UX people then the design is done either by product managers or by technical people, neither of whom are qualified to be doing that.

Ok, but what about in a startup / limited budget scenario where you can't afford dedicated UX people, something that is often the case?

Then you pick the person on the team most interested in design and get them to learn how to do design right. They become 50-75% design and the rest whatever they were doing before.

Being good at development or some other domain doesn't necessarily correlate with being good at design. Developers understand that their trade takes time and effort to learn, it amazes me that some of them can't understand that it's the same for other domains.

But we already have engineering experts in the field telling product it's not a good idea. The problem isn't the lack of expertise, it's the lack of ability to push back on a stupid task. The point is, there is no mediation here. If a UI/UX person can tell them what a bad idea is, so should an engineer be able to. Thus, engineering cannot be the slave of product in an effective organization and product that insists on its pixel perfect designs is by definition low quality (because nobody is perfect).

> You should have product and design teams that tease out user problems and come up with solutions.

If the solutions are technical, it makes no sense whatsoever not to include the tech team in the solutions.

I can't tell you how many times I've been given a "solution" that was needlessly complex at the technical level because the product team thought it was "easy" and were "helping" the tech team out. Product people often have no idea which approaches make sense technically, and worse, apparently no intuition about tech. It's amazing, really.

It definitely makes sense to have a technical person sit in on later stage product discussions to point out when minor tweaks will have significant impact on the implementation, but there are discussions that don't need technical input. IMO technical people should be brought in when making a wireframe or some other "handoff" from product/design to implementation.

The domain specialists know what their customers would like and are thus fantastic at evaluating proposals, but they don't know the range of possible solutions nearly as well as the people doing the implementation. Someone technical can propose something that the design side never considered because they didn't know it was even possible.

Having people from the technical side in there early also means helps to spread understanding of why something is designed as it is.

   Being a CTO doesn’t mean you are the craziest hacker on the team. 
   In actuality, writing code is probably the last thing you will be doing.

Not entirely true. This is a typical "You Mileage May Vary" scenario, in actuality. From all the small startup teams (headcount less than 15) that I've worked at in the past decade, CTO must be the role who leads in coding - in almost all the cases the first version of the software product was 100% done by CTOs because small agile teams don't have the luxury to be managing instead of doing and EVERYONE (even CEOs) wears a lot of hats.

After bootstrap and rounds of fundings, things will change for sure. But CTOs at very early startups are definitely more about doing less about managing IMMO.

I don't think this is a YMMV, but rather we're all lacking a proper, consistent definition of what a CTO is and does. Many in the the comments are coming from the idea of a C-suite officer of a large company, which I think is proper. I think a lot of the use of CTO / VP of Engineering / Director at a lot of startups is just some ego-stroking type behavior. Your claim of being a CTO at a 10 person startup is not likely to be getting you a job as a CTO of a mid-market firm because you're not really a CTO, you're some kind of architect at best.

The definition of CTO is evolving as the company evolves. The same company at different stages requires its CTO to be in different role, as you mentioned CTO in a 10-person startup is a different role than a CTO in Fortune 500 company.

For the purposes of discussion, we will not get anywhere fruitful if we say "Oh, it can be anything you want it to" - again, I contend that a CTO at a 10-person startup is not an actual CTO but some kind of team lead / architect. It's a pointless name as it does not convey what it typically does and serves only to act as some status signal.

Instead of saying "The definition of CTO is evolving" which is rather contradictory, a definition to make something distinct and clear, it would be better to frame it as that person's role is evolving, and that their title of CTO is not indicative of their actual role.

I think he addresses this in the very next paragraph:

>It’s easy to accidentally become a CTO by getting hired by a small company with no other developers, like you would see in most startups. But while the title might say “Chief Technology Officer,” it is probably just a fancy acronym for an “overworked developer.”

"If you ever find yourself writing a blog post on why PHP sucks, you are not ready."

About 4 articles down the article is about why PHP doesn't suck. This amuses me for some reason.

It's amusing because it's absurd. CTOs write articles about technology choices all the time, and sometimes its even tactical.

If I thought slagging PHP in a blog would get us more hires, I'd do it without hesitation.

I can't for the life of me think of a reason this kind of blog post would make me want to join a company. If anything it shows the opposite quality of a CTO as mentioned in the article. Use what is suited to your needs, don't worry about appealing to the tech crowd. After all, even if PHP is shit, it's not your problem. Let us handle implementation of what you need, we will (or our lead dev will) help you understand pros and cons to certain technologies. Besides, for every article written about why PHP sucks, there's at least 5 PHP devs looking for work :P

So... are you asking me for examples of CTOs of successful companies who have written tech articles promoting one type of tech because another is bad?

I can do that, if you really couldn't do it yourself. It's not uncommon at all.

Like I said, I don't do it because I don't think it would help. But in some cases, it can definitely help. How many startups use their dedication to a specific (incrementally more modern) tech stack as a perk while hiring? Quite a few, and these often have subtly disparaging remarks baked in. And I've absolutely had success hiring and growing my team by explaining why we use Clojure over stock java whenever possible.

Nah not at all. But I am saying that it's not gonna sway my decision when you bash a technology amidst many other companies that have successfully used the same technology. It just shows a lack of vision imo. My comment wasn't targeted at yours specifically, but was a follow up on the topic.

and imo explanation of why you use one technology over another is not equal to just a "PHP sucks!" blog post.

The point of a CTO talking up one technology or talking down another has absolutely nothing to do with swaying your ideas about that technology at all.

A CTO isn't a technology evangelist for or against that technology. The role is to get the most out of whatever technology the company is using. If talking down weaknesses in one technology and talking up strengths in another helps find hires looking for the technology the company is using or shows the strength of the company in being able to address those weaknesses or take advantage of those strengths, then that's good for the company.

CCP Games is probably certain someone else can do without Stackless Python. The folks at Facebook don't care if you use PHP or Hack at some other company. Booking.com is perfectly happy for you to use Python, Java, Forth, Haskell, or whatever at your company but they sponsor Perl conferences. Those companies will continue selling their in-house stack and its advantages. They'll continue pointing out where one solution grew creaky and they improved it with something else (like Facebook and Hack). They do that because it's good for them.

It's obvious click baiting to promote his own blog entry.

Being CTO/CIO twice in my carrier, being protector of my small dev-realm almost fulltime, I completely agree with that article! so, probably it's wrong somewhere.

Matt Tucker wrote a little blog [0] about being CTO. He went from co-founder to public company CTO over 15 years...

[0] https://www.linkedin.com/pulse/five-flavors-being-cto-matt-t...

  Sometime down the road legacy applications become expensive to
  manage, but rewrites almost always deliver zero value to the
  customer. It’s about balancing development efforts.

Well said. What is the guarantee that the rewrite would be relatively free from technical debt? I've seen several 100K lines of code being produced in rewrites that add absolutely no value -- neither in terms of performance, reliability, maintenance or even code readability.

I think there is some value in "someone who has spent billable hours deeply touching the currently running system is still employed at the company." You can have maintenance updates & docs as numerous as you want, but I'd still be terrified of running a production system I don't have trusted nuts-and-bolts expertise in-house for.

Juozas Kaziukėnas is a good conference speaker. And as a good conference speaker oversimplifies some things to sell himself.

Being a CTO also means that "age" matters. Not because you are not smart but because you haven't worked with people enough to become a CTO. A person on his 20s or early 30, maybe has lots of technical experience already but definitely not the social skills to lead an organisation.

I remember I was interviewed once by a 25 years old "CTO" in a suit and really it was a nightmare!

> I’ve sat in a few roundtables with fellow CTOs: This is kinda of what I don't like. We the "CTOs" gather to say "our" things and write blog posts about it.

As a CTO of a small start-up my neck is a little strained from nodding so much at this article. I really agree with... sorry I have an email with our largest customer to get back to.

> “Why are you stuck with this old version, why haven’t you rewritten it with React.js?” Sorry to burst your bubble, but that’s not a great idea. Sometime down the road legacy applications become expensive to manage, but rewrites almost always deliver zero value to the customer. It’s about balancing development efforts. Building a team of people who only want to touch the freshly baked technologies is not sustainable.

I wish more people would realize this.

> but rewrites almost always deliver zero value to the customer.

I disagree. Sure no immediate value, but in the long run? You could argue certain rewrites would mean faster product development, less bug proneness, happier developers. All of these deliver value to your customers.

Depends on the size and reasons for the rewrite. I am Director of Eng. at a 85 people startup (funny how that sounds), and last April we released "version 2" of our platform/website [1]. We basically threw away a huge chunk of the code that was developed by the technical founder, myself and another dev, and replaced it with a fully scalable architecture.

When the company I work for was being started, a technical advisor (who had sold his company months before) told us not to worry a lot about the first codebase, because we were going to throw that away after some time. I am deffinitely sure even what we have now, will get obsolete in a couple of years (two at most)

For this reason, I think having a good planned rewrite (even if it is underestimated) can be good. I think the important part is understanding why the rewrite is performed, and be sure that it is done for the right reasons.

  [1] http://nerds.kueski.com/the-path-to-kueski-2-0/

So then would the true top "Engineering" role just be lead dev? This is the role I am more interested in. Having to keep up with the state of the field to me as an engineer/CS is A: more fun, and B: more rewarding.

If anything this blog post (along with others) just keeps confirming that CTO is something I never want to be.

Edit: I should also mention that it is practice at my current company that our leads basically are the ones that consider the balance of implementation details and whether we do rewrites vs. staged refactoring. Not the CTO. This definitely seems like more of an engineering call.

Even if you don't want to be a CTO, you're better off knowing what the CTO role does. Part of how the World War 2 era German military worked was the idea that subordinates would understand how to do the job of people two levels above him, so that he could understand the intent of the orders he received and carry that out rather than the letter. If you also want to have high levels of autonomy, you need similar abilities.

Irrelevant to what I asked. I understand the role. And I can safely say I don't want it. What is the top engineering role?

Lead developer, architect, senior developer, fellow... it depends on company. It could be also CTO in some cases.

This depends a bit on if there is a VP of Engineering in the company. If so, then the CTO can operate more as a "engineering" role and still spend some time in the code. If the CTO is both managing the people in engineering and setting the roadmap for the technology then the "Distinguished Engineer" is usually the top technical role.

Titles vary so much company to company though that there's not a one-size-fits-all answer.

yeah this I believe. I kind of figured the role would be widely-varying, but kind of hoped not. It's hard to know what to strive for when it's different at every company haha.

If what it takes to become a CTO is understanding all of this, then I'm ready. The only problem for me is that I'm not one. Oh well, back to refactoring unit tests.

This article hit too close to home. It hits a lot of points which are all-too-true about many CT positions and how if they're not set up for success, how can the engineering team (and eventually the rest of the company company) also possibly be successful?

I hoped to get some real-life experience from the blogpost, literally blah what I read. With all respect to the author, though. I have no idea how that sort of posts are taking higher than 250 points nowadays. That's the question.

Love posts like these. My friend & I started a podcast to help engineers learn from other CTOs.

Check out StartupCTO.io. Would love any feedback here or on Twitter @startupctoio

> I’ve sat in a few roundtables with fellow CTOs

"Sorry guys, the event for tonight is cancelled, turns out the tables we were to sit at are rectangular."

This guy gets it.

Reply on news.ycombinator.com