Interns Can Run Your Business: How to hire interns that ROCK!

We’ve all been there. Your projects are taking off and there’s a ton of work to be done. Important work. You need to hire more people. You request a new headcount but you’re told that unfortunately there’s no budget for full-time hires. You’ll need to get things done with the people you have…or hire interns.

Let’s face it. None of us likes to hear that. Most of us don’t think important work can be done by interns. How can someone who’s only with the company for three months be effective, anyway, right?

Well, I’m here to tell you that I totally understand where you’re coming from and that you’re wrong. If you hire the right intern, they could potentially run your business in three months. For real.

Over a year ago, I needed help with API community management and outreach as well as the development of code samples to expedite the API on-boarding process at Edmunds.com. Like you, I had no budget for a full-time headcount and interns were my only option to scale. At first, I wasn’t really happy with the thought of an intern managing a community of developers, communicating with potential strategic partners, and writing quality SDKs. But that’s exactly what I needed help with, so I went for it with very low expectations.

Fast forward to today, I couldn’t be happier!

The Process

I started the search with a list of minimum requirements a potential hire must have (intern or otherwise). I knew I wanted someone who a) coded for fun, b) had experience with REST APIs, and c) was personable, humble and engaging. Simply put, I wanted someone who was demonstratively interested in the tech and business of APIs.

So I worked with HR on crafting the job listing. I set the bar really high. I wanted someone who was coding on Github because it’s fun, not because they had to. Someone engaged on Twitter, Stackoverflow and Quora because they have something to add to the conversation. Someone who was having conversations.

API evangelists are a special breed of developers. The good ones are experienced and possess excellent people skills. This made it even harder to find a candidate amongst the pile of resumes sent in by students trying to get a paid internship to meet some school requirement.

Needless to say, the process took a long time, almost 6 months. I got resumes from students with stellar academic credentials in computer science and math but with zero presence on Github, Twitter and forums. Some hadn’t even heard of APIs until they saw the job listing on their school’s bulletin board.

The Result

When the search was finally over, I hired @MichaelRBock, and boy am I glad I did! Michael’s been with us for over 6 months now, even while he’s doing a semester abroad …in Singapore.

Michael and I clicked right away. He’s smart, easy to talk to and very personable. Most importantly, he was extremely interested in our world of car open data APIs and their business impact.

Michael quickly proved himself an invaluable member of the team. Almost everyone who’s worked with him was shocked to learn that he’s just interning with us. He was all caught up with our systems, challenges and roadmap in a couple of days and by the end of the first week, he was knee deep helping developers with their API questions.

He sat on business development meetings and partner discussions on the second week of his hire. He built our Python SDK and was updating the Developer Portal on daily basis during our DX Certification process with Mashery.

Michael saw the potential in some of our API developers and brought them to my attention. He’s been great at handling difficult developers as well. All in all, he’s been fantastic at everything he’s done.

We’re Hiring!

Sadly, Michael’s time with us is about to end at the end of May ☹ If you or someone you know is interested in APIs and want to have a summer internship with us, let’s chat! There’s some big shoes to fill, which is always a good place to be.

Seven Practical Themes From The Lean Startup Conference

Earlier this week, I attended my very first Lean Startup Conference in San Francisco. I was invited to sit on a panel discussion of the lean startup practices in the enterprise by the good folks at Neo (thanks, Josh.) I spoke about my my experience at Edmunds.com and both the blessings and challenges that go with applying the lean startup principles in the context of a mature business.

Throughout the conference, many inspiring speakers told stories of successes and failures; dos and don’ts. There was a lot to take in (kudos to the event organizers for packing an impressive lineup! Seriously, my brain is still swollen from the data intake!)

After a few days of processing everything I heard, the seemingly disparate concepts started coalescing in my head into themes of lessons learned or best practices or whatever you want to call it. These are beacons derived from real-life experiences to help guide us maximize our chances for success and avoid unnecessary failures.

I distilled them down to seven main themes that every entrepreneur or change agent should live by. Here they are in no particular order:

Just Do It

Lean innovation and disruption is based in action. If you don’t do, then what the hell are you doing? We live in an incredible time where creating high fidelity software is easier than ever. With tools like Heroku, Twitter Bootstrap, Django or Ruby on Rails, Google Analytics, and Facebook Canvas, validating a product by building a minimally viable version of it, or an MVP, and putting it in front of real customers is relatively a no-brainer kind of affair, yet not many people do it.  In his talk, Steve Blank stressed the importance of “doing it” as opposed to reading or talking about how it’s done. If you work at a large company, use the tools aforementioned to “do it.”  If you can’t code, try to onboard a developer to help you out. If you can’t, then maybe the universe is trying to tell you something.

It All Starts at The CEO Level

Senior executives to companies are the VCs to startups, for better or for worse. If your CEO doesn’t truly believe in validated learning and experimentation, the spirit of the lean startup is dead in the water in that organization. Many senior executives give good lip and rarely follow up with action. Beth Comstock from GE spoke about the protected class of ideas at GEThese are innovation teams believed in and protected by the CEO and are set up for success (i.e. they are funded, removed from the day-to-day chaos, …etc.)

It’s Not About You; It’s About The Team

Eric Ries stressed this point several times as did other speakers: in order for you to be successful, you need others to believe and embrace the lean startup principles as well. It was almost a call to action: how to inculcate these principles in our peers and organizations? How do we create an ecosystem in which validated learning is a core value? It was almost a call for evangelism. I believe the best way to show others the way is to lead by example. By “just doing it,” others will follow, especially after seeing the value of the ideas in practice.

Talk to Your Customers

We’ve all heard the “get out of the building” cry for action, but it all comes down to engaging with your customers and learning what their needs are. That’s accomplished by talking to customers in person or virtually through usability testings or even through collecting behavioral data through Google Analytics. As long as you’re “listening” to what customers are telling you and adjusting your product accordingly, you should be fine.

Cut The Crap!

My personal favorite learning from the conference. This encompasses cutting unnecessary features out of your MVP to speaking to people in the language they understand without the jargon. I find myself struggling with this a lot. Just because you understand what an “MVP” or “validated learnings” mean, it doesn’t mean that the person you’re talking to understands them as well as you do if at all. Taking the time to adjust your language to the audience before you is a crucial tool that ensures proper onboarding, understanding of, and ultimately the success of your project.

Use Android to Validate Mobile Products

I really liked Matt Brezina’s talk on Rapid Mobile Development and his contention that all products, including mobile, can be validated fast. This gets really important in mobile development since iOS development doesn’t lend itself to rapid development, given Apple’s tedious approval process. Matt’s suggestion to use a different platform for rapid testing mobile products is really interesting. Doing whatever it takes to find out if there’s a market for your product before building it out will in the end save you money and time. No one wants to work on an app or product for several months and have no one use it in the end. Now that would be heartbreaking.

Having Daily Outcomes

This was one of the learnings I spoke about from my experience. Validating a hypothesis or releasing a feature/test/fix every single day is important for success…and morale. Having 3-week iterations promotes procrastination and lots of wasted time. If you break down your product properly and “cut the crap” brutally, you will end up with very small tasks that can be tackled on daily basis. The team needs to leave for the day with a sense of accomplishment. This practice isn’t common in big companies and one that the lean startup spirit could help bring to the table.

These are the main themes that jumped at me. What do you think? Did I miss something?

I left the conference inspired to continue embracing the “just do it” mantra but also doing a better job in reaching out to different people across the company to help institutionalize the practice of validated learning and rapid experimentation. What will you do differently with these learnings in mind?

Five Lessons Learned at The Reinvent Business Hackathon

Last weekend, two of my colleagues and I participated in the Reinvent Business hackathon in San Francisco. I’ve participated in Hackathons in the past where code with its sophistication and originality was the main focus. It was different this time around; the Reinvent Business hackathon was primarily a non-technical event focused on innovative business solutions as opposed to purely innovative technical solutions.

The experience was extremely fulfilling with many learnings to be shared. Here’s a list of the top 5 learnings we gleaned from the event:

    1. Frame the Problem: Hats off to the organizers of this hackathon! frog and LRN did a bang-up job with the logistics and the flow of the event. I liked the fact that spaces in which opportunities for business reinvention and innovation where clearly called out.  The 160 participants were then asked to state issues that need to be addressed under each space. The frogs (i.e. employees at frog) then took all those participant-generated statements and coalesced them into clearly articulated problem statements. The participants then organically gravitated toward the problem statements they wanted to solve, and in turn, meeting other likeminded individuals, which made it easy to form teams.  State the problem and let people come up with the solution.
      Adding opportunities for innovation under the Business Decision space at Reinvent Business hackathon
      Adding opportunities for innovation under the Business Decision space at Reinvent Business hackathon

      The frogs combining all submitted statements into clear problem statements individuals and teams could tackle
      The frogs combining all submitted statements into clear problem statements individuals and teams could tackle
    2. Inspire Don’t Direct: Dov Seidman, CEO at LRN, delivered the keynote speech.  He was absolutely inspirational. He challenged us to “innovate in humanity” by making business personal. He’s a master storyteller and got everyone stoked and ready to hack away!  To get people to care and do their best, you have to inspire them, not direct them.

      Dov Seidman giving the keynote speech at the Reinvent Business hackathon
      Dov Seidman giving the keynote speech at the Reinvent Business hackathon
    3. Less is More: I noticed that the teams that did well had not more than 5 members.  This reaffirmed my belief that the less people you have in a team (ideally between 3-5,) the better the product, the team and everyone involved for it. I believe this goes to the fact that smaller teams don’t suffer much from the “too many cooks in the kitchen” syndrom and will also likely to focus better. Obviously, there are many large teams that do very well, but those are the exception to the rule.
    4. Team Roles = Accountability: I know this firsthand since our team failed to assign clear roles like Team Captain, tech lead, …etc. Our team, on the human level, was awesome! But the fact that we didn’t have assigned roles meant that we did everything by committee. Design by Committee and Decision by Committee, both of which proved detrimental to our success. Assigned roles it clear what each member’s responsibilities are. With responsibility comes accountability and in turn focus to deliver and eventually success.
    5. Storytelling is Everything: No one cares about how awesome your code is or how complex your software architecture is. People care about the human story your product creates. Why is your product good for people? Why do they want to use it? How will it impact their lives? Our team built a mobile web app that illustrated our idea, but when it came time to sell the idea (i.e. pitch it) we focused more on the product than the people that would benefit from it. Ironically, the winning team had an identical idea to ours and no prototype. Yet they won and they won because they told a compelling, very engaging story about why their product is good for people and for business.  We didn’t win because we couldn’t agree on how to pitch our product and tried to accommodate every opinion.

      This team ROCKED! They told an awesome story and came in 2nd.
      This team ROCKED! They told an awesome story and came in 2nd.
The learnings are still sinking in and I’ll probably update this post with more learnings in the coming weeks. My colleagues and I left the event inspired and committed to making business personal and authentic through technology. Most importantly, we were inspired to tell better stories.
Team Edmunds (left to right): Ismail Elshareef, Daniel Kang and Joseph I
Team Edmunds (left to right): Ismail Elshareef, Daniel Kang and Joseph I

APIs: A Strategy Guide by Daniel Jacobson, Greg Brail and Dan Woods

Learn to Speak API for The Sake of Your Business

You should read this book if you are remotely interested in the following:

1. Why your company needs to have an API

2. How to design, secure and manage the API

3. What API strategies your company should adopt, including legal and operational considerations

4. How to measure the success of the API

5. How to drive API engagement

The authors have years of experience in the API space and I think they did a pretty good job distilling their collective wisdom and learned best practices in this “short and sweet” booklet (134-pages!) I think it is important for the success of any API initiative that *all* stakeholders read this book to get on the same page of what needs to take place to ensure the success of the initiative. It’s hard to argue with the “tried and true” practices of which this book is rife.

If you’re interested in getting into the nitty gritty technical details of how to build an API, I highly recommend RESTful Web Services Cookbook: Solutions for Improving Scalability and Simplicity as a technical companion read to this book. Read this book first, and then delve into the technical details with Subbu’s book. Full Review

The Mesh: Why the Future of Business is Sharing by Lisa Gansky

The Mesh: Why the Future of Business is Sharing by Lisa Gansky

A Look at How Sharing Defines The Success of Businesses in the Future

The book discusses the increasingly recurring themes of openness and platform that have been discussed in other books like Open Leadership by Charlene Li and Where Good Ideas Come From by Steven Johnson.

The core premise of Mesh businesses is: "When information about goods is shared, the value of those goods increases, for the business, for individuals, and for the community."

The author says that, "fundamentally, the Mesh is based on network-enabled sharing–on access rather than ownership. The central strategy is, in effect, to "sell" the same product multiple times. Multiple sales multiply profits, and customer contact. Multiple contact multiply opportunity–for additional sales, for strengthening a brand, for improving a competitive service, and for deepening and extending the relation with customers."

The book also references a recent study, which concluded that, "a recommendation from a "trusted source" like a friend or family members was fifty times more likely to persuade someone to buy a product or try a new brand. The same study reported that word of mouth is the "primary factor" behind between 20 and 50 percent of purchases, and emphasized the expanded role of information networks in driving this development."

WHAT IS THE MESH

The 4 Characteristics of a Mesh Business as listed in the book are:

  1. Sharing a high code, frequently used goods
  2. Advanced Web and Mobile Information Networks
  3. Focus on Physical Goods and Materials
  4. Engage with Customers Through Social Networks

"The Mesh model is based on a series of transactions, on sharing something over and over. Creating a share platform is the first, necessary-but-not-sufficient building block of the Mesh. The second is to create information infrastructure that takes advantage of mobile, Web, and social networks. Then each interaction, and transaction, becomes an opportunity to gather and exchange information with a customer."

The 7 Keys to Building Trust in the Mesh:

  1. Say What You do
  2. Use Trials
  3. Do What You Say
  4. Perpetually Delight Customers
  5. Embrace Social Networks and Go Deep
  6. Value transparency, but protect privacy
  7. Deal with negative publicity and feedback promptly and skillfully

WHY THE MESH

Tomorrow’s business leaders recognize that trust in a business’s environmental and social practices increasingly drives informed consumers’ decisions. Successful Mesh businesses harness information from customers, combine it with data from physical products and social networks, and then use that information to satisfy customers, and their friends, in ways never before dreamed of. Good Mesh businesses are smart about combining more frequent customer contact with enhanced information sources to create and refine superior experiences, partnerships, products, and offers.

MESH COMPANIES HIGHLIGHTS

Zipcar is one of the companies profiled in the book.  The author says that, "The robust information platform and focus on building the brand distinguished Zipcar from early car-sharing companies that were merely long on good intentions, many of which failed. In fact, Zipcar is primarily an information business that happens to share cars."

So if you’re in the information business, you are a Mesh business whether you realize it or not.

TCHO, a chocolate company in SF, produces "beta editions” of its dark chocolate. “Based on customer feedback and continuous flavor development, new versions of the chocolate emerge as often as every thirty-six hours. Version 1.0 went through 1,026 iterations in a year."

Why did Netflix slaughter Blockbuster? Blockbuster was late in acknowledging customer resentments, and late in understanding the spreading power of social networks to shape brand perception. They created a share platform, but neglected other elements that make Mesh businesses so competitive.

This is an excellent book that could help realign the business perspective on how to succeed in the future. Embracing openness, sharing and focusing on customer satisfaction are some of the key practices that could catapult your business from mediocre to stellar now and in the future.

SlideShare Deck: WTF is Social Media Now?

This deck is extraordinary in many respects. It really drives the point of how important Social Media is to businesses and individuals home. More importantly, though, it really showcases the best practices of putting together a visual presentation:

  1. Use Few Words
  2. Use Effective Imagery
  3. Have Fun

I’ve seen too many presentations fail because they don’t adhere to these best practices. They are too literal, too bland and too damn boring. THIS, ladies and gentlemen, is how you do presentations.

http://static.slidesharecdn.com/swf/ssplayer2.swf?doc=wtf-socialmedia-now-100717090720-phpapp01&stripped_title=wtf-is-social-media-now&userName=ankitbathija

Making the Web Faster as a Community

I recently wrote a blog post on the techniques we used at Edmunds to make our sites faster to the end consumer. The topic of web performance is big right now due to the fact that more and more business fully realize the real impact of performance on their brand and bottom line. It's heartwarming to see the level of interest and engagement we received so far.

I also wrote a guest blog post on the Google Code blog as part of the ongoing effort by Edmunds and Google to push for a faster web for all. I'm looking forward to further collaboration as we tackle the mobile web frontier and its interesting challenges and opportunities.