All about Innovation

At WhirlWind one of our core values is Innovation: To think and act differently in a useful way. During our 4th Quarter meeting, we participated in group activities,  applying innovative solutions to hypothetical (yet practical) issues at work. In our group, the issue we looked at was “recruiting”. Even as we examined  possible solutions, we realized no matter how well intentioned we were, most of the solutions we suggested were still within the box.

The exercise was meant to prime us for the Ted-talk style presentation on Innovation delivered by our globe-trotting CEO. KoJo recently attended the Growth Forum hosted by the Entrepreneur Organization (EO) at the London School of Business (LBS)  and was buzzing with excitement and ideas.

One of the sessions at the Growth Forum was facilitated by Amnon Levav, the Co-Founder and Managing Director of Systematic Inventive Thinking (SIT). Levav has developed a highly structured approach to “Inside-the-box” idea creation.

“Inside-the-box” is not the first thing that comes to mind when we think of innovation, which underscores Levav’s first mantra: Do not “do” innovation, do what you do in an innovative way. Our innovation sweet spot, he says, lies far enough from our existing service to attract real interest, but close enough to fall within our company’s existing position and capabilities.

According to Levav,  what he terms “Structural Fixedness” (or mental roadblocks) prevent most of us from thinking innovatively. Structural Fixedness makes it hard to see the possibilities, and we end up being stuck in a rote fixed sequence, one step after another.

Levav’s idea on breaking through Structural Fixedness is to:

  1. Start with the product or service, rather than a customer’s unmet needs
  2. Focus on its characteristics, environment and attributes (color, type of use, location etc.)

A brilliant example to illustrate the above steps is the development in the transportation arena from Taxis to the now ubiquitous Uber.

The key to breaking out of Structural Fixedness is to follow Systematic Innovation Patterns rather than Preconception. Levav outlines-

Five Patterns/Templates of Innovation:

  • Subtraction/Reduction: Avoid “feature creep” and simplify rather than add features (e.g. the difference between an old DVD player full of buttons and new sleek one) 
  • Multiplication: Add copies of a feature but alter them in a significant qualitative way  (e.g. doubling the trash bins to allow people to separate their recycled trash from regular trash)
  • Division: Breaking down a product to its parts, allows us to see it in a different light and to reconfigure it in unexpected ways (e.g. the gradual evolution of the old hi-fi, with its speakers and turntables into one cabinet)  
  • Task Unification: Assign a new task to an existing element (e.g. integrating the antenna into the back windshield of a car)<br>
  • Attribute Dependency Change: Create or modify dependencies of a product to its environment (e.g. lenses for glasses that darken in the sun, eliminating the need for switching glasses)

KoJo wrapped up the talk by illustrating how some combination of the patterns were used to transform a regular business card into a more inventive version. He left us with one last reminder: Function follows form.

So don’t be alarmed if what emerges initially seems bizarre.  Only after visualizing the revamped version of a product can you assess its likely success in the marketplace and viability of producing it. And remember, the fact that we are starting with an existing product or service reduces the chance that we will come up with impractical ideas that we are unable to produce or market.

What are your thoughts on innovation? Have you applied Innovative thinking to your work? What are your strategies for escaping your own mental roadblocks? Please comment and join in  this important conversation.

4 Qualities I Have Developed Working as a Jr. Developer

Screen Shot 2016-02-19 at 3.32.22 PMPhoto by Kim Hamlet 

First time in a tech company can be intimidating, so here are a couple of things I have learned that really helped me along the way…

1. Asks questions so you don’t waste time!

Before, I used to think “I can figure this out” and “It’s only a matter of time that I will debug this”. Now that I know better, I would suggest that you should ask all questions as soon as possible. Yes, you should be proactive and make a concerted effort to research and use Google or try to figure it out.  But as soon as you get stuck, ask right away.

I use to hold off on asking questions and it would set me back so far behind schedule, so learn from my mistake. 5 hours googling or 5 seconds asking?
Time is too precious to waste.  Ask everything and ask right away.

2. Know the difference between a workaholic and high performer.

I use to try to learn code by doing crazy amount of reading here and there. This seems okay at first because I am a junior developer and my main job is learning.  The problem was, I barely saw any progress with my skills. I then learned that I was obsessed with coding. I was trying to code nonstop and learn without a purpose.

I took a step back and decided that if I am going to use 100% of my efforts, I can’t let any of that effort go to waste. So, I then focused on my given task at hand (which was an internal project at the time). This allowed me to be more specific and have a purpose when learning new material.

3. The workload + learning curve.

Being a junior developer comes with tons of learning and new challenges.
I felt like there were infinite amount of materials that I needed to learn that would require lots of time. I really wanted to know all of the material and quickly so that I could perform the task given to me, but tackling learning curves that way could get very messy. I ended up skipping and taking too many shortcuts. So, sure I completed the work I was given, but I left with very basic understanding about the material.

Take your time and get past that learning curve. As a junior developer, your workload isn’t as intense as a veteran entering the job. So, take this time to really climb those learning curves.

4. Learn from your neighbors.

Before working for WhirlWind Technologies, I learned from books, articles, YouTube tutorials, etc. Lots of people learn this way. Now, being with a tech company, I figured that I could do the very same in my cubicle. Well, so I thought. After my experience working on a project with several other developers, I learned that people are the best resources. Why? People are like a network of resources. All of the best articles and information that I read are from my co-workers’ recommendations. I, too, contributed great links and references to valuable information. It is like a give and take situation. When people recommend resources, they usually recommend something they found very useful or truly believe it has great value to be helpful to others. I encourage every junior developer to collaborate with your team as much as possible and start a sharing community by offering tips and tricks that could help others around you.

10 Tips For Effective Technical Documentation

TechWriBlogAre your technical documents overly complex? Or perhaps, your technical documents are consistently plagued with content and grammatical errors? Is there room to streamline your technical documentation process? If you’ve answered “yes” to any of these questions, then check out the WhirlWind Technologies Documentation Team’s top ten tips for more effective technical documents:

  1. Research, Research and More Research!: A disjointed, ineffective and unpolished technical document is almost guaranteed when you have no clue what you’re talking about. Therefore, read all of the provided subject material and any relevant information resourced from the Internet, databases, etc. Researching your subject material tells you what to include and what can be left out of your document, and provides vital information to identify gaps.
  2. Create Repeatable Processes: A streamlined, repeatable technical documentation process will yield better time management, reduce workload redundancy and alleviate any confusion among team members regarding roles and responsibilities. A standard, repeatable process should include researching, drafting, reviewing and final editing phases. Suggested roles in the technical documentation process include the lead writer, QA specialist and final reviewer.
  3.  Collaborate with Technical Leads/SMEs: These are the individuals who know the “ins-and-outs” of the subject material; therefore, they are essential in the technical documentation process. During the research and writing phase, the lead writer and other contributors should consult with the Technical Leads/SMEs to gain clarity on subject material, ensure content accuracy and resolve any additional questions or concerns. Remember that they also have a vested interest in making sure your documentation is technically sound and effective.
  4. Create Checklists (Consistency lists, Quality Assurance (QA) checklist, etc.): Technical documentation differs from creative writing in that repetition is favored over imaginative text. For example, “WhirlWind Technologies” should always be written as “WhirlWind Technologies” and not “business,” “contractor,” “company,” etc. in a technical document. The repetition may seem redundant, but it will alleviate confusion to end users. For a polished technical document, maintain a consistency list that defines acronyms, specific terminologies, etc. and how they should appear in your technical document and all related documents. A QA checklist that addresses what to look for during the review phase will also ensure a polished and cohesive technical document.
  5. Collaborate to Draft Document: The lead writer should prepare the initial draft of your technical document. Reviewers and SMEs should provide input and raise questions to avoid major content overhaul during the latter phases of the technical documentation process. It is necessary to appoint someone to lead, approve and disapprove changes to ensure a cohesive document. Consider having the lead writer also lead collaborative efforts.
  6. Ensure That Your Document Has One, Cohesive Voice: Oftentimes, there are many people (e.g., business analysts, SMEs, other writers, stakeholders, etc.) involved in reviewing your technical document who have different writing styles. While their input is invaluable, your technical document should not read as if there were multiple authors because it can be distracting and appear unpolished to the end user. Acronyms, spelling and/or grammar inconsistencies in concentrated areas, and overly verbose sections are clear giveaways of multiple authors. The lead writer, while involved in almost every phase of the technical documentation process, should also ensure that your technical document reads as if it were written by one author, with one voice.
  7. Review, Review and More Review: This is pretty self-explanatory. Remember that your reputation hinges on the quality of your output. Glaring content and formatting errors may negatively affect future business opportunities.
  8. Separate Content Review from Formatting/Grammatical Review: It can be overwhelming to perform a content and formatting/grammatical review simultaneously, and important errors often fall through the cracks. Review content first, since substantial document changes may also impact scheduling and submission deadlines. Review the document’s formatting/grammar last, since these errors are generally easy fixes.
  9. Did We Say More Review?: By now, you can probably recite your technical document from memory. Take a break, or work on another project, and then return to your document with “fresh eyes.” Review once more for overlooked errors and resolve remaining document issues.
  10. Conduct a Lessons Learned Survey at the End of Major Projects: Solicit and incorporate feedback from the client, SMEs, writers and reviewers to improve and streamline internal process. Remember that there is always room for growth.

We want to hear from you! What are some additional tips for effective technical documentation? What are some habits to avoid during the technical documentation process? Share your thoughts and experiences (good and bad) below.