At work we decided to watch a very interesting webcast of a conversation with Eric Ries and Rally Software’s Founder Ryan Martens and CTO Zach Nies. Eric Ries is the author of Lean Start-up, currently holding the 9th spot on the New York Times best-selling business book list; Rally specializes in software to help with Agile Development, kind of a Basecamp for Agile – if you’re a PM and know what I mean by “Basecamp.” For those who don’t, these are online tools for managing projects, tracking deadlines and to-do lists, etc.
I had just been talking with someone in the morning about the need to change mindset within companies to really find a way to “Work Different.” There’s a challenge with teams in getting folks to understand it is safe not to be told what to do at every step of the way. What went unsaid in this conversation was brought out in the Lean/Agile webcast. It all comes back to not feeling like you might lose your job if you take a risk.
The same idea about mindset came up in this webcast conversation as it relates to the entrepreneurial propensity towards taking risks. The interesting dimension they discussed is what we, in the PM world, call “risk management.” Meaning, when you’re facing the chance that all could fail and you want to say “I’m scared that [x condition] will cause [y result],” you say instead “There’s a risk of [y result] and here are the ways we can mitigate that.” Risk management might not lead to innovation. This is because the very hypothesis behind risk management is that you can and should head off failure. With that approach, no wonder folks are scared to take a chance and try things. Seems obvious, right, they don’t want to take the risk. It comes back to a willingness to learn and to see past failures in Corporate America.
On the other side, I’ve worked with people who have no idea about this “risk” word, and no idea that they are actually taking all kinds of risks and just passing them downstream to downtrodden teams that then receive the risk and must “make it happen.” Usually these risks, however, are really about making hypotheses and not testing these hypotheses at all.
For me this is the important take away from Eric Ries’ work, if you had to write a TV Guide line about it: “Examine your assumptions as if they were scientific hypotheses.” However, one thing we all have to keep in mind is that the whole idea that we can be objective or empirical may itself be a flawed assumption. See my posts “We Look to Scientists to Settle Them” and “We Are Not As Smart as We Think” to see what I mean. We have so many assumptions that it takes quite a bit of digging to find the start of the assumptions. This leads us not to be very objective or empirical–and maybe not even so capable of objectivity or empiricism. But you have to start somewhere.
It occurred to me that the testing of hypotheses is not an exactly new idea. I was working on a start-up back, well, back a good bit ago, and the Boston Consulting Group guys running the show would list out what they called “testable propositions.” I don’t know if that was particular to the BCG methodology. I do know that we explicitly thought to test some of the hypotheses we were making about the product we were building. In any case, a future task for me is to find a scientist, like, say, my brother who worked up at Mass General on some complex experiment and try to understand the scientific method a bit better. Do scientists do multi-variate testing? Should we? Save all of that for the next chapter.
Raw Notes:
– ask yourself every day what are you learning
– requires a change in mindset
– old goal of management was to play Caesar and know if an idea was good, thumbs up or down
– responsibility of management is to empower employees to evaluate ideas
– do employees have any method to test the idea when they have to move an idea forward
– what works against innovation in companies is too much risk management and secrecy; sends wrong message
– sandbox of innovation with small, cross-functional team, given a small subset of customers to run tests on and experiment, then can report back into mainline business, way to incubate new way of working, keeping general mangers safe
The challenge of feeling safe, how can you propagate?
– important lesson of scientific method is not to say not to exercise intuitive judgment; real lesson is to test your hypotheses.
– establish a baseline for the experiment
*** rather than stuff we make up, get bad news that tell us a truth
Our conversation turned to split vs multi-variate testing – going to try to ask the question
“agile is a major advance over waterfall – but if building a payroll solution, for instance, agile may not be enough. Grand bargain of Agile is this: There is an agreement between the business and the developers to not interrupt work-in-progress within the timebox, for the business to prioritize in background and, in exchange, developers won’t complain about change–BUT we as engineers don’t care about outcome.”
“Was upset and asked ‘why am I building this piece of code very efficiently – which nobody wants.”
It’s a question of going from a line of working code to validated learning.
Suggested: Add a fourth state to your Kanban Board called “validated.” Have to set what validated means. Efficiently means learning, NOT “done code.” As a team become committed to validation.
(Comment: what I like is he is moored by actually having worked with teams, not floating in theory created from outside the realities of day-to-day work on a product.)
Q: How can you get a Continuous innovation cycle in an enterprise?
“Business plans are a waste of time. Biggest failures… were ones with elegant plans.” But this doesn’t mean we follow “The Nike Plan” and “Just Do It”… Use your system not just to make a plan but to figure out what your hypotheses are.”
Work Different 
Leave a Reply