10 ms·

Becoming a CTO

361 points by djug 10y ago

ben_jones 10y ago
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.
codesnik 10y ago
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.
scient 10y ago
This guy gets it.
tensor 10y ago
> “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.
- dberg 10y ago
  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.
  - ssijak 10y ago
    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.
    - dberg 10y ago
      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.
  - KirinDave 10y ago
    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).
  - typingduck 10y ago
    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.
    - ethbro 10y ago
- ryandrake 10y ago
  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.
  - tensor 10y ago
    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.
- benjiweber 10y ago
  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.
  - patothon 10y ago
    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.
  - 10y ago
- doublerebel 10y ago
  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.
- clarkevans 10y ago
  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.
- Mc_Big_G 10y ago
  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.
  - scalesolved 10y ago
    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.
    - ekidd 10y ago
      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.
      - __derek__ 10y ago
        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.
    - tensor 10y ago
- whataretensors 10y ago
  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.
- Kalium 10y ago
  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.
- joesmo 10y ago
  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)?
  - tensor 10y ago
    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.
    - joesmo 10y ago
      Ok, but what about in a startup / limited budget scenario where you can't afford dedicated UX people, something that is often the case?
      - tensor 10y ago
        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.
- erichocean 10y ago
  > 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.
  - vcarl 10y ago
    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.
    - slavik81 10y ago
      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.
dberg 10y ago
"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.
- KirinDave 10y ago
  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.
- ethbro 10y ago
  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
  - dberg 10y ago
    Fair point. I initially interpreted it as overly draconian, perhaps incorrectly.
- falcolas 10y ago
  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.
ryandrake 10y ago
> 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.
- gxs 10y ago
  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.
  - ethbro 10y ago
    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."
    - ryandrake 10y ago
      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."
oswamano 10y ago
"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.
- KirinDave 10y ago
  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.
  - CorvusCrypto 10y ago
    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
    - KirinDave 10y ago
      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.
      - CorvusCrypto 10y ago
deleted 10y ago
[deleted]
0xmohit 10y ago
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.
- ethbro 10y ago
  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.
CorvusCrypto 10y ago
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.
- ThrustVectoring 10y ago
  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.
  - CorvusCrypto 10y ago
    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?
    - dejv 10y ago
      Lead developer, architect, senior developer, fellow... it depends on company. It could be also CTO in some cases.
- nowarninglabel 10y ago
  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.
deleted 10y ago
[deleted]
- deleted 10y ago
  [deleted]
deedubaya 10y ago
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?
jgrahamc 10y ago
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.
- rootusrootus 10y ago
  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.
  - jgrahamc 10y ago
    Yes, that's very true. Perhaps a good place to start is by not calling yourself CTO.
    - 10y ago
devy 10y ago
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.
- 67726e 10y ago
  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.
  - devy 10y ago
    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.
    - 67726e 10y ago
      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.
joshmn 10y ago
> “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.
- deleted 10y ago
  [deleted]
miles_matthias 10y ago
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
lcfcjs 10y ago
I enjoyed reading this and generally agreed with up until discussing maintaining legacy applications. One major reason to rebuild a legacy implementation is scalability, this is a reason for the "business" to accept it's expense. Newer technology can certainly allow the application to scale. Drop SQL and Java. Use NoSQL and Javascript, you'll get scale, performance and the best developers in the area. You can turn technical debt into technical wealth.
tboyd47 10y ago
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.
jconley 10y ago
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-tucker https://www.linkedin.com/pulse/five-flavors-being-cto-matt-t...
a13n 10y ago
> 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.
- xtracto 10y ago
  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/
oktavist 10y ago
A CTO of a 5 person operation doesn't remotely have the scope/role of the CTO of a hundred let-alone thousand person operation. Ditto for the CEO. But I don't see how it's possible or meaningful to prevent people from declaring themselves a "king of a kingdom", no matter how small. I think this comes out in the wash - anyone looking at a resume of someone that called themselves the CTO of a 5 person company is going to assume they were capable of performing to the level of a basic manager in a large org, so does it do any harm in the end?
nstj 10y ago
> 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."
tscosj 10y ago
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.
deleted 10y ago
[deleted]
agounaris 10y ago
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.

361 points by djug 10y ago

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.

codesnik 10y ago

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.

scient 10y ago

This guy gets it.

tensor 10y ago

> “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.

dberg 10y ago
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.
- ssijak 10y ago
  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.
  - dberg 10y ago
    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.
- KirinDave 10y ago
  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).
- typingduck 10y ago
  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.
  - ethbro 10y ago
ryandrake 10y ago
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.
- tensor 10y ago
  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.
benjiweber 10y ago
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.
- patothon 10y ago
  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.
- 10y ago
doublerebel 10y ago
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.
clarkevans 10y ago
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.
Mc_Big_G 10y ago
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.
- scalesolved 10y ago
  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.
  - ekidd 10y ago
    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.
    - __derek__ 10y ago
      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.
  - tensor 10y ago
whataretensors 10y ago
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.
Kalium 10y ago
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.
joesmo 10y ago
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)?
- tensor 10y ago
  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.
  - joesmo 10y ago
    Ok, but what about in a startup / limited budget scenario where you can't afford dedicated UX people, something that is often the case?
    - tensor 10y ago
      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.
erichocean 10y ago
> 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.
- vcarl 10y ago
  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.
  - slavik81 10y ago
    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.

dberg 10y ago

"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.

KirinDave 10y ago
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.
ethbro 10y ago
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
- dberg 10y ago
  Fair point. I initially interpreted it as overly draconian, perhaps incorrectly.
falcolas 10y ago
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.

ryandrake 10y ago

> 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.

gxs 10y ago
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.
- ethbro 10y ago
  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."
  - ryandrake 10y ago
    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."

oswamano 10y ago

"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.

KirinDave 10y ago
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.
- CorvusCrypto 10y ago
  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
  - KirinDave 10y ago
    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.
    - CorvusCrypto 10y ago

deleted 10y ago

[deleted]

0xmohit 10y ago

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.

ethbro 10y ago
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.

CorvusCrypto 10y ago

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.

ThrustVectoring 10y ago
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.
- CorvusCrypto 10y ago
  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?
  - dejv 10y ago
    Lead developer, architect, senior developer, fellow... it depends on company. It could be also CTO in some cases.
nowarninglabel 10y ago
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.

deleted 10y ago

[deleted]

deleted 10y ago
[deleted]

deedubaya 10y ago

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?

jgrahamc 10y ago

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.

rootusrootus 10y ago
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.
- jgrahamc 10y ago
  Yes, that's very true. Perhaps a good place to start is by not calling yourself CTO.
  - 10y ago

devy 10y ago

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.

67726e 10y ago
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.
- devy 10y ago
  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.
  - 67726e 10y ago
    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.

joshmn 10y ago

> “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.

deleted 10y ago
[deleted]

miles_matthias 10y ago

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

lcfcjs 10y ago

I enjoyed reading this and generally agreed with up until discussing maintaining legacy applications. One major reason to rebuild a legacy implementation is scalability, this is a reason for the "business" to accept it's expense. Newer technology can certainly allow the application to scale. Drop SQL and Java. Use NoSQL and Javascript, you'll get scale, performance and the best developers in the area. You can turn technical debt into technical wealth.

tboyd47 10y ago

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.

jconley 10y ago

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-tucker https://www.linkedin.com/pulse/five-flavors-being-cto-matt-t...

a13n 10y ago

> 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.

xtracto 10y ago
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/

oktavist 10y ago

A CTO of a 5 person operation doesn't remotely have the scope/role of the CTO of a hundred let-alone thousand person operation. Ditto for the CEO. But I don't see how it's possible or meaningful to prevent people from declaring themselves a "king of a kingdom", no matter how small. I think this comes out in the wash - anyone looking at a resume of someone that called themselves the CTO of a 5 person company is going to assume they were capable of performing to the level of a basic manager in a large org, so does it do any harm in the end?

nstj 10y ago

> 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."

tscosj 10y ago

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.

deleted 10y ago

[deleted]

agounaris 10y ago

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.