Category Archives: Culture

Intern Demo Day

As the summer comes to an end, so do the internships for numerous university students here at Bazaarvoice. This past week, the interns were given an opportunity to present a summary of their accomplishments. This afternoon of presentations, known as the Bazaarvoice “Intern Demo Day”, highlighted the various achievements throughout the company, not just in the R&D department.

The following is a short summary of the great work our interns complete this summer as well as some images from the “Intern Demo Day”.

CHASE PORTER: My project, which I have named “The Great (red)Shift”, is intended to improve data accessibility for computed aggregated counts of various canonical events written to HBase. To do this I designed a data warehouse in Amazon Redshift that I loaded with transformed aggregated counts extracted from the tables in HBase. This makes the counts readily SQL query-able in an incredibly fast system whereas before they had to be computed with performance heavy queries from Raw Logs generated by Cookie Monster. The biggest block for this project was in processing the data from HBase which was stored as serialized bytes and needed to be handled uniquely for different types of canonical events (i.e. pageviews, impressions, features) to translate into a readable form for Redshift.

BEN DEVORE: My product is web crawler written in node.js that scrapes clients’ webpages for product data in order to build their product feeds for them. For many of Bazaarvoice’s smaller clients, building and maintaining their product feed is a significant obstacle in the onboarding process. This tool aims to clear that obstacle by taking this task out of there hands.

STONEY MCCRARY: So I have been fortunate enough to get to work on several different pieces in curations but I am going to talk on what I have been hammering on for the last couple of weeks. More and more of our high volume clients are receiving millions of hits a day and this has caused performance to become a higher priority problem for them. In response to this, we are focusing our efforts on building a new display with performance in mind. Performance for the display centers around only providing the minimal amount of data needed and supply the rest as necessary. The piece I will be showing is the display carousel and how it dynamically loads and dumps the data to allow for faster loading and to keep browser memory low.

ZESHAN ANWAR: Eagle is a dashboard built for our Incubator team. With so many moving parts, it was important we had a summarized ‘birds-eye’ view of the team in one place. Eagle was initially meant to be an aggregation of all our Jenkin builds; a single view of all our jobs across our different Jenkins environments. However, it grew to also include JIRA and GitHub statistics. My other project was optimizing our UI tests by having them run concurrently. Our old UI tests were extremely slow, and by running them in parallel we drastically reduced test times.

BRENDON KELLEY: Testing Framework: This summer my project was to help build out a new testing framework for Curations. The current automation tests used for Curations is Saladhands. Before my internship, there wasn’t much if any automation tests for the submission/direct upload capability of Curations. I worked on creating tests and a CI environment for submission in a new testing framework called Intern. One of tests includes a language translation test using mongoDB as an endpoint to store the various languages’ text. Intern is a javascript based testing framework which will allow developers to contribute to writing tests since Curations is mostly javascript. I’ve also worked on updating and creating new console tests in this framework. The foundation built this summer in Intern will enable the ability to further contribute to the framework.

KRYSTINA DIAO: My main project for the summer was to analyze and report the effectiveness of the implementation of the new Connections Knowledgebase. Through Salesforce, I collected and analyzed the number of cases, time spent on each case, etc. After drawing my conclusions, I decided to present my findings via data visualization methods (JavaScript’s C3 and D3 libraries) and provide actionable insights on how this information can be leveraged. This information is valuable in that it can be used for future product KB decisions, as well as understanding how much time, manpower, and money is saved by having a KB.

MARKO SAVIC: Over the summer, I was a part of the SEO Team. I managed to create a tool on pagesManaged and keywordsManaged feed for every Spotlights client. Generated feeds will be consumed by SeoClarity tools on a daily basis. This helps in identifying search rank gains on the specified keywords and pages where Spotlights are present. The SeoClarity reporting will help in proving out Spotlights value and eventually lead to Spotlights renewal/upticks.Also, I created algorithm tweaks on the PINS (Post Interaction Notification System) Generator that take into account product activeness, product relevancy and review count, and use them to ask the user to write reviews on the most relevant products.

TREVOR NELLIGAN: Here is a description of my project: I worked on the Aperture Component library and many of the projects it supports. Aperture is build in React, and its purpose is to be used as an internal Bazaarvoice tool for constructing web pages. Using Aperture, anyone at Bazaarvoice can easily create a functional, intuitive, Bazaarvoice themed webpage, all with the building blocks Aperture provides.

Using the Aperture library, I helped the construction of numerous pages for the curations beta console. I personally built the interface for a new client-facing template builder, which will allow clients to create curations templates quickly and easily without having to go through an implementation engineer and a long process, as was the case previously. I also supplied custom Aperture components for several projects, like the content curation beta page.

RAMIE RAUFDEEN: The mixer is a component of our product recommendations engine which differentiates shoppers, and optimizes recommendations for them. This is primarily derived from their shopping behavior – in real time. Prior to the mixer, product recommendations were aggregated from multiple sources, using the same algorithm for every shopper. Shoppers are now categorized based off of a set of rules (using the shopper’s profile data), each of the rules map to a plan (which you can think of as an ‘algorithm’). A plan defines how recommendations should be mixed from each of the sources. For example, if source B has proven to have a higher conversion rate for ‘heavy-shoppers’, the plan for ‘heavy-shopper’ would give a higher weighting to source B. We can now target specific types of shoppers when it comes to product recommendations. This also sets the groundwork for a more granular machine learning implementation in the future.

We want to thank all the interns who spent time with us this summer and wish you the best back at school. We look forward to hearing about all the great things you all develop in the future.

If you are interested in an internship at Bazaarvoice, please contact kindall.heye@bazaarvoice.com.

Don’t Look Back in Anger: Retrospectives, Software Development and How Your Team Can Improve

Retrospective – This term can elicit a negative response in people in the software development industry (verbally and physically). After all, it is a bit of a loaded term. Looking back can be painful especially since that usually means looking back at mistakes, missteps and decisions we might want to take back.

I have worked for over a decade in software development and information technology fields and during that time I’ve been involved in many meetings you could label as ‘retrospective’. Some of these have been great, others terrible. Some were over-long sessions of moaning and wailing resulting in a great deal of sound and fury, signifying little while others have been productive discussions that led to positive, foundational change in the way a team operated.

Looking back at all of that, I’ve realized a few common truths to the process of retrospectives and how it relates to building software:

They’re necessary – there’s always room for improvement.
Don’t focus on the negative – focus on the constructive (ie: “how we can improve”)
You need an actionable to-do-list – figure out what to change, quickly, then act on it

For the past five months, my team has been employing a process to facilitate retrospectives based around the three bullet points above to foment positive change in the way our team works. This blog post will detail how we do this. This is not to say, “you should perform retrospectives and you should do them this exact way”, because every software team works differently. This however is to say, “here’s an example of how the retrospective process was done with success”. Maybe it could work for you or give you ideas on how you can form your own process that works best for your team.

Step 1: Recognize!

OK, let’s get the grisly stuff out of the way first: Your team needs to improve. And that is OK – because no team is perfect and no matter how well we execute on our goals, there’s always room to improve. In fact, if your team is not at some regular interval assessing or reassessing how you design software, you’re probably ‘doing it wrong’ because (can you smell the theme I’m cooking up here yet?) – there’s always room to improve. If you’re exploring or actively participating management concepts like Kanban/continuous improvement, this process is essential.

Step 2: Togetherness

OK – you want to improve your process and are ready to discuss how that can be done. How does the rest of your team feel about that? You can drag a horse to water and you can drag your team mates into a meeting but you can’t make either drink (unless you’re looking to rack up some workplace violations and future sensitivity training).

This is not how we define team work.

It’s important to get a consensus from the entire team in question before proceeding with a retrospective. This will actually be easier than some might think. After all – in software engineering, we’re all trying to solve complex problems. This is just another problem that needs figuring out.

Before going further, you’re going to need a few things:

Somewhere to meet
Someone to take notes
Someone to keep time
Somewhere to post your meeting notes (Jira, Confluence page, post-it notes, whiteboard, whatever works for you)
Some time (30 minutes to 1 hour, depending on the size of your team)

Step 3: Good Vibrations

 












Come on, you know you loved this song back in the day.

The tough stuff is out of the way at this point. You and your team have decided to fine tune your process and have met in a room together to do so (the 2 boxes of Shipley’s donuts you brought with you is barely a tangent in this case).

When we started performing retrospectives regularly on the Shopper Marketing team, we started our discussion by talking about our recent successes as a team.

In this case, we as a team, one by one went around the room and listed one thing during the past period (sprint, release cycle, week, microfortnight, etc. – the interval doesn’t matter, whatever works for your team) and offered 1 thing we felt the team did well. Doing this has a couple of functions:

It helps the team jog its memory (a lot can happen in a short amount of time).
It helps celebrate what the team has done recently (wallow in your success!).
It sets the right tone (before we focus on what needs to change, lets give a shout out to what we’re doing right).

Note that, especially with larger teams, sometimes one’s perception of how well something might have gone might be very different from someone else’s. If Jane, your engineering head for your web service says she thought the release of the bulk processor was on time and under budget but Bill, your UI lead contends that it in fact wasn’t on time, wasn’t under budget and wiped out an entire village and made some kids cry, then this is the point where you should pause the retro and have a brief discussion about the matter and possibly a follow-up later. This leads us to our next step…



















Nick Young asking the important questions of our time.

Step 4: What Could Be Better?

Now that you’re full of happy thoughts about what you’ve done well as a team (and full of donuts) its time to discuss change. This process is the same as the previous step only this time, each team member must call out one thing they think the team could have done better.
















Mmmmmmm... Donuts...

Note that this isn’t about what was bad, or what sucked, or so-and-so is a doofus and has bad breath – but what can the team do better. In order to keep the discussion productive and expedient, each person is limited to 1 item and that item has to be something the team has direct agency over. You also might find it handy to nominate a moderator for this point of discussion.

Here’s an example of a real issue that was brought up in a retrospective at a previous company I worked for and the right and wrong way to frame it when it comes to focusing on ‘your team’s agency’.

“Marketing and sales sold our client a bunch of features that our product doesn’t do and we had to work 90+ hours this week just to deliver it”

-Or –

“We should work and communicate closer with marketing and sales so they understand our product features as well as the effort required in developing said features”

While the first statement may be true it’s the second one that actually encapsulates the problem in a way the team has a manner of dealing with. I found that focusing strongly on the positive aspects of a retrospective discussion helps some teams to self-align toward reaching toward the kind of perspective found in the latter statement above than the former.

Other teams I found realized the need to appoint a moderator to help keep the discussion focused. Its important to figure out what sort of need your team has in this regard early in the retrospective process. This might seem tough at first (and emotionally charged) and that’s OK. What’s important is to keep a positive frame of mind to work through this discussion.

As previously stated, if there appears to be a major disconnect between team members regarding issues that could have been done better, this is a good time to discuss that and hopefully iron out any misunderstandings or make plans to do so soon after the retrospective.

Whoever is taking notes, I hope you’re getting all of this because we’re about to tie it all together.

Step 5: Decide

By now, you and your team will have come up with a good deal of input on what the team did well and what could be improved. You might be surprised but having done this numerous times, often a very clear pattern to what the team though went well and could have improved on appears and does so quickly.

As a team, go over the list of items to potentially improve on and note which ones are the strongest, common denominator. Pick 1 or 2 of these and this will provide some focus for the team for the next period of work (sprint, cycle, dog year, etc.). These can be process-oriented intangibles or even technical issues. Here are some examples:

“Our front end engineers were idle during much of the sprint waiting on services to be updated”

–Or–

“We spend 1-2 hours doing process Y manually every week and we should probably automate it”

The first item has to do with improving the team’s process of how it interacts with itself. The other is a clear, intangible need that can be solved using a technical solution.



















A high-valued issue.

Once the team has identified 1 or 2 high-valued issues they feel need to be addressed, its time to do just that.

Step 6: Act!

This is the most important step. It’s one thing to identify a problem to be solved, another to actually act on it. Hold a discussion as to what potential solutions to your issues might be. The time keeper at this point should be keeping an eye on the clock to help the team keep the meeting moving forward in a productive manner. At this step, try and keep the following in mind:

By now, whatever issues the team has identified that need to be addressed, it should be something the team has full agency to solve (the matter is firmly in the team’s hands)
Depending on the issue at hand, it may be something complex and the team might need a couple of tries to solve it. Don’t get discouraged if the issue appears gargantuan or if you can’t solve it within your next period of work alone.

Once you’ve brainstormed on solutions to how you and your team can make improvements, it’s time to really act. In this case, you should have some ideas that can be transformed into action items (you get a Jira ticket and you get a Jira ticket and…). The retro should conclude with the team being able to break down a solution for improving into 1 or more workable tasks and then assigning them to team members for the next sprint, cycle or galactic year.

The key to making this all work is that last part. What comes out of the retrospective should be treated as any other item of work your team normally commits to in the confines of your regular working period (sprint, release, Mayan lunar month, etc.) with one or more team members responsible for delivering the solution, whether technical or otherwise.

Now you’re ready to move forward with improving as a team and dive into that post-donut food coma.





















Woooo! Food coma!

Step 7: Going Forward

Whether you use this process or some other framework to run a retrospective, repeating that process is very important. To what degree or frequency your team does that is for the team to decide. Some teams I’ve worked with performed retrospectives after every sprint, others only after major releases and some just whenever the team felt it was necessary. The key is for the team to decide on that interval and after your initial retrospective, be sure to devote some time at the beginning of subsequent retrospectives to review your action items from the previous session (did you complete them and were the issues related to them resolved?).

Hopefully this post has given you an idea how your team can not only perform retrospectives but also improve your team’s working process and even look forward to looking back.

And on that note…

Why we do weekly demos

If you are part of an agile, or lean, or kanban development team, you probably do or have done demos at one point. Some people call them “end of sprint” demos. Some people call them “stakeholder” demos. We are pretty informal and irreverent about it at Bazaarvoice, and we just call them “demos” because giving them too formal of a name, or process will defeat the purpose. Demos are an amazingly valuable part of the development process, and I highly recommend that your team start doing them weekly.

Why not to do demos

There are a lot of reasons why not to do demos. If you are doing demos because of any (or all) of these reasons, you are probably doing it wrong. (Oh, did I mention that this is my personal opinionated viewpoint?)

We are forced to do demos so that management can keep an eye on us.
We do demos so management can make sure that each person is actually doing work.
We do polished demos for our sales and marketing team and they have to be perfect.
I don’t really know why we do demos, but my boss told me to, so I just show up.

Prep Work

Before you can do effective demos that help accelerate your development, your delivery, your quality and your culture, you need to set the stage for success. So how do you do that?

At Bazaarvoice, we believe in hiring smart, passionate owners that we can trust to do the right thing for the company, for our customers, and most importantly for our consumers. If everyone is bought into the vision and mission that you are all working to accomplish together, and if everyone is engaged and proactively helping to find creative solutions to those problems, then it is a lot easier to have productive weekly demos. You want to have an environment where everyone can speak without judgment, and where they know that their random idea will be heard and appreciated and not shot down. If everyone is coming from this place of openness, transparency and trust, then you can get some great demos.

Why

We believe that demos are part of the creative, collaborative and iterative process of developing amazing software solutions. The point of the demo is it be a time when everyone on the team (and stakeholders) can get together and celebrate incremental progress. It’s a way to bring out all the current work out into the light and to discuss it. What’s good, what still needs work, what did we learn, what do we need to change, and how could we make it even better. It lets us course correct earlier before we fly into the mountain. And It gives others awareness of what’s going on and brings the “aha” moments.

It’s about learning, and questioning, and celebrating. Everyone who demos gets applause. All work that gets done is important and should be celebrated. All work and everyone means Engineers, QA, UX, Product Managers, Marketing, Documentation, Sales, Management, and anyone who completed something that helped move the cause forward.

When

I like to do demos at 4pm on Fridays. Ouch right?! Well that’s kind of the point. Doesn’t everyone just want to check out early for the weekend? Nope… Well let’s hope not. If people are leaving early and complaining, then pause and go back and re-read the “Prep Work” section.

We actually use that time because it’s the end of the week. It gives us the most time during the week to get things done, and it gives us free space after the meeting if we need to run long for a brainstorming session or to discuss things more deeply. We have 14 engineers/UX/QA on our team, and we schedule demos for 30 minutes. If we finish early, or not, we usually stick around for beers and games anyway until 6-7pm because we just like hanging out with each other. Imagine that.

So isn’t that great? You get to hang out with your friends, show off your accomplishments, and leave work for the week feeling pride in what was accomplished both personally and by the entire team. You are hopefully excited about the future, and probably brainstorming new ideas over the weekend from what you learned from the demos.

Planning

We do planning for our week on Monday mornings. That part is important too and it’s the ying to the demo’s yang. People get into the office on Monday morning and are fresh and ready to go and hungry to know what they can pick up next, so it’s the perfect time to set the stage for the week. What are our top priorities for the week? What do we absolutely have to get done by the end of the week (aka by demos on Friday afternoon)?

Planning is a great venue to ensure everyone is in sync with the vision and Product priorities. Product shares upcoming business epics, UX walks us through new mockups and user findings, Engineering discusses new platform capabilities that we should consider, and QA reminds us of areas we need to harder. It helps form this continuous cycle of planning and validation. It’s a bit odd, because we are very Kanban and flow oriented, but we have found that having some timeboxes around planning and demo’ing gives the team a sense of closure and accomplishment. It’s important to occasionally step back and assess the progress. We have found this sets a really good and sustainable cadence for a productive team.

Next Up

Tell me what part of our story you want to hear next. How do you build a team and culture that enables you to execute on your vision? Follow me on twitter @bchagoly and @bazaarvoicedev to be the first to read new related posts and to join the conversation.

BVIO 2015 Summary and Presentations

Every year Bazaarvoice R&D throws BVIO, an internal technical conference followed by a two-day hackathon. These conferences are an opportunity for us to focus on unlocking the power of our network, data, APIs, and platforms as well as have some fun in the process. We invite keynote speakers from within BV, from companies who use our data in inspiring ways, and from companies who are successfully using big data to solve cool problems. After a full day of learning we engage in an intense, two-day hackathon to create new applications, visualizations, and insights into our extensive our data.

Continue reading for pictures of the event and videos of the presentations.

This year we held the conference at the palatial Omni Barton Creek Resort in one of their well-appointed ballrooms.

Participants arrived around 9am (some of us a little later). After breakfast, provided by Bazaarvoice, we got started with the speakers followed by lunch, also provided by Bazaarvoice, followed by more speakers.

After the speakers came a “pitchfest” during which our Product team presented hackathon ideas and participants started forming teams and brainstorming.

Finally it was time for 48 hours of hacking, eating, and gaming (not necessarily in that order) culminating in project presentations and prizes.

Presentations

Sephora: Consumer Targeted Content

Venkat Gopalan
Director of Architecture & Devops @ Sephora.com

Venkat presented on the work Sephora is doing around serving relevant, targeted content to their consumers in both the mobile and in-store space. It was a fascinating speech and we love to see our how our clients are innovating with us. Unfortunately due to technical difficulties we don’t have a recording 🙁

Philosophy & Design of The BV System of Record

John Roesler & Fahd Siddiqui
Bazaarvoice Engineers

This talk was about the overarching design of Bazaarvoice’s innovative data architecture. According to them there are aspects to it that may seem unexpected at first glance (especially not coming from a big data background), but are actually surprisingly powerful. The first innovation is the separation of storage and query, and the second is choosing a knowledge-base-inspired data model. By making these two choices, we guarantee that our data infrastructure will be robust and durable.

Realtime Bidding: Predicting the future, 10,000 times per second

Ian Clarke
Co-Founder and CTO at OneSpot

Ian has built and manages a team of world-class software engineers as well as data scientists at OneSpot™s. In his presentation he discusses how he applied machine learning and game theory to architect a sophisticated realtime bidding engine for OneSpot™ capable of predicting the behavior of tens of thousands of people per second.

New Amazon Machine Learning and Lambda architectures

Jeff Nun
Amazon Solutions Architect

In his presentation Jeff discusses the history of Amazon Machine Learning and the Lambda architecture, how Amazon uses it and you can use it. This isn’t just a presentation; Ian walks us through the AWS UI for building and training a model.

Thanks to Sharon Hasting, Dan Heberden, and the presenters for contributing to this post.

Greg Brockman, How We Scaled Stripe from 4 to 94 Employees

Check out Bazaarvoice IO 2014 Technical Conference keynote speaker Greg Brockman, @thegdb, CTO of Stripe and designer of the Stripe CTF contests discussing how they scaled Stripe from 4 to 94 employees

Summer 2013 Intern Science Fair

Every year at Bazaarvoice we bring on a new class of Summer interns and put them to work creating innovative (and educational) projects. At the beginning of the Summer interns choose from a list of projects and teams that interest them. From there they are embedded in a team where they spend the rest of the Summer working on their chosen project with help from seasoned professional mentors. At the end of the Summer they set up demos and we invite the whole company to visit with them and see what they have accomplished. Read on to learn about our interns and their fantastic and innovative projects.

Below are some of the 2013 intern science fair projects in the creators own words:

Devin Carr
School: Texas A&M – Field of study: Electrical Engineering

I built a product review template using the Bazaarvoice Platform API as well as some of the latest front-end libraries and architectural patterns. It provides a best practice and simplistic model to assist potential/existing clients and their developers with a base to develop an efficient product page integrated with Bazaarvoice Ratings & Reviews.

Lewis Ren
School: UC Berkeley – Field of study: Electrical Engineering & Computer Science

Genie is a product recommendation tool based on user clustering. The idea is that you want to give every user the possibility of a product within the network as a recommendation; however, be able to rank them in such a way that is most relevant to the specific user. By clustering users based on modularity we can determine how big of an impact a specific user will have on the rest of the network. For example, a high modularity node that makes a decision will have a stronger impact on its neighbors, but will propagate out slower and have a small to negligible effect on outer nodes. Similarly, a low modularity node that makes a decision will have a lesser impact, but will radiate outwards much more quickly.

Matt Leibowitz
School: University of Dallas – Field of study: Physics / Computer Science

My project is called Flynn, which is a web page for accessing documents out our data store. Flynn allows developers to bypass a fairly long and involved process (up to ten minutes of looking up documentation and performing curl requests) with a quick and simple web interface.

Perry Shuman

My project is a bookmarklet built to provide debug information about a page with injected BV content: information that could help a client fix implementation issues that they might have, without having to know the inner workings of our code. It also allows previously hidden errors to be displayed to a client, giving them a first line of information to debug broken pages.

Ralph Pina
School: UT Austin – Field of study: Computer Science

“Over this past summer I interned with Bazaarvoice’s mobile team. In its effort to make it easier to integrate BV’s services into every platform and outlet their clients use it has build and distributed mobile SDKs (Software Development Kits) to display and submit data to the BV API. I worked to improve the Android SDK, and along with another intern, Devin Carr, wrote a new Windows Phone 8 SDK. I also wrote 2 Windows Phone 8 sample applications to demonstrate how to implement the SDK in an app. Afterwards, we opened sourced all our mobile SDKs under the permissive Apache 2.0 license.”

Rishi Bajekal
School: University of Illinois at Urbana-Champaign – Field of study: Computer Science

Built a RESTful web service for serving photos from the data stack and worked on the Conversations 2013 API as part of the that team.

Ryan Morris
School: McCombs School of Business at the University of Texas at Austin – Field of study: Management Information Systems

My project’s theme was predictive modeling and focused around using a client’s web metrics, review count, and average rating to predict orders for products. To create the predictive model, I pulled the client’s visits, orders, and revenue for a certain time period from their web analytics account. I then pulled the client’s number of approved reviews and average rating for each product from the Bazaarvoice database using mySQL. Finally, I ran the data in the statistical program R to come up with a predictive model. With this model, I was able to analyze the effects that varying review count and average rating had on predicted orders for a product.

Schukey Shan
School: University of Waterloo – Field of study: Software Engineering

My project was the brand search summary, which provides both an API and a UI to summarize data we collect on brands. For example, if we search for a brand “Acme”, the API looks for all the brand names that contain the word “Acme”, creates a composite of the matched brand values, and returns the count for pageviews, ugc mpressions, and unique visitors for each client of each brand value in the composite. This would be useful as an overview of how brand values look like over the network.

Steven Cropp
School: Rensselaer Polytechnic Institute – Field of study: Computer Systems Engineering and Computer Science

This Summer I worked on an xml file validation service. Users can set up “rules” that dictate how xml files must be formed, and then apply those rules to our clients xml feeds to generate user friendly reports that outline what is wrong with the xml, and some details about how to fix any issues. This should help smooth out the process our clients go through when importing feeds, saving the support team and our clients time.

Thomas Poepping
School: Carnegie Mellon University – Field of study: Computer Science

1. A tool to inject spreadsheets of UGC into the system.
2. An addition to the web app that generates a payroll report for all moderators, streamlining the payroll process.
3. A pilot WordPress plugin that moderates WordPress comments, then allows administrators to act on rejected comments.

Stop, collaborate and innovate: Engineering a company science fair

Many people are aware of Google’s “20 percent time,” and the number of innovations that have been produced because of it (Gmail, Google News, and AdSense to name a few). Several other companies have tried this before and after Google; one of the most famous examples of side-project innovation is 3M’s Post it Note. Software development companies are now emulating this model, holding hack-a-thons where flurries of innovation occur.At Bazaarvoice we’ve been holding regular Science Fairs every few months for well over the last year to allow our Engineering team to stretch their creative muscles. The format is simple; we schedule the two-day Science Fairs at times that are not likely to have a lot of conflicts with the regular release cycle, typically over a Thursday and a Friday. When the engineers arrive on Thursday, instead of working on the newest features in our evergreen platform, they get to choose what they want to work on. Teams of engineers (and designers) from across our Implementation, Development, Operations, and Support teams work together all day Thursday—often late into the night—and half of the day Friday to bring their ideas to life. After lunch on Friday the teams present their projects to a panel of judges and finalists, and winners are announced.

These types of events are an amazing addition to the company’s culture, and really help to drive new innovations into our products. Engineers walk away from the two days of coding with a new sense of empowerment, realizing just how much they can accomplish in such a short period of time. Additionally, many of the projects stretch the bounds of what our products can do already, showing us new areas for efficiency improvements, incredible new user experiences, or just plain fun new ways of looking at the same data.

Having done this for a year, we’ve learned a few things along the way about how to run a successful Science Fair. Here are my top three tips.

1. Get thematic

We’ve learned that providing some structure to the projects helps to give people direction. We’ve published a list of themes for the last two Science Fairs, and that has helped not only with the task of judging all of the projects by dividing it into manageable chunks, but has also been a way to help engineers discover projects that they are passionate about.

2. Don’t be afraid to show it off

Second, it is critical that participants be able to see as many of the projects as possible at the conclusion of the Science Fair. We still have room to improve on this, but including a Science Fair Open House the Monday after the fair provides everyone with a chance to see what their peers were able to accomplish.

3. Level set

Finally, it is worthwhile noting that you should not expect to get new features or products out of every event. It is much more valuable to keep the process very open and to allow everyone to enjoy themselves rather than feeling like they have to produce the next great thing.

bazaarvoice: engineering

The official blog of Bazaarvoice R&D