What iteration-less agile really means

I’ve written about the idea of an iteration-less process before, and we’ve been using the spirit of the idea at the startup I work at (Cinch) for the past few weeks.

The idea is simple, and has two parts. First, eliminate the concept of formal iterations (use a pull-system to let work flow through the pipeline – use Kanban cards if you like). Second, replace the rhythmic heart-beat of iterations with actual releases to customers (internal or external).

These releases do not have to be spaced out by a week or two or any arbitrary span of time. They ought to be, in fact, the shortest amount of time that the software system can be re-stabilized after undergoing change (through adding features or fixing defects). Hence, if it takes 2 days to do a release, do it then. If, for some reason, it takes 6 days (instead of the old five), then so be it. However, the focus of the team should be on getting quality software into the hands of the final users. After all, everything else is inventory.

Pretty simple, eh? We have combined this with the idea of the estimation-less process, for even greater effect. I have been hearing from some people that I have worked with in the past, and they’ve reported excellent results through just such a process. So, anyway – that’s what iteration-less means. 🙂


In a past life I had spoken about this with Jeff Sutherland when I attended Deep Lean (in 2007) – and he agreed that this made sense. He didn’t recommend it for any but the most experienced team – and I certainly agree with that. If your team is new to agile or is lacking in some other way, getting it going with the standard approach to agile is probably the best thing to do.

However – if your team can pull this off, you might want to give it a shot and see how much productivity increases over time.

Exit stage left

After six and a half years at ThoughtWorks, it is now time for a change.

I’ve wanted to do a start-up for as long as I can remember, and in the attempts at doing so thus far, I’ve realized that there is much I need to learn before jumping in. And after seeing how much my wife is learning at her new job, I was eager to get started on my own learning adventure.

So… as of Monday morning, I will be working at Cinch. I can’t give away a lot of information at the moment, but as things come together, I will blog about as much as I can. What I can say at this point is that its a 5 people team right now, looking to grow to about 10 in the near term, working on innovations in the online-retail industry.

Leaving ThoughtWorks was the toughest thing I’ve ever done, and it’s only the excitement of what lies ahead that’s keeping my spirits up. Here goes nothing!

An organizational pattern: Make it about the people. Really.

This post is inspired by two bodies of literature. One is about Lean Product Development, and the other is by a man named Ricardo Semler (and his two books – Maverick, and the Seven Day Weekend). These two bodies of work re-inforce each other strongly. If an organization could be born that truly, at a very fundamental level, implement the tenets of what they’re proposing – then what an ideal place it might be!

I think both these schools of thought start with their emphasis on the importance of people. How cliche! But seriously, these guys *really* mean it. Toyota has long focused on empowering the workers at the frontline – they get to decide a lot of what the manufacturing process is and how it’s changed/improved and so on. In fact, they’re counted upon to innovate and change the standard processes every single day – it might as well be part of their job description. Semler similarly talks of letting the guys that actually do the real job of producing things that the company sells decide things like processes, work-schedules, even pay-scales.

Believe me when I say I have read a lot about Lean product development. The flavor of agile that I use with my teams is heavily influenced by several Lean principles – both on large software teams (40+ people) and in really tiny ones (3 people). All of this basically involves letting the people self-organize and come up with the best plan and process to get the job done. It has worked admirably – and it made my job as a manager easier as well – all I had to do was to remove roadblocks and facilitate what they wanted to do, rather than plan and track and all that. I understand it, I get it.

However, on first hearing how Semler takes these ideas to their (extreme) conclusion – I was a tad less enthusiastic. It was hard to fully trust the idea that people could be OK knowing what everyone else in the organization makes (in terms of compensation), or that if given the choice to set their own work-schedules (the seven day work-week/weekend) they’d not end up with a chaotic schedule. Or even that letting people attend any meeting that was going on was a good idea, or even more so – letting people walk out of meetings that were boring.

However, none of my initial resistance stood up to the five-whys test. The five-whys is simple – all 4 year old children know it. You keep asking why until no more satisfactory answers are available (apparently you do this five times). Most of the time however, you can’t really get past the second or the third one.

I would love to see an organization that were built on these principles – take the seven-day weekend. A team would be able to decide what days of the week they worked. Who said that only Saturdays and Sundays were allowed as holidays? If you can work on a Sunday to get that important deal, you could certainly take Tuesday off to relax and go shopping. Organizations supposedly do this today – with the idea of ‘comp’ time. But usually it is difficult to get it approved, and it isn’t a matter of course. It should be! Why couldn’t someone work a full day on Saturday instead of on Wednesday, every week? My initial reaction was that it would be too chaotic! How would the team get anything done if everyone was taking different days off – it would just be a mess! But really, if your team were given this option, you wouldn’t randomly disappear without coordinating it with the team, would you? Wouldn’t you and the team figure out what the best schedule was for everyone involved? I’m certain they would, and it would be different for each team, and it would work just fine. Everyone would also get some respite from the fast-paced life we lead these days, and have a day to themselves that isn’t necessarily on a weekend when life still stays rather fast-paced.

Let’s now talk about letting people set their own salaries. This is actually based on top of another very important principle – to really empower people you can’t hide information from them. In this case, the information is of the financial type. If the books were open about how much money the company makes, what its costs are, and what industry standards compensation-levels are for the roles of each person involved, then surely the team would make informed choices. Further, this will require each person to know what other people make – if not specific amounts but the ranges based on say experience levels and the job role. People are mature enough to understand these basics, and as long as these decisions are being made as a team, this can work just fine. There will be situations when someone wants to pay themselves way outside their range, but the team will correct for them – either they will make an exception for reasons they understand, or the person will find that pay level in a different organization. It happens today – but the power and information would lie with the team members.

Speaking of teams handling exceptions – this whole system rests on another crucial aspect of the philosophy – that of peer review. Performance reviews shouldn’t be done by immediate managers – that system is too easily gamed. Instead every individual must be rated by all members of the team that they are a part of, and also the people that report to them, and the people they report to. Only complete 360 degrees of feedback can ensure enough checks and balances for this democracy to succeed. This is true when silly things happen – someone is spending way too much on their expense account – to when serious things happen – someone wants to give themselves a fatter than deserved raise. People know when they’re trying to do something that isn’t necessarily fair, but when they also know that everyone will know about it and judge them for it, they will be less inclined to do it. There is no need of a draconian corporate police that throws a large policy document at people – the system handles itself in all such cases.

Part of the peer system, of course, is that the group hires their own team members. No HR department or some other team hires people and then sends them over to join a team. Instead, the team itself interviews and decides who to allow in. This is now common enough in several organizations, so I won’t go into it too much.

Another aspect of Semler’s ideas involve meetings – there are no compulsory meetings, and all meetings are open to any employee. It’s amazing – he says that if no one comes to a meeting, the agenda can’t be too interesting. And if that is the case, then whatever is being talked about or planned won’t ultimately be carried out very effectively. Again, when I first thought about this, I was concerned about the time when no one would come and listen to my brilliant idea about the next big thing. On questioning myself further, I realized that if I were to force people to listen to me and then insist that we go down a particular path because I said so, the result would certainly not be what I probably would hope for. However, if what I had to say appealed to people and they came and listened, then we could together take the merits of my idea, fix its weaknesses, evolve it with collective intelligence, and move forward together as a group of bought-in people. More importantly, if this were really the only way things got done in the organization, then no one would have to waste their time attending meetings about stupid things and, more importantly, no one would have to actually waste their time following along strategies that are bound to fail. (Any of you ever had to follow along as stupid ideas were being implemented?)

A different aspect of this meeting culture is – any meeting be open to anyone. And why not? I couldn’t think up of a single answer. My first reaction was – too many people in a meeting make it ineffective. I have personal experience of this – I have witnessed far too many meetings go on forever or be entirely ineffective because of too many people saying too many things. However, I don’t believe that the reason was that there were too many people in the room. It was often because of the quality of the people in that room – most were, quite frankly, less than able to pull their weight in the capacity that they had been hired for – but the team was not empowered enough to self-select the person out. (Any one know people like this?) If the fortunes of the company (and therefore compensation, job satisfaction, quality of the people that one had to work with, corporate culture) were truly in the hands of the people (indeed, they were directly responsible for them), then people would stop wasting time, and people would try to get the job done as quickly and as effectively as possible.

One other thing – even in organizations filled with super-smart and capable people – sometimes meetings run too long and without useful outcomes. I believe this is because of the way decisions are made in such places. I have seen, many times, that the person with the loudest opinion tries to win by using volume, or that two factions with equal volume argue forever. However, facts speak loudest. Organizations that use actual data to drive the decision making process don’t have to worry about opinions. Google is a prime example. Even things like the logo design is subject to real-usage data-analysis before one is finalized. There are no aesthetically driven shouting matches beyond a certain point. More importantly, data serves as the ultimate equalizer – it doesn’t matter if the CEO has a personal preference about something, the greenest engineer can win the argument in the face of data that proves his point. This makes for truly empowered employees.

See, it isn’t about the meetings – it is about the idea that no one leads by decree. If there is a proposed path that a group might go down, it needs to be democratically selected. It needs to prove itself to that group of empowered individuals that are looking out for themselves, and therefore the organization. It becomes impossible for dumb ideas to take hold – the brutal natural selection ensures no one even gives a damn, and so no one does anything about it. What a wonderful difference from so many organizations where dozens of people march towards the end of the cliff, and right off, because the ‘product manager’ had this great idea.

Such organizations that actually believe that people are their most important asset (cliche time!) and make it so through real empowerment are places where the Lean product development system isn’t some new-fangled idea from the east. It is often the most natural evolution of the collective thinking and creativity of the workforce. Conversely, and importantly, for lean processes to truly be their most effective – such empowerment is a necessary condition. The added benefit is that such places are joy to go to every morning.

For more, I highly recommend Maverick and The Seven Day Weekend. And all the lean development stuff.

The Entrepreneurial Thought Leaders

I’m a book lover – I own nearly a thousand books now, and I even read many of them. I think that since there’s just so much to do and learn, and so little time, books are a fantastic way to know about things we might never get a chance to actually experience. Television can also be educational but I dislike it because it takes too much time to get through things – you can read at a much faster pace.

However, if there are times when you’re sitting in a train while commuting, or just driving to some place, podcasts can be absolutely fantastic. I love that the Economist has audio editions of their magazine (absolutely true to the printed form, and very high quality, btw). I haven’t missed an issue for nearly a whole year.

I want to share another great podcast resource – from The Entrepreneurial Thought Leaders seminar series at Stanford. I’m hugely thankful to my good friend Adrian Wible for telling me about this and his persistence in asking me to listen to them. Almost each and every one of them is like listening to a precis of some really important and interesting business book. Most are by very successful entrepreneurs, or venture capitalists, or professors from Stanford. Brilliant material.

They’re also available from iTunes; and I highly recommend them.

A Project Delivery Sanity Test

I’ve been working at ThoughtWorks as a software consultant for many years. During this time, I have done development as well as a project manager work. My most recent exploits were at a large project ($100 million+ program) as the PM on a sub-team of about 40 people.

After working with many clients and projects and also having worked on several side projects during the past few years, I like to think I’ve seen projects that span many characteristics – size, complexity, team composition, geography, domain, and technology. Based on the observations I’ve made over this time I’d like to present a list of things – a checklist if you will – of the most important issues that may determine the ultimate success or failure of a project.

1. A Delivery Focus

Being delivery focused begins with releasing software the moment it is written (almost). Releasing means to get the software into the hands of real, live users. Nothing else counts – developer-done doesn’t count, deploying on QA environments doesn’t count, staging doesn’t count.

Until the software reaches at least a single real user, all the code written (and all the design documents, passing tests, whatever else) is just inventory. (This implies that the goal of making money from the software can’t be achieved, thereby reducing the throughput to zero.)

The biggest benefit of getting code early into production (after creating a value-stream that might actually have some output) is that it brings the kind of focus on doing the right things that nothing else can.

I’d like to make a related point here. One of the few metrics that makes sense on software projects is cycle-time. The team must endeavor to reduce this cycle-time – and should be able to take an idea that needs to be implemented and push it into the hands of users in as little time as possible.

Another important issue of note here is that of usability. Once the software is out there, in the hands of the customers, are they happy using it? Or is it an exercise in frustration? If the users are captive (say internal users of an IT application), then the software still gets used (albeit it is the cause of multiple cuss-words a day). If it is a web-app meant for the general internet population, then the product will tank. Either way, the only way to truly understand and fix usability problems is by releasing it to the actual users.

a) Is your project in production? Are you satisfied with how long something takes to get into the hands of your users?

b) Is the feature-set being designed with a usability focus?

2. Clear Priorities

Speaking of bringing focus to software development, the most important thing is to ensure that you’re building the right thing! This relates to what feature next (and what feature never), what to improve, and what to remove. Setting a priority can not be arbitrary, it must come from a deep understanding of the market, the domain, and from listening feedback from real users.

This is not to say that one should do whatever any fickle user says, but it is important to listen, and include the feedback with the other things that go into prioritizing goals and features.

Without a source for rock-solid priorities, a development team will flounder. Rock-solid means that at any given time, anyone on the team can say what the next few most important things are. It also means that it is rock-solid until it is changed (which can happen at any time, based on changing reality and discovery).

I also like to think of a similarity between priorities and constraints. There can be only one top priority. When there are too many top priorities, there aren’t any.

Do you have a clear set of priorities (at any given point in time)? Does everyone on the team understand them, and how they are set?

3. Stakeholder Involvement

The one thing you can’t outsource is your product-owner function. Many teams seem to forget this, as product-owners spend so little time with the team, that they might as well not be present.

In today’s busy world of everyone playing multiple roles and having too much to do, it is common for people to multitask their days away. The effect of this on developers has been documented and studied – I have seen pretty much the exact same thing happen to busy product-owners.

The reality, however, is that if the bread and butter of an organization is the software their users buy, nothing can be more important than ensuring that it is built right and will garner the customer satisfaction and loyalty that is a must for it to succeed. Nothing.

A side-effect of this is some form of seagull-product-ownership. Here’s an example – the product-owner appears during a planning meeting (or the like), and makes comments that alter priorities (which is OK in itself). This changes what the team has understood so far and sends them into a flurry of activity to try and get things done which don’t necessarily flow with what they were doing until then.

A product-owner must, well, own the product. There can be no substitutes to spending several hours (at least) with the team each week – and truly understanding what the development issues are, and providing the team with critical information that is driving the priorities of the project.

Is your team’s product-owner involved enough with the project?

4. Business Analysis

This item is a larger issue in more complex domains. Remember, to truly complete a story it should be pushed into production. Small, incremental stories that make business sense are thus critical to running things in this manner. To help with analyzing requirements down into suitable chunks of work, they should be created with the INVEST principles in mind.

On teams delving with sufficiently complex domains, having business analysts that both understand the domain and are able to create such stories is a must. Again, the important thing here is the role – and that someone needs to do it. Having a team of poly-skilled people that include this skill-set is enough as well.

For what it’s worth, a good ratio of BA people to developers is about one BA for every one or two pairs of developers.

Does your project run off of well-written user stories? Is it sufficiently staffed up from a BA standpoint?

5. Team Size and Structure

From my experience, this one is a bit counter-intuitive to most people. People seem to think that for large projects (cost, number of requirements, whatever) large teams are required and even justified. There is plenty of research and literature out there that speaks to the negative impact of having too many people on a team. Even empirical observation allows one to reach the same conclusion – after all, how many smooth and successful large projects have you seen?

Ultimately, I think, this issue boils down to one of competent people. I find it somewhat difficult to believe that your average IT shop can attract not a dozen or two, but a couple of hundred developers to a project – and all of them are super-smart, super-motivated, and super-interested in the given domain.

The other issue that hits hard is how the team gets ramped up. Often there are too many people right at the beginning. Teams need to be ramped up slowly at the start – while high-level architecture is solidified (through code, being pushed to production!), and patterns are laid out, things of that sort. As these things happen and everyone understands the code-base well, the team can begin to add new members. This should be done slowly, as each new person needs to reach the same level of deep understanding. Once there are several people who know the existing system well, the ramp up may accelerate a bit.

However, I’m yet to see a project team of about 10 to 20 developers that couldn’t outperform a team of a couple of hundred. After all, you can easily scale up hardware, get more office-space, buy more snacks and food, but you can’t always scale up the rock-star developers that are required for a project to be successful. In other words, it’s probably Ok to hire less of those awesome developers you know if you paid them twice as much as your finance department thinks they’re worth. You’ll end up ahead anyway.

A related issue here is that once a project does get saddled with a large team, how is it sub-divided? Are the divisions made along functional lines (modules) or are they put into fluid workflow teams as the need arises? Is it one large team working on different stories with the whole code-base being collectively owned? Or is it bickering factions that jealously guard their areas of code from any change?

People who have suffered through artificial team separation along ‘module’ lines know the pain this can cause. Throw in the typical office politics into the mix, and the project ends up producing a system that conforms highly to Conway’s Law.

Finally, most people on projects know when these things have become issues – just listen in on any lunch conversation – or for the full details, hang out with the team at the bar.

Is your project over-staffed? Is the team sub-divided along the right lines?

6. Planning and Tracking

I’ve seen many teams ‘do Agile’, while not being agile in any fashion at all. Being agile is about focusing only on what’s important – and ignoring the rest. It means doing just enough of something so that it works as desired and produces the right kind of output. It means not doing anything just for the sake of it, and it means questioning any kind of process-thing which doesn’t add value to the software being produced.

Being agile allows and aids you in being lean.

How does this relate to planning and tracking? Because those teams that truly understand what being agile and lean is all about, focus on the activity of planning, and then react responsibly to changes that follow. Iterations are used to gather more and more knowledge about the system being built (while delivering to production at all times) so that better decisions can be made and better priorities can be set. Really mature teams don’t even need iterations.

What agile isn’t is a set of smaller periods of waterfall-type software development. An iteration planning meeting doesn’t produce a plan that must be met with perfect accuracy. Not meeting an iteration goal doesn’t mean it was a failure. Estimates still need to be treated as estimates, and iteration capacity still shouldn’t be filled to the maximum (basic queueing theory).

Planning on many teams becomes an exercise in craziness. This is especially true when the level of detail that people get into becomes so great, that they might as well just get the work done right then and there. Planning should be high-level goal setting, and as long as each individual team member understands the desired outcome for anything he/she picks up to work on, the intention of the planning meeting has been met.

There is often a tendency to re-estimate work in ‘real hours’, and then to track the progress and completion of each sub-task throughout the length of the iteration. This is a waste of time, and simply doesn’t need to be done. Might as well spend the time on taking the team bowling and spare them the wasteful effort of this sort of planning. At least the team will have a good time, and will get time to gel on a more personal level.

A more insidious issue here is the false sense of security or concern tracking things this way often produces. Graphs, pie-charts, trend-lines – all show the amount of work done, amount outstanding, tasks in progress, how many builds were green, how many bugs were found and how many were fixed, how many hours were worked overall, etc., etc. Instead, how about how many customers liked the product (is it even in their hands yet?), how many releases were made to the customer (boy, are we responsive!), how old a discovered bug is (why isn’t it fixed yet?), how little work-in-progress there is (unreleased software is just inventory), how fast the cycle-time is (turnaround time – from idea to profit) and so on? Metrics do matter, but ensure that they’re the right ones.

Does your project plan at the right level, and track and measure the right things?

7. Technical Architecture

Technical architecture can be a strategic advantage. This is most true if the design of the code allows new features to be added (or bad ones to be taken out) quickly and safely, and also allows maintenance to be done without breaking half of the system. It is an advantage if the turn-around time of a new feature or a fix is so short that the team can run circles around its competitor.

This is a system-wide issue (what isn’t?). If every part of the architecture except one is very well designed, is maintainable and extensible, etc., then that one module will become the constraint of the system when it comes to features in that area. The code-base needs to be kept clean and trimmed of fat at all times, across all areas. (All disclaimers apply – in the end it boils down to the cost of change vs. ROI).

Developer productivity is a related issue here, but is very important. The write_test-write_code-deploy-test-see_results-repeat-checkin cycle is how each developer spends his/her entire day. If the deploy-test-see-results part of this cycle is not down to less than a minute or so (at worst), you can expect major productivity losses from the lack of flow. Build times must be carefully monitored and everything must be done to ensure that developers aren’t waiting around for something like a build result.

Does the technical architecture of your project support a quick response (new feature, bug-fix, enhancement)? Does your project have long build times?

8. Testing, QA practices

Automated tests are the most important part of a code-base. Period.

No one can get a design right the first time, no one can get all the requirements down pat the first time. Things always need to be changed, and software spends four-fifths of its life in maintenance mode. The only thing that can automatically tell a developer that he has broken something is the test-suite. Without this, even making a simple change is a nightmare. Enough said.

QA people are also an important part of this. They are the independent verifiers of the developers’ understanding of the requirements. Testing early and often is the key, as they say, and QA folks need to be part of the development team. They need to be in there while a story is being written up, before it is played, and soon after it leaves the developer’s workstation. And everywhere else with their ad-hoc testing. And they should automate, automate, automate. Why should they do things which the computer is suited for perfectly – repeating a step-by-step procedure and ensure the output is correct? Enough said.

A good ratio of QA to developers is about one QA person for every one or two pairs of developers.

Is your team staffed sufficiently from a QA standpoint? Do you have automated GUI testing in place?

9. Understanding software development

This one is actually the simplest to state, but I’ve noticed that a lot of people have trouble accepting it. Here it is – people who run software projects should know what software development is all about.

If your project is being run by someone who doesn’t really understand the nuances of software development, and heaven forbid thinks he/she does, then you’re in trouble. Generally speaking, of course. I won’t say too much more about this – I just happen to think that people who either write the software or those who manage the people who write the software should know what the heck it’s all about. It just saves a lot of silly mistakes, absurd conversations, rework, and generally helps getting things done right, quicker.

Does your project team have managers that truly understand software development?

So there it is – my first cut at crystalizing many of the issues I’ve seen in the past few years on various projects into a list of nine items. There are other important issues to be watchful for, be sure of that. Also, I don’t think that the issues on any project that is in trouble can be traced to one single point above. It will always be a mix of several things, some listed above, some not.

I hope this is useful though!

Maverick, and the Cluetrain

I just re-read Maverick by Ricardo Semler, and having just read The Cluetrain Manifesto this past month, I feel like there could be some very serious synergy between the two.

First off, Maverick. If you recall, Semler talks of some fundamental truths about companies, markets, about being effective, agility, and about employees. The most basic of these forms the foundational element of Lean Product Development Systems as well – the fact that ordinary employees can generate extraordinary results if they truly engage in the company’s business. It is the management’s responsibility to make it possible for them to do so with the least amount of organizational friction. The important thing is simply to remember that most people want to do the best they possibly can!

Semler, of course, also talks about a whole bunch of other things they did at SemCo, and a lot of them are worth reading the book for – for instance, employees setting their own salaries, and a transparent compensation structure. Trust me, get the book.

I already talked about the Cluetrain Manifesto. I’m excited by the possibilities of marrying the two (they’re not conflicting at all) philosophies. I wonder about the power of an organization that does what Semler advocates, and that also extends the organization to truly include customers the way the Cluetrain Manifesto describes.

What would this imply, and what would such a company look like? I can’t really say, but I know I’d like to experience one. Maybe someday, yewoh might be such a place?

The Cluetrain Manifesto

I just finished reading this book called The Cluetrain Manifesto. I read about it on someone’s blog a long time ago, and had it on my reading list for a while. Then recently, my close friend Kiran recommended it to me again, and so I picked it up.

I liked it! Sure, it is a little repetitive at times – the book is kind of a collection of essays by a group of four authors – and they cover overlapping grounds. However, for most people the book will be one of two things – a) a whack on the side of the head, or b) a reinforcement of what they might have been thinking.

The basic premise is simple – the Internet has changed the way markets behave, and companies need to respond and engage the new markets in this new way as well. Nothing new, huh? Still, how many companies are truly doing it?

In fact, from the above, it might even seem a rather dated book. After all, it was written in 1999, when it was a fact that the Internet was new, and not well understood, and companies were jumping onto the bandwagon. The authors explain that the Internet is not just some new medium to advertise on, or set up websites that dispense corporate-speak. It is a place where people (existing and potential customers) can talk, have a conversation. And these people talk about companies, and share experiences about them. They swap reviews – both good and bad, they analyze companies’ strategies, they come up with ideas for improvement, so on and so forth. It is up to the companies to participate in these conversations and gather what they should from them.

Smaller companies are sometimes good at doing this. They actually know many of their regular customers by name, and gather plenty of feedback and ideas on what they could do more or better. However, there are plenty of companies out there, that even today, do not respect truly their customers, or think they can get away with being a corporation that doesn’t need to truly engage with their customers in a human-like manner. If you’ve ever been treated badly by a large company, say an airline company or a rental car company, then you know what I mean. Most people are pretty clear about the difference in service they should expect when they’re dealing with typical large corporations versus small, mom-and-pop outfits.

And that’s the point. Companies need to get off their high-horse of being a business, and become more like the normal people that work in them. After all, they’re customers too, from someone else’s perspective. Companies sometimes do this during the startup phases. And as they expand (when the distance between the producers and the consumers grows beyond a certain point), they lose this human-ness, and become a faceless corporation that is impersonal and forbidding. If the founders can truly inculcate this and the rest of the principles outlined in The Cluetrain Manifesto, they will find that it becomes another secret-weapon that can be wielded against their more traditional, large corporation-type competitors.

A decent read, I’m sure at least a couple of ideas will stick.