Everyone is talking about the Yahoo! memo ending work from home for employees. When a company is in crisis, as Yahoo! is, actions like these, that don’t seem to directly attack the decline, are ripe for ridicule and criticism. There has been speculation as to whether this is simply a layoff in disguise, i.e., a stunt to get people to resign voluntarily and reduce expenses. Though, even that doesn’t make much sense when you learn about the damning statistic, i.e., only about 300-500 (2-4%) workers are remote. Getting those workers to be incrementally productive or getting some of them to quit would hardly make any significant effect on the company’s bottom line. So why do it?

I am reminded of an article on Rands in Repose about telecommuting (my comments here). In the short-term, it seems to be a win-win for both employer and employee, but soon enough (within a year), the typical remote employee is on the verge of quitting or being fired. And it really has nothing to do with productivity, but simply that the employee has not been able to communicate well to eliminate the friction and trust issues caused by working remotely.

Telecommuting is a great example of where perception is everything and the facts do not matter. For example, think about the following situations, assuming you are a manager:

1. Employee X never sends an email before 10 am and never sends an email after 4 pm.
2. You called Employee X’s phone three different times on the same day and nobody picked up, but you got a return call five minutes later each time.
3. Employee X did not respond to your instant message.

Now let us assume that Employee X works in the office. You know, having seen Employee X, that she comes to work at 8:30 am and leaves at 5 pm. She is in the building and usually at her seat except for meetings or breaks. So Item (1) never registers unless you are actively looking for it. Item (2) is irritating, but you assume you called at a wrong time. You may assume that item (3) was because she hadn’t turned on her IM. Under normal circumstances, you would not assume the person was slacking off.

But with a remote worker, situations (1) to (3) go to the “slacking off” assumption very, very quickly. Employee X has to be responsive to incoming communication (phone calls, emails, instant messages) much more than a worker at the office. Even a true and legitimate reason like a bathroom break can be used only so often for lack of frequent communication. So you have to work extra hard to maintain the same level of trust, especially if you are someone who has guilt issues with people accusing you implicitly of laziness. Having a manager with whom you have a good rapport and trust improves things, but only to an extent. There is a much more fundamental process at play.

One truth is that everyone misses deadlines now and then. Also true is that your manager is not an independent entity, but also has his or her manager to answer to, including a customer to whom things have been promised. So when you miss a deadline, you are putting your manager in a difficult spot. And the manager would like an answer about why that happened. You can supply the reasons, but the manager makes the final analysis of where things went wrong. And usually what people are drawn to are major differences. In an environment where only part of the workforce is remote, any mistake by the remote worker is analyzed with comparisons to the at-office workers. And the analysis is that the problem happened because the person was not in the office.

If this seems silly, think of the stigma attached to the "9 to 5" programmer: the idea that the person who stays a few minutes longer than necessary loves their work more (and by extension, is more capable and productive irrespective of actual work produced) than the person who is watching the clock. Blaming the remote worker is simply an extension of the same concept. It is easy to see why this idea is popular. Through most of history, working harder (in the fields, pastures or elsewhere) brought greater reward. Knowledge work is not like that, but ideas rooted in our cultural thinking die hard.

Of course, Yahoo! should know better. But since they should have known better about a lot of things in the last decade, this is not particularly surprising even with a new CEO.

Aaron Swartz’s sad death is one of the great losses to the tech community. The first time I heard about Aaron Swartz was when I was looking for an RSS feed to Paul Graham’s essays. Because he had a static site, he had pointed an RSS link to one on Swartz's site, which Swartz had created by scraping the content. Over time, I became more aware of his early contributions and Reddit career. I followed (and twice linked to) the writings on his blog, which covered a lot of ground, including brilliant movie reviews, such as this recent one of the sci-fi movie “Looper” and analysis of the Batman trilogy from a political perspective. He was also writing a thoughtful multi-part series called “Raw Nerve” about getting better at life.

Swartz’s main life work was in the area of intellectual property rights, mostly related to copyright. Interestingly, from what I have read, it seems that his main brushes with law enforcement related to simply making public documents publicly available. As in, information that is in the public domain, but protected by a gatekeeper who charges for the privilege, or restricts the volume of information that can be accessed. The problem, of course, is that when something similar is done by Google (like with Google Books) or other companies, they have deep pockets and an army of lawyers to fight their point of view out in court unlike an individual.

But the ideas that Swartz fought for were important. The increasing dominance of technology over every aspect of our life means that whoever controls the agenda on intellectual property will increasingly control the rewards and rents in tomorrow’s society. Copyright law, patent law, trademark law and laws against electronic reverse engineering will determine the rise and fall of monopolies, whether we have increasing or decreasing innovation, whether we have more or fewer public goods. The IP rules not only decide whether you can watch a movie or song, but also relate to things such as industrial products, food grains, labeling, whistleblowers, etc.

For example, current copyright law has stopped any work before 1923 from passing into the public domain for almost a century, something that could still get extended again. The “fair use” doctrine is ambiguous enough for litigious lawyers to sock victims for money. Patent law is a complete mess with frivolous patents hanging as a sword over growing technology companies. If you are a small technology companies, you need the protection of the patent arsenal of a larger company if you want to be able to survive, which means selling out sooner than later. Trying to break a software protection could land you in jail.

Some of the battles are being won. There is a greater awareness of the damage caused by poor IP laws. Technology companies are now politically strong enough to compete with the entertainment industry, who prefer the old approach, though the tech industry has its own pet IP rent seekers too like patent trolls. The faster pace of innovation means that enforcement is simply unable to prevent departure from the laws. For example, increases in disk storage means very soon you could have every single movie ever made on a disk drive. It does make sense still to strike poor laws to prevent people from being law-breakers and for IP owners to understand how to deal with the new realities. Also, Creative Commons has resulted in an explosion of content that successfully competes in important areas, such as college textbooks.

We have to move Swartz’s ideas forward. And in that regard, we have to avoid the Howard Zinn-ish outlook that is clear from his writings, which is that progress is only made by the elites just enough to keep the masses quiet and avoid revolution. That is quite a pessimistic take and it fosters an “all-or-nothing” mentality that can be sometimes self-defeating. It also ignores different strands of progress on the IP front, notably the GNU versus Apache-style licenses, where the latter provides a way for businesses to share in the open source movement. The SOPA success shows that greater awareness and mobilization can help turn the tide and push legislation in a more sensible direction.

This is a nice image from 37Signals showing where their developers are located:

David says that they would have missed out on a lot of great people by only looking at developers living in Chicago. That is true. What is also striking is that despite their actively looking for good developers who can work remotely, there are many places that have no representation: China, India, anybody from the Middle East, Africa or the entire Southern Hemisphere.

37Signals is a small dataset, so this is to be expected. But it is interesting to think about the factors behind remote software programmers and geography in general:

1. Intellectual property rights: Once code leaves the country, you expect some level of confidentiality and protection of your code. This is not a problem for companies working on open source code, but otherwise you want to work with people in countries which have a good legal framework and working governmental institutions. That rules out many countries which have high levels of corruption.
2. Skill level: Countries that have a history of encouraging higher education in engineering (Russia) or are gaining experience in specialized areas of software development (Israel) are likely to have better developers. Also, the higher the wealth level of a country, the longer exposure of its population to computing and programming, particularly with respect to non-mainstream technologies.
3. Knowledge of English: Even though application/website screens use local languages, the popular programming languages are mostly based on English. That gives a major advantage to countries with English as the first language or official language (Commonwealth countries). Also if the “home” company speaks English, they would prefer someone speaking English too, or at least having the ability to write proper English.
4. Time zones: Communication can be done via email, but sometimes when you need to discuss something, real-time communication (video conferencing or instant messaging) is essential. The farther people are, the fewer hours in a day they can spend online together on a consistent basis.

Of course, someone may be so good that some constraints don’t matter.

I was digging through old stuff when I found some notebooks I had filled up about 20 years ago. I used to be a trivia fan and copied down things like Olympics gold medal winners from reference books. The idea was that I could easily look up the information without having to go to some library. I cannot imagine how many hours I spent on those activities, which today seems silly considering how easily Wikipedia or Google provides the same information. Even though twenty years ago, I knew about computers, thinking of them as data storage devices instead of computing devices still hadn’t entered my mind.

It is worse than a cliche to say this, but it is hard pressed to point out something that will not be made obsolete by technology. The list of things made outdated by handheld devices includes both old and new: cameras, alarm clocks, books, CD/DVD players, sound  recorders, paper, maps, encyclopedias, fax machines, envelopes, calculators, paint brushes, credit cards. Some will last longer than others by moving to the upscale market — You can still purchase a $10,000 camera if that is your living or you are into an expensive hobby. Or for reasons of sentiment or authenticity, you would rather have something that has less to do with modern technology. Though remember, physical books were once on the cutting edge of technology too.

Services performed by human beings seem immune to technology. But it is possible to see a future where much of the work is done by robots, both big and small. We already have dumb machines (dish washers, lawn mowers) doing a lot of work, but the last step is still done by human beings. The promise of Roomba is that much of those kinds of work will be taken over by robots, and you can just vegetate in front of the TV. One reason why this has not happened yet is the delicate financial situation across the globe, where household spending on newer technology has stalled, resulting in prices still being prohibitively high for the middle class. But that will change over time.

Similarly with medical care. We are close to a time when small robots the size of ants or smaller will be on or in your body monitoring and even fixing issues (“Hey, is that a tumor cell there? Zap!”) Less invasive, more precise surgeries performed by robots with minimal guidance from doctors. One issue is the massive amount of regulation that could slow the adoption of technology, but it is a question of when, not if. Over time, per unit health care costs will come down like it has in other areas. And it needs to as the human population is aging at a rate unprecedented in world history.

I think Paul Graham is right about this. Computing technology has reached a critical level where we are going to see all kinds of amazingly useful (and not just quirky) gadgets. And then people then will find ways to bring them together into single robot models. The jobs of the future will be be in how to make things that are going to make obsolete the things that human beings do. But don’t think we will only have the robot makers in the future. By then, the machines will have become intelligent enough to create copies of themselves and put the engineers out of work too. In all seriousness, though, barring politics or climate driven disasters, the next 15–20 years will be an era of fundamental change in the relationship between man and machine. Machines are going to be become smarter and more versatile, and take over much of what we do. And how we approach that world will have to be different, starting from schools to all the other institutions we have built.

The Dropbox team had a post explaining their decision to use CoffeeScript instead of JavaScript and, in particular, re-writing their existing codebase in CoffeeScript. In case you are unfamiliar with CoffeeScript, it is a language that compiles down into JavaScript, so you have the option to do new development in CoffeeScript while retaining your previous code in JavaScript. It is more succinct and has language features that avoid some of the pitfalls of JavaScript. Recently, CoffeeScript has seen more competition with the release of Google’s Dart and Microsoft’s TypeScript, though each of these languages approaches things from a different angle. TypeScript tries to provide a static typing environment for programmers used to .Net, while CoffeeScript embraces the dynamic nature of JavaScript, while providing idioms that simplify programming.

The drive behind finding an alternative to JavaScript programming for convenience and power has been going on for several years and includes Java applets, server-side code that outputs JavaScript and so on. An important reason is the lack of cross-browser support for newer releases of JavaScript. Take a look at the JavaScript page on Mozilla or the features in JavaScript 1.8 and think about how many of those features you can (actually cannot!) use in a website open to the general public. Even Google Chrome, with its rapid releases, is far behind on supporting new language features. One way to get around this is the library approach, using tools such as JQuery, and Underscore. But if you are interested in having more power at the language level itself, libraries are of limited help. And CoffeeScript offers a compelling solution.

If you have already been doing significant JavaScript coding and are aware of the good and bad JS parts, CoffeeScript can take some time getting used to. Unlike a language like C# which built many functional paradigms on top of existing syntax, CoffeeScript got rid of JavaScript tokens like semi-colons, curly brackets, etc. and introduced words to replace symbols as operators, as well as significant whitespace, making the syntax look foreign to a JS programmer. This “war on semi-colons” seems suspiciously like making life easier for Ruby and Python web programmers than for existing JavaScript developers. Having said that, with the significant benefits that CoffeeScript offers over JavaScript (especially with avoiding gotchas), adjusting to the new syntax seems worth it.

I did find this from the Dropbox post simplistic:

In the process of converting, we shaved off more than 5000 lines of code, a 21% reduction. Granted, many of those lines looked like this:

[lots of lines with only brackets and semi-colons]

Regardless, fewer lines is beneficial for simple reasons — being able to fit more code into a single editor screen, for example.

Measuring reduction in code complexity is of course much harder, but we think the stats above, especially token count, are a good first-order approximation.

It is instructive that the only reason for fewer lines actually provided is being able to see more of the code (which may be important for you!) This is the reverse of the old project manager’s method of measuring programmer productivity by using lines of code written. The argument against, rightly, was that writing more LOC was simply a measure of how much you typed, and not how quality code you wrote. A strict use of LOC as a metric could introduce dysfunctional dynamics through people inflating their LOC by not refactoring their code properly and creating future maintenance problems.

But this doesn’t mean that fewer LOC automatically translates into quality code. There is a general truth that one line not written translates into one line not having potential bugs. But when you are replacing multiple lines of code with a single line, you are sometimes not eliminating those bugs. You are just bringing all potential bugs into one line. To give an example, if you replace an “if-else” statement with an “?” operator, you are reducing 5 lines of code with one statement. But you didn’t eliminate any bug. You just folded them together.

Another case is where you eliminate intermediate variables and roll them into a final statement, which looks especially neat if you can get a fluent interface going on. The problem is that each section of a chained statement can fail at runtime and so you need to have many more lines simply to ensure that the code works as intended or fails gracefully. Any serious code base will always have a significant percentage of code (and libraries) for error-checking and resilience.

Another instance is when you reduce code by moving duplicated code to common classes or methods. This seems like a sure-fire way of reducing huge chunks of code. But centralized code with global side effects can be dangerous because they can be called from any place in your code base. So you need to have a good state machine (and good scoping) to ensure that the code is not executed at inappropriate times.

People also tend to forget that a vast portion of the code is not in the code you write, but in the libraries that you use. One aspect is that the total LOC is way more than the LOC usually counted. But another aspect is that people shouldn’t be counting some of the LOC they write. For example, if you have written a bunch of code that is reusable and tested (both in test and production environments), then for all intents and purposes, that is code equivalent to an external library.

What I am trying to get at is that in the twenty thousand lines of Dropbox code, a huge percentage of code is already tested and working. Nobody even looks at much of the code, because it has a clear API. Unless there is a fundamental change to the architecture or there needs to be a significant improvement in its performance, that code won’t be touched. So why count them? The code you should count is the code that is in play. This figure should be kept small, but not only by reducing what is written, but also moving them into code libraries that can be tested and forgotten.

Chris Eargle has a great article explaining that the term “technical debt” comprises both strategic debt and reckless debt:

Technical debt accrues interest, and it must be paid back lest the interest payments (lost time) become too high for product maintenance and future development. If immediate business concerns outweigh future business concerns, it makes sense to incur this debt. Debt incurred in this manner is known as strategic debt and is the only kind I find acceptable. […]

There is another form of technical debt that can and should be avoided: reckless debt. Unlike strategic debt, this is suffered without an informed decision. Reckless debt is far more dangerous as it is typically ignored or obfuscated until it presents a more serious problem.

This is right. In software development, even though you do research and discuss and debate, sometimes you cannot make a clear final decision that only has advantages. Ideally you can compromise on what features you have to deliver, but sometimes you have to accommodate the stakeholders on other software attributes. For example, you may choose to go with an older, slower version of a library than a faster version that has not been battle-tested. If you understand the decision you are making, you know you have to fix the problem at a later point in time, and will have to live with the disadvantages in the meantime.

But if you are misinformed, or don’t have the skills, or are prejudiced, then your decision is reckless. I am not sure that “debt” is the right word because people know when they are getting into debt, even with loan sharks. Some terribly wrong decisions made in software development are done without any awareness. People are either ignorant, or they are dismissive of the possibility that the decision could lead to loss. For example, not paying attention to backups.

A quick word about messy code. If your team has a programmer who doesn’t know how to write reasonably good low-level code, it is not worth it. At the end, you will have to read and rewrite every single line of code that they have written. This rewrite is much more time-consuming and cumbersome than just writing the same code in the first place, because now you have to worry that something is not broken, and have to build unit tests around them and need time from testers. Sometimes the old code contains bugs that you discover and cannot fix because fixing them can create problems for existing customers who rely on an unexpected behavior of  the software.

There is a hygiene factor in code. Going below that threshold indicates a programmer with poor skills and lack of professionalism. For example, an incorrect or outdated use of naming, formatting, low-level program flow techniques demonstrates a poor programmer. But if you have some programmer who is good at the low-level, but has problems with program structure, such as making good choices of how to split or join methods or classes, or how to manage a programming interface, then a lot of code can be salvaged by re-assembly without worrying about low-level implementation details. Of course, the hygiene factor varies from one project team to another; you don’t want a team of architects making rookie design mistakes. Teams need to set their base threshold for programmer skills and only incur code debt for mistakes above it.

Steve Yegge has a couple of posts (here and here) expounding a new theory of thinking about software engineering. As he says,

1) Software engineering has its own political axis, ranging from conservative to liberal. […]

2) The notions of “conservative” and “liberal” on this political axis are specialized to software engineering. But they exhibit some strong similarities to their counterparts in real-world politics.

3) Everyone in the software industry who does stuff related to programming computers falls somewhere fairly precise on this political spectrum, whether they realize it or not.

He goes on to explain the characteristics of the “conservative” attitude towards software development (which he says is risk management) versus the “liberal” view. He  suggests that static typing is the key demarcation between the two camps and then proceeds to assign computer science and programming concepts, languages and even technology corporations into them. The second post has a bunch of replies to feedback. Read them and the comments too.

Sometimes it is difficult to know whether these kind of posts are elaborate trolls, but since many people will take them at face value, let me go ahead and address some of the arguments made. The posts betray a poor understanding of both how the political system works (not to mention silly caricatures of conservatives and liberals) and how software organizations work. To start with, the use of “conservative” versus “liberal” is decidedly unhelpful. It injects the debate with emotional baggage. Politics is more important, far-reaching and have greater historic context than most software development issues. The difference of writing your application in Haskell versus Ruby is trivial compared to the difference in electing one party versus the other. (If you believe that “all politicians are the same”, you are not paying attention.)

Because of that, most people’s political views seldom change. An illustration of this is the popular vote percentage of the loser in “landslide” US presidential elections: Usually close to 40% and that is the same for both Republican and Democratic candidates. Many people have lifelong loyalty to one party and no issue, news, or evidence can sway them. Electoral results are decided by a few percentage of the voters and by demographic shifts. Also, the actual issues may not even matter as parties make big shifts, but their followers remain loyal. See neoconservatism or neoliberalism.

Software development attitudes are very different in contrast. Programmers can be adamant about languages and frameworks, but there is significant churn that can only be explained by pragmatism, not any philosophical outlook. For example, take a look at the position of Objective-C in the TIOBE index. The huge success of iOS devices meant opportunity and many programmers decided to try their luck by writing code in Objective-C. PHP is four times more used than the elite favorite Ruby, because every hosting vendor throws in PHP support for free.

In other words, money counts. The market decides winners and losers. And most programmers accept the outcome because otherwise they cannot feed their families. The market rewards programmers for longer experience in a particular technology or domain and for technologies that show momentum or have value to large corporations. Most justifications are post-hoc. Programming wars are usually nothing more than a battle for status. Few people can make choices entirely divorced from the market situation.

In a tough labor market, programmers (who are trying to break in) have the incentive to try learning many technologies to position themselves with more breath of knowledge, or simply have more targets to aim for. Programmers with jobs have an incentive not to rock the boat at their workplace. You don’t want to try something new if it has the potential to backfire and get you laid off. That is true even in a favorable job market, but then there is greater flexibility and room to try new things.

Within an organization, when someone is presented with a choice, the unasked question is, “Is this going to make life easier or more difficult?” And it is a deeply personal question. Most of the time, a change you propose will mean additional effort, time and risk for someone else, not to mention cold cash being spent on your idea. Also, you get most of the acclaim if your idea succeeds, but they will share in the blame if it fails. This has nothing to do with the other person’s orientation or outlook towards software programming, but simply a cost-benefit decision, sometimes made sub-consciously, but made nevertheless.

You can see people’s attitudes when you present a way out of this situation. For example, give an extra million dollars to a team and see how quickly people change their opinion about whether something is easy to do. Or a big hike if everyone starts writing code in Ruby versus whatever they are doing now. Or extend a deadline out 6 months without handing out new work. Amazing what gets accomplished.

So, no politics here. Just self-interest.

Jeff Atwood had a post about persuasion, linking to one of my favorite movie scenes where Idi Amin, the former dictator of Uganda, castigates his advisor for not effectively persuading him to expel Asian residents who were not Ugandan citizens. The conversation goes like this:

Idi Amin: I want you to tell me what to do!

Garrigan: You want ME to tell YOU what to do?

Amin: Yes, you are my advisor. You are the only one I can trust in here. You should have told me not to throw the Asians out, in the first place!

Garrigan: I DID!

Amin: But you did not persuade me, Nicholas. You did not persuade me!

Back in 2007, I wrote a post that referred to this last speech, about how some people want others to behave like saints and excuse their sorry behavior. But let me talk about persuasion here. Atwood is right in that convincing people to do things is important, but he confuses the issue by looking at it mostly from the viewpoint of the leader (the servant leadership style) instead of that of the subordinate. Because getting people to do what you want is very different when you have power over someone and when you do not.

In the standard manager-employee relationship, every boss has many elements of power over the subordinate. The power to fire, the power to choose whom to select when there is a layoff, the power to decide what raise to give, the power over managing benefits (such as vacation timings), the power to allocate funds, the power to show displeasure at subordinates. In short, the power to make someone’s workplace better or worse through various mechanisms (institutional or personal) at their disposal. In contrast, the only major tool an employee has is the ability to quit for another job and that ability depends on an external factor called the job market. Union/HR arbitration, lawsuits, etc. are last-gasp remedies for wildly unacceptable behavior and they cannot be used if someone’s manager is more incompetent than evil.

There is nothing wrong about this dynamic and in many situations, it works. The basic idea is that the boss knows what to do. The boss tells the employee what to do. The employee gets paid for it. When it comes to quantifiable work, such as say hauling boxes from one spot to another, this system works well and even better if the employer provides clear input on how much work should be done within a unit of time, say 10 boxes per hour. Even in work that does not lend itself to quantification, the power asymmetry greases the wheels. The boss wants to get simple things done without a discussion. The thing gets done and people can move on. No time wasted in arguing and analyzing. Similar to how a traffic policeman puts his hand and drivers stop. Everyone respects the policeman’s authority, backed by the power of the law. Things go smoothly.

But in other situations, the multiple kinds of power that a boss has, namely the ability to make unilateral decisions and the power over the affairs of subordinates, do not go well together. What if the boss is wrong in his decision-making? What if the boss not only is making a wrong decision, but is so completely sure about the decision that he is actively lobbying employees and deciding that their objections can be overruled?

Idi Amin had much more power than any possible employer has. What is an advisor to do? How far can they go to advocate a point of view before being branded a traitor and persecuted themselves? What kind of arguments can they use that would shape Amin’s mind which he has not previously thought of and discarded? Remember that any Amin advisor is already in a spot where they are a party to evil and the only question is whether they are doing less or more evil. Any recommendation will not be on the lines of, “Is this ethical?”, but based on some other dimension such as the country’s economic prospects or international prestige. Amin thought that expelling Asians would make his country more prosperous and more powerful, thus gaining more international status, and any advisor who would think of suggesting otherwise brings Amin’s judgment into question.

The reality is that a boss (good or bad) does not need to persuade. If they ask something, it will generally be done. Unless it is something unethical or unlawful, they have the full power of the institution (and the law) behind their request. And if employees do not remember that, repeating the request a couple of times, with increasing intensity, passion or irritation, gets the point across.

An enlightened boss realizes that their first job is not to persuade, but to understand if they are even making the right decision. And that is easy to say, but it is much more hard work. It means being able to trust the collective judgment of your subordinates. It means being able to swallow your pride when your pet idea is criticized. It means controlling your emotions and being neutral when discussing suggestions. Also, being able to agree upon a course of action from someone else and then not turning on it when it fails which eventually will happen because no one is infallible.

But as a manager, you are the one in the direct line of fire for any success or failure, i.e., you are also an employee under someone higher and you can be fired for inadequate performance. If you own the business, the success or failure of an idea can make or break your company. If you think an idea is going to work, would you listen to someone saying it wouldn’t work, especially if they have much less to lose than you do. And whether an idea is right is sometimes a gray area because no one can exactly know the apriori probabilities of risks and success factors.

This means that managers have to tread a fine line. They have to listen to subordinates, but also use their authority to overrule objections. My personal opinion about this is, “Don’t sweat the small stuff.” Don’t tell how to do every single thing, but set the overall goals and expectations. Get involved more deeply only if people are not meeting expectations that they promised. At that point, it affects your promises and then it is time to push your way of doing things.

Angela Baldonero at Return Path has a post about her work at human resource management. Some of her points are very good. She writes about not tolerating brilliant people who cannot work in a team. Their company (apparently) does not simply pay lip service to their stated value of total transparency, but acts on it even when not doing so could have been easier. They cultivate an executive team that discusses everything in the open and there are no back channels for communication.

However, when she discusses about policies and rules, she is not completely right:

Policies and rules are created to guard against people doing stupid things to control time and resources. The reality is, with clear direction 99% of our people make great decisions every day. The couple of misses we’ve had have been quickly resolved after a clarifying conversation. Instead of locking things down, we set them free. We’ve said no to creating a policy for every situation we might encounter. Instead, we have unlimited vacation and sick time. We have a common sense expense reimbursement philosophy (“spend the money as if it was your own”).

Of course, there are some rules that are meant to prevent people from doing stupid things. But that is not necessarily true for all rules and it is also not the case that the only rules that apply are the ones in the company’s employee manual. Think about the phrase “clear direction” in that paragraph. What does that mean? Does that mean someone (like a manager) tells people what to do and they follow them? Or is it the company culture that provides a guideline for the acceptable range of behavior? In either case, you have a de facto rule. What does a “clarifying conversation” mean? Does it not mean that you broke some unwritten rule and someone is giving you a hard time about it?

Take for instance, the “unlimited vacation”. What does that actually mean? Does it mean, someone can take a vacation for 3 months? Can an employee take a month off and then take another month’s vacation in the next quarter? I would bet that people at Return Path have rarely, if ever, done that. And the reasons are clear. Such behavior would not be tolerated because it interferes with the business and the employee (who doesn’t conform) has shown themselves not to be a team player. We are then effectively looking at maybe 2–4 weeks once a year as the de facto vacation. Not that much different from your average company.

So what is the problem? The issue is that without the written down rule, you confuse people instead of clarifying. You also make decision-making difficult for them. For example, if say 2 weeks is the norm, what happens if you want to take 3 weeks? Will that create a bad impression about you? Do you have to do something different to earn it? What if you don’t have enough time left to put extra effort? Also think of a manager who was asked by someone how long they can be and replied, “2 weeks would be ideal”. Then along comes someone in the same project and says they need 3 weeks for whatever reason. Do you accept or not?

In the case of expense reimbursement, I am more sympathetic. You would need several pages of an HR manual to cover all the different situations possible. But even here, you can establish high-level guidelines or reimbursement limits ($x for taking a customer to lunch, for instance) and then come up with an approval mechanism. This is important because when people are not sure about what they can expect, they are more cautious. Reimbursements are typically meant for acquiring or retaining business, and you don’t want people to be penny wise and pound foolish, just because they were not sure whether they should have spent a few extra dollars to please a customer.

Good rules allow everyone to know the limits of what is acceptable in the organization. They make it easy for employees to make quick decisions.Trust-worthy employees are afraid of creating the wrong impression of impropriety or dishonesty. In the absence of rules, their caution can cause you business. This might not be so evident on the surface. A policy that unwittingly makes employees spend less and take fewer vacation days may seem good. But there is a business reason why you give people time off and why you want people to spend money on behalf of the company. And not doing enough can hurt you.

I read Matt Gemmell's take on critics of Google's acquisition of Sparrow (an email client) with interest. It echoes some of what I previously wrote about entrepreneurs, i.e., they are in the game to benefit financially and because there are many business factors outside their control, sometimes it is worth selling the business when they have a chance. Innovation improves when there are more people working on new ideas, and you can only attract more people to your field if there are different ways for them to succeed, not just having to work on one business for years and hoping everything falls into place.

But Matt only gets part of the picture. And this has to do with the kind of acquisition where the acquiring company does not have any plans to continue development on the product. Essentially, they are buying the product to kill it. While this may be good for the two parties involved in the deal (the developers and the acquiring company) and you should be happy for them, it is not clear that this kind of situation is good for the industry.

Innovation benefits when there is competition. Not only is the end consumer restricted to the choices and decisions made by the larger company, the very existence of the smaller competitor makes the large company more aggressive about having a better product. There is less of a “take it or leave it” attitude towards consumers, instead, we get more, better features in the existing product. Sometimes, you initially see only a marketing push (maybe a FUD campaign), but if the competing product keeps biting into the market share, you see the larger company attempt to make big changes.

New products suffer from a lack of trust. There are significant barriers that a product must overcome before a user will choose it over the status quo. Functionality, security, usability, etc. But users also worry that if they spend time with a product, will it be there for them in the long-term? This is not an abstract concern, but involves real questions such as, what happens to their data if the company goes under? Will the application be updated frequently so that it keeps pace with general technology trends? How much time, effort and money would it take for them to transition out?

So startups have some convincing to do. There are many ways, such as providing easy import/export and being very transparent with their user community. But if the general trend in the market is that the older, larger company keeps gobbling up smaller competitors, then the likelihood of the average startup being around becomes lower. If the frequency of such occurrences is high enough, consumers will skirt away from products offered by new startups. And so it hurts the developers of startups in the future.

But as you can see, there are different contrasting trends. The higher likelihood of getting bought out increases the inflow of developers. But the lower likelihood of succeeding with your startup can drive away developers to market sections that do not have this problem. One event (as in the Sparrow acquisition) gives us little data to work on. We could ask questions, such as, are all the complaining Sparrow users less likely to purchase the product of another independent developer? Or are they angry enough at Google to encourage other independent competitors by purchasing their products? Not clear.

The general topic is also the subject of government regulation, as in anti-trust legislation. This is one tool that consumers can use (via elected officials) to prevent acquisitions that serve only the purpose of the larger company or prevent an effective monopoly. Whether they are used effectively depends on the quality of governance. But the intent is clear: There is a clear loss to the larger society when larger companies use mergers and acquisitions to destroy competition and stifle innovation. Whether such transactions are mutually beneficial (to the parties involved) or whether they deserve the benefits are independent issues to the societal effect.