This post is the forty-second part of a ramble-rant about the software business. The current posts in this series can be found on the series landing page.
This post is about the removing obstacles to performance (in people).
People Are Good
I believe people want to perform well – in life, on the job, in business and personal relationships. I think this is the natural state of most people, that people are basically good. There are some exceptions, obviously, and I think society has mechanisms for correcting deviations. And all people deviate from time to time through habit, error, or poor choices. But essentially, people want to do good and be good.
Daniel Pink writes about the work of Edward Deci discovering and measuring individual motivations in the book Drive; Clay Shirky writes about the same topic in is book Cognitive Surplus. Some of Deci’s work measures the effect of removing love from work. It does not, as popularly misinterpreted in business schools around the world, establish a link between stagnant pay and consistent performance.
I think leaders often get in the way of this inherent motivation in people to do good. Most of the time, this is unintentional. Sometimes it isn’t unintentional. There are people out there who derive pleasure from manipulating others. Some requests made by leadership are reasonable and must simply be executed. This is the use case for military orders delivered during combat. But most of us aren’t in physical combat (God bless those who are, I pray for them). The closest we come to this scenario is agile business or development environments where fast action and response is critical to success. The leader may have access to more information than is available to those she leads. In these scenarios, communication is vital. But even more vital is a history of trust and respect. If the leader is not the type of person to abuse their authority merely to enjoy the reactions of others, the leader is more apt to obtain the trust and respect of those they lead. Professionals want to know why they’re being asked to do something because they want to do a good job. If they know why, they will be able to adapt to and overcome obstacles – perhaps reducing the time or adding success to the achievement.
Holding up a hoop and expecting others to jump through? Ordering “Jump!” to hear others respond “How high?” These are simply blocking requests.
What do I mean by blocking requests? The human brain is an awesome processor. I recently read an estimate that the total computational power on the planet at this time is comparable to that of the computing power of a single human brain. While that represents the astounding amount of capacity required by conscious thought, it reflects the fact that the human mind’s abilities are also finite. People can (and do) use their minds to create amazing inventions and philosophies, to conceive art and discover science; but the mind cannot produce more mind. At least not in 2011.
Conscious attention is a subset of the working cognitive brain power available. Blocking requests – holding up hoops or ordering others to jump – consume cycles better spent on other tasks.
One example comes from a past conversation with a gifted technologist. He is well-known in his field as someone who’s created elegant solutions to complex problems. He’s currently employed by a company that believes anything he invents during his tenure with the company – whether on the clock or off – belongs to the company. It gets worse: As a condition of employment, he was required to sign a document to this effect. The result? He’s stopped innovating outside of work. This has impacted his performance on the job, as well as his opinion of the company for which he works. He longs for trust and respect, he wants to love his job. But this agreement effectively limits the cycles he desires to put into work outside of company employment, which in turn undercuts his continuing education, which in turn limits his effectiveness at work, which in turn reduces his performance, which in turn depresses him. It’s an engine of loss.
I formally encountered Agile Software Development in the late 1990’s via a variation of Test-Driven Development known as Fail-First Development. The idea is to begin by writing a test, execute the test (it should always fail first), then add code until the test succeeds. The methodology helps young engineers formulate their thinking, prioritizing the steps to achieve a working system. I loved it because I wrote a lot of code that failed the first time I executed it. TDD was a natural fit for me! (It still is…)
The elegance of Agile Software Development lies in its truth. First and foremost, Agile acknowledges some uncomfortable truths about software development. Next, Agile incorporates those tenets into a framework that produces better software. By recognizing the physics involved in software creation, Agile enables developers to see beyond the box and perform better.
Previous software methodologies grew from manufacturing and construction thinking. And it worked. For a while. It worked because software implementations were performed on relatively crude machines (which were themselves subject to the manufacturing / construction paradigms). When true abstraction began, gaps in the manufacturing / construction thinking began appearing. It’s not possible to build a skyscraper starting with the 42nd floor; but it’s commonplace in 2011 to model the presentation layer in software development early in the project. And by “model”, I mean build quickly using a tool that allows you to demonstrate intent and later convert into production code. The model is, effectively, the 42nd floor; and it’s built early to gather feedback from the customer and users. Attempting to apply manufacturing and construction methodologies to modern software development is increasingly difficult. It no longer maps. It’s no longer accurate. It’s no longer true.
In a nutshell, Agile doesn’t lie about software development.
In the current market, talented technologists move from venture to venture every couple years. While they’re at Venture A, they learn stuff that inevitably finds its way into their work at Venture B; stuff that inevitably finds its way into their work at Venture C… And so the cycle repeats. Companies trying to protect intellectual property pay lawyers to draft long contractual documents to ostensibly preclude industrial espionage; but they also – conveniently – stifle competition and innovation, as in the case of the gifted technologist I mentioned earlier. Non-compete documentation fails almost every time it comes to trial, because many of the cases come down to an individual’s ability to earn a living. (== Summary == Standard deviation diagram, based an original graph by Jeremy Kemp, in 2005-02-09 [http://pbeirne.com/Programming/gaussian.ps]. This figure was started in R using: <pre> x <- seq(-4,4,.1) plot(x,dnorm(x),type)
People grow. Technologists learn stuff. They “play”. It’s in their nature to do so. But non-compete agreements stifle their creativity and are not enforceable. They leverage the fear of prosecution and the integrity of the individual to abuse power and, ultimately, present a barrier to excellence. They effectively shave the last sigma or two from the bell curve of technologist thought and capability. This is precisely the domain where the 100x, 1,000x, and 1,000,000x innovations and inventions dwell.
What a sad state of affairs.
What would happen if businesses adopted a solution that recognized the conditions of modern economics for gifted technologists? What if, instead of punishing the technologist for learning as she grows from engagement to engagement, we defined business practices that accept or even encourage the nomadic nature of the technology market? What if we stopped lying? What would happen if we embraced the truth?
What would this look like in practice?
No Non-Compete Agreements
For one; unenforceable, innovation-killing non-compete agreements would go the way of the horse and buggy – quaint, nostalgic, but not useful in modern practice.
In the place of non-competes, imagine ownership agreements that express that the
serf inventor of an idea owns the idea (I know! Crazy, isn’t it?) and that this extends to works derived from the current employer’s intellectual property. Business leaders and MBAs are of two minds when it comes to derivative works. On one hand, they don’t mind it one bit when they derive something from another patented process and profit from it. On the other hand, they expressly forbid as many others as possible from doing the same thing to their inventions (see hypocritical).
Once the technologist is free to innovate, they can produce unimaginably awesome technology. And again, most technologists are good people who want to do a good job; so they’re more than willing to share the spoils with the employer who allowed (or facilitated, even!) their success in innovation (Note: I’m speaking of a minority stake). This is due in large part to the thrill of producing experienced by every technologist I know. Once this thrill is experienced, the technologist wants to do it again. And again. This stands in stark contrast to the gambling nature of the modern MBA who’s sole purpose in life is to score big on “one huge innovation” and then retire to Tahiti, consequences to plebeians roundly ignored.
Should the MBA / business own a (minority) stake in the derivative work? Once the non-compete thinking is abolished, such a suggestion becomes plausible. It’s amazing the possibilities that emerge once the threat of starving and/or bankruptcy are removed from the equation.
This post was inspired from two sources: conversations with my business partner Brian Moran (@briancmoran) and a comment in an anecdote from The Art of Possibility, recommended here by my friend and brother K. Brian Kelley (Blog | @kbriankelley | SQLPeople). Brian Moran and I are intentionally and deliberately defining a philosophy for our new business. We believe it is important and worth the effort.
The comment from The Art of Possibility is from an anecdote on pages 37 and 38 of the paperback edition. It’s about an orchestral conductor’s response to a musician who was disengaged from the piece of music at hand. After he found a way to engage her (he listened to her complaint – again, crazy idea) he had this comment:
"When I had been viewing her as an unimportant casualty, I had to pretend it did not matter that for some reason she was not engaged. Meanwhile, I wasted energy both watching and ignoring her."
Wow. Think of all the energy wasted in companies today. Think of all the energy wasted in communities viewing members as unimportant casualties (vocal minorities).
The conductor's final conclusion after communicating with this individual?
"The lesson I learned is that the player who looks least engaged may be the most committed member of the group."
Are we smarter than this? Can we find a better way?