Career Managing People Teambuilding

I believe in “A teams” over “A players”

By Jim Grey (about)

I’ve heard it again and again at work. “We need to hire a real A player for this job, a total rock star.”

A test team I once belonged to, dressed as crayons for Halloween. I’m the gray crayon, natch. Our colorful dunce caps do not mean we weren’t A players!

This statement usually comes at a time some critical task or function isn’t being done well (or at all) and it’s causing projects to fail. “If we can just bring in a super-skilled specialist,” the thinking goes, “it would solve all of our problems!”

Sometimes this gets stretched into a one-size-fits-all approach to hiring. “Let’s hire only A players,” someone proclaims, “and then get out of their way and let them perform.”

No doubt about it: A players are extremely talented and deeply experienced. They are heavily self-motivated and especially hardworking. They are creative problem solvers who focus on getting the job done.

But don’t assume that putting A players on the job is like sprinkling magic fairy dust that makes problems go away. That’s setting them up to fail – and setting your company up to fail, too. Companies are much better served building high-performing teams.

A players are no substitute for leadership. The most important step in that leadership is to help your people form solid teams. I’ve been in software-company leadership roles for more than 15 years now. I’ve delivered many, many successful software projects with teams made mostly of B players. But those successes came after company leadership:

  • Created a shared, common vision that everybody rallied around and focused on
  • Built a process framework within which team members worked, which set standards for workflow, quality, and completion
  • Praised and rewarded team members for jobs well done
  • Hired for fit within the company culture, as well as for skill

A players are hard to find. A reason why I often hire B players is because most people aren’t A players. I’d say less than one in ten people I’ve ever worked with are that good. I make software in Indianapolis, which we sometimes call the Silicon Cornfield. Many of the truly outstanding geeks move to California, North Carolina, or Texas, where the opportunities are greater. But even in those places, there are only so many A players to go around. Sooner or later you have to hire B players too. Those B players will work best under strong leadership and in highly functioning teams.

A players often have the biggest egos. A little swagger is part of the A-player territory. If you don’t lead well and help them gel into a team, conflicting egos will put your projects at risk.

A long time ago I followed, a once-popular Internet forum about music. In a recurring discussion thread, members wrote about which musicians they’d put in the best supergroup ever. The debate raged – Eric Clapton on guitar, and Neil Peart on the drums, and Paul McCartney on bass, … no no, Phil Collins on drums and Jeff Beck on guitar! …no! It must be John Paul Jones on bass!

It was fun to fantasize about such things. But do you really think a band with some of the biggest egos in music would gel? I’m reminded of We Are the World, the 1985 charity song recorded by a supergroup of pretty much every popular musician of the time. The famous story goes that someone taped a sign that read, “Check Your Egos At the Door” on the recording-studio entrance – but that didn’t stop arguments over many of the recording’s details, with at least one musician walking out and not returning.

Don’t let that be your team.

Still, A players can be mighty useful. There are times when it’s right to hire A players. Here are the times when I’ve settled for no less than an A player:

  • Lead roles – I needed someone to figure out some thorny problems, and to set the pace and point the way for the team.
  • Lone wolves – I needed someone for a highly specialized job where I was unlikely to need more people in that role for a long time, especially a role where I lacked the skills to do it myself and therefore would have a hard time managing its details.

Really, I’ve never not hired an A player just because he or she was an A player. Who wouldn’t want their skill and determination on the team? I’ve only passed on A players when they would be a poor cultural fit in my company and in my team.

The Business of Software

Much ado about Flickr

By Jim Grey (about)

I was shocked when I logged into Flickr last week and found an entirely new interface.

I'm staying right here at Flickr
My Flickr homepage.

My shock turned to disappointment and sadness that some of my contacts were super angry about the change, left strongly worded comments on their photostreams, and immediately moved their photos to other services.

make software products for a living; I’ve seen firsthand how interface changes can alienate users. They become comfortable with a product’s features and usage, even when they’re flawed. They don’t want to learn anything new (which often masks a fear that they can’t learn something new).

At the same time, Flickr (and Facebook and any other thing you do on the Web) is a product, built by a company that is trying to make money in an ever-changing landscape.

I’ve seen it often, and it’s happened at companies where I’ve worked: A company builds a good product that takes off. Success causes the company to grow or to be sold to a larger company. And then some scrappy startup company builds a product in an overlapping market that becomes a new darling. By then, the big company is so invested in what it’s always done that it struggles to adapt to the shifting market.

From where I sit, it looks like all of this happened to Flickr. Founded in 2004, Flickr quickly became arguably the king of the hill among photo-sharing sites. Web giant Yahoo! quickly noticed and, in 2006, bought the fledgling company. Success!

But consider all that’s happened in photography and on the Web since 2006. Most people had just discarded their film cameras for digital cameras. Soon cameras in phones became good enough for casual, everyday use; many of them are now very good. Users found it easy to share their photos across any number of the social networks that had emerged – primarily Facebook, which was founded in 2004, too, but also on upstart Instagram. Today, the three cameras that take the most photos uploaded to Flickr are all iPhones.

The market has shifted. It was a matter of time before Flickr either responded or became a niche product of ever decreasing importance. This new interface is its bid to stay relevant. I’m impressed with Yahoo! for moving Flickr so boldly.

I think that if people give the new interface a chance, it will work for most of them. I’ve heard complaints about slowness; I advise patience as Yahoo! would be foolish not to address legitimate performance problems. I’ve heard complaints about how crowded the interface feels; I’m also sure Yahoo! will tweak the new interface over time for better usability.

Another source of uproar is that advertising now adorns Flickr pages. I hate Web ads too, but really, they are the major way many Web products make money.

I sympathize a little with one complaint: all of us who bought Flickr Pro accounts for unlimited photo uploads now feel kind of let down, given that everybody gets a terabyte of storage now. That much storage might as well be unlimited; you could upload one photo a day for the rest of your life and never run out of space. But Flickr is letting us cancel our Pro accounts with a pro-rated refund, or keep Pro at its rate of $25 per year and never see an ad. Anybody who doesn’t have Pro already will have to pay $50 per year for that same privilege. I think this is a reasonable trade.

Flickr’s real mistake might be in underestimating how attached its users were to the old interface. But if my experience is any indication, perhaps that mistake won’t be fatal. Of my contacts, about five percent of them have moved to other services. I’ll miss seeing their photos. I wonder if they’ll soon miss the rest of the Flickr community.

Cross-posted from my personal blog, Down the Road.


A thing called platform support and why Android makes me nuts

By Jim Grey (about)

“Our product is a Web app,” the CEO said. “Why wouldn’t it work flawlessly on an iPad?”

The answer, of course, was that we didn’t build it with the iPad in mind. When we got it to work on our PCs on Chrome, we declared it done. But some guy at one customer site decided to run it on his iPad, and he was upset because it didn’t work “at all.” Support escalated the case to Engineering, where one of the testers poked around the product on her personal iPad. She found that she could log in, navigate, and enter data on any screen. “It was a pain. I’d rather do it on my laptop any day. But it did work,” she said.

So we were puzzled by our user’s bad experience. And then we learned that he had an original iPad. Our tester had a fourth-generation iPad – on more modern hardware and the latest version of iOS. Unless we wanted to shop for an old iPad on eBay, we were never going to get to the bottom of this complaint. The user wasn’t thrilled when we told him that we couldn’t support his old tablet.

Crushed under the weight of platform support

If you don’t tell your users what they can use to access and run your product, they will run it on whatever they want. When it doesn’t work, they’ll demand you support it. This will crush you. You need to set some limits.

This isn’t meant to be done by fiat. You need to think it through: What are your customers likely to want to use? You need to be there. How will they access your product – devices, operating systems, browsers? If your product will be installed on their equipment, what hardware (or virtual servers), operating systems, and databases are they likely to use? If your product interfaces with other products, what versions will your users want to use?

What you’re doing is limiting the edge cases, like that user’s original iPad. You’re also limiting the list to what you can meaningfully test.

Creating a matrix of supported platforms

Create a spreadsheet that says your product runs on and with these versions of these other products. If you support several versions of your product, the list of supported platforms will probably vary a little version to version.

Give the spreadsheet to support and sales and say, “Use this to set expectations. If they want to use something that’s not on this list, try to talk them into sticking to the matrix. If they insist on going their own way, tell them we might not help them if they have problems.”

This isn’t a once-and-done job. New versions of your supported platforms will be released. Your users will want to use entirely new products with your product. You’ll have to decide when and whether to add them to your matrix. You’ll need to remove old platforms from the matrix sometimes. You need to keep gathering information and keep updating the matrix.

You can’t support it all: why I hate Android
IMG_5629 sm
I used to have a Palm Pre (right). I loved it, but it was on nobody’s platform matrix! My iPhone 5 (left) is on everybody’s matrix.

Still stinging from the customer who had the bad iPad experience, the CEO asked, “Do we have any idea how the mobile Web site behaves on Android? It needs to run on Android, too. It needs to run on any device they have in their hands.”

The problem with Android is that there are eleventeen base versions in active use, each of which a vendor can customize for their devices. And the devices themselves run the processing-power and screen-resolution gamut. When I explained that I’d need to buy a hundred devices and hire twenty testers to test them all, the CEO became less excited about Android.

You can limit the scope of Android, and any other platform with a lot of permutations, by deciding which permutations you’ll support and testing only those. As I write this, the 2.3.x (Gingerbread) versions of Android are the most widely used. You can buy a couple of popular devices on that version and test just those.

The only challenge is that where there are lots of permutations, you’ll have plenty of users on unsupported permutations who aren’t going to be happy.

This reminds me of the browser interoperability problems from several years ago, and why companies usually limited their Web apps to work only on Internet Explorer. Browsers are better now, and it’s more common for Web apps to work on any modern browser. Here’s hoping Android settles down as browsers have.

You can’t test it all: Supported vs. Certified

The items on your supported platforms matrix needs to be things with which your product actually works. As much as possible, design your product up front to work with them. But if you’ve just created a supported platforms matrix for a product that’s been around a while, the best you can do is test your product with those supported platforms to find out where the bugs are. The knee-jerk approach is to do a “full” (whatever that means) regression test on every platform.

One place I worked, our supported platforms matrix grew huge. When we printed it, we needed a jeweler’s loupe to read it. For each version of our product, there were fifty or more supported platforms. I couldn’t afford the army of testers I’d need to do “full” regression passes on them all.

But all that testing really wasn’t necessary. You can look at what’s new in the latest version of a supported platform and make a pretty good assessment of the risk to your product, and size your testing accordingly. For example, a product I used to work on ran on the Oracle and SQL Server databases. When Oracle 11g Release 2 ( came out, it offered enough new stuff that we weren’t sure how it would run with our product. So in our next release, we did our normal release testing, including regression, on that database. We also ran some special tests that exercised our most complicated SQL queries on it. We found and fixed some bugs that way.

When Oracle issued, we looked at what was new in that release and saw no reason to believe that any of it would create new bugs in our product. Our experience was that if a database version was going to throw bugs in our product, those bugs would be foundational and would appear right away under even light testing. We had a bug-fix release coming up, so we installed on that test server and tested the bug fixes on it. The release sailed through testing, so we shipped it and added to the supported platforms matrix.

Platforms that got the so-called “full” test treatment were listed as “Certified” on the matrix. What we told our customers was that we had “performed a certification test” on the platform, had fixed the bugs we found, and were highly confident of a good experience on that platform.

Platforms that got light testing were listed as “Supported” on the matrix. Sometimes our analysis showed low enough risk that we did no testing and still called the platform Supported. We told our customers that we expected that they would have a good experience on that platform.

The bottom line for both Certified and Supported was that if the customer experienced a problem, we’d take their call and resolve their issue.

The bigger bottom line is that you want a manageable list of platforms with and on which you believe your users will have good experiences using your product, a list that won’t kill you to keep up with. Through understanding what your customers want, limiting the list to the most common and important platforms, and varying the depth of testing based on risk, you can keep up.


Even a mediocre plan will work if everybody follows it

By Jim Grey (about)

I have been astonished in my life by how few problems are truly unsolvable. I have also noticed that, most of the time, when a problem ends up not being solved it is for one of two reasons: people deny the problem, or they won’t work together on the solution.

There are any number of ways to make software. All of them involve programming, of course; it’s the core activity. But there are other jobs to perform, and the bigger the software being developed, the more people you need to perform them. It becomes necessary to organize the people and form work processes. The ways to do that range from loose and chaotic to structured but flexible to ponderous and formal. They all have their strengths and weaknesses; they all can work. I’ve made software in all of these situations.

Perfect gravel road
Even a gravel road will get you there.

One of my past employers sequestered its programmers in a room to hack code together as fast as they could. When they were done, a couple people would play with the product for a week or two in hopes of finding some bugs, which the programmers might or might not fix. Then we shipped it to five customers, who upon installing it invariably found that it failed spectacularly. When we fixed all the problems they found, we chose five more customers. We repeated this process until the software stopped failing, and then announced to the rest of our customers that it was ready.

At the other end of the scale, another past employer had such a heavy software development process that following it felt like slipping into a straitjacket. There were reams of documentation to write and keep with layers of approval at each step. I led the test team. We had to take a screen shot of every test step, print it, and put it in a folder. At the end of a project, we had boxes and boxes and boxes of printouts, hundreds of pounds worth, that we would send to an offsite storage facility. This was in case our only customer, which happened to be the U.S. government, wanted to audit us.

Both companies are still in business.

A third past employer carefully hired smart people and trusted them to know what to do. Because they hired well, this worked for a long time. But as the company grew, this approach became more and more difficult to manage. Product quality became a problem. A big part of the software was an accounting package, and in one fateful release the general ledger simply would not balance. This affected every customer, and to make a long story short, it took the company almost a year to fix it. Several customers quit us.

Too often it takes great pain to drive important change. This pain made us face that we needed more structure to deliver successfully. So we hired a consultant to guide us toward a better software development process. He showed us a way with just enough checks and balances that we could have greater confidence in our work without being too bogged down. We also hired a consultant to help the management team (of which I was a part) work more collaboratively. She taught us how to lead the company through this transition.

It worked. In the very first product release under the new process, quality problems fell off dramatically and we delivered on time for the first time anybody could remember.

The more important hire was the second consultant. The new methodology was good, but it wasn’t magic, and it might not have worked for us if we had not done a good job helping the team through the changes. You see, a few people didn’t understand why the old way couldn’t still work and still others thought our new process wasn’t going far enough. Our task was to overcome the resistance and get everybody singing from the same sheet of music, and it was the hardest thing we did. But we pulled it off.

It’s a rare organization that faces its failings and works to change. It’s a rarer organization still that drives change collaboratively.