Stories matter

Humans are story-telling creatures; stories resonate with us, they guide and influence us, they inform us as to our identity and purpose. They are especially good at bringing us together, which makes it ironic that we do such a poor job of using them in our organizations.

Why do we need stories? Because when it comes to conveying what is important to and desired by an organization they are better than mission statements, employee handbooks, presentation decks, or any of the other devices companies and HR departments typically use.

I still remember an old story about Nordstrom, often repeated in business and management books throughout the 90's. You may have heard of it; an old lady brings in a tire, wanting to return it. Of course, Nordstrom doesn't sell tires. What does the sales cashier do? Without blinking an eye, he happily processes the return, satisfying the customer once again with Nordstrom's impeccable service! Whether this story is true or not, it very clearly imparts the standard of service desired by Nordstrom.

This is significant because such standards or expectations are remarkably difficult to convey. In any business, we often feel conflicted or unsure of what to do (i.e. what our boss would like us to do). Should we put our foot down? Should we demand a receipt? Is it better to make the customer happy, or is it better to prevent the company from losing money? We are keenly aware of the merits of both sides, and it can be very difficult to know which is the course the organization would like us to take. If we want people to be confident in their own judgement, it helps immensely to have stories to refer and compare to.

Has someone done something particularly noteworthy or impressive lately? Make a story out of it and spread it. Learn an important lesson? Make a story out of it and spread it. Are employees not engaged? Maybe the problem is that your organization doesn't have any interesting or exciting stories to tell. Are you not exhibiting the values you want to embody? Perhaps you have no good stories that embody your values--and nobody is talking about them. Want to successfully lead? Learn to tell a good story.

Seniority is a state of mind

Where do we find senior resources? I'm not talking about folks who are high up in years, or high up in years of experience. I'm not excluding them, but what I mean by "senior" is someone who is not only a deep subject matter expert, but who can take a leadership role in their area of expertise.

My experience in working with dozens of developers and designers of different specialties is that the correlation between "seniority" and "years of experience" is fairly weak. While almost everyone who's been in the industry for a while likes to think of themselves as "senior", I contend otherwise. This is because I consider a "senior" person someone I can entrust a job to--which is entirely different from their level of experience. In particular I ask the following questions:

  • If given a problem in general terms, can they take the ball and run with it without requiring close supervision?
  • Can they independently exercise good judgement and problem-solving?
  • Do they have sufficient patience and persistence to overcome challenges and difficulties which confound or frustrate others?
  • Can they present their own work in a compelling manner and positively influence others?
  • Do they take initiative to do their own research and come up with solutions?

What I've found is that people who can do all of the above have one thing in common, and it's not years under their belt--it's attitude. Amidst the great sea of so-called "senior" resources, I find that someone with the right attitude is a rarity indeed. In fact, I sometime see the right attitude in another place--new recruits. They may be junior now, but I can tell they're on their way to senior responsibilities, just from their personalities. On the other hand, I've seen experienced veterans who still exhibit a "junior" mentality--essentially repeating an unremarkable performance year after year.

Given a choice on a challenging role, I'd rather pick the person with the right attitude. They may have a lot of learning they need to do, and they may make more mistakes as they come up to speed. The key thing however, is that I can trust them to actively try to learn whatever it is they need to learn--and that they'll use their mistakes to improve themselves and the process around them. That's talent worth developing.

Cracking the Millennial code

There's a lot of talk these days about the "Millennial" generation -- the kids born in the 1980's and 90's, who are now the faces of our new labor force. How do we motivate them? How do we manage them? The business world is abuzz with theories on how to turn Millennials into productive assets.

Ironically, this is the very approach I imagine Millennials look upon with disdain. I see them as any other new generation of human beings; they do not want to be judged, they want only the same thing we all do: which is to be acknowledged. They represent a step forward in the same way as we think of ourselves as a step forward from our grandfathers. Of course they are young and have a lot to learn, but what can we learn from them? Perhaps this is the key to making a connection.

I can think of many themes over the last few decades that not only influenced Milliennials, they also influenced me. Whatever faults the Millennials bring with them, their experiences and perspectives reflect truths that are worth contemplating.

Older generations glorify work; we literally brag about how busy we are, how little we sleep, and the overtime we spend at the office. If the company calls, we jump up to answer. Why shouldn't the Millennials think differently? All they saw come from that was an absence of family time, their parents getting divorced, and then being laid off for their troubles.

Older generations learned how to play well in corporate settings and follow company leadership. Millennials learned that you can't trust big business, the government, or groups of old men. Under the guise of propriety they polluted the environment, gave us tainted foods, told the wrong information, and trapped people into consuming what they produce. No wonder researchers have identified Millennials as the "least trusting" generation in decades. And all this harm to people and society for what? Company profits? No wonder Millennials are more interested in doing meaningful work, something that makes a positive social impact.

Like many new generations, I think the Millennials are sure the older generations screwed a lot of things up. And they're right. That's how we progress as a civilization; each new generation building on the one before it. The great concern, I realize, is that there are values, ethics, and attitudes that we fear Millennials do not possess but should, because they are worth retaining. However, I see little hope for any generation to pass their values to the next without acknowledging and meeting them part way. No doubt it is frustrating to deal with Millennials who don't conform to business as usual. Where did we have a hand in creating that? Rather than trying to psycho-analyze Millennials, perhaps the best approach is to try to understand where they're coming from--and recognize that the future depends on changes on both sides.

What to do when IT hits the fan

Sooner or later, technology problems happen. The server goes down, the deployment goes awry, or something just suddenly stops working. I've seen such events trigger more crises than I can count. Certainly there's cause for concern; sales may take a hit, reputations may be tarnished, leads may be lost, or productivity may come to a standstill. Therefore, we should be prepared to effectively deal with and resolve such emergencies--at least one would think.

Unfortunately, little thought is given to such procedures before things go wrong. This results in a lot of needless stress and emotional upheaval during and after an event. The way I imagine we should act when something goes wrong is how a trained responder would handle a medical emergency; by staying calm and systematically running down a prepared checklist. This would be in contrast to the generally unhelpful communication I often see during IT "emergencies", which may include angry emails, phone calls, and provocations which increase stress instead of helping to identify and solve the problem. While the IT folks may have an idea about how to diagnose the problem, the business folks don't know what to do or how to help. As a contingency, I think a checklist for reporting IT emergencies would look something like this:

1. Stay calm. This speaks for itself--staying calm and relaxed helps you and others around you think more clearly, which is paramount when trying to troubleshoot an urgent or complex problem. Adding unnecessary stress to the situation will only slow things down.

2. Verify the problem is occurring on more than just your computer. This may sound silly, but I've been chewed out many a time for problems that turned out be "user error" on the part of the reporter or something that occurred only on their computer--because of a firewall setting or an upgrade that wasn't applied, for example. The simple courtesy of double-checking can prevent wasted time and unnecessary frustration. It also makes the problem quicker to troubleshoot if it is only happening on your computer.

3. Provide a specific and detailed error report, with steps to recreate it. Simply complaining in broad terms that something is "broken" or "not working" might be gratifying to the reporter, but is a waste of precious time when it comes to the fixing the problem. Rather than starting a game of 20 questions, provide a screenshot and give details. Until someone knows exactly what the error looks like, and how to recreate it, no progress is likely to be made on fixing it.

4. Tell the complete story, even if you don't know what's connected and what's not. The error may or may not be connected to what you were doing right before it occurred. It may or may not be related to something you just installed. It may or may not be related to changes in the system environment. Nevertheless, providing as much context as you can is helpful--because if one of those things does matter, the problem will be found and solved much quicker.

5. Avoid touching anything until the problem is diagnosed. When you see a problem that looks serious, verify it it means putting a halt on other operations. It's possible to cause a "cascading error" by doing other things that require whatever is broken to be working. You don't want to turn a minor problem into a major one--it's better to assume nothing until someone with technical knowledge gives you the green light.

6. Don't be a bother while the problem is being fixed.
Your IT team will be stressed out when something breaks--trust me. They don't need you yelling at them so they "appreciate" the urgency and magnitude of the matter. Once you've given them the information they need, the best thing you can do is get out of their way and give them space to breathe, think, and collect their wits. That's what will get things resolved as quickly as possible.

I hope this list comes across as both simple and reasonable. By taking these principles to heart, I believe we can make strides towards dealing with IT problems as minor events instead of as a great strain on the organization.

The next step for human resources

I have a radical idea for how human resources can evolve when it comes to motivating and engaging employees. To explain, allow me to make an analogy with how marketing has evolved over the years.

In the beginning, we had one product for everybody. You could have any car you wanted, as long as it was a black Model T. Then the idea of market segmentation arose; splitting people into groups, then trying to figure out what those different groups want, and marketing to them something appropriate. Product variants become the hot item. Now the big thing is customization and personalization; every person is now a "market of one", and their product is customized to suit their individual tastes.

So what does this whirlwind summary of marketing history have to do with human resources? Well, along with these developments, the definition of "customer" has expanded. Everybody outside the organization has been identified as a type of customer, potential or actual. There's now an idea to recognize "internal customers" as well. If everyone is a customer now, does that not also extend to employees? I think it does.

Employees are customers of a company's leadership. If they like what the company is selling to them personally, in the form of a career and lifestyle, they make a purchase decision, or apply for a job. If they become dissatisfied with the "service" they receive, they quit, and take their labors elsewhere. How much they "buy" into an organization--it's vision, it's culture--affects their level of engagement and ultimately their productivity for that company.

When it comes to marketing to these internal customers, we're still selling a black Model T. Someone at the top of the organization dictates what all employees should want. Never mind the fact that Fred really wants more salary, Barney mainly wants more vacation, Betty would like her childcare and gym membership subsidized, and Wilma wants to be able to work from home twice a week. Yes, we are living in the Stone Age when it comes to personalizing HR.

There's a lot of talk about what Google, or Amazon, or Apple is doing in terms of perks for its employees. But there are some red herrings here, because I'm sure not every employee at these companies see the perks the same way. Some no doubt think they're the greatest; others will be neutral; and still others would prefer something else that they're not getting. What if we treated each employee as a customer in their own sense, and customize what the company provides them based on their individual wants and needs? In the war for talent this might be the next logical step.

Here's how to fix email

I distinctly remember the first time I missed an email. It was at my first job out of college; I had been assigned my first cube and my first work PC. Up until this time I had never even used Outlook before, only my personal email which I was use to checking every few days

I could see that I was going to need to upgrade my habits. Probably check email every morning--or so I thought. It took only a few days before my boss swung around to see me; "Didn't you see my email?", she asked. "Huh?", I replied. "Well I haven't checked it since this morning", I mumbled as I clicked the Outlook icon to open my mail again. Sure enough, in my inbox were several important messages I was supposed to be reading.

She looked at me quizzically. "You had Outlook closed?". That's when it hit me. I was used to the idea of only opening a program when I wanted to use it--it had never occurred to me that I was supposed to keep it open all the time, and let it notify me as to when it needed to be used.

This shift in thinking seems so obvious now. Since communication has become instant, we are expected to be on high alert at all times, responding to every request and inquiry in real time. Now I get email on my smartphone, and it beeps, or at the very least buzzes, to let me know that, wherever I am, I should reflexively grab my phone, read the latest missive fired in my direction, and tap out a response.

These constant interruptions to our day are universally recognized as the bane of personal and organizational productivity. This has been talked about by researchers extensively, so I don't have much to add about the detriments of constant email. I do, however, have an idea. We're all familiar with the "high priority" flag in Outlook--and how it's relatively useless and has no real functionality. How about something like this: suppose you do like to check email in the morning, and then would like to spend the rest of your day working without getting interrupted by every trivial message sent to your inbox.  Suppose you could program a setting in your mail program that you will work on email from 9-10 am every morning. Now, every email that is sent "low" or "normal" priority, would show up in your inbox at this time. After 10am, any such emails sent to you will be temporarily held in purgatory until the next day at 9am, when it's your email-checking time.

What about those emergency emails? That's where a "high priority" flag could come in. If it's truly high priority, it would bypass your 9-10am rule and hit your inbox immediately, so when you get pinged, you know it's something that is truly urgent and requires your immediate attention. The problem we normally encounter is that most of the emails we get throughout the day aren't important enough for us to drop everything to read them--but we have to do that to make sure. The question is, would a system like this work, or would people abuse it and consider all emails they send out as "high priority", bringing us back to square one?

Dedicated resources are everything

With few exceptions, I can put my project history into three categories. On projects that turned out to be resounding successes, I had a dedicated project team that worked on the project full-time. On projects that turned out unremarkable, members of the project team split their time between two projects. On projects that turned out mediocre, members of the team split their time between 3 or more projects.

Despite these results, we have a love-affair with taking on multiple projects at once. We overestimate our ability to do it well, and tend to ignore the mountain of results and scientific research that tells us we're incredibly bad at it. What amazes me most are the clever assumptions that are made as to why this can work. Let's take a look at a few--and why they don't really work.

"We will evenly split our time." This is the myth of percentages. The idea is that we'll allocate our time based on on a 50%/50% split between two projects, or 50%/25%/25% between three projects, or some other combination. Unfortunately, projects don't fall into place this neatly. Instead of spending 4 hours a day on project and 4 on the other, it's more likely to be 2 full days on one project (in order to meet its deadlines) followed by 3 full days on the other (to catch up on its deadlines). Or even more likely, pressing events on one project demand that it take 80-90% of a week's time so the other gets virtually ignored until the following week, when the tables are reversed. Deadlines, fires, and squeaking wheels cause time to be spent in intense, unpredictable bursts instead of as a steady "stream" which can be precisely throttled. It comes down to "who's getting the short end of the stick this week?"

"We will evenly split our focus." The lifeblood of projects is meetings, and competing projects nearly always mean meeting conflicts. Even missing a few meetings here and there can throttle down a project considerably while everyone waits for team members to get up to speed. There are also psychological limits to our attention; as researchers have noted, we have limited "attention units"; once they've been exhausted, say earlier in the day on one project, we end up, despite our best efforts, tuning out on our second project. The same goes for our creativity; it's tough to be brilliant on two projects when the act of being brilliant on one is likely to lead to creative exhaustion.

"We will stay on top of everything." To keep moving a forward, a project team needs two things on a very frequent and timely basis: feedback and approvals. If a team leader, needed to provide said feedback and approvals, happens to be juggling multiple projects, expect delays. I've routinely seen team members stuck or left hanging while they wait for their team leader to get back to them--who is usually entangled in a long meeting or intense effort on their other project--right when they are needed. If you can't be in two places at once, supporting multiple projects that each require timely attention is a non-starter.

"We can switch our attention as needed." Researchers report that the cost of task switching is higher than we'd like to admit. One study showed that it took 7 minutes for someone to get back "in the zone" after being interrupted by an email. Thanks to email, we can be assured that we will be pinged simultaneously on all of our projects. Carving out uninterrupted blocks of time is more of a myth than reality--even when we're working on just one project. My own conservative estimate is that we suffer a 20% drop in time-efficiency when working on two projects at once--with more severe consequences for even greater multi-tasking.

I have yet to discover any management or leadership "secret" which can compensate for the loss in effectiveness which occurs due to taking on multiple projects at once. While it may be necessary, I contend that it will be at the expense of superior results that would be achieved with a dedicated focus.

Why should we innovate?

The title of this blog post might seem nonsensical—everybody knows that you have to innovate these days in order to survive. That’s not what I’m asking. I’m asking why should we innovate for the organization? If I come up with a great idea, why shouldn’t I try to sell it or use it to start my own business? Why would I share it with the organization? Let’s admit it: this is a darned good question.

First of all, I might not even get credit for the idea. Somebody else might take it. Secondly, I might be throwing away all the potential rewards of the idea. Heck, I might be lucky if the company gives me so much as a “pat on the back” or some nominal form of recognition. Thirdly, it might not even do much for my career. The company might take my idea and profit greatly, but I’ll still be stuck where I am.  On top of all this, the idea might cause me a lot of extra work, stress, and hassle because the company wants me to develop it in addition  to everything else I have to do.

Now, I might be willing to share an idea I don’t really care about, and that won’t create a lot of work for me, if I happen to accidentally come up with one. Although offering up a bad idea is risky too--that could negatively impact my standing in the organization. Many of us have arrived at this same conclusion, which is why companies that exhort their employees to “be innovative” can look forward to hearing the sounds of crickets chirping.

While I’ve made my point here in a brutally frank way, what I’m driving at is that it is unrealistic for companies to expect innovation from their employees without a lot of "safety nets" in place. What kind of safety nets? Business researchers tell us that innovation actually does happen in companies that have extremely high levels of trust, extensive social bonding within the organization, and a supportive culture that recognizes individual contributions.

I think this explains why many companies are not innovative, and certainly not from top-to-bottom, even though it may be managerial decree. If the "innovation show" appears to be over once the folks at the top run out of ideas, then this is a telling sign. Unless the prerequisite of investing, supporting, and encouraging people is put into place, an organization's "well" of innovation is likely to look dry.

Why visible metrics lead us astray

The words of the day are “analytics”, “data”, and “metrics” of all sorts. We have conversion rates, ROI, CPC, impressions, transactions, and numerous others. Focusing on metrics seems to be important—except that it’s not what really drives excellence.

But isn’t “what gets measured gets managed”? With apologies to Peter Drucker, I’d like to make the case that it’s the things that are difficult to measure that are actually the most important. In fact, many of them are downright invisible. Take, for example, the matters of security and reliability. Let’s say I showed you two software applications, written by two teams, designed to do the same thing. They look virtually identical. One team took 10 months and invested over $500 million into making the software as reliable and secure as possible. The other team took 3 months and spent considerably less, but, for all intents and purposes, their app looks the same. By conventional measures, the second team has a far superior ROI—unless their application gets hacked or experiences a critical failure. But how do you account for the “quality of the code”? It’s not something you can even see—how do you measure it or quantify its value?

Going further, how do you measure usability and design? How do you measure craftsmanship? My chief concern is this: “what can’t be easily measured gets de-prioritized.” An over-emphasis on metrics is akin to focusing on the symptoms of a problem rather than the problem itself. Managing the symptoms to where we want them does not necessarily mean we're healthy.

This strikes right at the core of an organization. How do you measure integrity? Employee engagement? Trust? These things are difficult to quantify, yet business researchers confirm time and again that those organizations that have them in abundance outperform all others. In fact, at the foundation of great performance is often “quiet work”—the steady and meticulous efforts of those who provide support, perform essential calculations, or attend to the fit and finish of things. It is the essential work behind the scenes and below the surface, and the qualities of an organization that cannot be immediately tied to ROI, that makes possible the visible outcomes. There are many loud, aggressive, and extroverted parties selling the benefits of visible metrics—and while these are important, let’s not let that distract from the fact that the most important things we need to work on are not as easily measured.

“Self organizing” teams still need guidance

While I like the concept of a “self organizing” team, I’ve always been a little uncomfortable with the term. What worries me is that it might suggest that teams are, or should be, self-sufficient, which I would argue is not the case. An argument might be made that “leaders” or “managers” can get in the way of a team’s focus. This is sometimes true; but I think equally true is that leaders and managers can help a team focus. While providing latitude in the right way, and empowering a team, is a hot topic, we should also be mindful of the types of “coaching” we can—and need—to actively provide teams. This has less to do with handing out tasks and assignments and more to do with the social aspects of teamwork.  Understanding each team member and helping them align to the work in small ways facilitates overall team performance. Here, from my experience, are a few examples of where such coaching is needed:

Getting unstuck. Some team members inevitably get hung up on small details or points of confusion or uncertainty. Although these may not technically be considered “impediments”, they cause team members to spin their wheels, or stop work altogether as they wrestle with a particular issue. It takes a level of alertness to recognize when this happens, and to provide guidance or support when it does so the team member can keep moving forward.  

Seeing the small details. While other team members are excellent “big-picture” thinkers, and can seemingly move forward in a self-directed manner, I’ve found that in doing so they sometimes miss small details or make certain assumptions which, if left unchecked, can lead to off-target results. Again, a level of alertness is required to help provide small adjustments before work gets too far along.

Putting things into perspective. Complex or challenging projects come with a dose of stress and frustration. Team members can easily become demoralized for a variety of reasons and lose their momentum. Lifting spirits, acknowledging difficulties, and encouraging a positive perspective is often a critical need.

Sounding things out. Some team members need to bounce ideas off others in order to clarify their own thinking or understanding. Sometimes they just need someone to listen while they talk through a problem—even coming to the answer themselves as they do so. In such cases, the key to productivity is simply being ready to lend an ear.

Staying on the vision. Occasionally, in their enthusiasm, a team may start shifting a project towards something they’re imagining instead of the original vision or requirements. In such cases it’s valuable to step in simply to remind everyone what the vision is—so they can re-align to it. Being able to do so without negating any effort the team has made is a valuable skill in itself.

As long as teams continue to be made up of human beings, I predict such coaching will be a needed asset. In my mind a “self-organizing” team may mean we should mostly get out of the way—but we should stay very close by and ready to jump in.