Posts Tagged ‘management’

The Silicon Valley “Bubble”

by Hang

A lot of people are rightfully worried about the “bubble” that exists around Silicon Valley. In the two weeks I’ve spent immersed deeply in the Bay Area culture, this is the best way I’ve found to explain what’s actually going on:

In the valley, people are willing to adapt their behavior to fit the software.

Everywhere else in the world, people adapt the software to fit their behavior.

Let me explain through an example: One of the things I talk a lot about is how corporate shared calendering systems suck because they’re all built according to a list of features without a consideration of the narratives that people are wanting to express through them. Everywhere else in the world, when I’ve discussed this, people join in the gripe and tell me crazy stories of their own about socially tricky situations made awkward due to shared calendering systems. It’s only in the valley where I tell people this and they go “That’s not a problem for us, we adopted this corporate culture which means our shared calendering system doesn’t suck anymore”. Let me repeat that again for emphasis:

We turned our entire corporate culture upside down to accommodate the whims of a piece of software we wanted to adopt.

That’s crazy. Absolutely, bat shit insane crazy and that’s what’s made the valley such a great place to build software. The valley is uniquely able to take a piece of software in it’s rough, early adopter phase and figure out how to mold their lives so that this software becomes useful. This is the classic early adopter pattern and it happens to people everywhere around the world but only in the valley is it a cultural norm and you’re looked at weirdly if you’re not willing to join in. It’s only in the valley where I’ve met companies who now have their entire corporate philosophy centered around being OK with you publicly declaring that you’re going to take a nap in your office and that you should not be disturbed solely because their shared calendering system didn’t have the effective privacy controls necessary to navigate that tricky social dance.

This attitude is so pervasive and so normal within the valley that it’s taken an outsider like me to come in and point out to people how goddamn weird that is. When I put it the way I do, people get pretty disturbed and rightly so. Because, while the valley is a uniquely great place to be building software, it’s not a great place to be designing it. Over and over again, I’ve encountered the pervasive attitude of “Well, the average user will just have to make this fundamental shift in the way they conduct their lives and it’ll be great. They’ll do it because the benefits will outweigh the costs”. That companies don’t understand on a gut level how unrealistic such a statement is for anyone living outside of the valley is, IMO, the primary cause of failure for startups that never manage to move out of the valley.

I really don’t know what the solution to this problem is except to become acutely conscious of it and to fight that impulse at every turn. There’s a certain ambivalence I have towards moving to the valley as a result of this, this visceral fear of being digested by the valley process and emerge the other end as a pod person. A year ago, the last time I was planning to move down here, I don’t know if I would have had sufficient life experience or insight to articulate the pattern that happens in the valley. If were to avoid the valley for another year, who knows what insights I’d be able to articulate then that I’m still not able to articulate now?

August 5 2009

The Dream Job

by Hang

The Dream Job is so simple I’m wondering why I’ve never heard anyone propose it before.

I’m going to start off describing The Dream Job by the most inconsequential and most easily changed details because, well… you’ll see.

The Dream Job pays one million dollars per year and only one is offered every year. Every application for The Dream Job must be made public. Once you’re hired, the only power the employer has over you is firing you. That’s it, those are the only overt constraint for The Dream Job, everything else flows from there.

You don’t apply for The Dream Job by sending in a resume. Well… you could but you’re not likely to get it. There’s only 1 Dream Job a year, you need to dazzle. The Dream Job is only for people who first of all love that company very very much but that love is tinged with a deep channel of ambivalence. It’s for people who are driven with the desire that this company, while great, could be so much greater if they could only fix this one thing and you are the right person to fix it.

I would be deeply, deeply tempted if Newegg offered The Dream Job (There are a half dozen other companies with which I would apply for a Dream Job without hesitation but I’m holding those closer to the chest as they’re related to stuff I’m actually working on). Classic usability isn’t even my field anymore but The UI behind online computer buying has essentially remained static since the mid 90’s and every time I want to purchase a computer online, it makes me deeply angry that the user experience is still so poor from a pure usability standpoint. I have so many ideas bursting in my about how you could revolutionize the user interface to make it orders of magnitude more productive and fitting with the tasks that people have. Give me a week to prepare and an hour to present to Newegg and I’m utterly confident I could convince them hiring me at a million dollars a year would be a bargain. Here’s a simple idea Newegg: Build a braindead reliable text parser so that I can paste the shopping cart from any other web store and you can tell me how much identical or similar items would cost at Newegg. Why should price comparing systems be a laborious half hour of hunting for equivilant components on multiple sites when some simple engineering could reduce it down to seconds?I managed to come up with 8 other ideas inside of an hour before I got bored at how easy it was.

The Dream Job is not for everybody. The freedom offered by it sounds alluring but when you consider the full implications of it, can also be slightly terrifying. Once you get in, you can do literally whatever the hell you want but that also means not a single person will actually know what you do until you sell them on it. By definition, you’re hired to do something at that company that’s never been considered before so you’re starting off with nobody obligated to give you the time of day. It’s up to you to build up the support within the company and selling people on your vision or your mission is dead before it’s even born. There’s a reason why a company full of otherwise smart people hasn’t been able to see a problem that’s so obvious to you and it most probably stems from a complete difference in cultures. You need to be not only a visionary but also an anthropologist and a translator. On top of that, you need to constantly justify your $1 million dollar expense or you will be swiftly canned. The Dream Job requires not only brilliance and passion but also deft people skills and the ability to work around showstopper obstacles.

So, given all this, why one million dollars? Simply because, even in this day and age, one million dollars still means something. It still has that allure when those crisp syllables roll off your tounge. The actual number is meaningless, mostly symbolic, and the bargain of the century to boot. Anyone that brilliant willing to work for one million dollars a year is clearly not in it for the money. Instead, the requirements for The Dream Job are simply the natural result of the observation that hiring only for the skills you know you need is a rather stupid way of doing things.

The conventional way of hiring is you first figure out what resources you need, how much you want to pay them, where they slot in the org chart and then you search for a candidate. This was great when your grandparents were busy climbing the corporate ladder but why don’t we shake it up a bit. How the hell is a company supposed to know what it needs anymore? If you’re a process nerd, then you’re going to hire a bunch of other process nerds and build a great process nerd company culture but how can you ever know what you really need is a deep design aesthetic as well? Similarly, if you’re a design person, how are you going to find out how an obsessive A/B tester can transform how you build? The simple answer is that you never will with a conventional hiring model. Instead, you need them to tell you how they want to do their job.

Everything about The Dream Job stems from transferring the onus of responsibility of defining your job from the employer to the employee. The limit of one a year is what gives it the specialness, the prestige and the cache neccesary to attract the rare people who could handle such responsibility. The million dollars and the enforced hands off approach is what gives them the confidence that The Dream Job is something the company is taking seriously and is committed to integrating as a core part of how they do business. The requirement that applications be public is a filter that screens out the chuckleheads and leaves only those who have a credible chance of deserving it. The requirements are not carved into stone, they’re simply my interpretation of what would be the minimum required for The Dream Job to even work.

 The Dream Job is so stunningly obvious that it must be wrong. I can’t possibly have been the first person to have come up with this. But if it’s wrong, it’s probably at least going to be wrong in an interesting way. If you’re in a position to, do you have the balls to offer a Dream Job? If so, you better hurry because I know the first chance I get to scrape a million spare dollars together, this is what I’m doing.

February 24 2009

Incentives as surrogate values

by Hang

I was reading Paul Graham’s Startups in 13 sentences and came along this interesting piece of advice:

7. You make what you measure.

I learned this one from Joe Kraus. [3] Merely measuring something has an uncanny tendency to improve it. If you want to make your user numbers go up, put a big piece of paper on your wall and every day plot the number of users. You’ll be delighted when it goes up and disappointed when it goes down. Pretty soon you’ll start noticing what makes the number go up, and you’ll start to do more of that. Corollary: be careful what you measure.

It had been meshing with my thinking a lot about visualising valued work and community building. I think the same thing applies in both contexts, if you display each user’s post count under their username, then people are going to start posting a lot. If you implement a karma score, then people will try and do things that maximize karma. Not only exposing information about valued work important, not exposing information can also be an important design strategy. Unfortunately, for most online community organisers, there’s little thought about the effects of a feature, features are often turned on just because they’re there.

But chewing over this a little bit before going to sleep last night, I realised that inventives can be thought of as a context free instantiation of values. To have values means that you believe that certain actions are either right or wrong stemming from some base moral reasoning. What incentives do is it replaced that base moral reasoning with a much simpler system of rewards. In other words, you switch from doing something because it’s right to doing it because it’s good for you.

Because incentives are context free, they’re much easier to scale, both up and out. Every person you meet has their own rich tapestry of past experiences and beliefs which influence their value system but every person is going to get exactly +1 to their post count when they make a post.

However, the downside of an incentive system is that they never incentivize precisely what you want to reward and, whenever you get humans into the mix, you’re going to get gaming of the system. Incentives are also inflexible in the face of novelty compared to values because values stem from the motivation rather than the result of reasoning.

Values are more effective but harder to implement, incentives are easier but less subtle. One of the unique advantages that startups have is that they’re still small enough that they can make the effort to instill a strong value system and this is one of their unique competitive advantages. Some companies nowadays are starting to get the picture and have come out full force in the expression of their values but too many still try and ape large companies and hide behind a bland moral ambiguity. More startups need to realise their true values are a massive asset, not a liability and that they won’t have the luxury of having them for much longer.

January 27 2009

Make it right

by Hang

At some point in your professional career, you will make a mistake and you will do something that ends up causing serious inconvenience or harm to the people you are working for. In these circumstances, I see people default into one of two different attitude, make it right or make it go away.

Making it go away entails doing the least possible to get the person in front of you to stop complaining. Shift the blame, absolve responsibility, offer enough to restore the situation to the status quo.

Making it right entails doing enough that the person in front of you goes away satisfied and this is much more rarely seen.

The first step of making it right is owning up and it goes something like this:

You’re right, I’m sorry, I should have…

Each of these 3 components is essential. The “I should have” is important because it communicates to the other person that you understand the scope of the problem and what needs to be done to fix it. It allows both parties to come to an agreement over the extent of the grievance.

But too many people think that just owning up is enough to make it right. It’s not, owning up is cheap and just owning up by itself is merely an advanced form of making it go away. The next step is to remove the hurt.

You did something wrong, it’s not the end of the world but you did hurt someone. Merely restoring things back to the status quo does not remove the hurt. Instead, you need to transfer the hurt onto your shoulders and show that the consequences for your mistake hurt you more than it hurt them.

If your site had half an hour of downtime, don’t just give people half an hour of credit, give them 2 days of credit. If you make a mistake on your billing, don’t just refund the discrepancy, write off the entire section you billed them for. If you accidentally wipe all of their personal data from your servers, well, you’re pretty screwed, I have no idea what you should do.

The only way to remove the hurt is to show people that you’re equally as motivated as them for the hurt never to happen again. This is the only way you can restore trust in someone that you won’t be making the same mistake again.

This is great, you might be thinking. Making it right sounds like some noble, code of honor type shit which only an idiot would not want to follow. But making it right is also fucking hard as well. It requires an extraordinary level of effort to keep yourself at the standards that are imposed by making it right. I personally think that making it right is important enough to strive towards those standards but understand that it’s not something that can be undertaken lightly.

November 20 2008

Helicopters and anti-Helicopters

by Hang

From a post on the straight dope:

I work in advertising, where frequently the challenge is to get the client to agree to pay you as much money as possible, then go away. The problem is that some clients (particularly new ones) will absolutely refuse to let an estimate pass their desk without making some alteration, just to show that they’re involved in the process. Now, if you go in with a carefully crafted ad campaign, where everything beautifully interlocks with everything else, then this moron blindly slashing away with his pen will inevitably cock it all up.

The solution is to give him a helicopter. A helicopter is something glaringly, obviously wrong, deliberately thrown in to satisfy a busybody’s need to “do something.”

It comes from a video producer I once knew who would always include an actual helicopter (for aerial shots of the city) in the estimate every new proposal he made. The helicopter was always obviously far more expensive than anything else on the list, and the client would always immediately cross it off before approving the proposal. End result: the producer got to do the project as he wanted, the manager got to feel useful, and everyone was happy.

An anti-helicopter is the opposite of this. It’s something you inadvertently put in which seems to make everyone fixate on it at the exclusion of what you were trying to show them. If you’ve been in enough debates or done enough blogging, you get a general sense of what the anti-helicopters are and yet it doesn’t stop you for occasionally throwing one out. You’ll be making this long, well structured, elaborate argument and add in a totally tangential sidenote and all of a sudden, everyone’s gone off in a huge 100 post argument about whether the sidenote is valid.

A proper understanding of helicopters and anti-helicopters can be very useful when trying to convince.

October 23 2008

Oct 23rd (day 11): The most useless form of help

by Hang

I’ve been reading Why should the boss listen to you by James Lukaszewski and it’s one of those books which is so obviously right that it shouldn’t need to exist. One of the very obvious things that the book says is:

you should be helpful to your boss

Simple, trivial and easily accomplished right? It’s not as easy as you think.

The second most useless form of help

When I was writing my PhD and I met another academic, we would talk shop and I would explain my research. More often than not, they would suggest a paper to read, a new avenue to explore or a new perspective on the issue. Of course, they were just trying to be helpful but the majority of the time, these conversations were the second most useless form of help I could have gotten.

I am willing to wager that there has not been a PhD in history who thought he did not have enough papers to read or that their project was too tightly scoped. Working on a PhD program is like trying to empty the ocean with a tablespoon, the list of potential work would occupy several hundred lifetimes. Given that you only have 4 – 10 years to complete a PhD, you are forced to prioritize and intelligently ignore everything that is not within your immediate scope.

Every PhD student has an internal priority list of papers they could feasibly read, papers they would love to read and papers they know to be useful but they have no hope of every getting around to reading. So when you propose a new paper that is only tangentially related to their topic, they’re just going to smile politely, let you email it to them and it’s going to slide to the very bottom of their to-do list. This is the second most useless form of help.

The workload of your boss is similar to a PhD student. There’s an infinite mound of work to be done and only so many hours in a day. The second most useless form of help in the workplace is pointing out trivial problems. The boss knows about all the trivial problems. And even if they don’t know, they don’t care about the trivial problems because there’s so many more important problems that need solving.

Coming up with problems feels like you’re helping, It feels like you’re doing something productive. You could be happily chugging along proposing problems all day long and then be completely blindsided with the knowledge that you’re just dead weight who must be let go.

The only way to determine if a problem is trivial is to know what it is the boss does on a day to day basis and how he orders his internal priority list. Only by knowing this can you get a sense of what he believes is feasibly accomplishable and anything below that line is considered a trivial problem. If your bosses job is a complete mystery to you, then you can never, by definition, rise above the second most useless group of workers.

The most useless form of help

Whenever you bring up a problem with your boss, you’re giving them two tasks to add to their list. The second of the tasks is to actually solve the problem. But before they can do this, they need to first figure out whether the problem should be solved. If you’re a person who clearly can only complain about trivial problems, that’s fine. They can quietly ignore you and shuffle you out of the team in the next department restructuring. But if you start dumping problems into their lap with no sense of how important it is to them, they’re now forced to spend time figuring out whether you’ve given them a legitimate problem or not. You’ve now added a task to their list which has bumped off a piece of actually useful work.

The truly useless people in an organization can be treated with benign neglect but if you’re the type of person who dumps unsolicited problems into the bosses lap with no sense of context or priority, then you’ve just given them the most useless form of help and you’ll come to be actively despised.

The only useful forms of help

There are only two really useful forms of help that you can perform for a boss. One is to highlight a problem which should be on the to-do list and the other is to solve a problem on the to-do list that they were planning to by doing it yourself. If you bring a problem to the boss, you need to bring the justification for why this isn’t just an important problem to you but also to them.  You need know what the boss believes to be important and show how this problem is more important than the least important thing he plans to do. If you solve a problem, you need to justify why that was the most important problem you could have been solving, again, not based on your own priorities but by the bosses priorities. Both of these things are impossible if you are wholly ignorant about what it is that your boss does all day long. It seems like such a simple thing but it’s surprising just how many people at all levels in an organization have no clue or curiosity about anything except their immediate job function.

The very most useful form of help is when you perform both types of help at once. You discover a problem and prove that it’s an important one worth solving but you’ve already figured out how to solve it before even approaching the boss. Such help is invaluable because it you’ve now just made the bosses life easier without them having to lift a finger. If you’re the type of person who can regularly do this, you become indispensable within an organization.

October 21 2008

Oct 21st (day 9): Test driven management

by Hang

Mike Burns has some interesting thoughts on how non-testing code is trivial and it lead me to thinking about placing testing above development in the corporate heirarchy. In a normal organization, people start off in testing and maintenence and then only move up to development once they’ve proven their chops.

What I am envisioning is that everybody starts out as a developer and the development work is considered trivial and mindless because it’s aimed solely at passing tests. Once you’ve proven yourself as a good developer, you get promoted into testing. Once you start testing, you can’t ever write code again on that project and the job of the testers is to make the developer’s lives hell by making sure the code base is rock solid.

This has a number of nice features that I can see: First of all, it replicates the common “hazing” pattern that we know reinforces group solidarity. The job of the senior members is to make the lives of junior members horrible and junior members put up with it because they know some day they will get to do the same. (As an aside, there’s an interesting educational theory which says that bullying is a product of an age segregated education system. Before mass public education, children mainly interacted in mixed age groups with status based on age which was far more egalatarian because everyone at some point got to be the alpha of a group)

By forbidding testers and developers to communicate except through a chinese wall, it encourages both groups to form a unique culture and language which further enhances solidarity and cohesion. Additionally, the develop–>test heirarchy naturally encourages an evolution into develop –> test –> design which can allow for a much more organic growth into a design oriented company.

Of course, there’s a few downsides to this management structure as well: Development inherently requires more technical skill than testing and so it’s an inefficient use of expertise as those most competent at developing will be siphoned off. Additionally, not everyone is equally adept at both soft skills and hard skills and having a promotion path that moves from hardcore technical skills to people skills is only suitable for some people.

Say you’re a hardcore algorithms guy who loves working on scalability problems. You don’t want to move up to testing, testing is boring to you. Whats more, even if we let you become a senior developer, you’re going to get frustrated because all the smart programmers under you are going to move on.

Test driven management seems like an interesting way to structure a company and I’d be interested in hearing examples of people who are using something similar to this sort of approach.

Oct 20th (day 8): Programming as artisanship

by Hang

It’s been noted before by many people that programming should be thought of as craftwork, not manufacturing. The economics of programming is such that the cost for each incremental unit is 0, so it makes sense to view development as a source of revenue generation and not a cost to be contained.

The most visible manifestation of that seems to be the Google style perks that seem to be de rigeur now among web 2.0 companies. Basically, the equation boils down to more perks means happier programmers and happier programmers mean the most number of feature points per hour.

But if programming is artisanship, then I think creature comforts are merely the most rudimentary of what we could be doing and it’s instructive to look at true artisanship in other field. In particular, when we look at examples of the truly haute in couture or cuisine, one of the things which is most striking is that they revel in their stunning inefficiency and that this is what makes them special. There is no attempt to streamline or rationalize or redesign for efficiency purposes. If a suit jacket can be made even incrementally better by individually hand stitching each seam so that the stripes are aligned, then this will be done as a matter of course. Sure, you could get a suit for half the price with a barely indistinguishable drop in quality but this doesn’t matter because what artisans are striving for is not efficiency but quality.

So what does this mean for programmers and programming shops? What would happen if we abandoned efficiency as the primary goal of the organisation? What stunningly inefficient paradigms could we embrace?

The first that comes to mind is pair programming. Maybe pair programming works, maybe it doesn’t, I don’t know. I’ve not seen that many people talk about it outside of the hardcore evangelical XP community and it’s easy to see why. No matter how you manage to slice and dice it, two developers working on a single machine are just not going to be able to produce as much code as both of them working independantly and XPers trying to sell you that it does start stretching for increasingly absurd arguments. To any organisation, the idea of pair programming sounds like an extraordinary extravagance which would be impossible to justify under any budget.

Another thing which seems curiously missing is the concept of a “stage” or sabbatical or any other form of dedicated educational experience. In haute cuisine, chefs will stage at each other’s restaurants all the time to pick up new skills or gain different perspectives on food. Why is it that no company offers a 6 month, paid time off so that their employee can go work at Google or Facebook or any other place doing interesting things? What would happen if people were regularly allowed to drop out for a few months at a time to do pure research?

Even in the most enlightened companies right now, programming is still viewed as a fundamentally productive activity (in the sense that the goal of it is to produce things). It’s a very tough sell to propose anything which doesn’t demonstrate an increase in function points/hour/dollar. But if we truly believe programming to be an artisanship activity, then we should consider optimising for something else, optimising for quality so that even the most extravagently inefficient touches are celebrated because they make the product better. Could this work economically as a model for commercial programming? I honestly don’t know yet…

July 23 2008

The right size for the job

by Hang

Being a computer scientist by background, one of the things which I’ve always been keenly aware of is issues of scale, not only of computer systems but also of human systems. As organisations grow larger, layers of beaurocracy and organisation are needed just to keep things on track and get the job done. When done well, each of these things has a clear task and purpose but they also involve an inevitable tradeoff of time taken away from actual production.

One of the challenges I’ve been facing establishing policy at this early stage is what formal procedures and mechanisms should we put in place to safely navigate between the twin pillars of informal cowboy style development and rigid, stifling control freak management. At the moment, my inclination is to lean towards slightly too much procedure over slightly too little because I’m also treating this phase as a learning experience.Part of the reason to implement these systems is so that we can learn to use them and be familiar with them and understand the individual nuances (aka: frustrations) of each one.


Copyright ©2009 BumblebeeLabs — Theme designed by Michael Amini