2. This talk will be
• Not always mincing words
• From both manager ,consultant, and
engineering side
• Borrow from other talks I did
• Less cynical than you may think after hearing it
3. So you have a great idea
• You see all this entrepreneur ecosystem
• Better move by yourself than wait for the train
• You are sure you have identified something that
could be a business
• But to do it….
5. Let’s put an ad!
“I have this great idea and I have a great background in
well known business or political school. You know Ruby
on Holy Grail, love hacking since the age of 2, and feel
comfortable walking on The Mission? Do you want to be
my CTO, no salary intended but you’ll get a generous 2%
of shares”
“PS:if you’re not all of those, do not even talk to us”
6. Except that
• You know in fact nothing about what
programming is, except what you say to your
peers
• You would tend to engineering is deterministic
because it means somewhere science
• A few years ago you certainly you would not
have chosen an engineer career
• May have committed already for a demo
7. So let’s find our way
• Understand the “cool dude hacker” marketplace
• Swim in the land recruiting
• Evaluating people and build a team
• Manage a team of nerds
11. Conclusions (round 1)
• Getting the good ones is difficult
• Doing recruiting mistakes will happen
• Your hopes will make you judge to fast
12. What your emotional bias will tell you
Perception
“I am so lucky I have
seen only good people”
13. But isn’t there more people on the market?
• There are also more projects. So the match may
even be harder
• Statistically you may change a little bit some
gaussian parameters
• But you will not change very much in a relative
way. However certainly more positive effect than
negative
15. Conclusions (round 2)
• People will be expensive. This is the market law
• If you pay too cheap, there is likely something
not clear
• You can expect a high level of bullshit
16. Cultural reptilian brain
Marketing
Sales
Product
Engineer
QA
OK I can go in cocktails
Do not go outside of the room
20. Parameters for a search
• How to search : direct, word of mouth, recruiter,
interns and students?
• Type to search: Contractor or employee?
• Who to search: junior or senior?
22. Really?
• I have no connection to the author, Mr Joel Spolsky,
but he has done a few thing in his life :-)
• This book is the only one that should be read before
hiring developers. All is here!
• It can be read in a couple of hours, so re-read it
regularly
23. In a few words
• Good people are not on the market because
they already can do what they want
• Smart does not mean Get things done. You need
the 2.
• Not being a jerk is optional
• Be factual in job interviews
25. Contractor/Employee
• When hiring a contractor especially senior, be
clear on the expectation “I pay you not only to
do a task but possibly to lay down foundations”
• Confidentiality and discretion with employees is
required. Stay in your role, on both sides.
• Plan the conditions of contract ending from the
start
• Good ones are expensive really
• Be prepared to end fast, and from both sides
26. Contractor/Employee
• Think about building a team. Refer to the
Dreyfus model of skill acquisition.
• Decide what should be your team level. Never
forget: simple arithmetic counts. The “level” of
your team may not be the “level” of the “best”
employee.
• Employees talk (wages, opinion on decisions):
be fair all the time and explain it
27. Senior/Junior
• Is able to speak to you in English/French
• Does not equal years of experience
• Will write “bad code” to meet a goal AND come
back to it
• Knows the boundary of his knowledge
28. Senior/Junior
• Tells you about how he knows technologies, and
may know more words than a senior
• Will systematically explain you why?
• Will never warn in advance that he has
difficulties
• Believe 2 years makes you a senior
29. In no case, differences are in
“what technology do you know”
30. Decide according to your business
• When will technic become an asset of the
enterprise. Should it really?
• Do not think money. Think investment: cheap shoes
must be re-bought every two months
31. How to?
• Words of mouth and “personal contact” is IMHO
the best. But be careful of “clans” and “biases”
• Using recruiters implies more cost, but with the
hope of less time
• The recruiter problem: how to reduce the signal
to noise ratio? Do not forget, they have people to
be hired. But if the SN ratio gets higher they may
become precious allies.
32. The “rock star” effect
• Fashion and appearance
• Buzz words : agile, hackers, San Fransisco,
since he was a 9 months old
• Has worked for “XXXX”? Ask him what he
learned from it (and be prepared to be
disappointed by answers)
• Be careful of impresario recruiters
The fact is that you will want it also: appearance is king
33. Contractor
Price
Pay for Insurance
Pay for standard engineers
Pay for code writers
Pay for arms
(Paris 2014)
1500 €/day
850 €/day
200 €/day
Pay for software product doers
450 €/day
34. Employee
• Price varies from region
Junior startup Paris 38/45K€
Junior Consulting/Big Company
Paris or East Europe startup
(Germany, Switzerland neighbors)
42K€/50K€+ Bonus
Junior Well known Startup SFO 90k/100K+stock
Junior Gross Boite SFO 100K-115K+stock
35. Practical
• What you pay is what you get
• Ask someone to teach you job interview and
practice. Write scenarios, find exercises
• See a maximum of people to train yourself. Do
not wait that you have a need
• It takes always a few months to see the reality of
someone you have recruited
38. 2 axis
Dreyfus model of skill acquisitions
Technical Area
39. Technical Competences
• Changes over time. C++ is not fashion anymore.
• Can be learned if needed. Not a blocker (Rails
versus Django or how does HTTP work)
• Have a context (iOS 5 years ago versus now has
changed a lot)
40. Technical Competences (2)
• Also very sensitive to fashion effect
• Good varnish when one knows nothing
• Ok you get it : this can means not a lot
41. Dreyfus model
• Developper by 2 brothers (Stuart and Hubert) in the
1980
• Models of skill acquisition and mastering
• 5 levels from Novice to expert. They see the world in
different ways
• Per skills model
• Times plays a role in the sens that you can’t get
faster than you think but time will not make you
cross the levels
42. Dreyfus model
Expert Expert work from intuition
Proficient Proficient practitioner can self correct
Competent Competent can troubleshoot
Advanced
beginners
Advanced beginners don’t want the big picture
Novices Novices wants recipes
43. Influences of the 2 axis
One thing to remember : someone has a technical
knowledge as good as her/his Dreyfus level
44. Building a team
• Consider the two axis
• See the level of tomorrow. Beginners +
beginners = beginners….and it may even be
worse if everyone wants to be the center
• There is a need to bring balance to the force.
One expert for 6 novices may not work
45. The “plumber” effect
• Apply to plumbers, but also electricians,
software engineers, car dealers, lawyers…
• More dangerous for contractors than employees
• “All was badly done. I have to redo a good
chunk of it before I can do my job”
• Ask for “english spoken” precisions, and what
would be the next steps
The fact is that you will want it also: the savior
47. Let’s get practical here
• We have a product release to do
• We have some specification like an old consulting
company although we pretend we are agile
• We want our team to be happy at work
Based on those good intentions it will go wrong
48. Cycle is everything
• If you know nothing, play the bass drum
• Use your technical weakness as advantage
• Practices call repetition.
• Quantify everything, always : cold facts lower BS
ratio
49. Use the product
• Developers nearly never uses what they do
• But they argue they’ll do unit test (which are also
good do not get me wrong)
• Build a common knowledge : the first user. Lower
the bull shit level. Non technical clever guys knows
more than technical not clever ones
50. Give room to come again
• A good developer knows that way he wrote 2
months ago may in fact be buggy
• Force people to spend time on coming back
• Ensure esthetically pleasure in code
• Be firm about documentation. Everyone has said
this stuff is not understandable and it it oneself. Use
the due diligence argument
51. Invest yourself in the team
• Do 1/1 meetings.
• Do not think you do not have to repeat. This is not
insulting
• Being too cool can be used against you.You may be
despised
• Remember “arguing with a developer is like
wrestling with a pig in mud. After a while you realise
the pig is enjoying it" ;)”
52. Signs it goes bad
• “We need to redo everything”
• “We need more time”
• Talk about how to improve the process every 2
days
• Aim for perfection at the first shoot
• Lament about loosing time with mistakes
53. So it goes bad
• It is always better to get rid of a problem than to
think it will arrange. Prepare everything to get rid
of people easily
• Explain it to your team, especially if you fire
someone. They are not kids.
• Do not hesitate. Show no mercy. Only then will
you be strong enough…