Take A-List coders, for example. Characterized by the (alleged) quality of the code they write, the (alleged) speed at which they work, and their (alleged) ability to deliver exactly what their bosses ask for, A-list coders are the holy grail of software design. Rumors of their miraculous powers notwithstanding, “A-List” is merely a convenient and unscientific distinction: there is no certification for or test to become an A-List coder. In spite of this, there seems to be a legitimate group of coders who routinely outperform others in stressful situations.So who are these people and are their deeds really heroic?At Gray Hill Solutions, we too sought out these de facto heroes to deliver us from crises. It was only after several years of working with both the vaunted and their more humbly-titled brethren that we came to an interesting realization: A-listers were successful not because they had superior programming skills, but because they took the time to learn why they were building the software in the first place. They sought clarity from the onset, gathering vital information and incorporating it into their design. If the pertinent information wasn’t readily available, they used deductive reasoning to devise a plan to obtain it. Once they found clarity, they had the freedom to innovate and the ability to outperform their colleagues.When we recognized that the real superpower at play here was the foresight to seek out hidden clarity, we introduced a visual control—a kanban—to provide clarity to the entire team. It wasn’t long before we discovered Band C-list coders rose to meet or even surpass their A-list colleagues. The logical conclusion here: A-list artistry is not born of technical prowess, but of clarity of purpose.
Does this mean that kanban is the path to greatness? No, not really. Does this mean that a product should be designed by committee, so that every participant is fully onboard? No, not that either. However, it does mean that engineers should be allowed to ask questions – deep, meaningful, and potentially difficult questions – to achieve that clarity. This is why having a vision for a product is so important; it can be used as a common ground, a “first principles,” so that even in the absence of explicit instruction everybody can continue to work towards the same goal.
The flipside of that is a product that doesn’t seem to have a clear vision, a product where the key stakeholder(s) aren’t really sure what they want or are ambivalent (or, worse, obfuscatory) about their goals. This ambiguity, this confusion, can lead to even the greatest A-List coders or other engineers producing barely middling results, or otherwise underperforming.
