Mixu's tech blogWhen I read what I write I learn what I think

People have an interesting tendency to believe that best practices do not apply to them. In this post I discuss the “I’m special so I should write my own web framework” case.

Take for instance:

1. Writing a CV. Best practice states that shorter is better, but oh so many people still want to have an eight-page CV because they are special.
2. Web frameworks. Best practice states that using an established, documented and supported framework is better, but look at the proliferation of different MVC frameworks, ORM systems, CSS frameworks et cetera. And these are just the published examples: there are many many more in private use, because the authors were special and had special needs.
3. Pitching. Best practice states that you should rehearse, keep your presentation short and focused, you should do market research and you should not rely on “chinese math”. Yet we have tons of pitches which are not rehearsed, overly long, unfocused, unresearched and based on lazy assumptions – because people expect to succeed because they are special.
4. You can probably think of ten more examples pretty quickly.

Why oh why do we have to be in this situation? Can’t other people figure out that we don’t care about their overly long CV, their self-authored web framework and boring, unrealistics pitches?

The “I’m special” excuse

I hate the excuse that someone is special, and therefore does not need to follow good advice. And yet I find myself compelled to, for instance, write my own web framework. 

As always the problem is other people. And the worst thing is that to other people, you are another person!

I will stick with the web frameworks example, because it is so common and easy to recognize as a problem.

Writing your own web framework – are you really that special?

Why on earth would anyone want to reinvent the wheel by writing yet another web framework? The justifications I think come down to one of:

1. Speed. The existing web frameworks are slow, because whomever wrote them was either incompetent or because they included the kitchen sink with their framework.
2. Ease of coding. The existing web frameworks are horribly documented, and you prefer to reinventing the wheel to reading API documentation.
3. Unique problems or novel ideas. You have a really unique problem or a really innovative new idea, and the existing frameworks do not support it.
4. Learning experience.

And here are the reasons why you shouldn’t be doing it:

Speed.

Assume for a moment that all other developers are not incompetent (I know, it’s a huge jump for someone as special as you!). This implies that the reason frameworks are slower is that they have more features, which inevitably increases execution time. Thus you can quite safely assume that by the time you reach the same level of functionality as any top-tier web framework, you will be equally slow or slower.

The only way you will reach that point and know for sure is through grueling reinvention of the wheel.If you want certainty about performance, pick a reasonably fast existing framework and go make it slower by adding your own functionality. As Don Knuth said: “We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.”

How many times have your customers called you and complained about performance? I’m not saying that performance does not matter – it clearly does – but this isn’t likely to be the most significant business, or even technical problem you encounter.

Ease of coding

The lack of documentation is in my humble opinion a valid criticism of existing frameworks. While some documentation and tutorials exist for existing frameworks, the state of documentation in PHP web frameworks is rather bad.

However, how well documented is your own framework? You will be familiar with it when coding it, but what about five years from now? What about the other people you will want to add if your project succeeds?

Unique problems or novel ideas

How unique are your problems? Most of what web applications is a variation of a theme rather than a wholly novel problem. In fact, I have a hard time thinking of a counterexample. It is true that some frameworks make working with complex backend logic harder – but this is more a matter of picking the right framework; having the perfect framework won’t still make the backend logic any more simple.

Is your novel idea actually useful? Imagine that you had built that crazy new framework with that neat idea – how much time would it save you in practice?

I’m pretty convinced that this reason is in fact just an excuse for not liking the aesthetic feel of whatever frameworks were evaluated, rather than a real reason. The core reason is that whatever you are doing is complex, and having your own framework will only provide a slight relief at a huge maintenance cost.

Learning experience

I think this is a legitimate reason. There is no substitute for learning by doing – but if you deploy that code into production, you are no longer learning: you have gone into the business of framework maintenance.

I’ve spent a reasonably amount of time looking at the various blogs writing about how to evaluate entrepreneurial ideas. Market size, first mover advantage and the idea of a hot or trendy business model are often mentioned as key factors, but I would argue that their impact is not quite as straightforward as some would argue.

1. Market size != potential for success

It is better to go for a credible-sized opportunity instead of a lemonade stand. However, counting on the idea that the company “only” needs to capture a small percentage of a large market is often a cop-out from coming up with an actual plan which relies on some kind of genuine advantage. In the long run, it is probably better to be a big fish in a small market rather than a small fish in a big market, given that as one of the “best known brands” in a market one can often achieve a sustainable position among pragmatist customers.

Saying that you have a 500 billion market and only need to capture 0.01 percent doesn’t mean you are in a better position than someone aiming at capturing a larger percentage of a smaller market. It is often true that the bigger the market, the easier it is to find customers – but larger markets also frequently mean more competition, lower dollar amounts per sale, a more heterogeneous set of customers, larger advantages for being established in that market and larger capital requirements.

2. First-mover advantage != potential for success

I read about this so often it makes me sad. Having first-mover advantage isn’t really as great as it might intuitively seem. I am pretty sure that the obsession with being “first” to do something is more hurtful that useful. When people talk about “first mover advantage”, what they actually mean “first-successful-mover advantage”: being first to come up with an idea that was possible to scale profitably.

To me, that is not really about being there first, it is about being there at just the right time to get the product out to match the overall trend (in technology development, in market terms) to succeed.

Pioneers are the ones with arrows on their backs. They may have to develop a technology and a market for a long while just to find that a “fast-follower” gets there at the right time to capitalize on their work. Fast follower and first-to-market are both valid models for building a business, and not being there first may have it’s advantages. Paul Tyma has an awesome anecdote on this:

“One of my favorites was [..] the idea of selling a new product that creates a brand-new niche – often a very difficult task.

He likened it to the first person that had to break ground selling thermometers. Not the “How’s the weather” thermometers, I mean the “Do you have a fever thermometers”. Surely nowadays these are digital little gizmos, but when they came out they were the old-fashioned mercury based ones.

I can imagine the sales-pitch:

Customer: So, whats it good for?
Salesman: It will tell you your temperature.

Customer: Why do I care about that?
Salesman: Well, then you will know when you have a fever.

Customer: Um. I already know when I have a fever.
Salesman: Yeah, but now you’ll be sure.

Customer: Erm.. k.. What’s it made of?
Salesman: Glass

Customer: Whats that stuff inside it?
Salesman: Mercury – careful, its toxic.

Customer: How do I use it?
Salesman: You just put it in your butt for 2 minutes.

Customer: Um. So basically, you want me to take this toxic-substance filled thermo-thing made of breakable glass, stick it and leave it in my butt for 2 minutes so that I’ll know something I pretty much already knew.
Salesman: Yepper.

Customer: Awesome – I’ll take 2 !

That had to be a hard job. Solve a problem that was perceived as not needing solving and then do it in a new, dangerous, and highly uncomfortable way. “

3. Hotness/next big thing != potential for success

Being told that China is the next big thing, or biotech is the next big thing, or that energy and food is the next big thing is really only good if you are in those specialties. Chasing the next big thing just because someone thought it might be great is hardly a winning strategy.

Next big things have a wide margin of error in terms of timing and in terms of actually coming to fruition. Pursuing a trendy area of enterprise might find it easier to get funded, but that has little to do with actual success. Tools for Twitter might be the hot market now, but is it a good business to be in? For some, perhaps, but is it any better than some non-trendy market if you are thinking betting into it now? Not necessarily.

Factors that might actually matter

So what might actually matter? Here are a few good factors from experienced entrepreneurs/VC’s:

James L. Woodward (here):

• “Do you have an experienced team that knows the industry inside out?
• Do you have an overwhelming and defensible advantage?
• Is your market the right size?

These remain the keys, with people, always people, first. And remember, that while the second point implies some sort of technology advantage, technology is not the primary driver of successful companies. “

Philip Greenspun (here):

“Don’t start your own company because you want to be your own boss. There are three ways in which a company can make more profit than an investment in a Vanguard S&P 500 index fund:

1. You know how to do something that nobody else can do (the typical MIT tech spinoff approach)
2. You have a lower cost of capital than anyone else (the “my dad was really rich” approach taken by Bill Gates and others)
3. You have a better understanding of one kind of customer than anyone else.”

I think the most amazing thing about spectacular project failures is that they happen one day at a time. How do you get 170 million USD over budget? One day at a time.

Given the size of many of the largest failures (hundreds of staff members), there have had to be a number of people who recognized early on that the project was not going as it was supposed to. And still, someone made the decision to continue! In the FBI virtual case file project linked to above, the US Congress approved another $123.2 million for a project whose total cost would now be $581 million (instead of $458 million).

If the project is late and you are asking for, you know, a hundred and twenty million more, I would expect that someone would ask whether the whole project should be re-evaluated. But a re-evaluation didn’t happen until well over a year later. There is something patently absurd about that. Reminds me of Bil Dwyer’s fifteen wives clip on Comedy Central: “Imagine the nerve to look around at your fourteen wives and think to yourself … one more.” . A hundred million $ more, and were done.

Why does this happen?

I’d attribute the failure to re-evaluate the project to number of cognitive and organizational biases. Obviously, the cause of the failure itself may not be the biases, but rather the things that were done by those responsible for the project. But when you go over the budget and deadline and seem to be far away from achieving the original goals, why isn’t the project cancelled or re-chartered?

In an article (available here and also discussed here) Shore (2008) summarizes a number of cognitive biases as shown in the table below:
(Shore, B (2008). Project Management Journal, Volume 39, Issue 4 p. 5-16)

“We can still do this”

The specific bias are not as important as the overall dynamic that causes failed projects to continue. Whether it is sunk cost, conservatism or illusion of control, the bias cause those responsible for the project to believe that they can still salvage the project, that all is needed is a bit more time, resources or people.

Bringing about epic failure by avoiding the perception of failure

There is a good reason for this. Most people consider revising the project goals to be an admission of failure which reflects badly on their careers and competency, hence preferring to stick to their guns. This may work in some smaller cases of failure and in cases where it is possible to trade quality for productivity, such as “homework” -type written assignments. But for projects where the quality is discernible, the number of people involved is large and increasing the number of people makes the project less likely to succeed – such as IT/IS projects – doing more of the same (which is the first reaction) is just not the answer.

As Steve McConnell said about project recovery:
“Remember, the real problem at this stage is not developing the product in the shortest time possible or creating the best possible product: it’s completing the product at all. [...] If you’re caught in the middle of a political skirmish rather than a product development, the project-recovery plan [...] won’t be of much help, and you should choose your actions accordingly”.

Doing what can be done

Here is a brief four-step program for doing what can be done to rescue a failing project. More details can be found elsewhere!

1. Reassess the overall situation and pinpoint obvious problems. Any 12-step program begins by recognizing the problem. Without that, one ends up doing exactly what McConnell said: chasing the fastest completion or the best product, both of which are unlikely to be accomplished.
2. Revise your goals. Since you have shown that you cannot do what you attempted to do, revise what you are aiming to do so that at least something can come out of the project. Set your goals to something more achievable.
3. Restore morale. A important point in failed projects is that you are likely to be facing a morale problem already. While the “official” recognition of failure is sudden, many people are already overworked and demoralized. Do what you can to fix the people problem before continuing.
4. Track the project meticulously to avoid sliding back into the abyss. If you don’t get strict, you will continue to fail each day. As said earlier, spectacular failures result from day after day of slips. So stricter tracking of progress is the only way out of the abyss. Otherwise, the same slips that got the project here will continue.

There was an interesting quote on the “Diary of a Failed Startup“:

“How do you tell if you really are doomed?” – “If nobody cares about what you’re doing and nobody on your founding team cares enough to change that, then you’re probably in trouble.”

Here is pet peeve of mine: why is calling something “subjective” an acceptable way of not answering a question? In particular, with technical people, “subjective” seems to mean “not worth answering, because there is no correct answer”.

“Avoid asking questions that are subjective, argumentative, or require extended discussion. This is not a discussion board, this is a place for questions that can be answered!” (Stack Overflow)

Now I do not have a problem with the fact that in order to be successful, a site will need to maintain focus. And I have nothing against Stack Overflow, I am just using it as one example of the mentality where subjective somehow equates to bad.

What is “subjective” and what is “objective”?

“In philosophy, an objective fact means a truth that remains true everywhere, independently of human thought or feelings. For instance, it is true always and everywhere that ‘in base 10, 2 plus 2 equals 4′. A subjective fact is one that is only true under certain conditions, at certain times, in certain places or for certain people.” (Wikipedia)

I appreciate the importance of striving for objectivity, but if this is the definition of objective in day-to-day discussions, then I don’t think I would want to read very many objective answers.

If “objective” means “true everywhere”, then whatever can be said about the world in objective terms is likely to be very boring. If this is the criteria for objectivity (and presuming objective is the opposite of subjective), then an objective question with an objective answer is one where there is only one answer to a particular question.

The better part of the world is subjective

Grouping “subjective” with “argumentative”, “requires extended discussion” and “a question that cannot be answered” is just wrong.

How often do you see discussions in which all the necessary criteria for objectivity are filled? The number of interesting, relevant and really cool things to discuss for which any answer is bound to be true “only 1) under certain conditions, 2) at certain times, 3) in certain places OR 4) for certain people” is enormous.

Nevertheless, we are still very hypocritical about this, pretending that the difference between subjective and objective is clear-cut and black-and-white. Many textbooks that tell you “avoid subjective criteria in doing X”. What they hopefully mean to say is “don’t ignore the facts while doing X”. Don’t just do whatever the hell you want to do, do something reasonable. Which is far away from “objective”.

“It’s subjective” is just a cop-out

You can weigh different factors and think about the possible consequences of doing something. But in the end, the decision is subjective. You need to make a judgment call, because you never have all the facts nor do you have complete certainty. Therefore, given sufficient complexity, whatever you decide is bound to be only true under (at least) one of the four conditions above.

Sometimes various weighting and decision criteria are used to come up with a “objective” approach. But who came up with the criteria, the weights, and would they always apply? Don’t call it “objective”. Perhaps consistent, or transparent. But not “objective”.

Why binary thinking tends to dominate among technical people

It’s a false dichotomy – subjective/objective is a continuum. There may be good criteria for “objective”, but they cover so little that we are mostly dealing with varying grades of “subjective”. This reminds a lot of something Eric Sink said about why it is difficult for technical people to spot business opportunities:

“All of our training and experience happens in a world where there are no grays. A digital bit is either one or zero, on or off, nothing in between. This binary thinking tends to pervade the way we look at everything, including business opportunities. But not everything in the business of software actually works that way.

When we discuss the potential of a new product idea, we tend to believe that the product will either sell it or won’t. But markets don’t work that way. We ask ourselves, “Will people buy this product?” Instead, we should be asking, “How many people will buy this product?” The difference is pretty important. I claim that every well constructed product will be purchased by someone. The only question is how many people will buy it every year. “

All people consistently short-change the future in order to get present gains (or some people, sometimes – doesn’t matter). I don’t mean the kind of monetary things, where you will eat one candy today rather than a bag tomorrow – I mean in terms of time.

What you don’t do in the beginning will bite you in the ass later

Take any project. The stuff you don’t do well in the beginning because you were so anxious to move on or could not be bothered to do WILL turn out to be a big deal in the end if things don’t go according to plan. And things never go according to plan.

The funniest thing is that when things go to hell, our natural reaction is to make more short-term tradeoffs looking for a quick fix (like add new methodologies, add more people, add more pressure).

Pay more attention in the beginning, before you are screwed. And if you are screwed, stop doing what you are doing, and give your project a real reboot.

Seek victory from the situation you choose to be in

Sun Tzu said: “A skilled commander seeks victory from the situation and does not demand it of his subordinates.” This seems to contradict my previous statement about planning, since plans as they are understood are pretty much about demanding something from other people.

Wrong. The way I interpret this, Sun Tzu is saying “don’t have a point in your plan which says you will perform at a superhuman level and thus succeed”. Superhuman performance is at best a bonus for plan for which you have done that preceding legwork to ensure that other things: the environment, the customers, the competition and the governance structures are just right so that screwing up a bit will not kill you. Die because you did not execute, not because you did not care to look at the situation you are entering.

What do you hate doing?

My points is, there are many things which are both unpleasant to do and very effective when done early enough. Here, early enough = voluntarily, not forced by the situation.

One of those things is thinking things through, writing them down and arranging ideas in order to explicitly clarify our own thinking.

We tend to like to think of ourselves as intelligent, thinking beings, but the extent of our thoughts is in fact often surprisingly shallow and random. We trust that we know while assuming many things.

For example, in research, it is easy to read promiscuously — and to believe that that by itself will help increase our understanding. But I doubt that it is true – leaving the development and synthesis of ideas to some random blink of genius is a doubtful idea.

Managers tend to be victims of their own success. As Andy Grove (long-time Intel CEO and president) notes: “Looking back over my own career, I have never made a tough change, whether it involved resource shifts or personnel moves, that I hadn’t wished I had made a year or so earlier. [...] This tendency is easy to see in others although we are prone to blindness when we do it ourselves.”

Make sure you fail for the right reasons

I don’t think I can put it better than how Ian Landsman put it:

“Here’s the big secret on how to do this and fail for the right reasons. Your pre-planning needs to be 100% focused on making your success or failure about the execution. So you need to plan away those things that are not execution related. It’s really not that hard to do. Make sure you can survive for enough time to see if it works out.”

Given that I have spent some time studying expertise from an academic perspective, I figure it would be good to summarize some of the things we know about experts and the process of developing expertise. Keep in mind that academic studies will rarely give you the simple answer – there is none. But what they can reveal is the chain of factors that, if done right, will lead to better results.

Experts don’t process faster, they process better

Classic studies such as de Groot (1965) and Chase & Simon (1973) have shown that experts in chess do not consider more moves as much as they consider better moves and have a better knowledge (memory) of real chessboard configurations.

The effect of domain-specific knowledge is shown in the observation that chess experts do not perform any better at remembering random chessboard configuration but perform significantly better at remembering chessboard configurations from real games. However, the distinction between knowledge and processing ability is not as simple as it seems initially. Chess experts for example remember features relevant to the game better – they have learned to identify the most significant patterns in a chessboard configuration.

That is, their higher performance is a result of a superior processing strategy. Thus, to be an expert, you should improve your processing strategy – it is not about having more raw brainpower but rather having developed better mental models (schema) to process problems. As Detterman & Spry (1988) point out:

“It is highly unlikely that graduate student performance would correlate with IQ, because graduate students have been so intensively selected on the basis of intelligence that other factors become increasingly important. [This] does not mean that intelligence is not important. [C]ompared to that of the general population, graduate students would have a substantially higher IQ. [I]f graduate students were selected randomly from applicants [...] a relation between IQ and graduate school performance would be obtained. Samples that have a high degree of selection must be examined closely when discussing validity.”

In other words, in a select group of people, non-IQ factors are emphasized more because simply being able to do a particular activity entails a level of selection. To be really good, you need to differentiate based on other factors. (This comes up interestingly in executive training, where rather subtle soft skills are emphasized over other things. I suspect this is because the high degree of selection does not leave space for incompetence in less subtle areas.)

The example of two teachers

How does such a superior processing strategy come about? Scardamalia & Bereiter (1993) give the example of two teachers who begin their careers fresh out of college.

In their example they demonstrate the development of the teachers in terms of the skill development strategy the two teachers take. Initially, both teachers experience similar problems and have essentially the same list of difficult problems to solve. For example, maintaining order in the classroom, organizing their teaching material and keeping track of homework.

As they learn while working they address the problems on the top of the list (such as maintaining discipline) and can remove the problem from their lists by developing an effective routine for dealing with (e.g. shout at the top of their lungs – I don’t know, I’m not a teacher) or preventing the issue.

However, the key difference between the two teachers – who both are doing good at this point in their careers – is that while one of the teachers is simply reducing the number of problems without revising the goals of her efforts, the other teacher is setting new goals as she is more able to cope with her initial problems.

Problem reduction versus progressive problem solving

In other words, simply knowing more does not make you an expert. If your learning goal is to get rid of all the problems in your day-to-day work – rather than to both solve those problems and add new, tougher problems on the other end – you are becoming a specialist in dealing with those particular kinds of problems.

The problem-reduction approach taken by the first teacher in the example is a typical example of normal adaptation to an environment. Initially, the problem-reducing teacher is challenged by the environment, but as she learns more she is less and less challenged by daily events in her environment. She is able to get the kids to shut up and sit down, and life gets easier each day.

The problem-reducing approach distinguishes experienced people from less experienced people, but does not result in expertise as much as adaptation. At some point, the first teacher can essentially handle a set of routine problems without a lot of challenge. However, they will never start tackling the heavier issues, such as how to get a student with a learning difficulty to learn better. The teacher who took the progressive problem solving approach by setting new goals continues to advance towards expertise in her profession.

Reinvesting in learning

As Scardamalia & Bereiter (1993) point out, the experts skill development strategy is characterized by reinvestment of effort into the work instead of simply reducing the amount of effort taken by the work. The authors argue that the general characteristics of expert skill development through progressive problem solving are:

1. Reinvestment in learning. As the learner needs to spend less effort in achieving the same performance, the reduction in effort is used in learning, thus resulting in continued improvement.
2. Seeking out more difficult problems. The learning effort is not simply characterized by a quantitative change in the amount of effort required to solve the problems – it represents a qualitative change in the type of problems and knowledge requited to solve them.
3. Tackling more complex representations of recurring problems. Initially, many problems are represented in a simplified form in order to cope with the demands of the environment and task at hand. However, as expert learners develop, the aim to reformulate the problem more specifically, allowing them to deal with the problem with greater flexibility. (For example, rather than coercing compliance from difficult students, the teacher recognizes and begins to address the underlying learning problems.)

The skill development strategy leading to expertise differs from the one leading to non-expert performance in that it requires that the learner not only improves in performance but also that he or she continues to set new goals and new targets, and that the improvements in performance are used in order to address ongoing issues at a greater level of depth. This process is principally internally driven and motivational processes play a major part in enabling expert skill development.

Different kinds of learning goals

The different orientations of expert and nonexpert students can be expressed quite well in terms of goals. Scardamalia & Bereiter (1993) suggest three different types of goals which different kinds of learners use to guide their actions:

1. Task accomplishment goals. Task goals are focused on performance on a particular task or activity; learning is incidental.
2. Instructional goals. Instructional goals are based on explicit or inferred learning objectives which are based on an external standard but go beyond task accomplishment.
3. Knowledge-building goals. Knowledge-building goals are set by the learner him/herself and may include other types of goals but are not limited to them. Knowledge-building goals are usually related to a personal aim to understand a problem or a field of knowledge.

Goals are important because they orient the learner and guide task performance and selection, which lead to action and learning. Ng & Bereiter (1991) studied participants in a programming language learning task and classified their statements based on the criteria above. Knowledge-building goals are progressive and useful, but results from the study show that other factors are important in addition to the goal setting.

Knowledge-building goals were not a direct predictor of performance in the Ng & Bereiter (1991) study. Instead, more important for performance was in the effectiveness in the direction of efforts towards self-set goals – for example by skipping a task which the learner assessed to have little new knowledge to offer.

Do our current educational and instructional systems support the development of better self-regulatory skills?

While some individuals are able to learn the self-regulatory skills and motivational skills needed by themselves, Scardamalia & Bereiter (1993) stress in their conclusion that in order to help learners develop into experts and not nonexpert specialists, our schools and institutions should place more emphasis on supporting knowledge-building – instead of the more traditional task accomplishment based goals exemplified by “educational activities”.

Expertlike learning consists of a specific set of skills which can either be fostered or suppressed in our formal education. In order to help more people to develop into experts, we ought to reconsider the idea of expertise as an end-state and focus more on the process of knowledge acquisition through “expertlike learning”.

The terms “business owner mentality” and “employee mentality”, or, as I prefer, “project owner mentality” and “project worker mentality” are commonly used to describe the difference between effective workers and effective managers. These two mentalities come up in almost any human endeavor of appreciable complexity, and I think it is worth recognizing the difference and looking explicitly at the mentality one approaches any tasks, projects or ideas that one is working on.

The differences

The difference between an owner mentality and a worker mentality is that someone with a worker mentality looks at work as a set of tasks to be done in a given time. The focus, like in prison, is on spending the required time and doing the required and expected things, then clocking in and going home. A project worker mentality implies the expectation that one has a fixed set of tasks, and one’s responsibility ends at doing those tasks. That is, the responsibility is about spending time doing things, not the end-result of the tasks. In contrast, a project owner takes responsibility of the results rather than the specific tasks.

Doing something that has never been done before

I don’t think one has to be a business owner to practice the mentality of ownership. In a simple and predictable project, there might not be such a large difference between these two. However, on a complex project (containing some uncertain and open-ended goals) there is a major difference.

First, they project workers expect to be able to apply a previous formula and succeed. There is a place and time for routines and best-practice-guidebooks, and that is in getting something established run smoother. But blindly applying advice from other people who did something different at a different time with different people is not a route to success. You may think this is obvious. It isn’t. A lot of people prefer to abrogate their decision making responsibility to whatever they are told by someone and pretend that they are not at fault for following faulty advice. In fact, the Internet is full of those people.

Second, they will underestimate the need of informing others about plans. Someone with a project worker mentality will expect to 1) do everything on their own and 2) be able to get things done just by doing what they think are the assigned tasks. However, in many cases you 1) should be thinking about enlisting others and 2) be thinking about new ways to get the result you need. Flying by the seat of you pants is fine if you only care about what you want to do. But the more people are involved, the more there is a need for explicitly telling others about what ought to be done. You can’t do that well if you focus on the tasks rather than thinking about the outcomes of the whole project.

Third, they will underestimate the importance of selling ideas to others. “I think it is good idea, so probably everyone else will agree”. Wrong. You aren’t the only one doing the work, and the outcomes are hardly clear if this is a complex project. You have to invest time in convincing others about it. Churchill said it well: “If you have an important point to make, don’t try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time – a tremendous whack. ”

Fourth, they will expect to control all of the project. It’s my baby! Any successful idea ought to outlive it’s originator. You don’t own your work, you own the outcomes of your work. That means that you must not only be willing to let other people take your place in the project, but plan and work towards it. People will distort your idea, and that is fine. It means they have accepted it and adapted it. As Richard Farson put it: “Effective managers are not in control [...] Many of us have the idea that as managers we can use our skills to shape our employees as if we were shaping clay, molding them into what we want them to become. But that isn’t the way it really works. It’s more as if our employees are piles of clay into which we fall – leaving an impression, all right, and that impression is distinctly us, but it may not be the impression we intended to leave.”

Please do not take this as me saying that one is superior to the other. The point is, both mentalities have a place, but in the wrong place and role they can be ineffective, even disastrous.