#define CTO
blog.gregbrockman.com
blog.gregbrockman.com
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.
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.
2) loudly squawk
To take the analogy further, sometimes you need to throw some breadcrumbs to keep the seagulls busy.
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.
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 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.
I think the analog for the CEO might be giving up sales, if they were engaged in that early on, which is common.
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).
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.
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?
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.
[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.
[1] http://www.sas.com/en_us/company-information/executive-bios/... [2] http://www.forbes.com/sites/peterhigh/2014/05/12/an-intervie...
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 actually wrote down some of my thoughts on it here: https://medium.com/@shl/write-code-sometimes-e7516c2b1f71
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.
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.
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.
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.
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?".
In any case, of things that keep me up at night, falling into a boring role is definitely not one of them :).
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:-)
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.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).
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 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 :-)
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.
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.
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.)
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!
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.
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.
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. :)
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.
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.
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.
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.
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.
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).
#define CTO
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.
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.
But code review should not be done alone. It should be review and discussion with the developer who committed that code.
>@ID_AA_Carmack Do you still write code in your day-to-day work?
>@sircmpwn yes, most of my time is spent writing code
http://webcache.googleusercontent.com/search?q=cache:Nz1ajuW...
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 :).
[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.