Agreed. "A" players aren't necessarily prima donnas, and as you said, they spend most of their time as worker bees functioning as members of a team, getting a project completed and out the door.
Yes, when a project requires a big leap forward or something radically new and different, you need your A players to achieve that. But those leaps aren't needed every workday, or throughout the duration of the project. The A players are critical at the architecture and concept phase, but they will not be content -- nor can the company afford -- for them to sit on the sidelines while the B players do the implementation, verification and release to production.
One item only presented tangentially in the ten rules is the significance of interruption. While interruption often inhibits productivity (even strong multitaskers can suffer from unpredictable or frequent interruptions), it can also be important in supporting creativity. Part of the utility of 20% time comes from this. Some workers may need to be encouraged to step away from a problem (sleep has some of this effect), potentially by a co-worker rather than the manager.
Code review not only leads to more maintainable code but also helps expose assumptions which may affect component integration. (The reduction in the criticality of the single developer not only potentially reduces stress and hubris but also builds up the skills and familiarity of co-workers with respect to the component and with respect to the developer. Knowing a co-worker's strengths and peculiarities can improve morale and reduce communication overhead--well-founded trust reduces communication, knowing how to make a request reduces risk of miscommunication [less need for "ECC overhead" and retransmission].)
As Brooks points out (in MMM), communication overhead is a major constraint in large projects (where the significance of size is related to timing constraints). Some communication overhead is unavoidable--even a single developer can benefit from his/her own documentation--, but reducing this overhead is one of the reasons that more skilled developers add disproportionate value. However, high performance nodes will not be as effective if their network links are bad (poor communication skills, inadequate protocols), the routers are bad (when information is not sent to the proper destination or the proper "protocol" translation is not performed [e.g., filtering and organizing information to suit the target]), or the network topology is bad.
Obviously, I am not good at communicating given how long this reply is (while so much information is not expressed)!
As cdhmanning pointed out, knowing the workers and developing and maintaining the "organism" is important (and not only for managers--knowing how to communicate with individual co-workers and with whom to communicate is important, not just facts but also emotional content).
One item that I recall from Brooks' The Mythical Man-Month (which has a lot of classic wisdom on project management) was the use of dual-track promotion, but perhaps this should be generalized to providing different reward structures for different people.
(Brooks' MMM also mentioned the distinction between status communication and actionable communication, which relates to the first rule. Status communication is not meant to be an invitation to propose solutions.)
Automation is only a one type of offloading work. Even some tasks which cannot be automated can be offloaded onto another person, allowing concentration on the actual work and not the necessary support activities. Not only does such reduce distraction, but it can also improve morale (when the offloaded tasks are not suited to the person) and provide apprenticeship opportunities (which is important for growing talent).
[to be continued]
I don't think these oversimplified generalizations reflect reality, however.
Reality is that the so-called A players spend a lot of time also functioning as worker bees (presumably what you call B players). But they still drive the innovation. The more of these you have, and I mean real ones and not just prima donnas who are mostly impressed by themselves, the better off you are.
I think reading about Belbin team structures would really help.
Perhaps by "A players" you mean Plant and Shaper types. Those that bring in massively new ideas and like to drive architectures and change. Clearly too many of those just makes for a mess.
Perhaps by B-players you mean the Completer-Finishers and others: the "worker bees" that need direction but work diligently until the product works properly.
Sure, if you are working on fairly pedestrian products that don't need a lot of technical innovation, then you want lots of Completer-Finisher types. You don't want a bunch of people making changes for the sake of change that they leave unfinished.
But a team full of Completer-Finishers won't get the job done if the product is completely new or a project needs some radical changes to get things going.
Like most things in life, you need a balance. There is no magic recipe (eg. three Comp[eter-Finisher to one Plant) as each project is different and each phase of development is different too.
Perhaps, but the B players will always make you money with good solid products. A players are hit and miss. When they are good, they are very good. When the fail, they fail bigtime.
No matter how you look at it, A players are gambles,they are not team players, they do not communicate well, and forget about getting any useful documentation. You still need a core of B players to go in and restore order to the chaos left by the A player.
There is no problem with many A players so long as they know the role they are playing.
For a good understanding of dynamics, I highly recommend reading up on the Belbin team roles.
Where A-loaded teams go wrong is when too many of them are the Plant or Shaper type and far too much time gets spent on exploring perfect solutions rather than just making a good system.
The time when you *do* need A players is when the project needs a huge leap forward to get to a new level. Your B players just can't do that.
In my experience, I could get better work done with a group of "B" players who followed a good process than I ever got from an "A" player. "A" players do what they want based upon their EGO that they can't fail. Unfortunately, they do. "B" players know they have limitations and are more likely to collaborate and help one another because they know that they ALL have to succeed or the project fails. Plus "A" players tend to be a pain in the A&% and difficult to manage. Who needs them!
I agree with the trend, in the US, to more of a "free agent" self-identification, among engineers. Even those who work for large companies. And I don't think there's anything wrong with that trend, especially in view of how fast companies sell off divisions, or how readily they lay off employees these days.
I've been lucky to work for a (large) company that treats engineers right, identifies itself as an engineering company first and foremost, and my own managers have tended to let us do our thing. Not much micromanagement going on, at least, not unless the engineers prove that they can't carry on on their own!
Why? Perhaps it has to do with two things: 1)America's inherent respect for the individual, and 2) the, "anti-BIG" movement, as I call it, that is going on now. Big Business, Big Government and other "Big" institutions are in doubt. What's left but the identity of the sovereign individual?
That's the long view. On a more specific note the company-employee relationship has changed here in America. For many reasons, but chief amoung them is that managers and Government Compliance Offices (known to most as HR departments) have made sure that working for the likes of IBM is as vanilla and predictable an experience as working for the comapny down the road.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...