Innovation at Scale

by

scaleAt Control Group, we help some of the biggest brands leverage technology to solve complex business problems and build engaging customer experiences that activate new sources of revenue. Over the past year we have been working with a Fortune 50 national retailer to transform their marketing operations and position the organization for future agility and growth.

In speaking with key leadership early in our engagement, it became evident that in order to be successful and deliver meaningful and lasting results, we were going to have to solve for a key problem that is common amongst many clients we work with: tension between enterprise IT and the business. On the one hand enterprise IT has traditionally focused on implementing policies and controls that provide security, minimize risk and ensure that technologies are ready for the enterprise environment. The business, on the other hand, is commonly tasked with finding the best solutions to increase the speed of bringing new ideas to market. While these two forces can often seem contradictory and at odds with one another, strategies can be employed that harnesses the entrepreneurial spirit of the business to innovate and try new ways of doing things and maintain the necessary organizational controls – solving for a seemingly intractable problem and bringing about the best of both worlds.

Sustainable innovation requires inherent tensions to be managed appropriately, and for this client, we developed an innovation framework built on some core principles:

Staged Innovation Process. The culture of innovation at this client is particularly vibrant but it required focus and an outlet for creative ideas to be acted upon and executed. Control Group spent time understanding existing business processes to identify what worked well, pinpointed opportunities for improvement and crafted an innovation process tailored for the client and rooted in methodologies Control Group has used successfully time and time again. This process clearly articulates how new ideas progress from concept to prototype to limited pilot to scaled production launch and incorporates key stage gates and departmental sync points along the way to ensure the appropriate controls are in place.

Strategic Alignment. With an innovation process defined, we worked to build support amongst the client’s key leadership as well as their strategic partners to galvanize the framework and unite all stakeholders around the shared vision for the future. From executives to managers to line staff, we ensured a consistent message about the significance of work ahead, the value to be gained and the importance of each employee’s engagement was being delivered.

Controlled Experimentation. To promote inclusiveness and employee engagement, Control Group built a sandbox environment to allow the business to evaluate new technologies, simulate and test future in-store interactions and replicate incumbent technology ecosystems. The environment was built leveraging the organization’s approved technologies, is aligned with the enterprise IT’s preferred technology stack to ensure future compatibility and support and incorporates best practices from enterprise architecture, integration services and agile Software Development Life Cycle principles. This environment will serve as the rallying point for marketing innovation and toolkit for getting new ideas to market; allowing stakeholders to remain hands on in the innovation process, providing full visibility into early wins for the business and customers and functioning a staging ground for production planning and readiness.

Managed Implementation. At Control Group we understand the complex issues that exist with enterprise deployments and believe that success is not simply a system implemented to specification; it is a great user experience for customers and employees. To ensure that this client reaps the full benefits of their innovation framework and platform, we’ve brought to bear our comprehensive program management approach to manage change through strategically aligned work streams, established roles and responsibilities and formal governance processes.

Through working collaboratively with our client and understanding their core needs, we’ve found a way to harmonize the aspirations of the business with the requirements of enterprise IT. Together, we are building a platform to reach more people, more inventively and more effectively. And beyond the technology transformation, we are helping to develop a sustainable innovation practice within the organization that will unlock future growth opportunities for the business for years to come.

Food Groups: A Real-World Experiment in Workplace Interaction

by

pushI recently repurposed a weird, old project of mine from grad school for use in our office, which will basically turn all of my co-workers into test subjects in a company-wide social experiment. So let me elaborate…

Two years ago when I was a research assistant in the Changing Places group at the MIT Media Lab, I spent a good deal of time exploring how technology can be used to increase informal, serendipitous workplace interactions. These are the famous “water-cooler” types of conversations that you might have even experienced at your own company. For example, perhaps you recently struck up a forced, awkward conversation with a coworker you only sort of recognized as you both waited for a pot of coffee to brew. Then you realized that he happened to be an expert in the programming language you were having trouble with, so he offered you a few pointers. As I had written in my paper at the time, organizations are particularly interested in these serendipitous encounters because “such interactions can lead to increased idea cross-flow, creativity, productivity, and innovation at large, though few attempts to design architectural, organizational, or technological solutions have succeeded in achieving this.”

My thesis revolved around designing and testing a few different technological approaches to this problem, and one of those happened to be a quirky, little device called Food Groups.

ml button

Food Groups is a flashy, big red button on a pedestal that randomly matches coworkers up to grab lunch together. Even in highly creative and collaborative places like the Media Lab and Control Group, people tend to eat lunch either by themselves or with the same group every day, making lunch time a prime time for interaction optimization. When I first built Food Groups, I tested it out with the students and faculty in the Lab, but it received a lukewarm reception. Despite having been initially excited about the button, my subjects quickly became afraid that they’d be matched up with less-than-desirable lunch partners, and seldom used the device. I jokingly chalked these results up my participants being awkward MIT students and always had the intention of testing Food Groups out in a real-world workplace environment. Unfortunately, I never had the chance to do so, until now.

Control Group is a growing company and as such, sometimes it’s hard to know who everyone is and what they do. But as a fast-paced development shop that uses cutting-edge technologies to build never-before-seen digital experiences, we need as much help as we can get to ease the flow of knowledge within our organization and be as collaborative and productive as possible. So, last month I was inspired to bring Food Groups back to see how it would fair in the real world. With a little refactoring to make the code CG-specific, it was ready to start revolutionizing lunch time.

Here’s how it works:

1. Anytime before 12pm, CG employees can head to the kitchen, swipe their ID card, and hit the button.

foodgroups swipe push_zoomed

2. They then receive an email confirming that they signed up for lunch that day.

Screen Shot 2015-04-10 at 10.14.11 AM

3. At 12pm that same day, they get matched up with 2 – 3 others and receive an email introduction with a suggested lunchtime of 12:30pm at a suggested nearby restaurant.

Screen Shot 2015-04-10 at 10.15.06 AM

4. Groups then use the email chain to coordinate further

Food Groups has only just launched at CG, so it’s still too early to say whether or not it will be successful. Check back here on the CG Blog in a month for a follow-up post with an analysis of how much (or how little) it’s being used! What do you think? Would this get much use in your own office place?

Designing LinkNYC for NYC

by

Value Sort_Martin (1)

As Fast Company reported last week, Control Group is in the process of conducting ethnographic research to understand exactly how people across NYC might experience LinkNYC. As partner Colin O’Donnell explained: “We want to reflect the diversity and interests of the city and fit in aesthetically and functionally with what people want.”

UserInterview_Mariama (1)How do New Yorkers perceive things that are “free”? How is video chatting best communicated? What are different public screen scenarios that people are used to? This important human-centered design phase will help inform our entire development process here at Control Group – from user experience design, to interface design, to software development. In this way, we are not only able to build strong community partnerships to learn more about citizens’ needs across NYC, but we are also able to communicate directly to these neighborhoods about Link simultaneously. This will ultimately help foster both widespread adoption and usability.

FocusGroupBrooklyn (1)We’d like to thank the following organizations who have welcomed us to their neighborhoods and provided much needed insight and guidance on how their constituents would like to experience Link in New York City:

Outreach_siliconharlem (1)And the ones we will visit in the coming weeks:

Of course, this is just the beginning. Just as New York and New Yorkers will continue to evolve over the next decade, so will Links. And this type of research and engagement with different communities will help inform what Link will do, whether in 2015 or 2025.

Unit testing Websockets in Play 2.2.x

by

150307 Yang_EMKI Surround-113On a recent project for The Edward M. Kennedy Institute, we made heavy use of the Play framework and its underlying Akka implementation. As part of the system architecture, we applied the concept of entities from Domain Driven Design to that of an actor. This idea was sourced from Jamie Allen’s book, Effective Akka. In our domain, we modeled museum visitors as actors. As part of the DDD services within this bounded context, was a device gateway that held a web socket channel to visitor tablets. This proved very efficient and easy to reason about as domain entities within our system. In a previous post I described how we used the Concurrent.broadcast mechanism in Play to create a web socket connection. In this post, I will dive a little deeper and show you how you can model your actor and device gateway service to allow for easier unit testing of the web socket channel offered through Play’s Concurrent.broadcast.

To do this, we will use the following strategy:

    - Create a trait that handles creation and usage of Concurrent.broadcast channels

    - Using Traits, dependency inject this trait onto our actor representing the visitor entity

    - Create a controller with a method that will instantiate our actor and return back a broadcast channel

First, let’s create our trait whose single responsibility is the creation of the Concurrent.broadcast channels and usage of them:

Next, let’s create our actor worker to represent our visitor entity and inject our WebSocketChannel trait:

Next, let’s create a simple controller that will allow us to create a web socket connection:

Cool, with these pieces we can establish a web socket connection. Based on the logic in our RegisterSocket event handler within our actor, we should expect a JSON message with the keys ‘type’ and ‘data’, and their respective values. So how do we unit test this?

Well first off, let’s determine just what we need to test. Play already has tests to verify that it’s Conncurrent.broadcast mechanism works, so we don’t need to reinvent the wheel here. However, we do want to ensure the side effects of our RegisterSocket, which is that a message is pushed up the channel.

With the use of traits and DI, this becomes surprisingly easy!

First let’s create another trait that extends our WebSocketChannel trait that allows getting the message being sent:

Here we override the push method, keeping the argument and return types the same. The only difference is that we utilize a List data structure to model a channel, which itself is Queue (First in, First Out). With this trait we can write a simple test that verifies the side effect of our RegisterSocket event.

And that’s it! We have successfully tested the side effect of our actor’s web socket channel.

 

Could MTA Ever Make A Leap?

by

This past March, Leap launched a new “lounge-like” bus service in San Francisco. The Verge found it reminiscent of the reception area for a large tech company. I was reminded of WeWork, in their own words:

At Control Group, we reinvent services– public and private– by building capacity within the organizations that deliver them; we connect our efforts to a business need or revenue stream to ensure the changes are sustainable. Part of this process involves putting aside the constraints of an existing organization– thinking big – and then (sometimes lightly) reapplying reality until things fit.

So a thought experiment: consider the New York MTA, which serves one of the most dense cities in the United States, New York City. Could Leap become a model for MTA’s bus service, or is Leap forever destined to be a startup?

An overview of some key issues from our perspective:

Funding. Funding for “amenities” in the public sector is scarce. How can new revenues, e.g. from advertising, be earmarked towards funding amenities like Leap instead of being spent to maintain the status quo?

Mandate. A “customer-first” mandate needs to come from the top. Customer communications and marketing is an easy place to start; getting customer communications and operations together to affect service is a bigger challenge. Great things are happening at Sound Transit, LA Metro and Motivate.

Title VI. Requires equal service be delivered under Federally-funded programs. Leap doesn’t serve everyone. It isn’t handicap accessible. It doesn’t stop in all areas of the city. Could MTA leverage technology to help?

Cultural Plurality. As Leap imagines bringing a “living room” to a formerly sterile public space, can we all agree what a living room should look like? Design-led research and community inclusion can help build consensus around shared values.

Partnership. One solution to some of these issues is partnership with the private- and third- sectors. Partnership can externalize risk, helping government “take a chance”. Finding the right areas and structure for collaboration and partnership is critical.

Technology. Technology is absolutely essential to making a model like Leap work on a larger scale– especially as it might expand the reach of such a system via dynamic routing, dispatch and pickup requests. Imagine a bus that works like Uber.

Density/Connections. Currently, Leap only travels between two neighborhoods in San Francisco, making only 3-4 stops to pick-up passengers, depending on time of day. Dense residential and commercial areas, bikeshare and other “last mile” mobility solutions make limited stop services like Leap work.

The biggest barrier for Leap as a model for public transit is that Leap solves a different problem. Public transit has to serve everyone, Leap serves a very select few. Finding the aspects that are transferrable and those that are not will be the task of government and startups that provide transportation services (like Leap, Bridj, Uber and others) in the coming years.

At Control Group, we are defining the “responsive city”– a place where connectivity, interactive digital touchpoints and sensors might make a city more efficient and responsive to citizen needs. Self-driving cars aside, these technologies stand to fundamentally change the economics and operational models for public transit.

EMK Institute: Commit History

by

For the last two years, dozens of people at Control Group have been building the technology stack and implementation behind the recently opened Edward M. Kennedy Institute. Working with our design partner ESI Design, we created something that has never existed before: an interactive, immersive digital museum experience that includes a complex, tablet-driven role playing recreation of a Senate session in addition to multiple games and galleries in the chamber surround.

The 42-minute video above, synched to some of Ted Kennedy’s most iconic speeches (downloaded from http://tedkennedy.org/ownwords), is generated using gource off of our git logs. For the non-coders, what that means is every time we make a commit (ie: save a file) to one of our source-code repositories, the action appears on this visual map of our system.  The dots are files, the lines represent folders, and the people icons are (you guessed it) people.

Software is built by people, for people– many people sometimes, working together, crafting and refining and perfecting. You can somewhat see into our process in this short film. This movie focuses on 5 different repositories that cover a lot of what we did for the museum (but not all by any means, we have over a dozen repos for the project). The source code repositories– and where they are visualized in the movie– are detailed below:

Platform: (20 seconds) Primarily Scala – used to control and manage all museum interactions, API for internal and external data feeds. Like the project itself, this repo starts a long time ago and takes a while to get going, but once it does it really flies.

DevOps: (10 min) Build process and deployment, crucial for a project of this complexity. Also amazing to see how this was refined and improved over the last few months before launch.

Exhibits: (16 min) Everything up on the walls of the museum with a few exceptions. You’ll see a lot of activity in this one!

Webapp:  (25 min) Tablet web-based technology – AngularJS, HTML5, CSS, etc. This was also very active throughout the project, with many contributors.

Tablet: (33min) Android Application that hosts Webapp technology.

Everyone at Control Group who worked on this project is extremely proud of their contributions, and while there is no greater tribute than the physical institute itself, this movie shows some of the hard and constant work required to engineer something beautiful. Thanks to EMKI, ESI, Gigantic Mechanic and many others for the opportunity to work on this project and bring it alive.