Technology and Organizations

February 4th, 2010

Piazzza – E2.0 in the Classroom

Andrew McAfee defines Enterprise 2.0 as “the use of emergent social software platforms within companies, or between companies and their partners or customers.”

Piazzza provides E2.0 for interaction between fellow students and faculty. Interaction and emergence are at the heart of modern business, and ideally, modern teaching. I have used a threaded discussion approach for “course questions and comments” since 2000. Since 2001 I have been adamant that email is for health and personal grading issues only (for more on my thoughts on email, please see Kill Email). Questions and comments should be made where all can see, provide support, and gain value. My approach is an application of transparency for learning. Piazzza takes a big E2.0 step forward from a threaded-discussion list by being responsive to student needs and taking emergence to the next level.Picture 1

Pooja Nath (ex-Facebook developer, current Stanford Graduate School of Business student) approached me this Summer about being a beta site for Piazzza. Immediately I could see the value Piazzza provides to the students both from its base design and via the control it provides the students in terms of how they each individually experience the tool and the contributed information.

In the threaded discussion approach (old form), students had one level of control — they could either subscribe to the posts, or not. No option for digests. No option to only follow a particular thread. The result could be 20+ fragmented emails, and then a search through the website to find the full stream. Even the full streams were disorganized as students didn’t always follow best practice in terms of sticking to a thread’s topic. This was a nightmare and drove some students to ignore the material, which likely cost them some points and connections to useful information.

Piazzza realizes that not all questions/discussion have the same value to each student. Piazzza allows students to make the subscription choice — but at a more granular level. Once you’ve opted in, you see just the initial question/comment via email. At that point you get to choose whether or not to “bookmark” the question/comment. Only if bookmarked do you receive notification of the rest of the stream. (Piazzza.com is always available to see/search the full set of comments/questions.)

All of us must be systems designers to be effective in our current environment. We must make our own choices about how to weave together technology, organization, and people dimensions of our work. I feel that Piazzza is giving my students greater opportunity to make the best design decisions for themselves. Neither the technology or our practices are silver bullets and Piazzza allows us to use the technology to design practice at the class level (how we promote particular uses in class) and at the level of the individual (how individuals choose to interact with the material). We are integrating the technology and the practice.

Designed by a student, for students. Clean interface. Anonymity when needed, credit for providing answers to question. Engagement through tracking speed to answer. Ability to give thanks for answers. I’m a fan and the feedback from the students is that they are fans as well. We are still working on the organization/people intersection (anonymity means that not all the questions are well considered; students forget to search to see if the answer is already available).

The students are also quick to add suggestions around the technical feature set — recall that we are beta testers. For example, they wanted, and received, more control over the email flow and the ability to answer a question anonymously (I’m not sure how I feel about that — but so far so good). They also wanted, and received, greater clarity around new items.

Pooja and her team are right on the mark with their product. They ask for feedback, follow the use patterns, and are quick to make improvements. I’m looking forward to using Piazzza in all my classes!

Post to Twitter Tweet This Post

February 1st, 2010

The DIO Economy – Do It Ourselves

Chris Anderson (Editor-in-Chief of Wired Magazine) presents a spectacular cover story on “The New Industrial Revolution.” The teaser reads:

The factory, the investors, the workers — obsolete. In the age of DIY manufacturing, all you need is a garage and a great idea.

He opens with an example of a crowdsourced car:

Local Motors will officially release the Rally Fighter, a $50,000 off-road (but street-legal) racer. The design was crowdsourced, as was the selection of mostly off-the-shelf components, and the final assembly will be done by the customers themselves in local assembly centers as part of a “build experience.” Several more designs are in the pipeline, and the company says it can take a new vehicle from sketch to market in 18 months, about the time it takes Detroit to change the specs on some door trim. Each design is released under a share-friendly Creative Commons license, and customers are encouraged to enhance the designs and produce their own components that they can sell to their peers.

The Rally Fighter is a great example and raises the possibility of crowdsourcing for complicated systems. …but then the article goes into overdrive:

Here’s the history of two decades in one sentence: If the past 10 years have been about discovering post-institutional social models on the Web, then the next 10 years will be about applying them to the real world.

This story is about the next 10 years.

Transformative change happens when industries democratize, when they’re ripped from the sole domain of companies, governments, and other institutions and handed over to regular folks. The Internet democratized publishing, broadcasting, and communications, and the consequence was a massive increase in the range of both participation and participants in everything digital — the long tail of bits.

The article is part economics lesson, part how-to. Chris includes his own story, describing the founding of DIY Drones, a community site focused on amateur Unmanned Aerial Vehicles (UAVs). Within the community, he met like-minded and skilled collaborators and now markets autopilots and other related products. He includes great detail throughout, including tools and production outsourcing links.

Wired Sidebar

Wired Sidebar

We need to get our minds around the possibilities of this new industrial revolution. Chris Anderson and others have focused on D-I-Y (Do It Yourself), but I think it’s more than that. I see this new approach as D-I-O (Do It Ourselves). Each of his examples highlights the value of collaboration. These are not stories of lone inventors (except for his description of professor Bob Kearns’ invention of intermittent windshield wipers — but he apparently goes mad — so much for the lone inventor…).

My own interests are around how to support DIO organization through my teaching and research. In an earlier post, I claimed that “Recruiting, Knowledge, Evaluation, Tools, and Market seem to be five foundational ways Web 2.0 supports innovation.” Now I realize that DIO is more than about just innovation. DIO seems to be providing the foundations for what Anderson calls small batch entrepreneurship (with credit to blogger Jason Kottke). A new industrial revolution. I look forward to your comments as I think out loud.


For a different take on the value of crowdsourcing, please see Sarah Cove’s (for Wired News) Interview of Douglas Rushkoff What Does Crowdsourcing Really Mean.

Soon: A review of Cory Doctorow’s Makers (free download):

Perry and Lester invent things—seashell robots that make toast, Boogie Woogie Elmo dolls that drive cars. They also invent entirely new economic systems, like the “New Work,” a New Deal for the technological era. Barefoot bankers cross the nation, microinvesting in high-tech communal mini-startups like Perry and Lester’s. Together, they transform the country, and Andrea Fleeks, a journo-turned-blogger, is there to document it.

Post to Twitter Tweet This Post

January 28th, 2010

IT Savvy – Systems Savvy: Basics for TOP Management

I’ve known Peter Weill, co-author of IT Savvy: What Top Executives Must Know to go from Pain to Gain, since our days on the faculty at the Melbourne Business School. I was a visitor during my summers, while Peter and his colleague Marianne Broadbent were full-timers and doing the top research focused on IT business value. Peter is now Chairman of the Center for Information Research at MIT.ITSavvy (I hope to follow up with Marianne soon!)

Of course the title of Weill & Ross’ new book, IT Savvy, jumped out at me given my colleagues’ and my work on Systems Savvy. I find IT Savvy to be a beautiful, more organizational-level, companion to Systems Savvy.

Systems Savvy: The human capability to grasp the possible functions of technology tools and organizational practices and how these might be meshed to best effect. People with SysSavvy understand that technologies and practices are intertwined and they know how to make design adjustments to both the technology and the practice to effectively weave them together. We see SysSavvy as distinct from expertise, but more on that when our data are in…. Systems Savvy is critical to the ability to practice TOP Management.

IT Savvy: “…a characteristic of firms and their managers reflected in the ability to use IT to consistently elevate firm performance. Like savoir faire, IT savvy looks effortless from the outside. But IT-savvy firms distinguish themselves from others by building and using a platform of digitized processes” (p. 23).

My reading of this is that IT Savvy firms have managers who themselves have Systems Savvy. While Systems Savvy can be used beyond strategic information technology — when focused on the strategic issues described by Weill & Ross, the benefits to the organization are clear.

Weill and Ross note that IT Savvy is a rarity:

IT-savvy firms are not necessarily high-tech firms. In our research we have encountered only a small number of IT-savvy firms. Without exception, these firms use IT to “wire in” core transactions, and they use the data from their core transactions to inform decision making. Our list of IT-savvy firms includes highly successful new-age e-businesses such as Amazon, eBay, and Google. But long-established brick-and-mortar firms can also become IT savvy. Take, for example, 7-Eleven Japan, United Parcel Service, and Procter & Gamble (p.24).

Though rare, IT Savvy matters:

Our research found that firms that are above average on both IT savvy and IT spending have margins 20 percent higher than industry average. In contrast, firms with less than average spending and savvy have margins 32 percent lower than their industry (p.121)

What does it take to become IT Savvy? A business transformation that includes:

  • Fixing what’s broken about IT – broken accountability and decision making
  • Building a digitized platform – a base that provides stable core operations
  • Exploiting the platform for profitable growth – leading change and driving value from this new asset

IT Savvy is full of clear examples (many based on their own research) and steps to take. Weill & Ross provide an assessment tool and the ability to compare your own firm with others. I found myself drawn in by their ability to answer questions I’ve had for a while. For example, In February 2008 I wrote a post about Southwest Airlines’, then new, boarding process. I was impressed with the success of Southwest’s complex implementation of the required technology, organization, and people components (showing TOP Management) and noted, “I’d also love to hear how Southwest came to manage the process in the way they did. Do they have this social and technical focus for all of their changes?” IT Savvy gives me the answer: Yes, they do!

The top thirty leaders of the company each sit on two or more strategy teams so they can inform their colleagues of services and needs within their own functional area while learning about the operations of other functional areas. The teams propose enterprise IT projects, which are reviewed by the firm’s executive committee in establishing project priorities. Around 80 percent of Southwest’s technology projects are aligned with one of the strategy teams. pp. 87-89.

I used McAfee’s Enterprise 2.0 book in my Organizational Design course this term. I think IT Savvy is the perfect next step (rubber meeting the road) for those students who continue on to my Managing Technology & Innovation course. My highest praise: IT Savvy was the first professional book to make it to my B&N Nook.

Post to Twitter Tweet This Post

January 25th, 2010

Brett Colbert — Story of a Phoenix Project

Not all TOP Management stories start with a success. Technology projects can develop a life of their own, sometimes to the detriment of what is best for the organization and the individual teams involved. Brett Colbert, now VP of Enterprise Architecture at McAfee, gave me a great example from his early management career at Cisco. This is a story of how it is much more difficult to kill a project than to make the adoption decision — but when the killing is done well it can demonstrate an example of TOP Management by all involved. This is a story of how people and organization/management are tied to the heart of technology development, death, and resurrection — A Phoenix ProjectphoenixRedsm

Brett’s story:

A mentor suggested that Brett take on a new assignment: eContact. The project would give him a bigger role and broad visibility given the diversity of sub-teams involved.

I started doing some analysis and saw that pretty much every category related to general project management was broken or in the red: Quality component that’s being managed – No; Code being saved with source control – No; Right level of exec buy-in or change management – No. After about 2 months I went back to Andy [the mentor and overall manager] and said, “Each individual problem is solvable, but altogether it’s not. It’s a death march and we’re way off course.” Andy replied, “I was afraid you were going to say that, I agree with you. A rare occurrence, but we have to stop.”

They were 20 Million USD into this project at the time.

If you were talk to each person individually they’d say yes, kill it. But when you brought people together there was this strong desire to meet the culture of stretch goals that’s embedded at Cisco. People could not resist but to say, “We can fix anything! We can do anything!”

Even the most rational people, when you tried to put the breaks on things, pushed back — even though deep down they knew it wasn’t fixable. It was a big epiphany for me in terms of the desire for people to be able to prove or stay on course with these incredible stretch goals. They lose the ability to judge what’s reasonable, what’s impossible, what’s stretch [doable, but challenging].

Generally when management scholars talk about “escalation of commitment” it’s to say that tons of good money was thrown after bad (think Denver Airport baggage handling system). Not so in this case, though it wasn’t easy:

It took eight weeks to put the breaks on it… with a lot of analysis. Went back through the criteria that make a good project. This is where it got politically challenging. You want to be honest of how bad things are but you don’t want to focus on the people. The people are trying their hardest. You don’t want them to feel bad. We built a lot of collateral around why we were red in so many places. We’d over stretched as a company, group, team.

What was more important than finding a scapegoat was doing a reset. Tried to separate the people from the failure…. They were busting their butts, giving up holidays. Generally the team was doing what it was being asked.

Next came a request to present at the World-Wide IT Managers’ Conference. Brett’s boss said, “This is such an awesome example of success.” Brett replied, “I just killed a 20 million dollar project….” Boss, “Get up in front of 500 IT managers and tell the story of how you killed this thing.” Brett gave presentation and says his friends still laugh about it. Remember, this is at the beginning of Brett’s career. The amount of support from management was critical. They said, “you never learn when things are going great.” Smart management.

Ironically, a year later, after rebuilding their reputation, the same team went after the same problems — structured it right from the beginning. Focused on all of the lessons learned: starting off with change management, managing scope, exec support. Hugely successful. They will harken back that those were some of the greatest days: On time delivery, camaraderie, hitting stretch goals.

I asked Brett, “Given that most escalation of commitment stories end badly, what would you say made this one different?” His answer was the aforementioned management support and the follow-on:

Ultimately jumping back into the same problem and solving it: Having the right people, right roles, right player position…. You may want so badly to solve problem X, team may want to take it on, the business is there — but if you don’t have the right people stop until you do…. If you don’t have an org change management plan, it really isn’t the individual contributor’s problem. If you haven’t managed scope, it really isn’t the individual contributor’s problem.

I opened by saying that this was an example of TOP Management by all involved. It was a technology project with all the risks of technology projects everywhere: scope creep, complexity, etc. What made it TOP Management was the clear understanding that the problems weren’t about the technology. The problems were about the goals (organizational issues) and extreme motivation and commitment (peoples’ responses to the goals). Killing the project required being about to see all three aspects (technology, organization, and people) at once — seeing that there was no hope given the three aspects as they stood — and making a tough choice. Resurrecting the project was also TOP Management. The basic technology goal was still sound. Managing the organization and people issues with the lessons learned from the first go-round tied the process together.

More on Escalation of Commitment:

  • Barry Staw: Knee Deep in the Big Muddy (pdf)
  • Mark Keil & colleagues: Why Software Projects Escalate (pdf)

I’m always looking for examples of success or failure that demonstrate the tight ties between technology, organization, and people.  Contact me directly or post a comment below — I’d love to hear your story.

Post to Twitter Tweet This Post

January 21st, 2010

Jennifer Kenny – Helping Others Become TOP Managers

Jennifer Kenny, CEO and co-founder of Social Thought Matters, is a geologist by training.  She notes that geology is systems thinking at its most fundamental.  She’s spent the last 25 years integrating technology and business and this systems background has been critical to her success.   I had the pleasure of interviewing Jennifer this week about her experiences.  (Thanks for the connection, Queene!) We focused on how to help others understand and practice systems thinking, or in my words, how do you help them become TOP Managers – managers able to weave technology, organizations, and people together for effective solutions?JenniferKennyJennifer made it very clear that people don’t learn TOP Management via training.  Training is typically about information people are supposed to learn – you know some information and they’re supposed to learn it.  Systems thinking is better demonstrated through helping people “mobilize their own ideas.”

I asked Jennifer if she could give me an example of how you would do this in a real work situation.

Her story:

A friend had taken a new job managing a several-hundred person loan processing support group at a bank. Things weren’t going well with the workflow and the group was working to implement a multi-million dollar workflow technology to solve the problem.  The project was having a rough time and her friend was frustrated with their progress.  She asked Jennifer’s team to take a look as consultants.

Jennifer asked, “What would happen if the people were involved?” Given the friend wasn’t happy with the current work the loan processing group was doing, she wasn’t sure that participation would have much to offer — but ok, give it a shot.  They put a hold on the technology implementation work and instead looked at human cooordination.  About 10% of the group were asked (and agreed) to attend workshops on how to design their own processes.  Note that these were workshops about taking different perspectives (loan processors’, salespeoples’) and learning a new process (how do you learn about the different organizational roles and the related performance goals that people in the different roles work with?). This was not training focused in learning facts/information/details that someone else had prepared.

Next step was for the full group to meet with the Senior VP of the group and Jennifer’s team.  The SVP was clear: unanimous support was needed to move ahead, or the consultants would be out and they’d go back to the earlier approach. …let the tension build…  Did the subgroup that went through the workshops really believe in the new approach?  Was the subgroup able to convey the same enthusiasm to the full group of several hundred?

Unanimous approval.  The participative approach was rolled out to the full group and later on to three other groups.  They kept the hold on the technology and ended up with a minor modification to what they already had.  ”350 people came back to us and said ‘I’m enjoying work I’ve always hated before.’”

Helping this group practice TOP Management wasn’t about training — Jennifer says these workshops were,

joint design sessions… We knew that they knew a 1000 times more about their actual work than we did — training wouldn’t make sense.  Instead, we helped them tap into their knowledge using the common language about their work — mobilization of their own ideas.  Joint design, metrics and analysis.  Collaboration and co-invention is what’s going on. We were precipitating versus leading…  Doing systems work is being able to listen.  Deep listening.

Deep listening was being demonstrated and supported.

[We showed that] the way that they’ve been trained to do was input-process-output.  They had no understanding of the bigger game they were playing in.  We [helped them see] that was how their work had been designed and that was why the handoffs were problematic, no context.

For example, the loan processing group hadn’t understood that the sales part of the business had quotas.  Only by listening did this part of the context become clear.

We also brought the sales folks into design with them. Up to then sales had been the people who screamed when they didn’t get what they wanted.  Next was to show all of them working across an entire system, rather than each person as a single cog.  Then they saw context upon context and why it all connected.  Once people begin to get context, they start looking for it themselves. Gave them the bigger picture.

The results speak for themselves (as measured by the bank’s own customer satisfaction team):

  • 13% increase in customer satisfaction in a 3-month period
  • 4% increase in responsiveness
  • 10% improvement in quality of service for performance in documentation, credit and collateral

This was the first interview where I focused on how you teach others to be TOP Managers.  In prior discussions (here, here, & here) I’ve been more concerned about specific examples, or how people learned to become TOP Managers themselves (here & here).  My take away from Jennifer’s story is that you don’t train people to be TOP Managers — you help them develop their own systems savvy by suggesting new lenses for seeing their own role, the situations of the people around them, how the policies and practices of their organization link to their role and those of others, and how technology can be intertwined — or not.  Please comment below with strategies you’ve practiced or seen for helping others develop the systems savvy needed for TOP Management.

Post to Twitter Tweet This Post

 

Twitter links powered by Tweet This v1.6.1, a WordPress plugin for Twitter.