Groupon’s colossal HR failure in China

Over Christmas break, a good friend shared her experience at Groupon China.  She was there for four months and joined the company before it launched and oversaw its expansion in some of the tier two cities in China.  Listening to her experience was a case study for what not to do if you want to launch a successful startup anywhere.

From what I could gather, the problems where many folds, but as with many company problems, it came down to people.

Groupon China’s HR strategy is to create a pyramid structure where a small number of well-educated ex-pats ran the general management, while sales and general operations were performed by locals.  I knew several folks who worked in Groupon China’s management group, all of them fit the bill.

In Groupon’s evaluation of China, it still lacks best practices and high quantity of disciplined managers to support the type of sales organization that Groupon need to replicate, so it had to hire expats.

The end result is actually, a fundamental disconnect between the generals and the foot-soldiers that were Groupon China.  The generals were unfamiliar with the terrain that they encountered.  Yes, they had copious amounts of data to make decisions, but they were untrained in the art of Chinese relationship management, culture, and people.  What worked in the west, does not work in the east.   Local employees didn’t feel incentivized by the commission structure in place.  They treated their managers like little emperors, never doubting anything they say and never providing feedback for what is obviously right or wrong to the locals.  The pillars of organization behavior that western management depends, simply didn’t apply to the local Chinese.  Western management methodologies, the strength and reasons for Groupon’s success in the U.S., was it’s downfall in China.  It imposed a rigid gap between management and employees.

Others I’ve talked to mention that Groupon China expanded from 10 to 200 people in a matter of a month as another reason for it’s initial slow growth.  And that they were giving too much responsibility to folks who were not committed to be there for the long run.  I think these are all valid reasons too.  But they are all symptoms of a miscalculation by Groupon on the human resources capabilities of China.

What should they have done instead?  I think they should have hired local entrepreneurs and paid big bucks to attract the good local managers that are their and get them to run the show.  Sprinkled in between the ranks are a few ex-pats to help with communication and general strategy alignment with Groupon International.  But fundamentally, China is a big enough market that it’s offices should be given independence and operate as a wholly separate entities.  HQ may dictate some big picture sales targets, and provide resource needs as necessary, but should not be dictating the specific type of expansion strategy that the Groupon China should adopt.  With all ex-pats running the show, effectively Groupon China didn’t adopt a realistic China expanstion strategy, and instead was simply trying to copy a formula that worked for a more mature market, in a different part of the world.


Looking forward to Rails 3.1

At Gojee, we are running Rails 3.0.7.  Recently, we’ve been experimenting with Sprockets, Coffeescript, and Sass.

With tonight’s release of 3.1.0.  All of our experimentation will be a lot easier, since 3.1.0 comes with default support for JQuery, Sprockets, Coffeescript and Sass.

I also found the following updates to 3.1.0 awesome and important.  For the full list go here

Reading up on some of the rails 3.1 features:

  • HTTP Streaming, allowing a user’s browser to download Stylesheets and JS while the server is generating the response.
  • Default scopes are now evaluated at the latest possible moment, to avoid problems where scopes would be created which would implicitly contain the default scope, which would then be impossible to get rid of via Model.unscoped.
  • Support the :dependent option on has_many :through associations. For historical and practical reasons, :delete_all is the default deletion strategy employed byassociation.delete(*records), despite the fact that the default strategy is :nullifyfor regular has_many. Also, this only works at all if the source reflection is a belongs_to. For other situations, you should directly modify the through association.
  • Migrations are now reversible, meaning that Rails will figure out how to reverse your migrations. To use reversible migrations, just define the change method.
  • class MyMigration < ActiveRecord::Migration
      def change
        create_table(:horses) do
          t.column :content, :text
          t.column :remind_at, :datetime
  • Migrations now use instance methods rather than class methods
  • class FooMigration < ActiveRecord::Migration
      def up # Not self.up





The Japanese women’s soccer team and resilience

What an amazing demonstration of human spirits sports can be.

How did the Japanese women’s soccer team (all 5’4″ of them) beat the U.S. team (average height 5’7″) for the World Cup?

The U.S. was clearly the more athletically talented team, but it was the Japanese who had the mental edge.  What else could explain 3 missed penalty kicks for a U.S. team that was perfect just a week before?

In 120 minutes and 2 equalizer goals, the Japanese team showed their nation and the world what a gritty attitude and an indomitable will can bring.

The many ways I failed as a first year entrepreneur

How fast time flies.

It’s been a full year since Mike and I officially started working on Gojee full-time.  I’d left a job I really enjoyed for the chance of accomplishing a dream I’ve had since childhood — starting my own company.  Team Gojee was ready to take on the world and nothing could stop us.

…since then, I’ve been humbled many times over and made more mistakes than I can count on.  Want some examples?

  • I showed my hand too early during vendor negotiations and probably cost us a few thousand dollars (take-away: keep your mouth shut and let the other guy name the price first)
  • I missed a train to an important business meeting and had to take a VERY-EXPENSIVE cab ride (take-away: keep 2 alarm clocks, and don’t think 2 hrs of sleep is going to be fine and you can just ride on adrenaline)
  • I had a heated skirmish with my cofounder right in front of our team and then had to admit I was wrong to everyone (take-away: take heated debates to a private setting, otherwise you run the risk of introducing doubt to your whole team)

The past year has taught me real-world lessons that no business school class can teach and given me valuable skills that no 6-figure finance job can give.  The ones that left the most impression on me were the ones that challenged (and replaced) existing views and biases I previously had.

- Startup = 24×7 Work (Wrong!). Working hard is important, working SMART is too.  For the first 6 months of Gojee, we worked 7 days a week, until 3AM on most days.  I didn’t do much sleeping and my programming/general intelligence was seriously degrading.  While people were always impressed that I could work so much, I wasn’t sure it was a good thing.  I soon realized sleeping 8 hrs a day and having some time off on weekends actually improved productivity and mood.  Try it, if you don’t believe me.

- We Can Be Leaders in Many Ways (Wrong). Leadership takes many forms, but that doesn’t mean it’s a license to choose.  I always believed in leading by example.  But as Gojee grew, I realized that it’s a very passive form of leadership (irony is thy name) and not exactly scalable.  An effective leader is vocal, persuasive, strategic, compassionate, tough, AND aware of the big picture. OR is not an option here.

- Good Processes = Good Results (Wrong). Using methodologies like Agile, Scrum, Lean Startup can help a startup’s productivity. But there is no silver bullet.  Those methodologies can make a good team better, but they can’t make a bad team good.  In a small team format, people and culture outweighs process.  Find team members who care about the work they do AND have the right character traits.

- Raise Money Only When You Need It (Wrong). When we raised our second financing round, we didn’t need the money, but Mike had a good argument for why we need it (it’s insurance money just in case our product didn’t gain market traction).  Am I glad we did it.  It turns out, we did have to pivot and the “insurance money” gave us the confidence and run-way to move in a new direction.  The startup world is risky, a good entrepreneur finds ways to derisk.

After 2 financing rounds, building our team to 7 people, launching a website (3 times…), I feel like the journey is just beginning.  I look forward to my mistakes and learning from them.

What entrepreneurs can learn from the Mavs

I’ve never been a huge Dallas Mavericks fan.  To me, they weren’t exciting, they weren’t fun, and nothing about them stood out.  The truth is, I never really gave them a chance, because they were so unassuming.

But somehow these Mavs are the NBA champions.  And they deserve that title.

Watch the mini-movies for each Finals game on and you’ll see that this team is methodical, disciplined, and confident.  Every team they faced seemed stronger than them, but ultimately the Mav’s toughness won out.

Each of these opponents faltered due to a weak-link in team chemistry.

  • The Lakers’ Pau Gasol all but disappeared from the basketball court, leaving his teammates and coach exasperated
  • OKC’s Westbrook was heavily criticized for being a selfish point guard, while Durant seemed at times tentative and unready to take on the role of team leader.
  • For all their talents, Miami’s triumvirate seemed immature.  Lebron James shied away from his opportunities for greatness.  Dwayne Wade started the infamous “Cough Gate” giving Dallas extra incentive to win.  Chris Bosh… well he was quiet… too quiet.

On the other hand, the Mavs role players stepped up at crucial times when their numbers were called.  Jason Terry, J.J Barea, Jason Kidd, Tyson Chandler, and Shawn Marion lightened the load off of their leader Dirk when the team needed it most.

In a league rich with stars, and against teams that are stacked with “talent”, Dallas proved that teamwork and define roles within a team can still win championships.

To all the aspiring entrepreneurs out there, I hope you’re building a team like the Mavs.  You’re hiring for attitude just as much as you’re hiring for aptitude, because it’s just as important that everyone on your team can be on the same wavelength, feast off of each other’s energy, and inspire each other.

Build a team that have heart and an identity, even if it is one that is “unassuming.”

How Gojee threw away its entire codebase and got to a better product, faster

Since March, Team Gojee Engineering (@eric_hummel, @dhf2001, and I[@hetianye]) have been heads down developing the new Gojee.  Using Rails 3 and plentiful pots of coffee, we were able to quickly develop a prototype.  After 3 months, we’re finally live!

This is a short story on how we decided to sacrifice TDD/BDD for development velocity in the face of uncertainty, and how we reintroduced testing when we felt the time was right.

The Setting
Gojee hasn’t always been a recipe inspiration site, in fact, up until March 5, we were more of a data-centric site… that is until a late night conversation between Mike and I resulted in a memorable trip for Team Gojee to Soho Park where we announced the new direction of the company.

Because of the major shift in focus towards recipes, it rendered the old site essentially useless.  Everything from the user experience, to the design, and code had to be rethought and built from the ground up.  The engineering team decided to blow away our code base of 9 months and start everything from scratch.

The Beginning
Thanks to the magic of Ruby on Rails, within 2 weeks, we had a functional prototype.  It was buggy and not ready for primetime, but it actually wasn’t too different than what we currently have.

For the next 8 weeks, the product team spent a lot of time refining the prototype–introducing add-on features, removing many of them, and in general writing and deleting much of the code base.

During those 10 weeks, we ignored writing any tests because of the high uncertainty on whether a feature would actually persist for more than a week.  We favored a quick release over developing 100% to spec, because we wanted the entire team to play around with the new features ASAP.

The Problem
While the “no-testing” approach worked great to start, by the end of 10 weeks, releasing code without testing became a huge liability for everyone. Everyone on the Gojee team from Engineering to Design to Marketing and Content was beginning to pay the price. Without tests:

  • We had to rely on human testing. This was slow, imprecise, and a horrible drain on time.
  • We didn’t find out about broken features until 2-3 deploys after they were initially introduced into the site. This made every team member a little nervous about each deploy.
  • Debugging took a long time because we didn’t have spec tests to tell us where exactly the code was broken and we didn’t know when the bug was introduced into the codebase.

When development had just started, the tech team had a ridiculous velocity and benefitted from the lack of test. By the tenth week, our velocity was significantly crippled by the extra time we spent debugging.

The worst part was that people were beginning to doubt the quality of work by the engineering team. Dan, Eric, and I pride ourselves in the quality of work we do. To get such feedback was devastating.

We had to do something because any level of distrust within a team can be detrimental to its performance.

The Solution
To find a solution, we took a step back and surveyed our effort. What we saw was:

  • There was a core set of features that was considered “stable”
  • The site has gone from doing 1 thing (showing recipe pictures) to doing many things (invitation, account setting, educating users, etc…)
  • New features that were in the pipeline, interacted with many parts of the site, meaning side affects will only get worse

All signs pointed to the need to start testing. We decided to first catch up on tests that are missing and then shift to test driven development (TDD) as features become more stable. So we took a week’s time to catch up on our technical debt. We implemented Cucumber for feature tests, RSpec for unit tests, and Jasmine for JS tests.

The Results

While our test suite isn’t perfect all the time, we’ve already started reaping the reward of having them. Just this week, we found a bug that we otherwise wouldn’t have discovered. The rest of the Gojee team, now spend more time on their real jobs rather than as human guinea pigs. More importantly, we’ve earned back some of the trust from the rest of our team.

While I don’t think we had the perfect development process.  I feel like forsaking test for development speed was the right decision for us, because of how uncertain we were of the final form of Gojee 3.0.  It allowed us to prototype fast and experiment with many different variations of features.  We were less hesitant to blow away code, because we spent the absolute minimal amount of time writing them.  However, as our code got more complicated, the design specifications became more complex, and the team’s time began to get weighed down by manual testing.  At that point, it made all the sense in the world to begin introducing tests.

We are not TDD yet, but we probably will be soon.  Now that we’re beginning to make incremental changes that don’t change from day-to-day, it makes sense.  I’m not sure we’ll ever be full BDD, that’ll depend on things that I can’t predict.

4 ways that Gojee recruits for talent

Chris Dixon recently wrote a nice piece on the importance of just “showing up” when recruiting talent.  His view is that talent is out there, you just have to look harder than everyone else.

He’s absolutely right.

When Mike and I started Gojee a year ago, we knew we needed to recruit design and technical talent ASAP.  We asked startup veterans what they found to be the best way to recruit talent, but found no consensus.  So we decided to just leave no stone unturned.

Here’s what we did.

  • We scoured LinkedIn for potential candidates and used InMail for outreach (Mike literally spent weeks doing this).
  • We went to design and tech meetups on a regular basis (Every week)
  • I posted our Engineering job description on as many Ruby job lists as I could
  • We hosted a hackathon
  • We asked for referrals every chance we got

It took a good 4 months to fill the Gojee team to the 9 people we are now.  Each method we tried brought us new leads, and we interviewed incessantly (~1-2 people a week).

The most successful measure we tried also required the least effort.  We tapped into our existing network.  Four of the team members we recruited were friends with existing Gojee team members before they joined Gojee.  I’m a huge fan of referrals (especially from current team members) because 1) there is a strong quality guarantee and 2) there’s almost no chance of cultural fit problems.  Not all referrals are the same by the way, I prefer “I’ve worked with…” rather than just “I know a friend…”

LinkedIn turned out to be the best external resource for us.  We hired four people from there as well.  It’s important to note, even though LinkedIn and our “network” both yielded four team members, the effort it took to narrow down the field to the final four was significantly higher using LinkedIn.  But when you need talent, you should try everything possible regardless of the amount of effort.

The last measure that yielded real results was simple brute force job postings.  Dan, our co-lead Engineer, happen to have ran into a job posting I made on  There is an art to the Job Posting that really deserves its own post, so I won’t go into it here.

Meetups actually didn’t yield any short-term hireable candidates for us, but I think they do provide a great place for expanding/collecting contacts in an area that the entrepreneur isn’t familiar with.  They helped us get to know other design/tech/marketing professionals in the NYC startup scene.

At the end of the day, I don’t think there is a sure-fire way to hire for early stage startups.  The key is to be consistently on the look out and keep in touch with any great talent you happen to meet, even if you’re not looking.


8 simple steps to hackathon epiphany

A “Brief” Behind The Scenes Look at the Food+Tech Hackathon

Up until a week ago, the largest event I had ever organized were dinner parties for 10 in my apartment.  Then the Food+Tech Hackathon came along.

With 12 days of lead time, a $100 budget from Gojee, and big aspirations, I joined Danielle Gould (founder of Food+tech Connect), Marc Alt (CEO of Opensourcecities), and Steve McGrath (CTO of Gojee) to figure out how to create the first ever food-themed hackathon in human history.  Our goal was to register about 45 people for the event.

As it turns out, we had:

  • 139 people register their interest
    • 117 people registered (along with a 22 person wait list)
    • 59 registrants reported for hacking, another 10 or so came in just out of curiosity
  • 13 ideas were generated (9 before the event started)
  • Out of the 13 ideas, 9 teams eventually developed prototypes to demo.  My favorite two are:

Needless to say, the Food+Tech Hackathon was an astounding success.  We had more participants than we imagined possible and we didn’t even need to use the $100 budget from Gojee.

How did we do it?  Below I try to summarize the 8 steps that we took which lead to a successful hackathon.  I am not saying this is the only successful formula, but it is one that worked for us.  This article is focused mainly on the organization work required BEFORE a hackathon happens.  I leave the best practices during the hackathon for a different piece.


Step 1: Find a theme

First and foremost find a unique and intriguing theme.

Food and technology are two very sexy topics in New York City. Even though that is the case, foodies and techies don’t necessarily see eye-to-eye on things.  Techies often adhere to a strict diet of pizza, hotdogs, and fried rice (*cough* yes… you), on that alone, a purist foodie is unlikely to go near a techie.  Without an agreement on food, we might as well all go home.

In our case, we promised good food to our foodies, and a good ole hackathon for our hackers.  I suspect there was a degree of curiosity for the two groups as well.  Foodies saw hackers as mystical wizards who could solve all their wild technology dreams.  And the hackers saw foodies as their end users and a great source of food insight.

Step 2: Assemble the Dream Team

Right from the onset we had a great organization team.  Right along with the theme Food+Tech we had a good mix of foodies and techies as organizers.  We weren’t just foodies and techies, we were expert foodies and techies.

The industry experiences and networks we brought alone (Danielle in food and media, Marc in food and non-profit organizations, Steve and I in technology and operations) were crucial in all phases of the event planning and execution process.  The long-term investments we’ve all made in our respective fields were what made a 2 week execution possible.

Just as the three musketeers weren’t complete without D’Artagnan, we wouldn’t have pulled it off without the help of Dominic Difranzo from RPI’s Tetherless World Constellation.  His experience with previous hackathons were very helpful.

Step 3:  Agree to Goals and Roles

The first thing we all did when we met on Skype for the first time was to figure out what our goals are for the hackathon.  We agreed that

1. The intention is for foodies and techies to meet so we want to invite a large number of participants from both groups.

2. We would like to see demonstrable products at the end of the day, which meant the need for plenty of hackers.

3. To encourage participation and idea generation, we would not have many restrictions on the types of ideas that people can work on and we would direct people to generate ideas before the hackathon.

With common grounds established, we went on to make a checklist of things to do and assigned responsibilities for everyone.  Everyone was responsible for marketing, because we had different groups of people we intended to attract. The rest of the task just became a matter of personal expertise.

Step 4:  Find an Event Management Site for Ticketing

We first started with Facebook group.  We quickly realized that while Facebook groups is great for smaller, less formal events events, for a hackathon something like EventBrite is much better.  It helps to manage ticketing, check-in of attendees, and looks much more professional and official.

Step 5:  Marketing, Marketing, Marketing

First, I just want to say, I now have a newfound appreciation for marketing professionals!


This is probably the most important step in ultimately determining the success of the Food+Tech Hackathon. It’s also where the real work began.  Aside from Dominic who isn’t based in New York City, we all tried to spread the word about the hackathon as much as possible.  We had two problems, at the onset:

1. We didn’t really know what the format of the event was just yet, so how can we spread the news?

2. It was Thanksgiving week and we had to get the word out by Tuesday before people check out for the holiday (the organization started on Monday)


We decided that problem 1 wasn’t really a problem. If we got the word out and enough people showed up, we would be able to figure out sponsorship and event organization fast (as long as we don’t overcommit to the capacity of Soho Haven — Thanks for letting us use the space Chris and Erik!).

Problem 2 though was a real problem.  We decided that we needed to leverage mailing lists and our personal networks to get the word out.  We:

  1. Posted to some of the largest tech and food mailing lists in New York City: New York Tech Meetup, NextNY, Tech4Good.
  2. We also followed up on those mailing lists’ messageboards
  3. Contacted the editors of well subscribed NYC digests: Gary’s guide, Charlie O’Donnell’s list to get the event listed
  4. Reached out to NYU, Columbia, Cooper Union, CMU, and MIT mailing lists and professors (Thanks @mplavalle and @okaysee!)
  5. We then sent personally contacted people we knew who would be interested in the event (I think Danielle sent direct messages to everyone of her followers on twitter. That’s what I call commitment!)
  6. Twitter became a huge marketing engine, as we were giving everyone in our network event updates.

Not everything was perfect though!  We actually failed to check if some of the emails we sent to the mailing lists went through.  As a result, some of the emails didn’t get sent out until AFTER thanksgiving holidays.  Lesson learned:  always follow up on your email outreaches sometimes it takes 3 or 4 tries!

Step 6:  Figure Out Your Budget

Once we got the word out, we started figuring out our budget.  Because we weren’t quite sure about sponsorship until very late, we had contingency plans in place.

For breakfast, instead of Bagels and Cream cheese (which is at best $1.50/person), we went with Chinese pastries.  They’re super delicious, have a lot of variety, and were only about ($.70/person).

For lunch, we figured a $500 budget would suffice for everyone.  For contingency plans,  we would have gone with a place called “5 Combinations and 1 Soup” in chinatown, which is the best deal in NYC.  It’s a buffet that cost $4 for about 2 Lbs of delicious (but not necessarily MSG free) food.

With materials cost for the event running another $100 or so, we quickly realized that making the event free, yet still maintaining a high enough standard for our everyone’s standards would have been impossible.  That was when we decided we needed to charge a $5 fee for the event.

It was a tough decision, because we’d already sold 10 tickets.  But we knew that it was better to offend 10 registrants before an event, than to disappoint 50 people the day of. The proceeds would allow us to not only fund the event, it also:

  1. Increase the likelihood that people who signed up actually care about food and technology
  2. Improve attendance rate the day of event (though $5 doesn’t quite hurt that much I guess…)


Step 7:  Secure Sponsorships

Once we did figure out that we were going to be able to deliver an event that met our standards.  Danielle and Marc went about figuring out how

The monetary and food sponsorships that Danielle and Marc secured for the event were one of the biggest reasons why the Food+Tech Hackathon was a success.  I really don’t know the details of how they worked their magic as much, you’ll have to talk to them!

If I had to guess a combination of 1) a unique theme, 2) a large attendance, 3) masterful negotiation skills, and 4) a large network to try out 1-3 made the difference.


Sponsorship really is something that we worked on but wasn’t as worried about.  Regardless of what happened, the show would have gone on.

The alternative would have just have been sponsorship through Gojee and the Bank of Marc (Marc, thank you for generously offering your own support for the event).  And we knew of cheaper alternatives than 4food around Chinatown as an option.

Step 8: Figure Out Logistics for the Event

I cannot emphasize this enough.  Don’t stress about the logistics for the event.  Many of the factors are controllable, especially for a 12 hour hackathon.  I think we spent a total of about 2 hrs talking about hackathon logistics 1 day leading up to the event.  It wasn’t until the night before when we had our final debrief meeting.

During the meeting, we did realize we had shortage of supplies and materials, like a projector, large papers, etc.  But it is amazing how resourceful people can be when they are given constraints.

Sure the event could have been better if we had a projector the morning of to show everyone Dominic’s presentation, but we did have it for the more important afternoon sessions.

And yes we could have provided name tags for everyone at the very start of the day, but teams formed naturally without (thanks in large part to a combination of 1. emails and messages to our participants that encouraged them to think of idea before the hackathon + 2. the right organization and people placement day of the event.)

The most important thing that we focused on was to make sure people had the essentials needed for a hackathon: Food, Internet, and Ideas.

Now: Take a deep breath and have fun

With steps 1-8 taken care of, the day of the event was a breeze.

Helping to organize the Food+Tech hackathon was a crazy fun experience.  It’s no cake walk, but it was well worth every bit of time and stress that I put in.