
#define CTO - craigkerstiens
https://blog.gregbrockman.com/define-cto
======
brandonb
>But universally, “sparse micromanagement” (the best term I’ve heard for
jumping in to some random issue, overturning all the decisions, and then
disappearing) is the worst.

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.

~~~
tdicola
I've heard 'seagull management' or something similar too. They fly in, shit
all over everything, and leave.

~~~
qthrul
you missed step 2 after fly in:

2) loudly squawk

~~~
tdicola
Hah, true!

To take the analogy further, sometimes you need to throw some breadcrumbs to
keep the seagulls busy.

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

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

~~~
jkarneges
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).

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

~~~
codahale
Marc's definitely the best.

~~~
danbmil99
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?

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

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

~~~
djloche
Exception: Carmack @ Oculus VR.

~~~
jotux
>>>Exception<<<

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

~~~
peteretep

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

Just wanted to add a counter-point; I was CTO for a technical team of ~40 and
didn't write code (and joined once the team was already almost that big).
While I'm sure I had many failings, I didn't find keeping up with the
technology to be any kind of problem, and frequently got involved in the nitty
gritty of technical discussions.

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.

~~~
lmm
Do you have a way of measuring? One of the companies I worked for was
completely sunk by the "chief technical architect", who to the end was
convinced he was making the right choices.

~~~
peteretep
Measure? No. But I never insisted we did stuff my way, only suggested it, and
we often went with it.

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

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

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

~~~
gdb
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?".

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

~~~
gdb
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/](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 :).

~~~
staunch
It sounds like a good environment and you're thinking about the right issues.
It will probably work out well. Good luck!

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

~~~
hiharryhere
I saw him speak in Sydney just under a year ago. Coincidentally my biggest
take-away was also around tech-debt management. Impressive bloke.

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

------
lifeisstillgood
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:-)

------
jbarmash
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.ctoschool.org/)

[http://www.meetup.com/ctoschool/](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).

~~~
guiambros
Nice! Just submitted my application.

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

~~~
paulcnichols
That's basically a sprint retro, no?

~~~
lifeisstillgood
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 :-)

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

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

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

~~~
gdb
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.)

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

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

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

~~~
jimmaswell
Everyone can learn to read but only some are capable of learning to program.
[http://blog.codinghorror.com/separating-programming-sheep-
fr...](http://blog.codinghorror.com/separating-programming-sheep-from-non-
programming-goats/)

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

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

~~~
peteretep

        > The rest of the article just reads like someone is CTO     
        > purely because when he joined.
    

I disagree. I joined my last role as CTO in a slightly bigger team, taking
over from someone who hadn't put in a very good structure. I found the article
to be thoughtful and insightful, having gone in to it with the suspicion it
was going to be another CTO at a 7 person company self-aggrandising.

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

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

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

~~~
kayamon
A 32-hour interview? That's insane. It's completely irresponsible of a company
to ask that of anyone.

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

------
cperciva
Being as cynical as I am, my immediate thought was that the title was a
summary of the article:

    
    
        #define CTO
    

i.e., "CTO" means nothing at all.

~~~
gdb
Maybe that's secretly the point of the post — the CTO title itself isn't going
to magically provide meaning for you :).

------
kfcm
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/...](http://www.cs.princeton.edu/courses/archive/spring12/cos448/web/readings/smith.pdf)

and

[http://www.brixtonspa.com/Career/The_Role_of_the_CTO_4Models...](http://www.brixtonspa.com/Career/The_Role_of_the_CTO_4Models.pdf)

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.

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

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

~~~
lukasm
The age is not a problem. Speed is.

------
nartz
At Magnetic ([http://www.magnetic.com](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.

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

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

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

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

~~~
Sir_Cmpwn
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](https://twitter.com/ID_AA_Carmack/status/527173010219102210)

------
JoeAltmaier
Manages the technical team. Provides direction on infrastructure, tool chains,
architecture goals. Hires and fires.

------
johnyzee
Site is down. Cached:

[http://webcache.googleusercontent.com/search?q=cache:Nz1ajuW...](http://webcache.googleusercontent.com/search?q=cache:Nz1ajuWmOVwJ:https://blog.gregbrockman.com/define-
cto+&cd=1&hl=da&ct=clnk)

~~~
gdb
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?"](https://blog.gregbrockman.com/define-cto?"), it would 404, while
"[https://blog.gregbrockman.com/define-
cto"](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 :).

~~~
three14
https failure for me. http works, but Chrome reports: Error code:
ERR_SSL_VERSION_OR_CIPHER_MISMATCH

~~~
gdb
Ah interesting. I'm running on Cloudflare's free SSL tier (have been very
curious to see how well it performs). What browser are you on?

------
yegor256a
would be much more convenient if the article would say in the beginning what
it is about...

------
comex
Changing the title from the original "#define CTO" to "Define CTO" does not
seem particularly helpful to me.

~~~
dang
We changed it back.

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

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

------
rfurmani
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!

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

