I was reading the article Run IT as a business — why that’s a train wreck waiting to happen and it got me to thinking … which can be dangerous. The article specifically talks about how the idea of “running IT as a business” has unintended consequences, one of which is thinking about folks outside of IT as “partners” or “customers” and how it effects the behavior of the organization.

How does the language we use effect how we behave? Is it possible that the common practice of using terms like “partner” and “customer” causes us to behave in such a way that we are disconnected, at least mentally or emotionally, from the people that we try to make a difference with?

This has long been a pet peeve of mine. I think these terms cause an artificial separation between groups. An example that I used in a meeting recently:

At a company I worked for at one time, it was impossible to get a software release out without incident. There was not enough structure, and it was obvious that tools were required to automate the process that were not available at the time, for the particular platform we were working on.

Thats right folks, this was a time in which even Capistrano didn’t exist.

I wanted to help solve the problem. At the time, with the specific deployment model this company used, solving this problem required access that I did not have. Because I was not part of the group that got this access, I was not able to get it – until I transferred.

Yes, I actually transferred to this group to solve the problem. Two days later, I had the access required.

Same person – different access.

Much feverous work ensued. Finally it was done. The problem was solved.

So I transferred back to my previous group. Guess what went with the transfer?

Yep – the access.

Same person – different access.

It sounds ridiculous doesn’t it? But it happens – a lot.

In corporate culture we tend to use terms like “Partner” and “Internal Customer” to reference each other. I think it often causes unintended consequences.

It’s kind of funny. As I was telling this story, I thought about the story of the Sneeches. You know, the folks who some had “stars on thars” and some didn’t. Each were treated differently according to the status of the markings on their bellies. In the end, they were all the same – they just didn’t know it. Actually, in the end, when the markings were automated, no one knew Who was Who.

Corporations spend (and waste) a lot of time fighting who is at what level, whose responsibility is whose. Defining roles and their responsibilities rather than getting things done. Its not that defining roles and responsibilities is bad, but we tend to confuse people with roles and in doing so keep them from performing at their full potential. We fail to realize that people may have many skills and can serve multiple roles.

The next time you use the term “partner” or “internal customer” – think about this a bit. It might make you think a little different. It’s definitely been something I’ve been thinking about lately.

I finally got around to listening to The Gang XX tonight and thought this quote from Mike Arrington was priceless:

This is the reason why I’ve never raised money, because the one thing I don’t want to do is go to a monthly board meeting and listen endlessly to people telling me how to run my business …

Amen.

[tags]business[/tags]

I received this email from a former employee today:

I was reading a book recently, called “The Goal” as I was flying to California. It is about a big turnaround in a manufacturing plant in less than 3 months.

It is a very nicely worded book. The reason I am writing this mail is because there is one character in that book, Jonah – a professor – and he is a management consultant and the kind of questions he asks the main character Alex, the Plant manager are sufficient for him to ‘click’.

It was so interesting and I was smiling whenever Jonah showed up in the book since he reminded me of you, the way you would ask me something when I used to work for you.

If you get a chance do read that book. The book is basically about removing bottlenecks in operations.

Its nice to feel like you made a difference. I would never describe myself as a Jonah, but its nice to know someone would.

I found this article this morning after doing some reading around Jason Calacanis’ post from Friday. 37signals “experiments” sound a lot like Semler, don’t they?

As anyone who reads this blog regularly knows, I’ve spent a lot of time over the last 3-4 years studying agile methodologies and most recently lean concepts and principles. I have most recently been reading a couple of books by Ricardo Semler, who runs his company in a completely democratic way – doing away with all top down authoritarian management principles and allowing the employees to make decisions on dress, salaries, where they work, when they work, and most importantly, how they work.

I remember when I had first read the book Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle and I had sent an email to my manager with a link to the book and the small sentence fragment “common sense codified”. We began experimenting with Scrum within my group, but it was very difficult to get other groups on the same page. We wound up with a lot of sprints that ended when things left development and entered the “normal corporate process” to finish things up and get them to production. We also had a lot of conversations around whether what we were doing was “standard process”.

As I started reading books on TPS and Lean, the same thing occurred. It struck me how most of the things that are characterized by “lean” are just common sense principles explained in such a way that they sound like a “process” that manager types can “buy into”. But really, they work because they make sense – and people have the permission to standardize and then change their work rather than having things written down and subsequently treating these processes like they are set in stone. You can’t change them unless you go through an agonizing approval process up the management chain.

Over the years, I’ve read and listened to many podcasts talking about the same things going on in other companies. People struggle to be able to change the way they work because they have to get “management buy-in” to take action. So much wasted effort just to try something new.

Interestingly, once the “buy-in” occurs, over and over again people try to “implement Scrum” or “do XP”, mostly by the book, and do not throw out things that do not work for the group. For some reason, we all think we have to be a part of some “methodology” in order to be effective.

One of the most fascinating things about Semlers company is the explicit trust and ability to control ones own destiny that the employees of Semco seem to receive. I ran across a particular section of the book where he was talking about the process improvements that “just started happening” due to this culture change and I found some interesting similarities to lean that I thought would be interesting to highlight. He starts off with:

The factory committee spun off groups that studied the plants products and how the workers made them, looking for ways to save time and make improvements. These teams weren’t created by Semco; they formed spontaneously, as the bracing winds of democracy swept through the food service equipment unit, and often met after hours or during lunch.

Interesting, employees actually wanted to do a better job and self organized because they could.

He goes on, talking about some of the changes:

One group restructured the dishwasher assembly line, changing it from a sequential assembly process to a batch concept in which dishwashers are assembled in twos and threes by teams of workers that do many different tasks and spend the time between batches prefabricating the components they will soon need. They also came up with a system in which all the parts for the dishwashers were stocked in open racks in the middle of the factory. Metal tags, green on one side and red on the other, hung on each rack, and the workers would flip the tags when they saw it was time to reorder, ensuring a steady supply. This was a big improvement on the traditional assembly line, in which dehumanized workers have no role in decisions regarding the production process.

What we see here are people electing to move from an assembly line to, basically, work cells implementing small batches of inventory with workers that are skilled in multiple areas. They even set up a “Kanban” system, though I doubt they knew it, where they had visual cues of when parts needed to be supplied.

Note that not once in these paragraphs does he mention the word “lean”. There was no implementation of “lean”, no “lean” or “continuous improvement” initiatives. This just seemed to make sense to the people doing the work and since they were allowed to do it – and knew enough about the overall process rather than just their small piece of the overall process (i.e. they were multi-skilled), they were able to see the obvious and execute it without all of the red tape – and get great results for the company.

He goes on:

The strength of these groups was their diversity. They included factory workers, engineers, office clerks, sales reps and executives. They didn’t have a formal head; whoever showed the greatest capacity to lead got the job, calling meetings and moderating discussions. In more than one group, a shop-floor worker guided professionals. Instead of a seniority system, or boxes on an organizational chart that guaranteed power, the groups were held together by a natural system of collegial respect.

Again, you hear this a lot in TPS. People are trained from the bottom up in the company and have skills in multiple areas. While there are “leads” that are responsible for a product line, everyone has the ability to lead when they are the most skilled for the job at hand.

The only vague reference to lean that Semler makes in this passage is the following paragraph, where he draws similarities and differences between what Semco did and TPS (though Toyota is not explicitly stated):

There are similarities between this system and the Japanese approach to organizing manufacturing operations, but also important differences. In our groups, younger members didn’t automatically submit to their elders. Moreover, once a team decided an issue, it stayed decided. There was no approval needed to make a change. Then again, there were no special rewards for new ideas. It was a spontaneous process; people participated only if they wanted to.

As I read this it really got me thinking. In most of the process agile / lean related books that I’ve read there seem to be a few common themes:

• Trust people to do the right thing for the company
• Give them freedom and authority to work the way they want to
• Push decisions down the chain as far as possible
• Work in small batches and change things that aren’t working
• Allow those who are capable of leading to lead, no matter what their title or position is
• Put quality checks in place – whether it be test-driven development, or quality checks at each step in an assembly
• Fix problems at the core and stop the line as quickly as possible – in development this would be TDD and automated builds. Once a problem is found, find the root cause and put a test or quality check in place to ensure it doesn’t happen again
• and finally, Trust people to do the right thing for the company

One more principle that I would add would be “tolerate mistakes”. Many of the issues that I’ve come across with other groups is that if they make a mistake they feel they will be punished. I’ve had great success with my team in articulating that I know mistakes will be made, but I want them to be made once, a lesson learned, and things put in place (usually automated) to ensure they won’t happen again. I’ve found that if people know it is expected that mistakes will be made, and everything doesn’t have to be perfect, they are more receptive to trying something new.

But I digress.

What Semler’s story shows me is that if people are given the freedom to work the way that is most effective, they will. More than that, if you invest in them with trust, they will want to do these things as their commitment to the company will obviously go up based on how they feel they are treated.

Semler uses a key phrase throughout his books that is repeated over and over. “Treat people like adults”. Semco, Toyota, Amazon and Google seem to do a really good job at this, as I’m sure most high functioning companies do. Read this article called The Google Way: Give Engineers Room and you will see the same concepts outlined in the excerpts on Semco that I have just written about. It seems to be a common theme.

So my real question. Is methodology and process really the answer, or is it deeper than that? Is it the way we treat employees that cause inefficiencies? If it is, if we took this base principal of trust and actually implemented it, would our employees come to the same conclusions as companies like Semco, Toyota and Google?

I think they would, because the principles and processes implemented by these companies are really just common sense without all of the complications of “process” and authoritarian management. They encourage workers to work outside their “box” and learn what they need to learn to be more effective. I would guess these employees feel valued, because they can constantly improve themselves rather than just “be the guy that puts the screw in the hole”. When you are allowed to improve yourself, your commitment rises to those who “allow” you to do so. What you wind up with is a highly efficient company that can change on a dime because people are allowed (and encouraged) to change and improve.

Most interestingly, the processes wind up looking “agile” or “lean”, without all the cruft of trying to follow a cook book.

Am I officially becoming a hippie, or does this line of thinking make sense? Let me know if I should go join a commune.

While I still have a few books in the queue mainly focused around TPS, I started reading Maverick: The Success Story Behind the World’s Most Unusual Workplace, the prequel to The Seven-Day Weekend: Changing the Way Work Works.

Not too far into it yet, but riveted again. Pretty amazing story. Highly recommend both books.

I’m really curious about a lot of the ideas in these books, and how they would work in a traditional company. I know I’ve made little adjustments in this direction even before reading the books, but now I’m really curious as to how extreme you can go. Ricardo seems to have had great success going more extreme than most. I admire his idealism and his trust in people.

It’s been a long time since I’ve read a book on business that has kept me captivated through the whole thing, but Ricardo Semler’s The Seven-Day Weekend: Changing the Way Work Works certainly did.

Semler is the CEO of SemCo SA, a company in Brazil with a pretty crazy management model by conventional standards. A complete democracy. People choose where and when they will work. There are no permanent desks, no dress codes, and employees select their own salaries and bonus structures. Most ideas for new business for the company comes directly from its employees. The bottom line, the company is run on the base assumption that their people can be trusted to (and actually are motivated to) do what is needed to keep the business running and growing.

This is, oddly, the complete opposite of the normal viewpoint seen in corporations today that employees are not trustworthy, must be monitored, must be in the office during a certain timeframe and dress a certain way to ensure that they are “behaving professionally” and “productive”.

Semlers philosophy may seem weird to some, but it also seems to work, as according to Semler the company has grown from $4M a year when he took over the company from his father in 1982 to, as of 2003, an annual revenue of $212M. Reading the book, its hard to figure out what SemCo actually does, but the model in which it is run is so intriguing that by the end of the book you don’t really care.

Some of the most interesting assumptions, behaviors, and programs that I found while reading this book that SemCo pioneers:

• People are inherently good and trustworthy – Sure, there will be bad apples, but if you create a culture in which the social norm is trust, the “bad people” will be pushed out by their peers and/or subordinates if they violate the social norms. An interesting idea.
• Management positions are not guaranteed – All managers are evaluated openly by their teams. Think of it as a Digg.com for managers. Repeated low scoring usually results in the manager either leaving or being dismissed. I found this to be a very intriguing example of giving the teams the power rather than the management structure.
• Employees set their own salaries – SemCo’s books are completely open to their employees so that they can see the impacts of their salaries on the companies bottom line. Each knows what the other makes, and requests for salaries that are out of the whack are run the risk of being rejected by colleagues. Its an interesting concept to allow social norms to keep behavior in check, rather than the traditional approach of hiding information from employees. Given all of the information, employees are able to make decisions based on the impact to the company.
• Retire A Little Program – The company did a study on work productivity and found that the peak of physical capability is in ones twenties and thirties. Financial independence, on the other hand, usually occurs between age fifty and sixty, while “idle-time” peaks after seventy. The conclusion was reached that when you are most fit to realize your dreams, you do not have the money or leisure time for them, and when you have the time, and money on hand, you no longer have the physical energy to realize them. Semco allows their employees to buy early retirement time, from the company, allowing you to do the things you are passionate about while you can still do them. Another twist on the program is that for all of this time you take off, you receive a voucher for time to work, so that when you are older, you can come back and work at a proportional pay level. Brilliant.

Its extremely hard to characterize the thoughts contained in this book in a review. They are so different, and so people oriented, that the best thing you can say is once you read this book you will more than likely begin thinking about how to relocate to Brazil to be a part of it. The book is really well written and Semler has a great conversational style to his writing. It isn’t your typical business book, which would be expected being written from someone who is not the typical CEO.

Do yourself a favor and pick this book up. It will completely change the way you look at your employees and your company.

Related Links:

• The Semco Way – section of their web site detailing their management and company philosophy

37Signals has an article on the Signal vs. Noise blog about the Secrets To Amazons Success. Its a good read.

My favorites:

People’s side projects, the one’s they follow because they are interested, are often ones where you get the most value and innovation. Never underestimate the power of wandering where you are most interested.

Innovation can only come from the bottom. Those closest to the problem are in the best position to solve it. any organization that depends on innovation must embrace chaos. Loyalty and obedience are not your tools.

and finally

Everyone must be able to experiment, learn, and iterate. Position, obedience, and tradition should hold no power. For innovation to flourish, measurement must rule.

Check out the full article. There’s a lot there, most of which sounds like it comes straight out of lean books I have read. These three, however, are key for me. People are the greatest asset, and the things that they are passionate enough to “play” with are the key things that foster innovation. You just have to learn to trust them enough to let them play, and release some of the structure that “mature” companies think they require.

Another example of how Amazon gets it.

I’m reading The Machine That Changed the World : The Story of Lean Production by James P. Womack, Daniel T. Jones, and Daniel Roos. It is an extremely interesting book.

I ran into this small paragraph yesterday that for some reason stuck in my head as something important:

The truly lean plant has two key organizational features: It transfers the maximum number of tasks and responsibilities to those workers actually adding value to the car on the line, and it has in place a system for detecting defects that quickly traces every problem, once discovered, to its ultimate cause.

I’m telling you, the Poppendeick books are great, but there is nothing like going right to the source for an explanation of lean. I’m about 100 pages into the current book and I am absolutely fascinated at how much of todays current corporate structure (multi-level, many people with very specific task sets or responsibilities) is based on things that Ford and Sloan did with their companies.

In IT, this management style is manifested through all the different groups one hears about all the time from people in the field: Development, Infrastructure, Business Analysts, Quality Assurance. Each its own little silo, with its own responsibilities – and never should one group know how to do, or be privy to, the information in one of the other groups. Handoffs occur between the groups via very large documents.

Sometimes it goes further than that. I was talking to a friend once (who worked at another company, BTW) who told me about how their DBA’s were responsible for uptime and performance of the database and had decided that developers were not allowed to use ORDER BY clauses in their SQL because it effected the performance of the database. These developers were actually forced to sort their results within the application, rather than use the capabilities of the database, adding additional complexity to an already complex application. Worse, management seemed to buy into the decision, as I don’t think I would have been hearing about the situation if it was overruled. Ridiculous.

Another quote from the book, same page:

In old fashioned mass production plants, managers jealously guard information about conditions in the plant, thinking this knowledge is the key to their power.

Again, shocking how much of this mentality you read about in corporations not even connected to automobiles. This sounds like just about every company I’ve talked to people about (or worked at) over the years.

I’ve come to the decision over the years that ultimate transparency is the key to breaking down silos. It only breaks down your silo, but hey – thats a start, and at least you are setting an example.

Its definitely very beneficial, I’m finding, to read about things that are completely outside your profession to give you some distance from what is being taught. The lessons flow in easily this way, because you don’t have the predisposition that you “already know how things work”.

I recommend to anyone in IT to pick this book up. Its absolutely fascinating.

I really enjoyed Jason’s interview with Evan Williams (co-founder of Twitter, Odeo, and Blogger) especially Evan’s “lessons learned” about entrepreneurism:

1. Focus
2. Small things can become big.
3. Don’t go too wide.
4. Trust your gut.
5. Don’t do anything you aren’t absolutely passionate about.