Technology and Organizations

There are no silver or “magic” bullets for organizations.  Google Wave was a single technology bullet.  The introduction of Wave had no organizational practice wrapped around it and little indicating consideration of how people would perceive it.  Organizations are complex systems and betting success on any single dimension is unlikely to work. There was no implementation. There were limited use cases.  Even access was limited until recently, meaning you couldn’t drag others along with you in your experimentation. (Wikipedia version of the history here.)

As I understand Google’s approach with Wave, it was to give Wave to the world as a platform.  Developers were expected build tools around Wave that normal people would use (perhaps as email platforms are built around Intenet email protocols).  I bought into that approach and followed the Google Wave Interest Group so I’d be ready when the developers got it all together.  I tried to get some other generally early adopters to try it out, to no avail, and many others were similarly frustrated.  Conferences were where of I heard the most success as the real-time/rich communication aspects were highlighted in that focused environment.

According to a Google announcement, Google will stop their own development of Wave and may shut down the site after the end of the year. Open source access to some of the capabilities will remain and aspects may be included in other Google products. Jeffrey Mann, writing for Gartner, points out that developers and users may be less likely to spend effort on Google products given the apparent lack of long-haul commitment.  Wave was only fully open to the public as of May 2010 and the cited reason for shutting it down is low user adoption.

The folks at Google are smart.  They’ve done (and do) amazing things. But they do seem to have technology bias that may be getting in their way.  In Kathryn Schulz’ recent interview with Google Research Director Peter Norvig we get some clues:

From a story about the founding of Google:

One of the venture capitalists came to [company founders] Larry [Page] and Sergey [Brin] and said “OK, the first thing you have to decide is, is this company going to be run by sales or by marketing? They said, “We think we’ll take engineering.” He laughed and said, “Oh, you naive college kids, that’s not the way the real world works.” And they said, “Well, we want to try it.” Ten years later, that experiment is still running; engineering is still the center of the company. And it seems like it’s worked.

I’ll argue that this single-minded approach sometimes works because some of Google’s products are so good, or fit into existing systems so well, that they can get away without implementation.  But I think Wave (and perhaps Google’s other visible failures) indicate that they could do better by stepping away from the myth of the silver bullet.  Om Malik says, “I’m not sure Google is capable of understanding people on that level, and that’s the reason why the company strikes out whenever it tries.”  For added success, Google needs to understand people and the organizational systems we all live in.

Google seems to need more systems savvy.  Systems savvy management is the opposite of a silver bullet approach.  Like the woven fibers of a bullet-proof vest, systems savvy management intertwines technology tools, organizational practices, and people for flexible strength.

What did I want from Wave?  I liked the idea of a persistent activity stream that could handle multiple file types.  I saw it as a way of consolidating project documents with their history and discussion.  We have this to a degree with products like Socialtext, and given Socialtext’s careful consideration of the broader issues, I expect they’ll be tracking the Wave experience.

Yes, the fulfillment center.  You don’t think the Zappos family hits its Wow! service standard by drop shipping do you?  (Drop shipping is where orders start with the retailer, but then are sent to the shoe company, that then sends the order to the customer.)  Zappos did start out that way, but drop shipping didn’t give them the kind of control they needed to provide their extreme form of customer service.  Though the team didn’t have experience in complex inventory systems, they jumped in, got their hands dirty, and created a organizational (warehouse facilities & team) and technology (inventory management) system that can hit their service goals while still managing costs.  The iterations they’ve gone through show deep systems savvy driven by their focus on delivering a Wow! experience to their customers, as well as great shoes and other products.

© 2010 Zappos.com, Inc. or its affiliates

I’ve had the chance to correspond with Keith Glynn about how they came to do things the way they do.  Keith is the guy who (story from Zappos CEO Tony Hsieh’s new book, Delivering Happiness) jumped on a plane to Kentucky, without going home pack, to help for a couple of weeks with 3rd-party warehouse issues — and ended up staying for two years.  At the point where Keith and Tony decided they needed to run their own warehouse, Keith went back to San Francisco to pick up his truck.  He and Tony then drove the truck 36-hours non-stop to Kentucky.  This is serious commitment to warehouse operations! Many thanks to Amelia Smith and the “Ask Anything” team at ZapposInsights for the connection.

I asked how Zappos came to run the fulfillment center the way they do.  I’d read that they randomly stocked the shoes as this actually made things easier to find! Keith’s response:*

In a traditional brick and mortar store stocking was done based on Brand, Style, Size and Color.  At Zappos originally there was no intent to stock inventory. As Zappos grew we realized we wanted to own the customer experience, so we started to hold inventory.

We started with a small space in our office. It held a couple thousand pairs of shoes. This consisted of static racking and the shoes were stocked based on what other stores were doing.  Brand, Style Size, Color.  We learned early on that this was a laborious job. You would have to continually shift brands because you did not account for seasonality and future growth.

[In 2000] we moved to a larger warehouse in Willows, CA…. We would receive a shipment, let’s say from Ugg. We would have to unbox the shoes. Lay them out in a large area on the floor based on style, size and color.  Imagine hundreds of shoe-boxes laid out on the floor and the amount of space needed to do this.  And this was only one brand.

Once you had them organized you would have to now figure out how to put them on the racks for storage. In order to get everything to fit you most likely had to shift thousands of shoes to get everything in the proper place. There were other brands on each side which had to be moved as well.  We would review our processes and come up with some small wins as to efficiency but it could cost us in space or other areas.  We thought it would be great to have a system where we did not have to rotate the inventory every day when the shipments came in.  We had the idea but did not have the resources or know how to make it work.

*Keith’s quotes are © 2010 Zappos.com, Inc. or its affiliates

In 2002, they thought they had a solution when warehouse service provider eLogistics offered to take over the warehouse and fulfillment operations.  eLogistics had a warehouse next to the UPS Worldport hub and this would speed up shipping.

When we moved to the Kentucky eLogistics location they did things quite differently. They had large static racks about 25-30 feet high. This probably worked for most of what they were shipping but there was no way it would work for us. We had large volumes of shoes, thousands of SKUs [stock keeping units - product identifiers].  The need for speed and accuracy was extremely important to us as this was our business’ “customer service.”

We had many conversations with UPS on how to improve what they were doing. We even had them install shorter racks so it wouldn’t take as long to put shoes away or pick for shipping. They only wanted to use this space for the faster moving products and felt the need to grow upward since this space was available to them. Imagine having 30’ ceilings and only 6’ racks.  I could see their rationale but it would not work for Zappos. Another challenge was that we were paying them for space. Basically this was a cube that varied in size. Let’s say 1’L x 2’W x18”D. They may have had only one or two shoes in the space based on Brand, Style, Size or Color that we had in inventory. This left a lot of empty space that we were paying for since we paid for the entire cube.

This is a problem that requires serious systems savvy.  At this point they are trying to work with building space, types of storage racks, costs, alliance partners, customer perception, and human heights (note the comment about shorter racks and stocking).

They eventually decide to again have their own warehouse.  According to Delivering Happiness, Keith went shopping for a warehouse and found one only fifteen minutes from Louisville airport. Again, good for shipping, and thus, customer service.  They signed the lease and take the crazy road trip mentioned above in preparation for moving the inventory.

In Delivering Happiness, Tony Hsieh tells the story of how they gave eLogistics a last chance to keep the business.  They designed a competition pitting Zappos’ new warehouse operations against eLogistics’.  For every week that the Zappos system beat eLogistics on shipping and inventory accuracy, 10,000 pairs of shoes would move from the eLogistics warehouse to the new Zappos warehouse.  It took only a month for the Zappos warehouse to win all the inventory into the new Zappos warehouse. “It was a valuable lesson.  We learned that we should never outsource our core competency.  As an e-commerce company, we should have considered warehousing to be our core competency from the beginning” (p. 118-119).

Keith continues:

While receiving the inventory, Tony came up with a quick program that would allow us to scan the UPCs [the “universal product code” you see with a barcode on many products] into a location on a shelf. This allowed us to put any shoe anywhere in the racks and we would be able to find it based on the UPC and the rack location.  We realized that this system would give us a higher density of storage and allow us to store items randomly.

Random storage is good for the people in the warehouse.  They can more easily grab the right box when its randomly stored — think about having to grab the right box if it were stored next to boxes that all were identical except for a color or size designation — random is good for people as the boxes are more distinguishable.

But they needed yet another innovation.  UPCs are not unique to a particular pair of shoes.  That is, the pair of size 7 Chocolate Leather Fitflops that I bought would have the same UPC code as the pair of size 7 Chocolate Leather Fitflops that you bought.  No good for managing inventory or returns.  That and some boxes have multiple UPCs printed on them. The warehouse team wanted a unique identifier for each and every unique box of shoes.

Keith:

Tony initially came up with the LPN (license plate number) system.  He then created some initial coding to test the system… [and] went to our development team and asked them to scale the code.

The LPN turns out to be a excellent example of a systems savvy outcome.  It’s a great way for Zappos to track the location of every item accurately in the warehouse and have a higher density of storage — Technology.  They are able to track specific items through receiving, shipping, and returns (Fun fact: 1 out of every 60 overnight packages shipped by UPS is a Zappos box) and as a result be amazingly responsive to customer service needs (and so be true to the Zappos Family Core Values) — Technology & Organizational Practice. Random storage takes into account human perception — People. It’s the intertwining of these dimensions that makes the LPN so powerful.  All from a number!

The warehouse story also shows what happens when a system isn’t built on systems savvy.  Keith and Tony realized that the technology eLogistics used wasn’t a fit with the Zappos products or the Zappos Core Values; the “pay for space” system wasn’t a fit with the Zappos business model; and as an e-commerce company, they couldn’t outsource warehousing.  All the parts have to be aligned if they are to “deliver Wow through customer service” (the first of their Core Values).

Note that they didn’t come to this approach in one giant leap and it didn’t come for free.  From 1999 to 2010, Zappos has had four different warehouse locations and inventory/shipping systems. They continue to grow their warehouse space in Shepherdsville, Kentucky and have added large carousel storage systems that rotate like the racks you’d see at a dry cleaners.

Systems savvy is built into the  Zappos Family Core Values, even if it isn’t there by name:

1. Deliver WOW Through Service
2. mbrace and Drive Change
3. Create Fun and A Little Weirdness
4. Be Adventurous, Creative, and Open-Minded
5. Pursue Growth and Learning
6. Build Open and Honest Relationships With Communication
7. Build a Positive Team and Family Spirit
8. Do More With Less
9. Be Passionate and Determined
10. Be Humble

This list of values is a well woven together platform for how to achieve your organizational goals, create one of Fortune’s “100 Best Companies to Work For,” and hit a $1 billion in gross merchandise sales goal — ahead of schedule (p. 210 of Delivering Happiness).  Zappos openness to learning, change, and communication means to me that they are constantly considering how things (technology tools, organizational practice, and people) might work together in new and different ways to better deliver Wow! experiences to their customers, employees, vendors, and everyone who interacts with Zappos.

More on this soon.  I’m taking the Zappos “Tour Plus” in August.  What questions would you like me to ask? Please add as a comment below.

In 2007 I wrote the first version of this post. Three years and many comments later, many of the same issues are on the table… Laptops don’t kill meetings, inattention kills meetings. Mistrust kills meetings. Bullet points kill meetings. One-to-many information transfer without follow-on discussion/decision-making/action kills meetings.

That said, are laptops, smartphones, and tablets avenues to distraction? Certainly. Checking email, sport scores, or working on a project that is late is a temptation if you have the tools available — and if the meeting isn’t providing value. Systems savvy can help us think about new ways of working given we have always-on access.

I often talk about technology first (following the TOP — technology, organization, people — checklist), but in this case I’ll kick-off with the organizational issues given the leverage they provide. What are the roles in the meeting? Who is attending — and how? Is everyone face-to-face or is it a hybrid form with some people attending virtually? What is the goal of the meeting? (Thanks to Lynne Cooper for inspiring this prior post.) Should you go to this meeting or do you have other more high-priority issues and the meeting can go on without you? Could you just attend for part of the meeting? If you’re the host, is a meeting the best form of work for this task? Huge number of organizational issues that may influence who attends and how — following a hard look at whether or not the meeting should take place. Careful consideration of these issues may reduce the number of meetings you attend or run, reducing the conflict around whether or not people have their laptops open….

People: What human and personal dimensions are in play when we have laptops and Internet access in a meeting or presentation? Be honest with yourself. Sean, an MBA student, recently provided a great comment to my 2007 post. An excerpt:

A couple of my instructors have instituted rules on what constitutes acceptable use during class, but very few actually enforce it. I do not bring my laptop to class because the temptation to do things other than taking notes is too great. So I prefer to take notes the old fashioned way. It works well for me.

Two main issues — Sean’s instructors are letting the class down by having rules but not enforcing them and Sean is showing systems savvy by having the personal insight to make good design choices around his own tools and behavior.

Besides being honest about yourself, be honest about your audience, but also open minded. While this Southpark clip about out of control cell phones in an elementary school class may have aspects of truth (doesn’t most good comedy have some connection to reality?), surely our colleagues have more control. Though perhaps not. Again from a comment to the prior post:

As a professional manager, if one of my staff is on his/her laptop while in my meetings, I can’t tell if they’re taking notes, researching, doing email, or playing games. Well, actually I can – when I say “John, what do you think?” and get back a blank stare or half-answer, I know you’re not paying attention to the meeting. That really limits your ability to progress in my organization. Same is true for phone meetings, by the way.

And finally, the technology: Physical features of technology play a role in how the technologies are perceived. The form factor may make a difference. For example, Steve Rubel blogged about his early experiences with his Apple iPad. When I quoted him earlier, I highlighted this point “A tablet computer changes the dynamic because everyone can tell you are taking notes”, versus, I assume, playing FarmVille, checking Facebook, or handling emails from another project. Cross-platform note/info capture tool provider Evernote has experience with these issues and has taken the side of the notetakers in meetings. They make available the stickers shown above. (That particular one is stuck to my laptop. I may be adding another to my iPhone now that I can connect my Bluetooth keyboard.)

But systems savvy is more than just considering each of technology, organizations, and people. Systems savvy goes beyond in terms of designing intertwined systems where these three dimensions work together for success.

For example, we need to be proactive about how we plan and run meetings and how meetings fit into projects. We also need to be proactive as meeting attendees. Just having a laptop in the meeting doesn’t mean you or your meeting collaborators will gain value — even when people are taking notes. The notes need to be group notes in some way, either as a consolidation or a single source (ideally that was on the screen during the meeting so corrections could be made on the fly). Hmmm. What about presenting from a wiki that is annotated by someone other than the lead as the meeting goes along? You could pull this off using Google Docs or any other multiparty-editable wiki, or even just presenting from within the edit mode of PowerPoint and using the notes section to annotate. In settings where no norms have been set and I have the only laptop/smartphone out (I’m an attendee not the lead in this scenario, or norms would have been set), I’ve learned to announce my intentions, offer to project my notes for all to see, or to post the notes to a shared site after the meeting.

Use your systems savvy to evolve your meeting process and outcomes. What norms have developed in your own organizations? Are they helping you get the most value out of your systems of technology, organizational practice, and peoples’ time?

I’ve been following Elance, one of the first (maybe the first?) web-based freelancing markets, since 2000 when it was a start-up of the tech boom. When I saw their booth last week at Web 2.0 Expo, it was a great chance to ask them how things have changed over the last ten years. Think about these particular last ten years: Many of us live and work via the Internet rather than a desk; outsourcing is an assumption for many firms rather than an experiment; Moore’s law is still with us; and Emeritus Prof. Edgar Schein of MIT said in 2004, “..we bascially do not know what the world of tomorrow will really be like, except that it will be different, more complex, more fast-paced, and more culturally diverse” (p. 331).

Elancing is an organizational design tool that should be in all our toolboxes. Elancing, and freelancing in general, provide organizational flexibility — but not just about basic staffing-levels. Companies like Elance provide access to staffing for jobs you haven’t even thought of.

Jaime Mehl of Elance (featured in the video below) opened my eyes to this issue. She says there are “..going to be projects posted that we don’t even know about yet — or [that haven't] even [been] invented yet.”

From a recent Elance report:

While the U.S. Department of Labor reports that the nationwide unemployment rate held steady at 9.7%, the Elance Online Talent Report shows online work continues to grow at a steady pace as its talent pool earned more than $20 million in the first quarter of 2010, surpassing a total of $260 million of work completed to date on Elance. This represents a nearly 40% increase year-over-year and demonstrates that businesses are increasingly turning to online talent, an important and thriving employment segment, to drive their economic recovery. Companies are turning to online talent for mobile development, open source, social media and cloud computing, making these the fastest growing skills in demand on Elance.

Kudos to the managers who take advantage of virtual freelancing. These managers are responding to the added complexity (and cultural diversity according to the Elance Report) that Prof. Schein predicted. They have developed the systems savvy to work with the technologies that enable elancing and have the skills to design organizational practice to take advantage of the flexibility. I welcome examples in the comments below. Have you been able to integrate elancing into your organizational design? What are the technical and organizational skills you feel are most critical to your success?

—–

More background on Elance from their site: (founded in 1998, following the publication of Malone and Laubacher’s, Dawn of the E-lance Economy.)

Today, Elance is the most widely used application for Services and Contractor Management. More than 200,000 employees are using Elance to find, buy, manage and pay external services and contractors from more than 2,000 suppliers across 50+ services categories, including information technology, consulting, contract and temporary labor, marketing, print, human resources, engineering, maintenance and facilities.

I had the great pleasure of meeting Ben Kepes to talk about systems savvy – peoples’ capability for seeing and weaving together technical and organizational opportunities. This was a perfect first meeting: quick understanding of the basics and then exciting new extensions as we talked about how people in different roles may have very different forms of savvy, and the impact this can have in the organization.

Ben is the principal and founder of Diversity Analysis, a consulting company helping companies work with the cloud and business strategy. He works as an industry analyst, consultant, and journalist. I had seen Ben’s Change the System, Not the Technology post and was thrilled to see he was in San Francisco for SuiteCloud2010. A few emails and tweets later, we were talking in the lobby of his hotel.

I asked Ben about his experience with technology, organizations, and people; how these three dimensions are woven together in organizational settings. He talked about the common problem of an organization trying to implement “some whiz bang technology, but it doesn’t work, or the culture doesn’t accept it.” We’ve all seen this silver bullet approach and know it doesn’t work.

Our conversation turned to how the situation could be improved. Ben gave me an example that made a lightbulb go off:

One of my businesses is a manufacturing company. White collar and blue collar. Slowly we’ve been implementing some collaboration technology. Really simple tools: email, calendar, manufacturing planning. It’s interesting to watch our facility managers (blue collar) grasp the stuff. The technology doesn’t work the way they think.

My initial interpretation of Ben’s comment was that the technology doesn’t work the way the blue collar folks think it does, versus, what Ben was actually saying, that the particular technology doesn’t work the way the blue collar folks think! The mental models held by people in the two roles are different. One is not better or more sophisticated than the other, but they are different.

White collar [management] deploys a tool that they [believe] is entirely obvious. Unfortunately that’s not the way it works for the [blue collar] workers. Difficulty [for the people supporting the implementation] — is there is a blanacing act. To a certain extent the blue collar folks need to use the tools, but you have to balance between requiring them to use and the underlying the cultural aspects.

I asked what would happen if the implementation support team didn’t understand this balancing act: “Huge disconnect, blue collar workers would feel alienated; people deploying the tools, really concerned.” The problems could span the organization even to disenfranchising the people making the purchasing decisions as they see the investment causing conflict.

Ben suggests two solutions:

1. Focus groups — though groupthink could be a problem if the focus groups give the answers that they think you want to hear.
2. Better is to build transorganization groups from lots of different departments from the beginning. “You need some idea about the problem we’re trying to solve. We’re trying to ensure that communication and collaboration can happen across disparate geographical teams. Let’s get them in a room and watch them work toward the goal. Goal driven rather than tool.”

Version 2 seems to me to highlight an understanding that the members of the different departments and organizational roles (blue collar/white collar) will have different ways of understanding the technology tools and organizational practices in play. How these groups think differs by their context and goals. By working together on the task the teams can learn who knows what, learn who needs to know what, and learn how to coordinate in the given setting, with the given tools. (Experts on groups would call this a great way of developing transactive memory, a valuable group capability.)

The different roles have different types of savvy, ways of thinking, that lead them to these different perspectives. Their practical understanding, their wisdom, is set in different contexts. Even if they all have systems savvy around the connections between technology and organizational practice, their systems savvy will be set in their unique context. Only by working together to create a common context, as Ben suggests in the transorganizational group approach, can they gain value from their diverse perspectives and build a system of technology tools and organizational practices that adds value for all.

I haven’t talked about the importance of context in systems savvy and I thank Ben for this enlightening example. I expect to push on this idea more with a focus on how to integrate high, but different, systems savvy capabilities. Looking forward to Ben’s insights on this and other topics.