Tuesday, May 12, 2015

Adapting to Change

Adaptation is Essential

Stating the Obvious

“The measure of intelligence is the ability to change.”
― Albert Einstein

It may sound obvious, but in healthy systems things change often and frequently. The fact that change exists is less important than how we respond to change. I've worked for several companies that have a poor response to change - it's both treated negatively and the unfortunate requesting the change is treated as a pariah. I've worked for other companies that embrace change as opportunity, treating change as a normal consequence of doing business in an ever changing world.

So what am I writing about here? I'd like to explore how you can help change the attitude of your team regarding change (so it's more positive) and review a few methods to embrace change for a better outcome. I'm using the larger context of "company" in what follows as I believe for this stuff to work it needs to spread across the enterprise. However, what I'm going to write about can apply at the team or macro level too.

First we should establish a list of assumptions:
  1. Businesses that are successful, with very few exceptions, are constantly dealing with change, whether in the market, through competition or ideally due to company innovation.
  2. How a business responds to the changes listed above, can often have a critical impact to company success.
  3. Many times changes are external, a response is required and the speed of that response becomes critical to success.
  4. With software development and new technologies changing the market landscape so quickly, multiply everything above by several factors.

Don't be Oblivious

"I put a dollar in one of those change machines. Nothing changed."
- George Carlin

Before talking about change I think we first need to have a frank discussion about why companies have such a hard time recognizing that they need to change. I've found that there's a very bad trait that becomes inherent in some companies that are very successful - it's the fallacy of success. What happens is that for whatever reason, a company is extremely successful (often through timing and luck and NOT through skill) regardless of questionable practices, to the point that the executive management doesn't take criticism well if at all. This is exhibited when employees recognize inherent flaws or risks in the business, the information is disseminated and consequently ignored. It becomes a "we can do no wrong" attitude that can actually be quite self-fulfilling as long as the market doesn't change, or there are little to no external forces exerted on the company's success. Because of the success management argues that their initial plan is doing well so why change? These are companies that are often blindsided - when change happens they're left in the proverbial creek without a paddle.

It was this mindset that propelled many a start-up during the dot-com era - pretty much unlimited funding, a good idea and huge growth in numbers led many companies to expand quickly with little idea of revenue acquisition. It was all about registrations and not real users. Think about how many of those companies have survived, or better yet, how many of those companies you remember that were hugely successful, only to wither on the vine or become acquisition targets with little benefit to the founders on exit. I have three boxes of swag in my basement - they are full of stuff like frisbees, squeeze toys, pens, mouse pads - you name it and I have it. I acquired this stuff at any number of gigantic conferences (remember Internet World?) and not one of those companies is still around. Someday I hope someone will be interested in that stuff as a research project - or I may just take it to recycling...

Before exploring change factors, we should consider company culture.


“We first make our habits, then our habits make us.”
― John Dryden

Just as the example above provides some insight about how a company can fail, there are some very good habits that can lead a company from moderate to great success. In most cases, these companies are very good at dealing with change. For it to work, the company's corporate culture has to drive the ideal of change and responsiveness from the top down through example. This needs to be reinforced via company core values, communication and message delivery style; and every level of the company needs to buy into the idea. It also needs to be an automatic response - more good habit than reflex, to proactively look for the opportunity to any change rather than finding reasons not to change. Not that you should jump every time someone says frog, but you have good processes to evaluate change with a managerial support structure to effectively deal with it.

Too often business have complex change control procedures that act as a barrier to change rather than determining if change is first necessary and second worthwhile. Instead its become the norm to only take on change after some upper level management type has "signed off" - more as a CYA technique than as a considered opinion. This often results in someone holding the bag, so to speak, if things "Go South." You'll often see old-school management types keep some unqualified sycophant around so any big problem can be pinned on that unfortunate soul so he/she can be sacrificed if needed.

“It's too late to be studying Hebrew; it's more important to understand even the slang of today.”
― Henry David Thoreau, Walking


“You must be shapeless, formless, like water. When you pour water in a cup, it becomes the cup. When you pour water in a bottle, it becomes the bottle. When you pour water in a teapot, it becomes the teapot. Water can drip and it can crash. Become like water my friend.”
― Bruce Lee

So how to be successful or at least survive change? It's called adaptation - just as some cultures found that survival could be found in assimilation, it's often necessary to consume a change rather than spitting it out. This is most important when confronted by an external pressure, like a change in the market or the presence of a new, disruptive technology. I've always liked that term "Go with the flow" but not in the original context (which as I recall was more of a concession to events), but rather as the idea of adding your voice to the chorus to make beautiful music! Take the positive aspects as opportunity and you can survive devastation - you may get bruised a bit along the way but even those bruises can be turned into learning experiences. If the task looks insurmountable, try breaking it up into smaller, more manageable pieces. Remember, a journey of a 1000 miles begins with one step!
A good recent example of adaptation is the current incarnation of used-to-be internet giant AOL. The platform has lost most of its user-base and has become little more than a landing page - however due to brand recognition and fairly-decent news feeds, the portal still gets a worthwhile number of visitors, which equate to eyeballs and advertizing revenue. The company adapted and parlayed that adaptation into a $4B+ acquisition by Verizon - not bad!

Being Nimble

“It is not the strongest or the most intelligent who will survive but those who can best manage change.”
― Charles Darwin

Being nimble is a bit different from being adaptable - in my mind being nimble is defined by your ability to respond to change quickly. If your company has a host of processes you have to go through to make even small changes, then you're probably always going to be behind in execution. Somehow, you have got to spearhead an effort to get things into production environments quicker, remembering the resource triangle (cost, time and quality) and determining what a release can take advantage of to increase speed (hopefully it's cost and not quality, but at times quality can be relaxed - it's all about what you're trying to get out quickly).

To illustrate this idea, how many of you have heard about garage-style start-ups who have pushed what amounts to beta software into the public for the sake of speed. If they are lucky, they'll gain a ton of market share and not lose it due to crappy quality. These start-ups are much more nimble than most large corporate entities - while those are still writing requirements and making marketing plans, the smaller companies are scooping up all the customers, effectively diminishing the pool of fish .

"When you're finished changing, you're finished."
- Ben Franklin

Change Can Be Painful

“We are kept keen on the grindstone of pain and necessity.”
― H.G. Wells, The Time Machine

So what's the plan, man? How, with all this opportunity hanging around there can we best use what's happening to be successful, and make great software? This is fairly old-school, but I recommend as a first step to perform the SWOT exercise. I won't go into too much detail about how to do that - it can be a topic on its own and there's plenty of information available online. You're basically coming up with an analysis of the company's current state and how it stands in its current environment. Please look it up and it will give you some ideas. I do have a recommendation - use the largest pool that you can to come up with your SWOT - that includes executives, middle-management, your core employee pool and anyone else that half-way knows your business, even vendors. Make sure you are clear with everyone that there are no wrong answers and that there will be no repercussions to those who express honest opinions. This needs to be a frank look in the mirror.

I remember the first SWOT I attended. I had never heard of the technique, which was brought to one of my first companies by the COO who was a GE alumni. We got the entire company (about 50 employees) all together in an auditorium, explained what we were about to do and then proceeded to come up with an honest assessment. From that analysis, we had a foundation that we integrated into our company plans, software and sales roadmap, and initiatives and thinking of our leadership - shake well and you have something worthwhile. We ended up being extremely successful and became profitable within 3 years, surviving the dot-bomb. I won't attribute our success to the on-paper results of the SWOT, rather to the interaction that helped to shape our habits, creating a consistent message across all levels of the business, and aligning a program that considered all aspects: strengths, weaknesses, opportunities and threats. We were also very adaptable and nimble (it's also how I got my first taste of agile software processes and frameworks). Not to say it was all gravy - there were certainly mistakes made, however we were fairly good at learning from those mistakes, improving our business and processes; and having some fun along the way. Thanks for reading.

-- John

"Adaptability is not imitation. It means power of resistance and assimilation."
- Mahatma Gandhi

(also posted to LinkedIn)

Monday, May 4, 2015

Writing a White Paper

Writing a White Paper

I think that most of us have seen white papers before - I know the first time I was exposed to one it was in relation to what amounted to a sales promotion. Basically the company was defending its marketing position through the use of a white paper (I believe it was Forrester or perhaps Gartner, who both seem to write quite a few of them and in general are both fairly well respected in the industry). I believe the original concept behind a white paper was to produce an authoritative research document with the end goal of creating correlations or interpretations of raw data. Historically most of these were used by government (and in particular US government) to identify trends and produce some type of synthesis of the information that would then be used to form recommendations; and often the task would involve the use of university researchers - basically experts in fields that could make sense of the data and then produce a report that could be easier to consume, presumably by governmental branches (note that a lot of this type of research has been given to data scientists who have even more training in looking at trends and anti-trends). I'm not sure about why they are "white" but my conjecture is that it's supposed to mean that the opinions are external and objective; as opposed to regular reports which tend to be subjectively sourced for internal use only.
As I've already indicated, most of the white papers I've seen up until the last 10 years or so were put together by companies that specialize in producing them. Conceptually, government and most companies tend to make some assumptions that support a position or action and it's easier to defend those assumptions when an independent resource has produced a data-based opinion. If you read my last article on Inductive communication you'll see a trend. Academia tends to take a lot of raw data and while scientifically examining trends and anti-trends, tries to make sense of what is being observed and provide some reasoning or hypothesis regarding what is happening. The next step is to narrow the data set or look for additional data points to support the hypotheses - you start wide then narrow things down to proof your ideas. With the most current trend and approach, you first make some guesses then find data to support those assumptions - it takes out the appetizer which tends to be less rewarding and very time consuming, and goes directly for the entree, so to speak. Think of this as more of a marketing document and less of an objective research paper.

I'm not here to explore the validity of the approach - as with anything it can be flawed and if you're one of those companies that professionally writes white papers as an output, especially to get paid, you'll tend to find data and correlations that match assumptions. Sometimes this can lead companies into making strategic mistakes, but more often than not the initial assumptions are sound and the white papers help to get projects funded and off-the-ground. And the whole point is often to start with something instead of a back-of-the-napkin idea. I've been describing the development of the white paper concept and how I've seen it change over time:
  1. White papers as independent data analysis, correlation and theory using deductive reasoning and making sense of it all.
  2. White papers as proof using inductive reasoning to defend a hypothesis
  3. The latest trend, doing internal research to find information defending projects.
My focus will be on that third trend as I find it very interesting and I've experienced it first hand very recently. How did something which is supposed to be from independent AKA 3rd Party resources become an internal construct?
Most recently I've been asked to develop a series of white papers - these were asked for by our executive committee to be presented to help defend our division's current product roadmap and how ti relates to the overall company vision. I had witnessed a different group go through this exercise and frankly wasn't very thrilled to be caught up in a bunch of documentation and research. From my observations of this other group I noticed, very superficially, a consistent trend that involved: intent, due diligence (research), craft in writing, submission, review and rejection for edits, repeat ad nauseam. I could tell by the reactions, day-to-day from some of my product management coworkers (other teams, not my own) that what they worked upon was a bit of an exercise in futility. Most of the papers had gone through a revision history in excess of 30 versions, some exceeded 50 and many of the edits were really what I would call nitpicky - e.g. moving text two pixels to the right, changing the object color by a shade or recreating tables for consistent font size and usage. Stuff that for most of us who work in the agile world would find excruciating and yes, the outcry was robust, at least within our small sub-community within the company. This was all piled on top of a huge list of requested white papers - in fact there was so much research going on that there was a Senior Product Manager in charge of the project - sort of a PdM of White Papers (a paper crown would be appropriate, no?). Not to say that there isn't any value in consistency, presentation and messaging, but when you think about what's being asked for as content, you would also think that it would be more important to deliver good information rather than perfect, meticulous formatting? But I digress...
So with a bit of hesitation and a list of white papers being asked for from my group, I began tackling the task at hand. Originally I had three to do, but with a new hire to our team that went down to two. Fortunately, as with most projects there were already several artifacts available to me in the form of analysis by various business units and in some cases earlier attempts at white papers (at least they were labeled thus).
So how did these white papers turn out? Well, as you may infer, I started writing the papers with a bit of a negative mindset - no one wants to do "make work" for the sake of doing work. What was the most interesting was that in preparing my work and doing research, I actually found out a lot of useful information that began to change my perception of the entire task. It started to transform from boring documentation into something else, something much more useful. As with any research I first start with a diagram. It's my opinion that if I can't explain a process using a basic flow diagram, then what business do I have trying to explain it in detailed requirements? As with anything, one diagram suggests another and another and then you find yourself editing the diagram as you discover new ways of representing what's happening. You also start to see exception cases and allow for those. You also have a better view of what's important and what isn't so your MVP is much better.
Acting as a Product Owner for agile software teams causes you to become very focused on the task at hand. You end up often in a state where you can't see the forest for all the trees - this process of producing a white paper helped me to put things into perspective from a macro level. Rather than taking the least path to implementation, you begin to see where you might miss something that's part of the overall picture. Wow, I was suddenly propelled into the best aspect of Product Management - taking information and creating a strategic treatise on the "ideal product" and figuring out what baby steps need to be in place to get the whole product into production. That's the first real benefit of white papers - it's not the document your produce, it's the underlying research and thinking about the project that's important. It provides both better context and better overall product vision, that in turn produces a better product roadmap.
So what's next? One of the problems with working in a very tight team of product managers is that we all trust each other quite a bit. When we present to one another we accept much of what is presented and instead focus questions on the implementation rather than questioning some of the basic premises. As a result, when we distributed out white papers to each other there wasn't a lot of useful feedback. It wasn't until we shared papers in review meetings with a much larger group (that included both the BU head and also heads of engineering) that the really hard questions began. It was at this point that the next really useful benefit of the white papers became apparent - that the vision at the top began to be aligned with the thinking at the product level. The feedback and comments had us grumbling at first, however it did more to align our overall efforts, our product roadmap, and our thinking with the head of our division than during any other presentation or meeting. To me this was much more than a happy accident, this was a clinical example of how to align everyone for success! In turn, the message was passed to our corporate executives and now the unified message is passed in everything we say, do or release. This more than made the effort worthwhile and in effect transcended the dull work of writing white papers into something much more.
So White Papers... a waste of time? To answer this question, it really depends on what you are doing, the reason you are doing it, and what you ultimately do with the information. I started with the idea that these white papers were a waste of time, but in doing them found something more. The key to making these something other than words on paper is having the discussions that make them useful. In my case, the experiences became something much better than the sum of their parts. If everything worked this way, we would all be successful and every product would compete for greatness - we would make mediocrity history and raise the bar on all products. I think these papers had that level of impact on us and can only hope you too experience the same.
-- John

(also published to LinkedIn)