

The CEO's job - mindball
http://jessicamah.com/the-ceos-job-part-2

======
strlen
The bit about hiring contractors, especially for vital functions such as
infrastructure and support is bad advice. A high quality contractor charges a
very high hourly rate (it also usually isn't feasible to give them a sizable
equity grant in its place), so you're left hiring people who would prefer a
full time job but can't get one. This creates a poisonous and unpleasant
atmosphere, which makes you even less likely to hire strong people full time.

I understand that "war for talent" is a popular narrative, but you note that
those writing about it are almost always journalists who aren't programmers
themselves. Non-technical writers don't understand quality developers want
something more than a paycheck: they want to work on challenging problems,
with people who they can learn from and in a company that has a shot at making
an impact on the world. If you want to hire quality people than you should
take hiring (all steps: from employment branding to interviewing to closing) a
top priority: give employees time to interview candidates (expect each
engineer to interview at least two or three candidates each week), be willing
to let a position go unfilled for a _long_ time until the right person is
found.

In short, be ready to reply "we'd like to do Y, but either we must strip out a
feature X from Y, spend more time working on it or transfer an engineer
working on Z to work on Y". If you're working on a hard technical problem,
then your investors and customers shouldn't have a problem with that. If
you're not (and there's nothing wrong with that), change your hiring strategy
appropriately e.g., if you're building CRM software, stop trying to go after
TopCoder finalists and ex-Google Search Engineers and instead look for
engineers who are interested in business and product design/development. The
former aren't going to be interested in joining you (other than at an
exorbitant rate) until you're ready to use their talent, the latter will help
you build the business to the point where you will need their help scaling it.

To use a vulgar analogy, the strategy of hiring a contractors to "move faster"
is analogous to a man having nine one night stands hoping to conceive a baby
in a month ("because I can't find the right long-term partner, and nine months
is too long to wait anyway"): it's wrong on many levels and will poison your
culture. It's long been known (Brooks' Law) that adding more "bodies" to a
project to a project that's at risk of being late will only make it _more_
late. Creating a company full of dubious quality contractors (with no loyalty,
no "fire in the belly" about the product) will make your company look toxic to
engineers used to working at "talent brand" companies where engineers are
passionate about what they're working on and are confident in their technical
abilities.

The CEO's real job is to manage the managers ("no, we don't have the resources
to ship X at time T"), and sell the company (including to prospective
employees). The blog post doesn't read "wow, this is a company worth leaving
or turning down an offer from {Google, Facebook, Microsoft, etc...} for!".

~~~
jimbokun
"...and instead look for engineers who are interested in business and product
design/development."

Isn't this the same as the generalists she recommends hiring?

~~~
strlen
Wasn't direct at her in particular. Also note that she isn't building CRM
software. The example wasn't about her. In addition, generalists may actually
not be appropriate for _some_ kinds of software development: it depends on
your application.

Generally heavy complaints of "it's impossible to hire engineers" comes from a
dissonance between engineers you're trying to hire and the engineers you
actually need to hire (or at least the engineers that are interested in your
product).

------
j_baker
I agree that a startup should hire multi-talented people. But it's a bit
extreme to say that startups should hire people who can do UI design, backend
programming, and do business deals. Certainly such people are useful, but
they're incredibly rare and are probably more interested in founding their own
startup.

Also, I don't agree with the "just contract it out" philosophy. The problem
you run into with contractors is that even if they're good, they don't have
anything invested in what they produce. They don't have to live with it long-
term.

I'm not saying that it's bad to hire contractors, only that you have to be
careful with them. And I certainly don't think that it's a good idea to hire
contractors because they're easier to find and fire than full-timers. In fact,
many times it can be harder.

~~~
HaloZero
The important thing that I think Jess forgot to mention is that inDinero
doesn't contract out critical parts of the sites. It's usually smaller things
that we want to get done that aren't important enough for the full time
engineers. Example is a small ad that we run to get user feedback on the
dashboard page, something easy to build but not super critical part of the
site.

We also make sure all contrator code goes through code reviews, which takes up
my time but ensures that no code enters our site that isn't up to our caliber
of quality.

P.S. I'm an engineer (Rohan) who works at inDinero in case that wasn't
obvious.

------
zinkem
I come from a retail management background, so I'm a newbie to the tech
industry.

The guys who taught me retail management put extreme emphasis on training.
Training and knowledge dissemination was a top priority for the management
teams I worked with. Once I was managing my own stores, I adopted this world
view and had great success.

Coming from this background I'm sometimes surprised there aren't more articles
about improving the flow of knowledge and communication within organizations.

So what gives? I learn a lot of stuff on my own (as do most of my tech savvy
friends), is that the way things work in tech? Or are training and
communication just not discussed very often because they're seen as so
elementary?

~~~
lsc
training in the UNIX industry is largely ignored (or done so badly that it
might as well be ignored) by the business folks. But informal mentoring is
extremely common.

Your UNIX folks will informally organize themselves around the best people,
regardless of the org chart you try to impose from above. Part of the job of
being the senior person is mentoring the newer people. This is done
informally, but fairly consistently across most places I've worked.

------
random42
> Someone who can do business deals, write code, and do user interface design,
> is 5X more valuable to us than a typical backend engineer.

Absolutely.... If you can find someone who is _equally_ good at all of those.
Very rarely (I personally have never) you will see someone _equally_ apt (and
good) at both left (Writing programming logic, Solving tough technical
problems etc. ) and right ( designing User Interactions, Doing business deals
etc.) brained work. Humans are not programmed like that.

Sure there are people who can get by doing multiple domains, but they are
rarely fit/enjoy/brilliant at all of them.

~~~
skidooer
Talent is subjective and fairly assessing one's own abilities is impossible,
but I have been employed in both programming and design jobs and have received
a lot of positive feedback in both domains. Given that, I think the thought
processes behind each are very similar:

In programming, design is just as important as logic. Code not only needs to
be functional, but it also needs to look good. A visually attractive codebase
is much more maintainable due to the basic human response to beauty.

In design, logic is also just as important. When designing an interface, for
example, you are constantly solving problems about how the user is going
interact with the design. The process of getting there is exactly the same as
solving a programming problem.

I think there is a lot of ebb and flow if you don't typecast yourself. As a
young kid I was quite interested in the arts. I remember spending a lot of
time drawing and honing my visual skills because that's what I enjoyed doing.
As I got a little older, I became fascinated by logic problems, remember
spending a lot of time learning how to program.

Interestingly, as it relates to this discussion, now that I have grown older
still, I actually have become much more interested in business and is one of
the reasons why I follow this website. While I've closed a few deals along the
way, my business deal abilities definitely lag behind the aforementioned skill
sets. That I chalk that up to being much less experienced, not because of any
genetic hinderances, however.

It is of my opinion that the biggest limiting factor is time. I was, perhaps,
lucky that I started young which afforded me more time to put focus on both
design and programming. Whereas for someone else who started programming in
college it becomes difficult to fit in time for other interests, such as
learning design. I know I spend less time doing business type work than I
would otherwise like to because my plate is already full with other jobs.
Because of that I miss the opportunity to grow in that area.

------
uniclaude
After reading most of the posts in this discussion, I really feel like people
here see contractors as uninvested workers. I always invest 100% of myself in
every single project I join as a contractor, and this is very important for
me, which makes me read your comments like insults to what I do.

My age and relative lack of typical corporate experience may of course give me
a bad vision of the market. Maybe most contractors are not working the way I
do, which would make the advice Jessica gives a bad one. But even in this
case, generalization may prevent you from working with interesting people.

Disclaimer: I'm working as a self employed engineer, mostly doing jobs with my
team, and far from being someone "who would prefer a fulltime job but can't
get one".

------
geebee
I like reading Jessica Mah's blog, so I'm sorry to jump right into the
nitpicking. But something in she wrote doesn't sit quite right with me...

She writes that finding talent in silicon valley is like trying to find water
in the sahara, but then a few sentences later says "We had a lot of talented
people apply for full-time jobs, but they either lacked culture fit, or cost
too much money."

Unfortunately, there's a lot left unsaid here, and it would help to hear
something more specific. For example, what was "too much money"? What
attributes contributed to a candidate's "lack of culture fit?"

------
johnbender
If you're looking for fast on-boarding I would recommend Vagrant
(<http://vagrantup.com>). It's built for reducing project setup overhead which
can be an expensive proposition if you're juggling resources as she suggests
in the article.

------
known
5\. His name should sell company products/services

------
tedjdziuba
> It's typically difficult, if not impossible, to scale up and down your
> engineering team in the way you can spawn up new cloud servers. We're trying
> to change that by having a reliable source of contract engineers who can
> help us grow non-essential components of our codebase.

Sounds like an awful place to work. Treating your most valuable asset as a
commodity? Let me know how that works out for you.

~~~
amirmc
> ... _non-essential components_ of our codebase ... to build _lower priority
> features_ that our core team doesn't have time to get to." [emphasis added]

Sounds like they've already got their most valuable assets, the employees,
where they need them the most (presumably on core product). Using contractors
to fill the lower priority gaps doesn't seem so bad in that context.

However, I could see it becoming an issue if something that was previously
considered non-core suddenly turned out to be critical (e.g after changing
direction based on customer/market feedback)

~~~
quanticle
I disagree. How many features are there that are 1) not high priority enough
for a full time employee _and_ 2) high priority enough to justify bringing
aboard another person, train them in the code base, have them code the feature
and let them go after coding is complete?

I think Jessica Mah is misunderstanding the purpose of contractors to her and
her business' detriment. Hiring contractors because the team isn't able to
accomplish its tasks in a timely fashion is disastrous in the long run. What
happens is that the contractors will write code in the most expedient fashion
possible, without care for the long term harm to the code base. The team then
sees an inexorable decline in its ability to iterate, which causes the
business side to think that even more contractors are required. This self-
reinforcing cycle inevitably leads to a codebase that's almost impossible to
change or improve in any way; it leads to a place where moving a logo is a
three week project (don't laugh, I've been there).

There is another way of approaching contracting that is more valuable for both
the team and the contractor. Instead of thinking of the contractor as a hired
gun whose sole responsibility is to finish a feature or fix a defect, the
founder should think of the contractor as a teacher or a coach. Hire
contractors when your team needs to learn a new skill or improve some aspect
of their development cycle. Approaching contracting with this mindset ensures
that each successive contractor hired improves, rather than degrades the
team's skills. Otherwise, your team becomes trapped in a maze to which they
don't know the exit, and you wonder why every new version seems to have fewer
improvements and worse performance than the last.

EDIT: After further reflection, there is another way that contracting can
improve the business in a sustainable fashion. I know of a few companies that
practice "contract-to-hire". In other words, you're brought on as a contractor
for a period of 6 months or so. During that 6 month period, you and the
company have a chance to evaluate each other. At the end of that period, the
company makes an offer to you if you've managed to prove yourself as a good
fit for the company.

