Technology and Organizations

Megan Gailey’s job is all about helping people be effective at work. She is the Director of Global Training, Corporate Events & Tradeshows at National Semiconductor and has worked for tech leaders Xilinx and Cisco. I first worked with Megan as she led a world-class effort at Cisco to support their global communities of practice. In these roles she has helped her communities learn to weave together their available technology tools and organizational practices, with an understanding of the skills and needs of the people involved. Megan is a systems savvy leader and helps others develop this capability as she promotes change in the organization. Like many systems savvy leaders, she started out in engineering, but switched to learning and development in technical settings given her “love of both… technology and people together.”

Her approach uses demonstration and evidence to bring technology and practice solutions into the workplace. She recalls joining an organization that, though global, seemed to be overlooking the value that collaboration technologies could provide for team meetings and support. She took a systems approach to the situation: She reached out to her network of technical experts for advice on the different technical options given the company’s needs and workflow, she worked with corporate IT to consider the technical environment, and then she looked for the early adopters and situations where there would be strong value — in this case, getting a far flung set of experts into virtual meetings to pass along their knowledge, and to save this knowledge for future use.

Megan explains:

I tend to focus on the people who are the willing participants… the early adopters. Then through their demonstration and behavior change, show success. [The success] sways the resistors and the people on the fence. Get the earlier adoptors excited and the fence people come along.

I think that helps in the tech environment. The engineers need demonstrated evidence to accept and adopt. You have to show them a case, a pilot, a success, and then you can persuade.

My take on the demonstration approach is that it helps people see the situation in context — as apart of an overall system. It is from intertwining organizational practices, technology features, and implementation that you create new ways of working — not from stand-alone technologies or organizational adjustments. Megan’s engineers seem to have an innate understanding of this and want to make their judgement based on the combination of effects. Megan has found a strategy that shows the full system at work in the given setting and with peers doing the demo – very powerful!

How have you helped others become more systems savvy? Comment below, email me, post to Twitter — would love to share your example.

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 Project

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.

The energy around innovation activities is keeping me sane as we get to the shortest day in the Northern Hemisphere. Web 2.0 infrastructures and Enterprise 2.0 ideals are energizing innovation in a way not possible with just a few people in a garage. Recruiting, Knowledge, Evaluation, Tools, and Market seem to be five foundational ways Web 2.0 supports innovation.

Last week I ran across BuildItWith.Me:

Build It With Me is a tool that connects design & development entrepreneurs. It exists to make creating apps easier by connecting you with like-minded designers & developers with the same goal: create cool & useful apps. Getting funding for your app idea is hard and often unrealistic. Most of the time you may just need to connect with a partner who has a skill set you lack to finish off your app. This is where Build It With Me is comes in, connecting you to those people. Skip the funding. Build It With Me will help you bootstrap your ideas into actual apps.

Recruiting

Build It With Me supports innovation through both knowledge and labor. You may be able to find someone with a skill you don’t have, but need, for your innovation — or you may be able to find someone to just share the workload. Key is that you find them by skill/interest rather than location or ad hoc connections.

Knowledge

But not everyone who helps your with your innovation has to be a member of the team.

Communities of practice have always shared knowledge amongst their members. Knowledge sharing is one of their hallmarks. Web 2.0 versions of Communities of Practice increase the reach, speed, and ease of the process. For example, the Experimental Aircraft Association’s Home-Builders Corner was part of their 1953 newsletter (pdf). Through the wonders of the Internet I can find not only that 1953 information, but of course have access to the current 24/7 searchable discussion board version of Homebuilders Corner.

Evaluation

Not all ideas are good ones.

Many innovation support systems allow people to rate the idea, point to where aspects of the project might have already being done, etc. Cisco used a hybrid social networking approach in its I-Prize. The I-Prize was an open innovation prize competition, but the early stages were evaluated by the community. Intuit’s Brainstorm tool similarly provides a hybrid approach offering evaluation and more (recruiting, workflow support, etc.) across either an internal audience, or one that crosses organizational boundaries.

Tools

In this first example, when I say tools, I mean tools: lasers, saws, 3D printers:

TechShop is a 15,000 square-foot membership-based workshop that provides members with access to tools and equipment, instruction, and a creative and supportive community of like-minded people so you can build the things you have always wanted to make. You can think of TechShop as a health club but with tools and equipment instead of exercise equipment.

Technically the tools themselves aren’t Web 2.0, but the Web 2.0 connection is there in that members collaborate and share knowledge via the TechShop Member Forum.

Other examples of Web2.0 tools are more straightforward (e.g., open source software), but not as likely to throw off sparks.

Market

One of the keys to user innovation (versus closed corporate innovation) is that it be able to compete (Von Hippel, p. 118, free pdf of book). Software/web innovation has it easy in that transportation costs are virtually nil, but all innovations can take advantage of social media to gain immense marketing reach for little to no money. (Perky video on Social Media ROI: Socialnomics.)

Recruiting, Knowledge, Evaluation, Tools, and Market. Web 2.0 provides us with collaborative avenues toward innovation. What have I left out? How about incentive? Are we more likely to participate in innovation activities when we can interact with many more like-minded collaborators – even if we never get to meet? Are we more more or less likely to participate when our actions can perhaps been seen on a global stage? I’m hoping to write a follow-up post on Generating and Maintaining Energy for Open Innovation Platforms and would be happy to collaborate….

—–

For more on Open Innovation – with a review of some of Carliss Baldwin & Eric von Hippel’s recent work, please see More proof that sharing is good, von Hippel style.

Eugene Lee is CEO of collaboration/Enterprise 2.0 platform provider Socialtext. His resume includes leadership roles at Adobe, Cisco, and the co-founding of Beyond, Inc. He was kind enough to provide me with several examples of how he’s been able to develop Systems Savvy and how this plays out as TOP Management at Socialtext.

I’m going to start with an example from earlier in his career that may be the easiest for all of us to apply. (I look forward to sharing his “Getting to Know You 2.0″ story in the next week or so.) Eugene had just joined Cisco as VP of marketing for a new business line focused on SMEs [small and medium sized enterprises] and was in one of his first staff meetings with the finance director and other leaders. The presentation went into great detail around financial goals, drill-down goals and the like. Eugene turned to the controller who was helping him through this on-boarding process and asked for more explanation:

The controller was going through the mechanics of headcount, revenue, degrees of freedom, budget, variable marketing spend, allocation stuff… took me through all the lines of a vast spreadsheet. I asked “where’s my IT [information technology] allocation?” “Well, we don’t do that,” says the controller. “Everything is client funded, you decide what you’re going to spend on IT.” At first I didn’t understand.

The major “a ah” was when Eugene realized what it meant in this context that “everything is client funded.” It meant that he had a budget and it was up to him to make choices — across technology, organizations, and people — regarding how he was going to spend the money. This approach created a commitment well beyond that he would expect if there were just an “IT allocation.” It was all about getting the most from your dollar, and getting the most from your dollar doesn’t come from spending on IT independent of the rest of your organizational actions. It has to be a systems approach. It has to be an integration of the technology, the organization, and the people. The budgeting system was a trigger for TOP Management. If you separate out your budget allocations, people will think about the components independently. If instead you budget for a system — you get people to think and design in an integrative way.

I made systems thinking a major part of anything my team did. Raised the bar on what qualified as a fundable program. [Systems thinking] became a theme — and then how we could teach small business to do it at their scale.

The budgeting system also pushed groups across Cisco to collaborate:

Nobody had enough to make a nirvana system on their own, so people would pool resources and you would get alignment across stakeholders. Where the budget comes from plays into creating the conditions, part and parcel, of how the business gets driven.

Eugene said he saw these systems ideas further solidified in how Cisco handled his IT support. The IT Vice President came over to see how he could help. IT: “We need to hire somebody to support your group.” Eugene: “Cool. Who do you have in mind….” IT: “No, you’re going to hire somebody.” The budget money came from IT, but the decisions came from Eugene’s group and the new IT staffer sat (and ate lunch) with Eugene’s team. This “made such a difference. She sat in my building, came to our staff meetings. She could efficiently do the research around what would work and what wouldn’t because she understood the work that needed to get done.”

As a management professor who teaches systems thinking (and hopefully, savvy) in the context of organizational design, these examples sparkled. Cisco had built a budgeting system that clearly supported frugal and effective innovation. Eugene saw it as a way to leverage his resources and this insight served as an effective trigger in his development of systems savvy.

We can all do this — from high corporate finance to departmental budgets — we can use the power of the purse to encourage people to take a systems approach. Managing technology, organizations, and people as a system is likely to be a much more efficient, and effective!, use of limited funds.

Y2K, 9/11, H1N1, the financial crisis.  Crises trigger change.  Thank goodness. Otherwise many organizations would look the same today as 20 years ago.  Crises push people to look at opportunities within technology and organizations for responses to the crises — or to take the steps to go along with already built, yet sometimes ignored, technological and organizational innovations.  (Great example of this at UPS in a comment to a prior post.  Thanks, Paul!)  Crises are a case where the People dimension of TOP Management provides extra value.  Our human reaction to crisis gives us an opportunity for change. Managed well, we get to make lemonade out of lemons.

After Y2K, Chris Farrell interviewed (Transcript, Audio) Paul Saffo, Suhas Patil, AnnaLee Saxenian, Rafiq Dossani, Shankar Muniyappa, and others.  Farrell’s analysis included:

Economists initially looked at Y2K as a productivity killer.  Imagine a town threatened by a rising river. Every able-bodied person in town is put to work stacking sandbags. It’s necessary work to save the town – but it’s unproductive work. Nothing gets built. No food gets grown.  With the Y2K bug, programmers, chief information officers, project managers, and other digital workers were getting paid to do unproductive work – stacking sandbags of silicon. No innovative investments. No new productivity enhancing software.  But economists were wrong. Y2K wasn’t a flood.  Instead, think of it as clearing a path choked with underbrush.  Once the trail is open, it is much easier to zip from point A to point B. Y2K gave companies an excuse to clean up their software and hardware underbrush – a critical factor in today’s improved business productivity.

H1N1 may be our next “opportunity.”

In a comment to Rosabeth Moss Kanter’s post, Stay Home and Work,  Jennifer Fraone of the Boston College Center for Work & Family (on Twitter @BCCWF) notes:

…in light of the recent H1N1 flu pandemic, we should also add the fact that telecommuting programs should be implemented in organizations for business continuity reasons. Organizations that utilize regular telecommuting, and develop the technology to support it, will be better prepared for employees to work from home in the event of a disaster or pandemic.

At the Boston College Center for Work & Family, we have long been advocates of fostering more flexible workplaces. We would be happy to join with you in the dialogue to promote flexibility in the “re-invented” modern workplace.

Prof. Kanter had made the point that the barriers to remote work “are the usual human ones” — the P in TOP Management.  It may take a crisis, sadly, to push us to deal more effectively with Kanter’s stated issues of trust and culture.

The tech community is seeing the need to get ahead of the possible H1N1 pandemic.  In a current white paper, Cisco Systems offers: “To ensure business continuity during disaster or pandemic events, it is critical to enable fully functional virtual offices for their workforce.”  In another blog supporting the tech community, Kristen Caretta writes “…for those with no business continuity plans, it’s not too late to craft communication and other policies to ensure that business continues uninterrupted should conditions deteriorate.”  The post also notes that you need to walk a tightrope in terms of being prepared while not scaring employees.

Managers with TOP Management skills will use the threat of H1N1 to prepare for risks, remove barriers to flexible work, and focus the energy in broadly productive ways. They will:

• Weave together technical solutions that can support their organizations under extreme conditions (e.g., vast increase in employees working from home, customer call center increases for health related products)
• Build organizational systems that focus on collaboration skills, productivity, and awareness of others — even when not face to face
• Engage people in innovation and change such that the technology and organizational improvements stick

Have you noticed your organization taking steps to prepare for an H1N1 outbreak?  Has the focus been on the health and safety issues, or are they looking at broader issues?