The great technical swindlelcerveau@nephorider.com, lcerveau@mmyneta.com

• 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

This talk will be

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

So you have a great idea

….You need a software engineer

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”

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

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

The market is statistical!

This guy that will save your life

Carl Friedrich Gauss 1777-1855

German mathematician known also as “Princeps mathematicorum”

“

Whatever happens, the limit says

The vast majority is average

• Getting the good ones is difficult

• Doing recruiting mistakes will happen

• Your hopes will make you judge to fast

Conclusions (round 1)

What your emotional bias will tell you

Perception

“I am so lucky I have seen only good people”

• 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

But isn’t there more people on the market?

In a world of technical demand…

• 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

Conclusions (round 2)

Cultural reptilian brain

Marketing

Sales

Engineer

QA

Product

OK I can go in cocktails

Do not go outside of the room

Times are changing

Marketing

Sales Engineer

QA

Product

Should it be?

Marketing Sales

Engineer

QA

Product

Recruiting

• How to search : direct, word of mouth, recruiter, interns and students?

• Type to search: Contractor or employee?

• Who to search: junior or senior?

Parameters for a search

1 books to read

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

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

ParametersSenior

Junior

ContractorEmployee

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

• 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

Contractor/Employee

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

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

In no case, differences are in “what technology do you know”

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

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.

• 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 “rock star” effect

The fact is that you will want it also: appearance is king

Contractor

Price

Pay for arms

Pay for code writers

Pay for standard engineers

Pay for Insurance

(Paris 2014)

200 €/day

Pay for software product doers

450 €/day

850 €/day

1500 €/day

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

• 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

Practical

Evaluating

1 books to read

2 axisDreyfus model of skill acquisitions

Technical Area

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)

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

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

Dreyfus modelExpert 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

Influences of the 2 axis

One thing to remember : someone has a technical knowledge as good as her/his Dreyfus level

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

• 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 “plumber” effect

The fact is that you will want it also: the savior

Managing

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

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

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

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

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" ;)”

• “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

Signs 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…

So it goes bad

Thank You