#define CTO(blog.gregbrockman.com)
blog.gregbrockman.com
#define CTO
https://blog.gregbrockman.com/define-cto
111 comments
I've heard 'seagull management' or something similar too. They fly in, shit all over everything, and leave.
The term was popularized most recently by Mark Suster:
http://www.bothsidesofthetable.com/2009/10/25/choose-your-vc... --
One of the terms we coined there was a “seagull.” We used it to describe certain of our partners (e.g. the owners of Andersen Consulting). Seagulls were the partners who didn’t spend much actual time on your project. They were smart and accomplished. They knew enough about your project to have an opinion but not enough to help. They would swoop in for one day to “check in on things,” shit on you and then fly away. Seagulls.
The analogy holds pretty well for some VCs and this can be destructive.
http://www.bothsidesofthetable.com/2009/10/25/choose-your-vc... --
One of the terms we coined there was a “seagull.” We used it to describe certain of our partners (e.g. the owners of Andersen Consulting). Seagulls were the partners who didn’t spend much actual time on your project. They were smart and accomplished. They knew enough about your project to have an opinion but not enough to help. They would swoop in for one day to “check in on things,” shit on you and then fly away. Seagulls.
The analogy holds pretty well for some VCs and this can be destructive.
My favorite term for it is "Eye of Sauron" management. Most of the time the eye is not on you ... but when it is, look out!
Hit-and-run management too.
I think it's hard to make "chief architect" work out in the long term
I think it can work fine as long as the chief architect is acting as an architect. Problems arise when a chief architect tries to make engineering decisions about individual components. When you're dealing with a large project, having someone who knows what all the components are and how they interface with each other can be absolutely vital; but that person should be treating each component as a black box -- not just being uninvolved with the implementations, but being actively unaware of the implementations of the components, in order to ensure that he doesn't make the mistake of assuming that a particular implementation detail will remain available in the future.
I think it can work fine as long as the chief architect is acting as an architect. Problems arise when a chief architect tries to make engineering decisions about individual components. When you're dealing with a large project, having someone who knows what all the components are and how they interface with each other can be absolutely vital; but that person should be treating each component as a black box -- not just being uninvolved with the implementations, but being actively unaware of the implementations of the components, in order to ensure that he doesn't make the mistake of assuming that a particular implementation detail will remain available in the future.
Its a shame that Craig Silverstein does not get metioned as often. I will leave it to people better than me to elaborate on that.
[deleted]
Losing touch with actual dev problems is one of the occupational hazards of architects. I think the way to make "chief architect" work is that the chief architect does at least some development him/herself. The architect could for example build the prototype of a new system, perhaps with a small team of assistants.
"Bungee Boss", now over 20 years old:
http://dilbert.com/strips/comic/1994-09-07/
http://dilbert.com/strips/comic/1994-09-07/
I think one of the hardest parts about being an early stage CTO, particularly a founding CTO-by-default, is delegating away your codebase to potentially smarter engineers than yourself while still remaining a highly relevant team member. Not just relevant, but justifiably executive level (which, IMO, writing code is not).
This is an identity crises that deserves more coverage, I think. It is certainly not something the CEO faces in a typical tech startup. The CEO can delegate all day every day. In fact that's really a CEO's end game. The CTO, on the other hand, is expected to be superman.
This is an identity crises that deserves more coverage, I think. It is certainly not something the CEO faces in a typical tech startup. The CEO can delegate all day every day. In fact that's really a CEO's end game. The CTO, on the other hand, is expected to be superman.
The point you make about an identity crisis extends, IMHO, to most C-suite execs except the CEO. Because they all must measure up to both internal (company) and external (what thw world thinks a "typical", say, CMO, does). I've seen this often lead to insecurity and therefore, the desire to be "superman", as you rightly pointed out.
The CEO is relatively insulated because there are less people to question or challenge him/her. Plus, because the functional responsibilities are divided between his C-suite reportees (CTO, COO, CSO, CMO etc.), the CEO usually can deflect blame for missteps while claiming credit for successes.
The CEO is relatively insulated because there are less people to question or challenge him/her. Plus, because the functional responsibilities are divided between his C-suite reportees (CTO, COO, CSO, CMO etc.), the CEO usually can deflect blame for missteps while claiming credit for successes.
Sometimes I think coding as a CTO is inappropriate; sometimes I think it helps garner a deeper understanding. I go back in forth.
I think the analog for the CEO might be giving up sales, if they were engaged in that early on, which is common.
I think the analog for the CEO might be giving up sales, if they were engaged in that early on, which is common.
Sales is sort of an analog, but really the CEO's goal is to delegate everything, not just the things that he/she would otherwise excel at. In this sense, the CEO even delegates coding.
The CTO, on the other hand, ought to retain some skilled role or else risk becoming a middle manager. I'd imagine this goes for most other C-level or VP positions that aren't the CEO, so maybe some role comparisons can be drawn against those (e.g. CTO vs CFO).
The CTO, on the other hand, ought to retain some skilled role or else risk becoming a middle manager. I'd imagine this goes for most other C-level or VP positions that aren't the CEO, so maybe some role comparisons can be drawn against those (e.g. CTO vs CFO).
This is a challenge for individual developers too who are moving up to team leads or senior positions. It's hard to delegate when you can't judge the potential for success or failure (for example, when some members of the team need more training in order to be successful on a project)
It was really nice to hear someone else talk about Marc Hedlund (the VPE in the article). I wasn't one of the back channel references, but I would have said the same things: "he’s been an amazing influence and mentor for me”, “I still keep in touch."
Back when all I did was write code, Marc took me out for lunch and told me, "If you can write code and speak English, then you need to be in leadership."
There's some major hyperbole in that statement. I'm sure I'm not quoting him correctly, but that's how I remember it. Speak English was short hand for likes people & communicates well. I had never considered that having a dual skill set was particularly valuable or that there was a bigger impact to make than just writing really clean code. He really opened my eyes to a bigger world.
And then he followed through by making great connections and being a constant advisor. I've known him for 12 years now and he's the person I always think of when people talk about a career in startups. He's got such a huge network of people that he's helped and that now look to him for advice.
A lot of my career is thanks to Marc. Stripe is really lucky to have him.
Back when all I did was write code, Marc took me out for lunch and told me, "If you can write code and speak English, then you need to be in leadership."
There's some major hyperbole in that statement. I'm sure I'm not quoting him correctly, but that's how I remember it. Speak English was short hand for likes people & communicates well. I had never considered that having a dual skill set was particularly valuable or that there was a bigger impact to make than just writing really clean code. He really opened my eyes to a bigger world.
And then he followed through by making great connections and being a constant advisor. I've known him for 12 years now and he's the person I always think of when people talk about a career in startups. He's got such a huge network of people that he's helped and that now look to him for advice.
A lot of my career is thanks to Marc. Stripe is really lucky to have him.
Marc's definitely the best.
Strictly OOC, how well has he done financially, compared to actual founders and early investors?
I often wonder if there's fair compensation for what I would call "Venture Engineering". Do tech gurus join advisory boards, get bits and pieces of equity for sage advice? Or is it all about karma and the satisfaction of helping people?
I often wonder if there's fair compensation for what I would call "Venture Engineering". Do tech gurus join advisory boards, get bits and pieces of equity for sage advice? Or is it all about karma and the satisfaction of helping people?
I have a hunch that one of the good ways for a CTO to still occasionally write some code that delivers significant value for the company is to take on the "little" projects that reduce friction in the internals of the company itself.
Too many companies fail to invest in that kind of software, because its value is less obvious than code that's shipping directly to customers. But I think it's very high-leverage. It's literally reprogramming parts of the business itself.
It's tempting to slice off that kind of work for a new hire, because it's more self-contained and lower risk than your product. But I think that's probably a mistake -- the new hire will learn faster on a product team, and the "little" project will be bigger impact in the hands of someone deeply technical who has a vision for how the company should run.
Too many companies fail to invest in that kind of software, because its value is less obvious than code that's shipping directly to customers. But I think it's very high-leverage. It's literally reprogramming parts of the business itself.
It's tempting to slice off that kind of work for a new hire, because it's more self-contained and lower risk than your product. But I think that's probably a mistake -- the new hire will learn faster on a product team, and the "little" project will be bigger impact in the hands of someone deeply technical who has a vision for how the company should run.
At this point in time I would not work at a company where the cto is coding, unless the entire company is less than 10 people. The managerial job of a cto is huge, so seeing them code is a big indication that management is not fulfilling their responsibilities, or doesn't understand the tremendous and necessary role of good management.
[Response] - I know there are plenty of examples of good and bad CTOs who program or don't program, it's just been my experience that the likely situation resulting from a CTO coding is bad code and bad management. I see programming as something that generally requires full time attention to maintain good context, and good management is equally demanding.
[Response] - I know there are plenty of examples of good and bad CTOs who program or don't program, it's just been my experience that the likely situation resulting from a CTO coding is bad code and bad management. I see programming as something that generally requires full time attention to maintain good context, and good management is equally demanding.
The CEO of my employer[1] still programs 'from time to time' [2] and I would say understands the role of good management better than 99% of CEOs out there. That the firm is privately held means that he's certainly fulfilling his responsibilities as well, if fiduciary duties matter to him. Ultimately, outcomes are what matter and few have better track records.
[1] http://www.sas.com/en_us/company-information/executive-bios/... [2] http://www.forbes.com/sites/peterhigh/2014/05/12/an-intervie...
[1] http://www.sas.com/en_us/company-information/executive-bios/... [2] http://www.forbes.com/sites/peterhigh/2014/05/12/an-intervie...
I don't think a well-managed software company should keep everyone 100% allocated to their primary function. It's too brittle and it leaves too many potentially game-changing ideas unexplored.
I would be happy to work at a company where everyone spends 10% of their time on skunkworks-type projects, or cross-training in a totally different part of the organization, and that would include the CTO sometimes writing code.
(Obviously little startups don't have this luxury, but in those cases the CTO is justified in coding anyway.)
I would be happy to work at a company where everyone spends 10% of their time on skunkworks-type projects, or cross-training in a totally different part of the organization, and that would include the CTO sometimes writing code.
(Obviously little startups don't have this luxury, but in those cases the CTO is justified in coding anyway.)
The problem is that if the CTO abstracts themselves completely from the technology, then you end up with VPs of engineering who get away with making decisions based solely on the tech rather than the larger business issues.
It can definitely be weird, and particularly so if the CTO is head of both the live operations (TechOps/Devops) and product-development (frontend/backend) engineering groups. Really hard to straddle both of those well.
I totally agree. The only time I spend coding is on internal tools and process-y things. Another benefit is that there's typically less maintenance required than with product features.
I actually wrote down some of my thoughts on it here: https://medium.com/@shl/write-code-sometimes-e7516c2b1f71
I actually wrote down some of my thoughts on it here: https://medium.com/@shl/write-code-sometimes-e7516c2b1f71
That's such a neat little tool. Thanks for the inspiration to build something similar for Basecamp at our next internal hackathon!
Right on the money. I've come to similar conclusions over the years. You can't be a CTO without writing code. Not all of it, and certainly not the critical parts, but at least some code.
I've been in a company where I stopped writing code — and I found that I just couldn't keep up. I couldn't participate in architectural discussions, couldn't form opinions based solely on what other people told me. Worst of all, I started losing interest.
These days I strive for a healthy balance. It certainly doesn't make sense for a CTO to write code that is needed in production right now, because other duties might make him unavailable anytime. But prototyping, testing new solutions, writing proof-of-concept code, trying out a major refactoring just to see if it works — these things make sense and they allow a CTO to both perform his regular duties and keep in touch with code/technology.
I've been in a company where I stopped writing code — and I found that I just couldn't keep up. I couldn't participate in architectural discussions, couldn't form opinions based solely on what other people told me. Worst of all, I started losing interest.
These days I strive for a healthy balance. It certainly doesn't make sense for a CTO to write code that is needed in production right now, because other duties might make him unavailable anytime. But prototyping, testing new solutions, writing proof-of-concept code, trying out a major refactoring just to see if it works — these things make sense and they allow a CTO to both perform his regular duties and keep in touch with code/technology.
> I've been in a company where I stopped writing code —
> and I found that I just couldn't keep up. I couldn't
> participate in architectural discussions, couldn't form
> opinions based solely on what other people told me.
I worked with many talented people, but I think was frequently able to make better contributions to the architecture as a direct result of having not been close to the code. Not having any baggage from having not grown up with the company, and from not being day to day at the code-face gave me some altitude, I think.
The risk with this approach is that you take "cool" work away from your own engineers. The first question you should always ask is "is there anybody else who really wants to do this or who could learn a lot from it".
Unfortunately, the answer is almost always yes, because in most cases the code that is needed in production now is the least interesting work.
And you don't want to be known as the guy who keeps all the good bits to himself.
Unfortunately, the answer is almost always yes, because in most cases the code that is needed in production now is the least interesting work.
And you don't want to be known as the guy who keeps all the good bits to himself.
Nicely written. I find that more often the CTO is connecting people outside the company to technology inside the company, they certainly have a mentorship role to play but Steve Kleiman (CTO at the time of NetApp) once described it as the 'technical headlights' of the company. There are technological changes that can be just as impactful on the company as business changes or changes in taste. One of those I got to witness first hand was the notion that SATA drives were "good enough" for NAS applications (as opposed to expensive FC drives). Getting the company direction changed so that it could intercept that change in the technological landscape was something Steve did quite nicely. And no, it is never as straight forward as saying "Let's do this ..."
As I understood it, it is the CTO's role to make sure that the technology supports the business strategy.
It's perfectly fine to have a VP of engineering run day to day management, in this case you have more time to immerse yourself in stripe's business strategy and find and eliminate bottlenecks there.
According to the Stripe team page there are 160 people working there and engineering is the minority of it. I would be surprised if the other functional departments in your company are so optimised that they no longer have issues that technology can help remedy, these issues may accelerate the company or even prevent the company from reaching its objectives. e.g. the executives in charge of a department may lack visibility and have to beg for engineering time to get the analysis they need to do their jobs. Even worse, they may have already stopped asking for these insights and are now operating with limited insight.
A great example of this is Max Levchin his initiative to tackle fraud at Paypal, a core strategic issue for them but it wasn't part of product or engineering.
It's perfectly fine to have a VP of engineering run day to day management, in this case you have more time to immerse yourself in stripe's business strategy and find and eliminate bottlenecks there.
According to the Stripe team page there are 160 people working there and engineering is the minority of it. I would be surprised if the other functional departments in your company are so optimised that they no longer have issues that technology can help remedy, these issues may accelerate the company or even prevent the company from reaching its objectives. e.g. the executives in charge of a department may lack visibility and have to beg for engineering time to get the analysis they need to do their jobs. Even worse, they may have already stopped asking for these insights and are now operating with limited insight.
A great example of this is Max Levchin his initiative to tackle fraud at Paypal, a core strategic issue for them but it wasn't part of product or engineering.
This buys into Titles and Big Company thinking. It even draws on advice from a non-technical VC's blog on "rockstars."
You're far better off just defining people's roles based on what they're capable of, and what the company needs. Having titles bestowed and then filled is backwards and leads to problems.
You're far better off just defining people's roles based on what they're capable of, and what the company needs. Having titles bestowed and then filled is backwards and leads to problems.
In my mind, titles are indeed the wrong place to start.
Early on, we were pretty structureless — it was the best way to get things done. But as we grew, we found that lack of structure started to get in the way — if everyone feels equally responsible for everything, then either no one or everyone jumps to solve any given problem. So we started specializing, and structures started to emerge or were designed to help support the amazing people we were hiring. I specialized in a lot of the things mentioned in the post.
A great piece of advice I've gotten about organizational change is to make it in two cases: either to formalize what already exists, or to solve a recognized problem that's causing active pain. My becoming CTO was very much the former (putting a word to what was already happening). Hiring in a VP Engineering, in contrast, was the latter.
Titles are one way of quickly summing up a particular specialization, and there are many ways of going wrong with them. But I'm just using them as a convenient handle here: the piece isn't about "someone slapped a CTO label on you, now what?", but instead something more like "you want to be a senior individual contributor as your company grows, how do you stay connected and make a big impact?".
Early on, we were pretty structureless — it was the best way to get things done. But as we grew, we found that lack of structure started to get in the way — if everyone feels equally responsible for everything, then either no one or everyone jumps to solve any given problem. So we started specializing, and structures started to emerge or were designed to help support the amazing people we were hiring. I specialized in a lot of the things mentioned in the post.
A great piece of advice I've gotten about organizational change is to make it in two cases: either to formalize what already exists, or to solve a recognized problem that's causing active pain. My becoming CTO was very much the former (putting a word to what was already happening). Hiring in a VP Engineering, in contrast, was the latter.
Titles are one way of quickly summing up a particular specialization, and there are many ways of going wrong with them. But I'm just using them as a convenient handle here: the piece isn't about "someone slapped a CTO label on you, now what?", but instead something more like "you want to be a senior individual contributor as your company grows, how do you stay connected and make a big impact?".
With respect, I think you're deluding yourself a bit. The way you've described things, what you've done is hired a VP of Engineering to do most of your old job. It's a big change and you risk creating for yourself a (very boring) Chairman of Technology role if you're not careful.
For sure, with any change comes risk, but at a rapidly growing company there's even bigger risk with lack of change. (http://randsinrepose.com/archives/the-old-guard/ has some good perspective on this, I think.)
In any case, of things that keep me up at night, falling into a boring role is definitely not one of them :).
In any case, of things that keep me up at night, falling into a boring role is definitely not one of them :).
It sounds like a good environment and you're thinking about the right issues. It will probably work out well. Good luck!
[deleted]
This is an interesting point. I'm curious what you see as the better alternative. From the article, it seems that hiring a VP Engineering was absolutely the right call, both for the company and for himself. Also from the article, the right thing for the company and himself seems to be for him to be involved at something more than an individual contributor level. What would you suggest as the alternative for someone in that position? If a VP/Director Engineering type role isn't the best fit for a technical founder or early engineer, should they regress to an individual contributor's role or should they move on to a new gig, or what?
Great retrospective. I saw gdb talk at HN Meetup in London and with very few years on the 'work' clock, I felt he had a much better insight than seasoned vets. Spoke to him briefly after before dashing to get a train and when I followed up with an email he was quick to respond (feel guilty for taking his time now :( ), right to the point and gave really valuable information. I've utilised his tips on how he manages technical debt. From my few interactions, reading his posts and watching Stripe scale he's definitely a rock-star CTO in my books.
I saw him speak in Sydney just under a year ago. Coincidentally my biggest take-away was also around tech-debt management. Impressive bloke.
I don't mean this as a troll, and this is largely based on my own understanding of the CTO role, but - how many direct reports does Greg have now? If not many, then I imagine that can contribute to some existentialism around the role.
Before I over post here (really got me thinking on the journey home though) one more thing ...
The description of wanting to go back to coding is laced with guilt and uncertainty - and we have all felt it. But it reminds me of Ricardo's theory of comparative advantage - if coding is what you are best at, you should code even if you can do other things (like recruitment) better than some others.
So yes, go back to coding, get a feel for the boat thrumming over the waves again, listen to people's problems in the only way that matters - by sharing them. Your authority is useful but it is not what makes a good CTO else every idiot would be a good one. You aren't supposed to know the answers - enjoy the journey of discovery and speak not because you think you the CTO should weigh in, but because you the hacker feels it.
Ok, Time to stop pontificating, that's enough posts on one thread:-)
The description of wanting to go back to coding is laced with guilt and uncertainty - and we have all felt it. But it reminds me of Ricardo's theory of comparative advantage - if coding is what you are best at, you should code even if you can do other things (like recruitment) better than some others.
So yes, go back to coding, get a feel for the boat thrumming over the waves again, listen to people's problems in the only way that matters - by sharing them. Your authority is useful but it is not what makes a good CTO else every idiot would be a good one. You aren't supposed to know the answers - enjoy the journey of discovery and speak not because you think you the CTO should weigh in, but because you the hacker feels it.
Ok, Time to stop pontificating, that's enough posts on one thread:-)
Great Post.
If you are in NY (or Melbourne, Sydney) and are interested in becoming a better technical leader, whether CTO or VPE, or lead dev, please check out the CTO School Meetup We discuss topics relevant to technical leaders with both educational and networking components.
http://www.ctoschool.org/
http://www.meetup.com/ctoschool/
We've been doing it in various forms since 2010, and have about 1500 members in NYC, most of them in various positions of technical leadership.
(ONLY people with technical background can be members).
If you are in NY (or Melbourne, Sydney) and are interested in becoming a better technical leader, whether CTO or VPE, or lead dev, please check out the CTO School Meetup We discuss topics relevant to technical leaders with both educational and networking components.
http://www.ctoschool.org/
http://www.meetup.com/ctoschool/
We've been doing it in various forms since 2010, and have about 1500 members in NYC, most of them in various positions of technical leadership.
(ONLY people with technical background can be members).
One thing I have not tried, yet seems viable, is instead of frequent 1:1's (which only really matter when there is a personal problem) is something similar to the Oxbridge Tutorial (small group of students sit with Professor and discuss problems at hand.)
I think this approach could hear fruit as it moves the discussion from "how are you feeling" and onto "let's have an open but focused discussion on the problems facing us - not writing code but thinking first and foremost"
When me or my teams think first, things always flow better.
It's rather an indictment of me that I miss it and want to try it again ...
I think this approach could hear fruit as it moves the discussion from "how are you feeling" and onto "let's have an open but focused discussion on the problems facing us - not writing code but thinking first and foremost"
When me or my teams think first, things always flow better.
It's rather an indictment of me that I miss it and want to try it again ...
That's basically a sprint retro, no?
Not the way I am thinking of it. A retro is more what went wrong / right with our interactions in the team or outside team. It's rarely in my experience a technical what if discussion
I am thinking more a way of allowing a single CTO to engage regularly with individuals, less time consuming than 1:1, more free flowing and technically focused - a discussion on what are good or bad or crazy approaches.
Again the main things not to do are give the answers nor set deadlines. That's for the team / coders to do.
I think I see a blog post sized comment coming so will stop now :-)
I am thinking more a way of allowing a single CTO to engage regularly with individuals, less time consuming than 1:1, more free flowing and technically focused - a discussion on what are good or bad or crazy approaches.
Again the main things not to do are give the answers nor set deadlines. That's for the team / coders to do.
I think I see a blog post sized comment coming so will stop now :-)
Thanks for posting this. One question I have is this: When, as the CTO, you approach an engineer with the intent on coding together or otherwise building some system, are there not organizational challenges with an executive working with a subordinate? I realize that this has been tremendously beneficial to you, but I wonder how this works mechanically--do you just say, "Hey Jeff, let's build this together."? I have to imagine that if you're ever wrong technically, an individual contributor-level engineer might hesitate to tell you.
I would suspect that their culture has evolved in a way that allows people to point out the CTO that they are wrong.
If he has always been involved and close to his team then pointing errors would feel more like giving feedback to a peer rather than giving feedback to a superior.
If he has always been involved and close to his team then pointing errors would feel more like giving feedback to a peer rather than giving feedback to a superior.
Yes, but it is a very difficult line to walk.
The difference between "have you considered using X?" and "I tell you to use X", the difference between "can we hit date Y?" And "we must hit date Y so start cutting corners"
Authority as a position is a difficult stick to carry - if you are telling people "my way or the highway more than once of twice a year" you are over doing it.
"I feel uncomfortable with this architecture" or "this will take longer than you hope" are all indicators you are doing it right. Stop hearing those and you should worry.
The difference between "have you considered using X?" and "I tell you to use X", the difference between "can we hit date Y?" And "we must hit date Y so start cutting corners"
Authority as a position is a difficult stick to carry - if you are telling people "my way or the highway more than once of twice a year" you are over doing it.
"I feel uncomfortable with this architecture" or "this will take longer than you hope" are all indicators you are doing it right. Stop hearing those and you should worry.
I think a lot of these cultural questions require you to say over and over what's important, and demonstrate that you really mean it. I always ask people what they think, and when I sense hesitance I work to draw them out. In the end a lot depends on your relationship with the individual; I make sure to spend time getting to know every engineer who joins.
More broadly, one point Marc often makes is, if someone does something you don't like/disagree with, let them know directly. (There are some exceptions to this, and sometimes it's helpful to role-play with a manager to get some practice before doing so, but we work hard to make direct feedback a core part of Stripe.)
More broadly, one point Marc often makes is, if someone does something you don't like/disagree with, let them know directly. (There are some exceptions to this, and sometimes it's helpful to role-play with a manager to get some practice before doing so, but we work hard to make direct feedback a core part of Stripe.)
I spent a few days in the Stripe office with my team (Hey guys!) and I can tell you with certainty that they have a very strong collaborative team. They actually have a really great culture that they actively try to build (thanks for including us while we were in town!). Fridays are particularly awesome.
Anyway, my point is that I never got the feeling like people say "it's going to be this way, no questions", but also got the feeling that if a superior did say "look, I know you guys feel this way, but we are going in this direction and the deadline is X" that the team would rally behind their leader and support their decision.
Stripe, from what I saw you have done a great job building out your team. Congrats, it's nice to see companies doing it right!
Anyway, my point is that I never got the feeling like people say "it's going to be this way, no questions", but also got the feeling that if a superior did say "look, I know you guys feel this way, but we are going in this direction and the deadline is X" that the team would rally behind their leader and support their decision.
Stripe, from what I saw you have done a great job building out your team. Congrats, it's nice to see companies doing it right!
Yep, this is right.
I think it's precisely because he is known directly to the engineers that this works. No idea how well it will scale for them -- I wish them well.
In most "big" organisations, the C-levels are practically celebrities, everyone wants to be "connected" some how to them, but hardly anybody works "with" them. Everybody works "for" them (and even those direct reports/workers are imbued with some special celebrity powers by just saying the name). The hierarchical relationship of everybody working "for" you causes plenty of insulation -- communication grinds to a halt besides the cordial banter.
In most "big" organisations, the C-levels are practically celebrities, everyone wants to be "connected" some how to them, but hardly anybody works "with" them. Everybody works "for" them (and even those direct reports/workers are imbued with some special celebrity powers by just saying the name). The hierarchical relationship of everybody working "for" you causes plenty of insulation -- communication grinds to a halt besides the cordial banter.
I used to use the idea of a head chef as an analogy to CTO (well ok I had itmanagerscookbook.com - back in the day when IT manager meant what it said.)
Anyway Basically a chef must be able to cook and well, but their role is much more teaching and training people in how to do excellent cooking whilst fitting in around this kitchen.
I like this article ("I started doing things I thought were missing like culture") and I wish we could get a more useful definition of CTO rolling - something like a wiki editable only by good CTOs explaining the role to new ones.
Anyway Basically a chef must be able to cook and well, but their role is much more teaching and training people in how to do excellent cooking whilst fitting in around this kitchen.
I like this article ("I started doing things I thought were missing like culture") and I wish we could get a more useful definition of CTO rolling - something like a wiki editable only by good CTOs explaining the role to new ones.
Yeah, I think one of the biggest shocks about the role is how little documentation there is on being a CTO. (Contrast that with the CEO role, where you can read Andy Grove, Ben Horowitz, Fred Wilson, etc..) I'd love to see other people talking about their experiences: I think many of us are going through the same struggles.
The best book I've read on engineering management I've read is Leading Snowflakes:
http://leadingsnowflakes.com/
But yes, there is a dearth of information on how to be a good CTO (or VP Sales, CFO, VP Design, or really any other function). I think that's because a lot of the advice out there is effectively content marketing for VC firms, whose primary customer is CEOs. :)
But yes, there is a dearth of information on how to be a good CTO (or VP Sales, CFO, VP Design, or really any other function). I think that's because a lot of the advice out there is effectively content marketing for VC firms, whose primary customer is CEOs. :)
It's almost like a starter pack...
I am convinced we are entering an age of 'software literacy' similar to the literacy explosion after Gutenberg. And that era generated organisations that learnt to follow written policy - this time around the policy will be executable. So it's not a major stretch to imagine a younger version of you downloading the equivalent of Grove or Welch's GitHub and running their recruitment process with the same code - sort of like an executives dot-emacs.
Ok maybe it is a stretch, but at some point our companies processes will be programmable - and that means shareable.
I am convinced we are entering an age of 'software literacy' similar to the literacy explosion after Gutenberg. And that era generated organisations that learnt to follow written policy - this time around the policy will be executable. So it's not a major stretch to imagine a younger version of you downloading the equivalent of Grove or Welch's GitHub and running their recruitment process with the same code - sort of like an executives dot-emacs.
Ok maybe it is a stretch, but at some point our companies processes will be programmable - and that means shareable.
Everyone can learn to read but only some are capable of learning to program. http://blog.codinghorror.com/separating-programming-sheep-fr...
Have you checked out Startup Engineering Management: http://books.piaw.net/management/index.html ?
There's a chapter in HBR's On Managing Yourself called, "Manage Your Energy, Not Your Time," by Tony Schwartz and Catherine McCarthy.
Briefly, it is about having rituals and behaviours in place such as: getting enough sleep, doing cardio at least 3 times a week, have small snacks every 3 hours, take brief but regular breaks at 90- to 120- minute intervals 'away from the desk.'
I'm sure these are obvious, but they are easily dismissed or forgotten. There's a lot more in the essay, so it's worth taking a peek.
Briefly, it is about having rituals and behaviours in place such as: getting enough sleep, doing cardio at least 3 times a week, have small snacks every 3 hours, take brief but regular breaks at 90- to 120- minute intervals 'away from the desk.'
I'm sure these are obvious, but they are easily dismissed or forgotten. There's a lot more in the essay, so it's worth taking a peek.
Twenty plus 1-1s, means twenty plus direct reports.
No wonder the guy was burnt out. That number is simply not manageable in any worthwile way.
The rest of the article just reads like someone is CTO purely because when he joined.
The friction with the VP in terms of how the VP executed hints at someone a little out of there depth maybe.
No wonder the guy was burnt out. That number is simply not manageable in any worthwile way.
The rest of the article just reads like someone is CTO purely because when he joined.
The friction with the VP in terms of how the VP executed hints at someone a little out of there depth maybe.
> The rest of the article just reads like someone is CTO
> purely because when he joined.
> The friction with the VP in terms of how the VP executed
> hints at someone a little out of there depth maybe.
> If you're not out of your depth at least a little bit in your role, then it's probably time to be looking for a promotion. If you're a pure developer (and want to stay that way) it's time to find some harder problems, and if you've segued in to management, it's time to start thinking about how to do your boss's role.
Very well said, I think complacency is killer and thinking about how much you need to challenge yourself to move up the ranks is always a good think to reflect on.
Very well said, I think complacency is killer and thinking about how much you need to challenge yourself to move up the ranks is always a good think to reflect on.
> We then set up interviews with Marc: four days of back-to-back 1:1 or 1:2 meetings with everyone on the team from 10a-6p, as well as a talk to the whole company.
When the article says Marc had become available, should we assume he wasn't working at the time? That just seems way over the top. I can't imagine asking any serious/heavyweight candidate to 'interview' that way in the UK. I'm curious to know what others think.
When the article says Marc had become available, should we assume he wasn't working at the time? That just seems way over the top. I can't imagine asking any serious/heavyweight candidate to 'interview' that way in the UK. I'm curious to know what others think.
That's what I said in the post :)! But we felt it was important and he was up for it.
More seriously, hiring an executive is very different from any other hire. You're fundamentally hiring someone who is going to be affecting the jobs of (at least) every single person in their organization (compensation, performance reviews, etc.), as well as shaping and evolving what your company even is.
Making everyone feel comfortable with a hire like that isn't easy, and doing so takes a lot of time. But we owe it to the people we've hired to be thorough (and conversely, we owe it to the executive to make sure we've set expectations as fully as is possible, and made sure that both of us have a picture of what we're getting into).
More seriously, hiring an executive is very different from any other hire. You're fundamentally hiring someone who is going to be affecting the jobs of (at least) every single person in their organization (compensation, performance reviews, etc.), as well as shaping and evolving what your company even is.
Making everyone feel comfortable with a hire like that isn't easy, and doing so takes a lot of time. But we owe it to the people we've hired to be thorough (and conversely, we owe it to the executive to make sure we've set expectations as fully as is possible, and made sure that both of us have a picture of what we're getting into).
Hey, well it was obviously the right way for you all at the time. I was just surprised because I haven't seen execs interviewed that way, but my experience is heavily skewed towards very large companies. The more typical pattern I've seen has been (over a few weeks) an informal meeting, lunch/dinner then a few hours of in-house/panel interviews.
A 32-hour interview? That's insane. It's completely irresponsible of a company to ask that of anyone.
Pretty much insane. I'm not sure if they asked this from their other candidates but if they did, they probably eliminated 99% of all the other great candidates just because they would refuse to waste a week of PTO just to deal with this request.
MAybe that's why the comment about the company not having experience in hiring managers...?
depends on the role and maybe they offered compensation too?
Being as cynical as I am, my immediate thought was that the title was a summary of the article:
#define CTO
How to define the role of CTO is a question which has been asked for many years, and there are some "general" answers. I would recommend two things.
First, read these two articles. They're older, but provide some answers into how others have defined the role. You might be able to pick and choose to further define your role:
http://www.cs.princeton.edu/courses/archive/spring12/cos448/...
and
http://www.brixtonspa.com/Career/The_Role_of_the_CTO_4Models...
Second, I think right now it's best to look laterally into the business world as to your role. You are essentially the "CEO" of your company's technology realm. The VP of Engineering is the "COO". Look and talk to your business-side counterparts on how they handle their roles.
Your job is to work with the business to develop both business and technical strategies, and oversee the development of the technical architecture to get you there. To monitor competitors technology. To monitor emerging technologies. To prototype. To provide business and technical analysis and advice for M&A's.
The VP Engineering's role is to handle the day to day stuff. To be more tactical than strategic.
In the end, the role of CTO is still ambiguous, meaning different things to different companies. And it's changed in the past few years--I'd never heard of developers being in the CTO role until maybe five years ago or so--and it will continue to change.
First, read these two articles. They're older, but provide some answers into how others have defined the role. You might be able to pick and choose to further define your role:
http://www.cs.princeton.edu/courses/archive/spring12/cos448/...
and
http://www.brixtonspa.com/Career/The_Role_of_the_CTO_4Models...
Second, I think right now it's best to look laterally into the business world as to your role. You are essentially the "CEO" of your company's technology realm. The VP of Engineering is the "COO". Look and talk to your business-side counterparts on how they handle their roles.
Your job is to work with the business to develop both business and technical strategies, and oversee the development of the technical architecture to get you there. To monitor competitors technology. To monitor emerging technologies. To prototype. To provide business and technical analysis and advice for M&A's.
The VP Engineering's role is to handle the day to day stuff. To be more tactical than strategic.
In the end, the role of CTO is still ambiguous, meaning different things to different companies. And it's changed in the past few years--I'd never heard of developers being in the CTO role until maybe five years ago or so--and it will continue to change.
The CTO role is completely different depending on size of company. Here is my experience.
Startups: <10 I have had roles in small start-ups as CTO, but did the role of a Lead Developer in reality, it was important to get investment that they had a CTO on board that had a track record and could talk to investors, but I still had to build everything as well. Thinking back it would have been better to get a 2 day a week CTO and a full time Lead dev.
Mid Size:10>40 In a company this size with a dev team of 10ish its more of a Development Manager Role, this is some times worst than a startup as you have to be hands on, speak to investors and run a team.
Larger:>50 This is where a real CTO can really make a different, by this size you would have a couple of functional managers as your direct reports to look after day to day and get the time to focus on culture, team, investors, new tech, presentations etc.
Startups: <10 I have had roles in small start-ups as CTO, but did the role of a Lead Developer in reality, it was important to get investment that they had a CTO on board that had a track record and could talk to investors, but I still had to build everything as well. Thinking back it would have been better to get a 2 day a week CTO and a full time Lead dev.
Mid Size:10>40 In a company this size with a dev team of 10ish its more of a Development Manager Role, this is some times worst than a startup as you have to be hands on, speak to investors and run a team.
Larger:>50 This is where a real CTO can really make a different, by this size you would have a couple of functional managers as your direct reports to look after day to day and get the time to focus on culture, team, investors, new tech, presentations etc.
What I enjoy most about Greg's writing is the honesty. Here is someone who appreciates that software is a relatively young industry and many best practices are still a work-in-progress.
The age is not a problem. Speed is.
At Magnetic (http://www.magnetic.com) - we've implemented a policy of code review - maybe you could participate on some code reviews in one part of the code base - reading code isn't as fun as writing code, but at least you could still feel part of the codebase and have influence.
I think for CTO architectural discussions and code reviews are better than writing code.
But code review should not be done alone. It should be review and discussion with the developer who committed that code.
But code review should not be done alone. It should be review and discussion with the developer who committed that code.
This is so true. Moreover, our industry moves so fast that if your not in the dirt and on the ground for more than a year... it's hard to catch-up. Another things, is that I see some technical people move up so quick that they are never seasoned and thus end up making high level (architect) choices -- with alot of issues. I am not sure how other industry do it, for example, in medicine when someone becomes head of the hospital or something like that.
I recall reading somewhere of companies that split the CTO role into two, internal and external. I can see this. The internal CTO is primarily focussed on the technology and product, while the external one mostly talks to customers.
Does John Carmack (one of the true legends among great programmers) still write code? If yes, then it will be intriguing to find out how he manages to do that while being CTO at Oculus.
I was curious, too, so I asked him:
>@ID_AA_Carmack Do you still write code in your day-to-day work?
>@sircmpwn yes, most of my time is spent writing code
https://twitter.com/ID_AA_Carmack/status/527173010219102210
>@ID_AA_Carmack Do you still write code in your day-to-day work?
>@sircmpwn yes, most of my time is spent writing code
https://twitter.com/ID_AA_Carmack/status/527173010219102210
[deleted]
Manages the technical team. Provides direction on infrastructure, tool chains, architecture goals. Hires and fires.
Site is down. Cached:
http://webcache.googleusercontent.com/search?q=cache:Nz1ajuW...
http://webcache.googleusercontent.com/search?q=cache:Nz1ajuW...
Hm, what error were you seeing?
Assuming it was a 404: the setup is a bit weird since I changed the slug early on and added a Cloudflare-level rewrite to keep the old one working, but the Cloudflare rule was doing an exact string match. So if you went to something like "https://blog.gregbrockman.com/define-cto?", it would 404, while "https://blog.gregbrockman.com/define-cto" worked fine.
Just updated the rule to have a wildcard at the end, so feel free to append query strings galore :).
Assuming it was a 404: the setup is a bit weird since I changed the slug early on and added a Cloudflare-level rewrite to keep the old one working, but the Cloudflare rule was doing an exact string match. So if you went to something like "https://blog.gregbrockman.com/define-cto?", it would 404, while "https://blog.gregbrockman.com/define-cto" worked fine.
Just updated the rule to have a wildcard at the end, so feel free to append query strings galore :).
Error code: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Hey, are you guys hiring?
Yep, we're hiring engineers in SF and US timezones: (https://stripe.com/jobs/positions/engineer/), and hiring for a variety of positions globally (https://stripe.com/jobs/).
Ah, looks like non-remote (or, well, as you said, at least US timezone-only), thanks though.
would be much more convenient if the article would say in the beginning what it is about...
I also talked with a bunch of people who had worked with him previously, some of whom were references given to me by Marc and some of whom were backchannel.
[Edited to be less confrontational.]
That's reckless and unethical. I'm sorry, but if you make reference calls that aren't provided, you're engaging in the kind of invasive, fratty, white-male-privilege shit that gives Silicon Valley a bad name. It's also why we, in the technology ecosystem, don't have the credibility to get the rest of society to respect us and get some genuinely competent business people (see: Damaso Effect) in our mix. We let immature psychopaths get away with shit, and the rest of the world (rightly) thinks we're all a bunch of sexist, classist, oblivious tools.
Also, going beyond the "classic 3", in reference checking, backfires. Average people can provide 3-5 references, but the people who can survive a double-digit, backchannel reference check are mostly the ones who bought references (it's a real thing) and intimidated people into saying good things about them. Somewhere around 6-8, the empirical relationship between the number of references and the quality of candidate actually goes the other way, because you exclude more unlucky good guys than you filter out bad guys (i.e. unethical people you'd want to not hire, and hope to filter out by checking references). The worst of the bad guys almost always have their act together.
[Edited to be less confrontational.]
That's reckless and unethical. I'm sorry, but if you make reference calls that aren't provided, you're engaging in the kind of invasive, fratty, white-male-privilege shit that gives Silicon Valley a bad name. It's also why we, in the technology ecosystem, don't have the credibility to get the rest of society to respect us and get some genuinely competent business people (see: Damaso Effect) in our mix. We let immature psychopaths get away with shit, and the rest of the world (rightly) thinks we're all a bunch of sexist, classist, oblivious tools.
Also, going beyond the "classic 3", in reference checking, backfires. Average people can provide 3-5 references, but the people who can survive a double-digit, backchannel reference check are mostly the ones who bought references (it's a real thing) and intimidated people into saying good things about them. Somewhere around 6-8, the empirical relationship between the number of references and the quality of candidate actually goes the other way, because you exclude more unlucky good guys than you filter out bad guys (i.e. unethical people you'd want to not hire, and hope to filter out by checking references). The worst of the bad guys almost always have their act together.
I think when you hire someone who is a manager, you have to do this kind backchannel reference makes sense, otherwise you get someone who is not experienced at all in managing people but pretends to have done it already.
Sorry to comment on only the subject and not the content, but "#define CTO" just makes sure that CTO is recognized as something but makes it completely empty. All it's good for (standard C pattern) is asking "#ifdef CTO" and then it will happily reply: yes there is a CTO, just don't try to use it! Actually this does fit in nicely with the article, but to be pedantic maybe a typedef would have been better!
My thoughts exactly. I thought it to be oddly correct, regarding the way CTOs like to use technical jargon in a way that does not throw off the layman, but is immediately obviously wrong to anybody of their unfortunate inferiors.
Great essay. My favorite term for this is "drive-by micromanagement."
:)
I think it's hard to make "chief architect" work out in the long term--if the role is too weak, it often becomes nothing more than an evangelist; if too strong, it often disempowers the people who are closest to the work.
For figuring out what CTO means in an organization with a VP engineering, you might take some inspiration from Google's organizational history. Google never had a CTO, but they took care to establish ways for highly technical people to have huge impact without being forced onto the management track.
The first was Google Fellow, a level of individual contributor equivalent in to a VP engineering. Jeff Dean and Sanjay Ghemawat are good examples; they didn't manage people, but they did work on very hard technologies like GFS, MapReduce, and BigTable that were used by the whole company, and later inspired projects like Hadoop. (In general, I think having a dual career ladder—one for ICs, and one for managers—is a good idea, and the "Fellow" model really just recognizes the fact that the best engineers are worth as much or more than the best managers.)
The second model is essentially skunkworks: leading projects which are high-risk and important to Stripe's future, but far enough outside the main product that you want to treat it almost as a small startup. The first attempt at this were Googlettes, led by Georges Harik, which included projects like GMail, Google Talk, Orkut, and Google Mobile. At the time, those were very distant from search, but as they grew the successful projects became core to the company. The second version is Google X, where they're now expanding into very distant areas that involve hardware, biosensors, self-driving cars, etc. For Stripe, maybe the equivalent is something like cryptocurrencies, or physical payments, or something you've imagined by I haven't. :)
Anyway, thanks for writing. I have a lot of admiration for Stripe's culture and so I hope you all keep blogging about it.