Business

From Shop Class as Soulcraft,

Given their likely acquaintance such a cognitively rich world of work, it is hardly surprising that when Henry Ford introduced the assembly line in 1913, workers simply walked out. One of Ford’s biographers wrote, “So great was labor’s distaste for the new machine system that toward the close of 1913 every time the company wanted to add 100 men to its factory personnel, it was necessary to hire 963.”

A dozen years ago people would talk of building “software factories” to crank out software projects. Back then someone tried to get me excited about joining an effort to create such a factory. I told him I did not want to work in a factory. He tried to back-peddle, saying that it’s not what it sounds like. But I’m sure it was exactly what it sounded like.

Alex Tabarrok brings up an interesting question: Why should all patents have the same length?

Pharmaceuticals are really the classic case of where the [ratio of] innovation-to-imitation costs are extraordinarily high. It costs about a billion dollars to create a new pharmaceutical. The first pill costs a billion dollars; the second pill costs 50 cents. So, that’s a classic case where imitation costs really are low. That’s the best case for patents, in a field like that.

But my question is: Why does every innovation deserve or require the same 20-year patent? Why do we have a system which gives a one billion dollar pharmaceutical–where there’s $1 billion in research and development costs–we give that a 20-year patent and one-click shopping gets the same 20-year patent? That makes no sense whatsoever.

So, what I suggest is a more flexible system. I’d like to have a 20-year patent, maybe a 15-year patent, maybe a 3-year patent. Something like that. And then we could say: You want to apply for a 3-year patent? We are going to get this through the system quickly; we won’t look at it so much. … You want a 20-year patent, though, you’d better show us that you really are deserving and put some costs in there.

Source: EconTalk

I don’t like software patents, though I don’t see them going away. But it might be possible to pass legislation to reduce the length of software patents.

See also this post about the tragedy of the anti-commons. The tragedy of the commons is misuse of a resource nobody owns. The tragedy of the anti-commons is the under-use of a resource that too many people own.

Building a DVD player requires using hundreds of patented inventions. No company could ever build a DVD player if it had to negotiate with all patent holders and obtain their unanimous consent. … Fortunately, the owners of the patents used in building DVD players have formed a single entity authorized to negotiate on their behalf. But if you’re creating something new that does not have an organized group of patent holders, there are real problems.

Many so-called leadership positions are followship positions.

One way musicians learn to conduct is by conducting recordings. We did this at drum major camp back in the days of vinyl albums and cassette tapes. That’s OK for teenagers who are just learning the basic motions of conducting, but it’s not how real conductors are trained.

When you conduct a recording, you’re not leading, you’re following. Conducting recordings teaches you implicitly to expect to be ignored. Real conductors train by conducting a pianist or a small ensemble. They expect to be followed, and they learn the consequences of their actions.

I use followship to describe inverted leadership. This happens when someone appears to be leading when in fact they’re following. Conducting a CD is followship. So is managing a team by keeping records of what the team has done rather than giving direction. Supposed leadership positions in business are often followship positions.

Followship is reactive, not interactive. Imagine an orchestra recording a CD. The musicians in the studio follow the conductor in a fundamentally different way than the music student following the CD. The musicians interact with the conductor. The student doesn’t interact with the CD.

Followship is not simply bad leadership. Followship is passive. Bad leadership is active.

When I was drum major in high school, one night I started our half time show way too fast. The color guard dropped their rifles several time during the performance and it was my fault. Their routine could not be performed at the tempo I had set. That was bad leadership on my part, but it was genuine leadership because the band followed my lead.

Leadership mistakes are embarrassing, but followship is even more embarrassing. It’s easier to admit a mistake than to admit being ineffectual.

Related post:

Engineering route to accounting

In a discussion on Google+, Daniel Lemire argues that engineers end up essentially being accountants.

Engineering, at least how it is practiced in North America, is hardly very exciting. … By the time you have your degree, you have 5–10 years to go before, if you have any ambition, you end up a manager of some kind, doing more or less what your friends who went into accounting do. … No, you don’t get to build anything, technicians do that … you only approve their expense reports …

Of course there are exceptions, but the career path Daniel describes is common. And it’s not unique to engineering. It’s a sort of variation on the Peter Principle. Many people find themselves approving expense reports for people who do the work they enjoy doing, or used to enjoy doing.

What can you do if you want to avoid going into management/accounting? Here are a few ideas.

• Be content with a lower salary.
• Work for smaller companies.
• Work for specialized companies, e.g. an engineering firm.
• Go out on your own (but watch out for the e-myth).
• Spend a lot of time searching for a job.

Related posts:

Catalog engineering and reverse engineering
Decentralized knowledge, centralized power

Here are a few thoughts on institutional memory from a talk by Admiral Hyman G. Rickover.

When important decisions are not documented, one becomes dependent on individual memory, which is quickly lost as people leave or move to other jobs. In my work, it is important to be able to go back a number of years to determine the facts that were considered in arriving at a decision. This makes it easier to resolve new problems by putting them into proper perspective. It also minimizes the risk of repeating past mistakes.

I’ve never seen this done effectively. I’ve been part of business and non-profit organizations that kept good records, but I don’t recall anyone ever looking back through the records to review why a decision was made.

This is especially a challenge in software development where the myth of progress runs so strong. Newer is always better. The people before us were stupid, so why should we go back and read what they thought? Or maybe they weren’t stupid, but they were working with version 10.5 of FooBar. Now we’re up to version 11.2 and so everything has changed.

Related posts:

Medieval project management
Sheet music, DNA, and source code
Do you really want to be indispensable?

A few weeks ago, J. D. Long gave some interesting advice in a Google+ discussion. He starts out

Lunch today with an analyst 13 years my junior made me think about things I wish I had known about the technical analytical profession when I was 25. Here’s some things that popped into my head:

The entire list is worth reading, but I want to focus on two things he said about tools.

• Use tools you don’t have to ask permission to install (i.e. open source).
• Dependence on tools that are closed license and un-scriptable will limit the scope of problems you can solve. (i.e. Excel) Use them, but build your core skills on more portable & scalable technologies.

I would have disagreed a few years ago, but now I think this is good advice.

In the late 90’s I used mostly Microsoft tools. That was a good time to be a Microsoft developer. Windows was on the rise; Unix and Mac OS were on the ropes. Desktop applications were the norm and were easier to write on Windows. Open source software was hard to install and hard to use. People who used open source software often did so for ideological reasons, not because it made their work easier.

Of course times have changed. Mac recovered from its near death experience. Unix didn’t, but it has been resurrected as Linux. The web made it easier to write cross-platform software. And above all, open source software has matured. The open source community is more positive, focused on promoting good software rather than trying to give some corporation a stick in the eye.

Now the advantages of open source are clearer. There’s not the same hidden cost in frustration that there was a few years ago. Now I would say yes, it’s a great advantage to use tools you can install whenever and wherever you want, without having to go through a purchasing bureaucracy.

It’s interesting that JD equates open source with scriptability. Open source software often is scriptable, not because it’s open source, but because of the Unix aesthetic that pervades the open source community. Closed source software is often not scriptable, not because it’s closed source, but because it is often written for consumers who value usability over composability. Commercial server-side products may be scriptable. If I were to restate JD’s advice on this point, I’d say to keep composability in mind and don’t just think about usability.

I appreciate JD’s attitude toward applications such as Excel. He’s not saying you should never defile your conscience by opening Excel. Some tasks are incredibly easy in Excel. The danger comes from pushing the tool into territory where other tools are better. There are still some in the open source community who believe that opening Excel is a sin, but I’m much more in agreement with the people who say, for example, that Excel isn’t the best tool for statistical analysis.

Portability is funny. In the early days of computing, there were no dominant players, and portability was important (and difficult). Then for a while, portability didn’t matter if you were content with only running on the 95% of the world’s computers that ran Windows. Now portability is important again. Windows still has a huge market share on the desktop, but the desktop itself is losing market share.

And portability matters for more than consumer operating systems. JD mentions portability and scalability in one breath. You may want to move code between operating systems to scale up (e.g. to run on a cluster) or to scale down (e.g. to run on a mobile device).

There’s also the aspect of career portability. You want to master tools that you can take with you from job to job. I would be leery of building a career around a small company’s proprietary tools. If I were in that situation, I’d learn something else on the side that’s more portable.

In closing, I’ll give the rest of JD’s career advice without commentary. These points could make interesting fodder for future blog posts.

• Be a profit center, not a cost center.
• Use tools you don’t have to ask permission to install (i.e. open source).
• Dependence on tools that are closed license and un-scriptable will limit the scope of problems you can solve. (i.e. Excel) Use them, but build your core skills on more portable & scalable technologies.
• Learn basic database tools.
• Learn a programming language.
• Your internal job description may say, “Analyst” but get something else on your business cards. Analyst is so vague as to be meaningless. My external title is currently “Sr. Risk Economist.” I like the term “Data Scientist” for now. I expect that term will be meaningless in 5 years.
• Large organizations do not properly appreciate agile and smart analytic types. Time at large firms should be seen as subsidized learning. Learn lots, but get out.
• Ensure you can explain any of your projects to your wife or non-technical friends. It’s good practice for board meetings later in your career.
• Be sure you know the handful of things that you can do better than most anyone else. Add something to that list every year. Make sure you can explain these things to non techies.
• Be a profit center, not a cost center. At least be as close to the profit center as possible. The chief analyst for the sales SVP is closer to the profit center than an IT analyst supporting billing operations.
• Get really good at asking questions so you understand problems before you start solving them.
• Yes, that bit about being a profit center not a cost center is in there twice. It should probably be in there 5 times.

“A college degree shows you can finish something.” I’ve heard this forever, but I don’t believe it. Of course a college degree shows that someone finished one thing, namely a college degree. But I don’t think that’s the best predictor of whether someone will finish something else.

College provides a great deal of support: accountability, frequent feedback, a community of peers, etc. Succeeding in this environment is an accomplishment, but it doesn’t necessarily demonstrate that someone can succeed in a less supportive environment. It also doesn’t necessarily indicate that someone can focus on a project that takes more than a semester to finish.

Here are a few things that might be better indicators of initiative and persistence.

• Learning a foreign language as an adult
• Losing 50 pounds
• Learning to play the oboe
• Quitting smoking
• Reading Churchill’s history of WWII
• Starting a business
• Running a marathon
• Writing a book

Employers that use college degrees as their only filter on applicants are missing out. An ideal candidate would have a college degree and some proof of independent achievement. But given a choice between someone with only academic credentials and someone with only independent accomplishments, the latter may be a better hire.

Related post:

Picking classes

This afternoon I saw a fire truck with the following written on the side:

Staffed by professional volunteers

Of course this is an oxymoron if you take the words literally. A more accurate slogan would be

Staffed by well-qualified amateurs

A professional is someone who does a thing for money, and an amateur is someone who does it for love. Volunteer fire fighters are amateurs in the best sense, doing what they do out of love of the work and love for the community they serve.

Unfortunately professional implies someone is good at what they do, and amateur implies they are not. Maybe skill and compensation were more strongly correlated in the past. When most people had less leisure a century or two ago, few had the time to become highly proficient at something they were not paid for. Now the distinction is more fuzzy.

Because more people work for large organizations, public and private, it is easier to hide incompetence; market forces act more directly on the self-employed. It’s not uncommon to find people in large organizations who professional only in the pecuniary sense.

It’s also more common now to find people who are quite good at something they choose not to practice for a living. I could imagine three ways the Internet may contribute to this. First, it makes highly skilled amateurs more visible by giving them an inexpensive forum to show their work. Second, amateurs have access to information that would have once been readily available only to professionals. Finally, the Internet has reduced the opportunities to make money in some professions. Some people give away their work because they can no longer sell it.

Whether a person is a “jack of all trades and a master of none” depends on how you define trades. The same person could be a dilettante or a specialist depending on your mental categories.

Take an expert programmer back in time 100 years. What are his skills? Maybe he’s pretty good at math. He has good general problem solving skills, especially logic. He has dabbled a little in linguistics, physics, psychology, business, and art. He has an interesting assortment of knowledge, but he’s not a master of any recognized trade.

Is a manager a master of one trade or a jack of several trades? Obviously if you recognize management as a profession, then someone who is good at it is a master of that trade. But if you don’t have the mental category of manager, what is a manager good at? She knows a little psychology, a little sociology, a little math, she has good communication skills, etc. But she’s a jack of all trades and master of none unless you have a name for her trade.

Calling someone a jack of all trades could be a way of saying that you don’t have a mental category to hold what they do.

Related post:

Too much time on their hands

Paul Graham argues that people take bad jobs for the same reasons they eat bad food. The advantages of both are immediately apparent: convenience and immediate satisfaction. The disadvantages take longer to realize. Bad jobs drag down your soul the way bad food drags down your body.

I first read Graham’s essay You Weren’t Meant to Have a Boss when he wrote it three years ago. I read it again this morning when I saw a link to it on Hacker News. I found his thesis less convincing this time around. But he makes two general points that I think I missed the first time.

1. Watch out for things that are immediately appealing but harmful in the longer term.
2. Watch out for being part of someone else’s scalability plans.

The first point is familiar advice, but worth being reminded of. The second point is more subtle.

Companies sell bad food for the same reason they offer bad jobs: it scales. It’s easy to create bland food and bland jobs on a large scale. Fresh food and creative jobs don’t scale so well.

When you choose to eat junk food, you more or less consciously choose convenience or immediate satisfaction over long-term benefit. But it may not be obvious when your range of options has been selected for scalability. For example, few students realize how much the educational system has been designed for the convenience of administrators. Being aware of an organization’s scalability needs can help you interact with it more intelligently.

Related posts:

Stupidity scales
Corporations and Hanlon’s razor
Appropriate scale

Emerson was wrong. The world will not beat a path to your door just because you build a better mouse trap.

No busy, overstressed, fire-putting-out, content-with-the-product-they-have-now person really wants to hear from you. Even when you do build a better mousetrap, the world thinks you’re a giant pain in the ass. Nobody has the time, nobody has the patience, nobody wants to take the risk that your claims are exaggerated … We have to be invited in or we never get to tell our tale.

From Why Johnny Can’t Brand.

Not only does this apply to consumer and business products, it applies to science as well.

Related post:

Getting women to smoke

Here’s something I wish I’d understood early in my career. From Merlin Mann:

If a project doesn’t have an owner, it’s like a chainsaw on a rope swing. Why would anyone even go near that?

Related posts:

Priorities
Project management tip: destroy hope
Manage your project portfolio

Seth Godin uses linchpins as a metaphor for people who are indispensable. These people hold things together much as a physical linchpin holds together a mechanical system. But the metaphor works in a couple ways that I don’t believe the author intended.

First, linchpins are invisible. When was the last time you looked at a complex mechanical system and your eyes were immediately drawn to a linchpin? People who hold things together are often unsung heroes. They do such a good job that they don’t draw attention to themselves. People who prevent fires are harder to notice than people who put out fires.

Second, and more importantly, linchpins have to stay in place. Remove a linchpin and something comes apart. A human linchpin can never be promoted or work on new projects because they’re indispensable right where they are. Managers may show their appreciation for a linchpin, or they may react out of fear and resentment when they realize their dependence. They may even do a weird mixture of both.

Seth Godin’s Linchpin book was a fun read. I just wish he had picked something other than linchpins as his metaphor for people who are highly valued. And I wish he hadn’t used the word “indispensable.” Too often indispensable people are not highly valued.

Related posts:

Do you really want to be indispensable?
It doesn’t pay to be the computer guy

Eric Floehr is the owner of ForecastWatch, a company that evaluates the accuracy of weather forecasts. In this interview Eric explains what his business does, how he got started, and some of the technology he uses.

[click to continue...]