Archive for the ‘management’ Category

« Older Entries

Empathic Developers?

Saturday, January 16th, 2010

Amazing! Someone else also recognizes the crying need for “soft”, people skills in the hard, rocket science techie community!

I ran into Ari Krupnik at the Hacker Dojo job fair. I have constantly beaten my head against the wall trying to get other developers to understand that most people are not interested in technology for technology’s sake. Most people outside Silicon Valley has a life that does not revolve around technology but rather uses technology as an expression of “self” (“iPhone gets me the girl”). Non-techie types are anti-RTFM. Developers as a rule don’t understand and think the users are eager to spend hours discovering how wonderful the program is.

Ari apparently does:

I notice that engineers who block specific emotions entrain drama that revolves around the very emotions they block. The drama seems to go away as soon as the engineer is willing to experience the feeling that he blocks. In the tribe, we help each other unblock feelings and experience them fully. The results seem to include better relationships with peers and customers, and improvements in code quality.

Posted in management, starting a company | No Comments »

Blame. NO. Responsibility. YES!

Sunday, August 16th, 2009

When reaching for the stars, something will go wrong.

Rockets blow-up.
Servers crash.
Regressions happen.

How you handle the setbacks is critical. Blame is a useless response. Blame is negative. After blame has been assigned, the rocket is still in pieces, the server is still down, and the bug still exists.

Hire people that take RESPONSIBILITY for finding SOLUTIONS. Hire people that look to HELP others shoulder the RESPONSIBILITY to fire the problem. Hire people that look for ways to prevent a duplicate of the same problem.

Once the problem is fixed, do you and your company spend time praising the “firefighters” only? Do you spend any time praising the person who caused the fire but was RESPONSIBLE enough to step forward, admit the problem, and help fix it?

Do you take RESPONSIBILITY as a manager to give your people time to build a “sprinkler system” to put out a similar future fire?

The first “fire” might be caused by someone else’s carelessness. But the second fire is YOUR responsibility if you didn’t budget time and money for that “sprinkler system”.

Posted in amplafi, management, starting a company | No Comments »

The 100-hour work week myth

Sunday, July 5th, 2009

Chris Yeh calls out workaholism as the stupid choice it is:

If you work 100-hour weeks, no one (investors, co-founders, employees) can blame you if things don’t work out, right?

And I like to think I’ve worked a lot smarter since then [missing dinner with spouse].

The life of an entrepreneur can be rough, but at least it’s a life of your choosing. The same can’t be said for your family. Give then a chance to make their own choice.

In other words, it is the default choice in the valley and in the technology sector. And its a stupid choice. 168 hours in the week. 100 hours at work. Allow 8 hours/day for sleep. Drive-time to/from work of 1 hour. This leaves exactly 13 hours for the employee to do *anything else*.

A few years ago, I had a job with the best work-life balance. This start-up had with only 7 engineers with 30-ish total people. Between November and January, we built a Paypal integration and a major piece of functionality that got the start-up their first bits of solid revenue. Everyone took their normal holiday vacation. Every programmer worked 9-5. No weekend work. We completed the project on-time.

The company is LinkedIn. We achieved this because Jean-Luc Vaillant was fanatically about knowing exactly what was to be built and automated tests so he knew exactly where the code was. Those tests had to pass each and every night. No new work was to be done until all the previous night’s failed tests were fixed.

Every later employer had to live up to this reasonable bar. Sadly most fail and most projects are late.

They fail because the managers listen to the siren song singing the lies:

  • that says that automatic tests are optional;
  • “trusting” the developer to adequately test by hand is good enough;
  • that there is more time to do-it-again than to do it right
  • that documentation is optional and it better to have team members figure out anothers work than it is to demand that the creator document;
  • and that long hours are better than sane hours

While Chris does touch on the work-life balance with his wife, he misses some key points. If the team is working 100-hours/week:

  • the team has no reserve capacity – if a short-term sprint is needed to wrap up a project – forget it
  • the team starts to waste time at work: web surfing and game-playing. So while physically there, they are neither productive nor getting a break from the work environment.
  • as soon as there is any corporate setback – moral collapses. When it looks like the company is going to be the next Google, employees will justify to themselves that working ridiculous hours will pay-off. This illusion is dispelled at the first severe setback.
  • someone outside of work is always telling the employee how stupid they are to work such long hours. The wife, the husband, the kids, the mother, or just the friends who are going up for that most excellent ski trip to Lake Tahoe.

So my advice to employers:

  • Get rid of the game room. Make employees have fun outside of the building.
  • Cut the power to the employees computers at midnight. Make them sleep so they can think and not make silly mistakes.
  • Do a postmortem on every crisis. Without blame and with automation ONLY, look for ways to make sure that the crisis can never, ever repeat. Working “harder” or requiring greater “perfection” is NOT the answer.
  • Reward employees – not for working harder, freeing up ‘capacity’. Did some developer, IT person, or janitor do something or automate something that freed up 20 minutes/person/week? In a 30-person startup, those 20 minutes saved is the same as hiring a full-time person for 3 months! Get everyone to look for these “small” time-savers. Work now becomes less onerous, more enjoyable, and your headcount stays down.

Expanding on the last point with some examples:

  • Automatic tests — avoids developers acting like monkeys do manual tests.
  • Buy the absolute fastest machines. My latest machine took me from 15 minutes builds to 1m30second builds. I started running the tests all the time!
  • Virtual assistants to handle the random shit that an employee might have to do during the day
  • Every 6 weeks, a mobile oil change service so that no one needs to run to Jiffy Lube
  • Outsourcing human resource issues

Spend the time to discover those “small, annoying” things that seem to petty to complain about — but that impact a significant percentage of the company.

Remember for a small 30-person startup saving 1hr20m/person/week ( i.e. 16min/person/day ) is the same as hiring another person. And in the process, enables everyone to step back from the brink.

Google has their famous 20% “free” time to work on new projects. Every startup should have 20% “free-up” time to make existing projects less painful.

While I am working hard at amplafi I am working even hard on making sure that my family knows I much rather be with them than coding.

Also read Steve Blank’s post on the Lies told Entrepreneurs.

Update ( 27 July 2009 ) My response to Paul Jozefak, a German VC, guest blog post:

Strongly, strongly agree with:

Ask me what I see lacking most in startups in Europe and I’ll say hunger, drive, and lofty goals.

For me my hunger and drive come directly from wanting to change the world for my children.

So I equally strongly DISagree with:

worked four jobs for the money to launch their venture, without giving a second thought to “quality of life” or “spending time with the kids.”

For me sacrificing the hours between 6:30-9:30pm that I spend with my kids is a false choice. I sacrifice that time only when absolutely necessary and never more than 2 days in a row. Once I have those 3 hours with family, I am emotionally recharged and able to focus completely on building my company, Amplafi.

I am not alone in this. Chris Yeh and Steve Blank : Lies Entrepreneurs Tell Themselves share my feelings.

My personal reality is the least successful company demanded the worse and longest hours. And the most successful startup asked the most reasonable hours. We work from 9-5. No weekends. No missed holidays. You might have hear of it. Its called Jean-Luc Vaillant did his job and managed his people well.

Shitty long hours is not a badge of honor. Its a sign of bad prioritization and resource management. Sure some times the long hours are necessary… just like a sprint is necessary at the end of a marathon. But you don’t sprint the entire length of the marathon. And unlike a marathon in a startup, there is no rest after crossing the first finish line – just another finish line in the distance.

A startup that is sprinting constantly better hope that they get bought before exhaustion sets in. Otherwise their competitors that have paced themselves better will pass them up and their best people will burned out and quit. Any little stumble, any sign that success and glory are a few months away… and the startup starts spending time looking for fresh blood.

Posted in amplafi, management, rants, starting a company | 4 Comments »

Code Review #8: When to comment

Monday, March 16th, 2009

The last ? in a series of posts about commenting. See “the why”. See “not commenting is career threatening”. And the comment that started this off!

This post should have really been the second one I wrote. The first post was about who a developer needs to keep happy – the client or the manager.

But commenting everything is both hard, excessive, and wasteful of time. In “the why” post, I cover what should be in the comments – implicitly I was limiting comments to just the places where knowing “the why” is important.

However, still the question is “when” should a developer comment?

Here is my rule of thumb:

  • Any developer had to spend time figuring out what the code did. Refactor it and if still not clear comment the code with questions and assumptions. (Just in case the refactoring introduced a bug or caused an existing bug to appear.)
  • Another developer asks the implementing developer (or the current “owner”/responsible developer) about the code, interfaces, package. The developer asking the question copy the explanation into the code, cleaning up the chat log/email response and adding further edits and explanation as needed.
  • The code is not going to have further development for a while. Comment the code enough so that when development is resumed, the restart is faster.
  • The code is being handed off from one developer to another.
  • Key interfaces that are used by multiple groups.

And managers give developers time to wrap up and add these comments.

Conversely, what is not worth commenting:

  • Code that is actively, daily, being changed rearchitected. Every developer already knows what the comments would say and the structure is changing fast enough that the comments would become outdated.
  • Code that does not impact data integrity and end-user experience in a horrid way.
  • Utility classes/ methods.

Posted in code review, management | 1 Comment »

Third person in the room

Saturday, March 14th, 2009

Passion is a wonderful thing.

When someone is “wrong” about a subject that you care passionately about, it is natural to argue with them and try to “prove” to them that they are wrong.

Don’t.

Mentally step back. Look around. There is always a third person in the room. Even if that third person doesn’t look like they are paying attention; they are.

Are you at a party arguing in a corner? The tone of your voices will reach others. The facial expressions will reach others. What are you saying to those other people?

If this is a subject that you really do care passionately about, and the second person also cares passionately, diametrically-opposite opposite to you, neither one is likely to convince the other to change their mind.

The person’s mind you can change is that third person. The person who is casually observing. The person on the fence who hasn’t yet made up their mind.

Take the time to use and channel your passion to reach that third person to your side. That is the person you need to persuade.

Focus on being pleasant and reasonable sounding. Not argumentative. Don’t be dismissive of the person you are directly disagreeing with.

Use curiosity to counter their points. “I am curious why you feel this way, when …” (h/t to Genie Z. Laborde, Ph.D. )

Your curiosity conveys open-mindedness to that third person. Your curiosity will persuade that third person.

Posted in how to, management, marketing, political, starting a company | No Comments »

Code Review #7 – Comment the “why” not the “what”

Wednesday, March 4th, 2009

[This post continues the response to Mike.]

Clean “good” code is good but not enough. Code needs comments — but the right kind of comments.

“What” comments are useless and the most quickly out-dated. An example of a what comment is: “add the suffix path to the end”.

However, the post “Thoughts on how to evaluate code” was very specific referring to “why” comments.

Code no matter how “clean” can not self-document. Excellent comments are “why” comments. “Why” comments talk about :

  1. the assumptions / program state the code is expecting. (For example, the user is logged in, premium membership, or admin privileges )
  2. other code affected if this code is changed (For example, setting up a language default for the session, a default that another piece of code is expecting to be set.)
  3. if something is being done in a non-standard way – why it is being done that way (for example, iterating through a loop from high index to low-index rather than the standard low to high)
  4. should the code in question be used as an example pattern of how to do similar operations elsewhere in the code – or should a developer instead use a different pattern elsewhere.
  5. list the assumptions or conditions that require this implementation (with timestamp) so that it is easy to spot code that is present to handle conditions that no longer exist. For example, a comment like this: “12/20/2007 – yahoo’s open id implementation is using the openid 0.8-proposedspec.” Its pretty likely that the the spec has changed as has yahoo’s implementation. This wasn’t a HACK but knowing that reason behind the code is invaluable.
  6. Future work planned.
  7. Alternative solutions that were rejected (and why).
  8. Performance considerations – this code might be special because it executes millions of times a second. So there is good reasons for some “ugliness”.

The developer, at the moment they are writing the code, must be able to explain why they are writing the code a certain way. It is a red flag to any developer if they cannot explain the why. They should double-check to make sure they understand the requirements. Chances are they don’t and they are doing the wrong thing.

I started requiring developers to clearly document the “why” in their code. I discovered developers that were doing things “wrong” because they were unaware of the correct solution. I discovered that I was not as clear in conveying the requirements as I really thought. Without the developer’s “why” comment, it is easy to get frustrated with developers for the wrong reasons.

Parting thought

Why should the developers that come after the original developer have to spend any time ( and money! ) figuring out the previous work?

You may be the next developer.

Posted in code review, management, technical | 6 Comments »

Not commenting code is dangerous to your career

Wednesday, March 4th, 2009

There is this myth that code can be self-documenting and that comments are not necessary in good code. Michael recently comment on an earlier blog post advocating the idea of self-documenting code.

“Self-documenting” code is a career-damaging concept, because:

  • Your “manager” (person who decides you stay employed) is an “idiot”,
  • Your co-workers are “idiots”,
  • You are an “idiot”
  • The product manager is an “idiot”
  • Your client is an “idiot”

Your “manager” (person who decides you stay employed) is an “idiot”

That’s me. The guy who has 6+ people to manage has to figure out business plans and a much of non-technical stuff that has no doubt resulted in permanent brain damage.

Your manager is code reviewing all the changes by his direct reports. A task that takes a few minutes every day… unless there are no comments. I know that your manager should be able to immediately see what the code does. But remember your manager is an “idiot”. Unfortunately for you, he signs your paycheck.

Also unfortunately for you, if your manager doesn’t immediately understand your change — you are an “idiot” in his eyes.

You have also just turned a 15-minute task into a 2-hour task. He didn’t really want to be home with his family.

Your co-workers are idiots

Lets agree, your code was stellar but then your co-workers came in and mucked it up. They did a stupid refactoring and broke everything.

The code was “obvious” but not to them.

You are an idiot

Your manager returns from a two-week vacation and is code reviewing 2 weeks of changes. Your manager is asking about a “odd” change that you did 14 days ago.

  • Can you explain it clearly?
  • Do you remember your thinking at the time?
  • Alternative solutions that you tried and failed?

The product manager is an “idiot”

  1. Your stellar (comment-free) code is deployed into production.
  2. The product manager changes the product definition and a new feature is born.
  3. One of your (“idiot”) co-workers makes a change (but not to your code).
  4. The tests pass and 2am this Friday, the code is to be deployed
  5. You go out drinking.
  6. Your (“idiot”) manager deploys the code to production and it breaks.
  7. Unfortunately, it breaks in your code.
  8. Your manager looks at your code and can’t figure out why you wrote the code a certain way.
  9. Its 3am now. He calls you up. Are you going to remember why and are you going to be able to help him?

Lets pretend that the test coverage is better and the problem is discovered before deployment. But your change was made 3 months ago, are you going to be able to explain the thought process for the change?

Your client is an “idiot”

You are independent and you take on clients. Your new client is a non-technical person who needs your awesome coding skills. Now you are in trouble. A non-technical product manager and a non-technical manager (they are paying you!).

But your code is self-documenting right?

Not to them. The product is late. The doubts grow in their head. They ask a friend to look at your code. Their friend (“another idiot!”) says the code looks like garbage and he cannot tell why you wrote the code a certain way. The client starts to push back on paying your invoices. Things get ugly.

Posted in code review, management | 3 Comments »

Grow your own rockstar

Wednesday, March 4th, 2009

I have interviewed hundreds of people, technical and otherwise. I have managed a few as well.

Most interviewers do not realize that there is no “best” candidate on an absolute scale. The rockstar at Google may absolutely fail to fit in at the interviewer’s company.

For most companies, even most start-ups, the rockstar is not interested in the company because the company itself is not a “rockstar”.

  • Do you have Dave McClure or Seth Godin as advisors?
  • Is Reid Hoffman on your board?
  • Are you working on cutting-edge projects?
  • Are you using the latest technology?
  • Are you willing to let the rockstar do things his/her way?

Why would a rockstar be interested in your company? If you don’t know then your company will never attract and retain rockstars.

Look for the budding rockstar

Instead of looking for the proven rockstar (who has 10 offers; all of them better than yours) — create one!

Ask every candidate to bucket their skills into one of these four buckets. For good measure also ask about key “task types” (for example “debugging performance issues” ):

Good at doing Bad at doing
Like to do “Rockstar” Sweet spot
“future rockstars”
Hate to do Short-timer Stay away

“Rockstar”

Interviewers are told to look for the person in the “Rockstar” bucket. The candidate that is good at what you need and loves to do it. When looking for a brain surgeon, this is the doctor you want fiddling with your gray matter. However, when hiring for other positions you (the company) are asking this talented person to do exactly the same thing that they have already done.

So in effect you are asking them to tread water in their career and not grow. The company will have to offer higher salary, huge stock options, or enough “sweet spot” opportunities. Without one of these, it is quite likely that after a few months the new-hire (and you!) will discover that the rockstar has drifted into the “Short-timer” bucket and is now job hunting on the side.

However, in the absence of “sweet spot” opportunities and if the prospects of the company turn south — this “rockstar” is the first to bail. They are good, they know it, and they are heading for greener pastures.

“Short-timer”

The person is good at the job but they hate to do it. They will do the minimum necessary and no more. Late nights and long hours will quickly be resented. This person is job hunting ( or should be). Try to find a “sweet spot” for them fast to take away the pain.

“Stay away”

The person is bad at something and they hate doing it. If you hire this person you are an idiot. Enough said.

“Sweet spot” ( future rockstar )

This is the person to hire. They are bad at the skill but they are motivated to get better because they love doing it. They will stay up late figuring things out. They will think and breathe the technology or the skill and try their damnedest to become that rockstar.

They will be loyal because the company gave them the chance to learn and grow when no one else would.

Best of all the competition for the future rockstars is low. Everyone else is too busy looking for today’s rockstar.

Price of growing rockstars

However, growing rockstars is not cheap.

  • the company must be willing to mentor and guide the future rockstars.
  • Management and the rest of the team must tolerate failure and correct without punishment.
  • Labeling someone an idiot cannot be allowed. There must be a supportive environment.
  • the company must not have a consensus environment. Everyone is not equal in skills. The budding rockstars must not be deluded into thinking that they are rockstars.
  • Advancement and reward structure that recognizes supporting roles. This encourages others to help mentor the future rockstars.
  • Willingness to fire. Lets face it a company is not a school. There are certain people who will not work out. Fire those to make room to hire more future rockstars. And this includes your current rockstars!
  • Know the difference between “working hard” and “working smart”. Make sure the company rewards “working smart” not “working hard”.
  • Know when the future rockstar is in over their head and rescue them. (which may unfortunately include terminating)

Posted in management, starting a company | 1 Comment »

FAS157: VCs whining about what they have to do anyhow

Monday, February 2nd, 2009

So over at Techdirt, Mike Masnick gets all whiny about having to follow government regulations:

And, now, FAS 157 has come into play — a new rule impacting many venture capitalists, forcing them to figure out what the “fair market value” of their investments are, and provide that number to their investors. The problem is that these things are impossible to accurately value. Not difficult, but impossible. You’re asking people to value a totally illiquid asset as if it were liquid.

I am sorry but this smells like bullsh*t. Mike claims it is impossible to value a totally illiquid asset.

For arguments sake, lets think of some totally illiquid assets that get valued all the time in the courts:

  • A person’s sight (lost in an industrial accident)
  • Cancer caused by exposure to a TCE leaching into the water supply
  • A person’s life

The fact is that we figure out how to assign a value to “illiquid” assets all the time.

Mike links to Fred Wilson’s blog post which Mike offers up as “proof” that VCs are complaining about FAS157. However, Fred gives a fairly clear explanation of how his firm tries to value each company, including areas where there is a little bit of black magic. Fred ends his post:

There’s a silver lining in all of this, including the IRS 409a pronouncement of a few years ago that has created a whole industry of private company valuation firms and, if anything, even lower stock option grant prices, and that is that we are starting to collect a huge data set of private company valuations over time.

This, combined with the efforts of a few brave souls to create secondary markets for private company stock is going to lead to more data, more transparency, and more liquidity without having to register and do an IPO or sell your company.

Now I may be insane but Fred doesn’t sound like someone who cannot arrive at any valuation.

Now lets shoot some more holes in Mike’s “theory”. He says that he can possibly value any portfolio companies at any time. This means that, if Mike was to be a member of 5-partner VC firm, his firm could NOT:

  • pick the weakest companies that get cut-off (if Mike cannot value a company at all then he can’t value it against another company either)
  • decide which partner is doing better and which partner is picking poorly (can’t value, means can’t value partner performance either)
  • explain to a limited partner how well the fund is doing (“We can’t value our portfolio companies….” “WTF???” )
  • make a decision if the next round should be an up or downround
  • figure out if they got a great deal or if the founders got a great deal

Sorry…. BULLSHIT

Posted in funding, management, rants | No Comments »

Compensation in the startup world.

Thursday, November 20th, 2008

My comment to Rick Segal’s post.

Peter Thiel at TechCrunch50 (timemark 18:30):

He said the #1 predictor of whether or not an investment was a success or failure was the CEO salary. He drew the line at $150K. More than that and the company was like to fail.

  1. The CEO aligned with the investors
  2. The simple reason he offered was that the CEO salary caps everyone else’s salary.
  3. The focus of the CEO is focused on building a great product and company

From my and my wife’s personal experience, every start-up that we worked at (except one*) where the CEO had a great comp package — the company failed. Everyone was looking at scoring their next bonus — not making the company better. The other result was that because the compensation given to the big wigs there was less money available for the engineers to make things happen.

I look at the Detroit jokes (aka GooberMotors, Fnord, Christ!ler CEOs) flying in on their corporate jets to Washington, DC and I know that those companies are going bellyup.

Malusus might be the answer. UBS is looking at requiring that bonuses be returned when the results are bad the next years.

* [The exception was a company that was small and very profitable. The two founders idea was that they didn't hire anyone until they could guarantee that they could pay everyone's salary for 6 months assuming that the company made no more money.]

However, investors need to be aware of what employees and founders need compensation-wise to keep their mind focused on the business.

Posted in management, starting a company | 1 Comment »

« Older Entries