Recently we’ve had a few success stories published about how Base enables Groupon to sell more.

I’m proud to say that I was a part of a team we formed in Base that made this happen. Today, I’d like to share with you a couple of lessons learnt from my Groupon experience. I hope this will give you some valuable insights into how developers can think about projects they’re involved in.

It all started…

… a few years ago, in 2014, with Base winning the opportunity to work with and help Groupon — a huge company that I’m pretty sure you’ve heard of. Uniqueness of this work came mostly from the scale. At that time Groupon was the biggest client for Base, surpassing other clients by a wide margin. This posed lots of challenges, from the obvious ones (scaling the infrastructure) to the less obvious (like on-boarding hundreds of users).

Before I move on, I need to clarify one thing. Base is and has been a product company from day one, which means that we were always defining which direction our product, Base CRM, will be heading. But winning bigger and bigger customers means more complex needs and changing priorities to fit those customers. Huge, sales oriented companies are not so eager to change the core of how they manage their work. In fact, no company does that easily. This change affects them from the bottom up and they have to make sure that things will keep working well on all levels (sales team, managers, etc). This can mean two things: either you start building things that you didn’t yet mean to build (they were on your priority list, the Company Roadmap, but not high enough) or you build custom things which are not part of the product. We did both.

I joined the project and we started coding like crazy. You know the vibe, “there is some problem to be solved, let’s just understand how we can do that as fast as possible, and then code it!”. The team setup at that point was the following: some of our US team members worked closely with Groupon team to understand the need, and there was a bunch of Baseians in Kraków responsible for “the development” (PMs, devs, QAs, etc). Those teams synced on a regular basis to understand, who should be working on what right now.

It’s safe to say that it is a popular setup in how you approach such projects; you draw a line between development and a product/need. Needless to say, we didn’t want this line to be there. We all know that when developers don’t really understand what problem they are solving, it’s very hard (maybe even impossible?) to end up with a solution that fits the actual need. Communication over the wire tends to hide important details and more importantly, makes it hard to feel a part of a project that is being defined 8000 kilometers away from where you sit.

Despite being aware of these challenges, we didn’t pro-actively plan for how to tackle them and, in result, we allowed them to affect us, one by one.

As developers, we drifted away from the goal — making people at Groupon successful. We, perhaps not intentionally, started looking at our solution as pieces of code glued together doing something. Obviously it ended up being visible also on a project level where we didn’t actually solve the problems we wanted to solve, we spent many hours on solutions that didn’t necessarily end up being good. Despite a lot of people involved, the project didn’t move forward efficiently because we didn’t have a clear big picture of what we are aiming at. This had to change.

Hey Groupon, we’re here!

Eventually we made a decision to move a significant part of the team to work onsite at Groupon. A week later we were in Chicago. It was quite an intimidating experience at first — visiting Groupon, meeting people that I heard about only through calls and emails (yes, heard about, not met with – you see what I mean when I’m talking about a dichotomy between developing and designing a solution?). So the very first visit to Groupon’s office was a bit scary, but still a great, eye-opening experience — seeing all those people at work started to change my view of the project. I started asking the right questions: What are we even trying to solve here? Why do we want to use this solution over the other one, knowing that we have to provide sales reps with “x” and “y”?

It didn’t happen overnight, surely; but the mind shift was definitely visible and getting stronger. I started meeting people, who wanted changes to be introduced or features to be added. I started to understand why they wanted those changes vs how to add them. I can’t be speaking for others on the team, but I’m pretty sure that they felt it too — the sense of solving real problems for real people. For me personally, this is one of the biggest motivators, it’s what makes me happy and active, keeps me thinking positive about the effort that I’m a part of.

It wasn’t all sweet and easy, we had to cut scope here and there, but finally the day has come to include Base in Groupon’s process of selling. It was a huge thing for me, seeing people with Base open in their browser tabs, calling people, leaving notes, moving deals! Wow! Base was always about the end-user experience, the interaction between the system and the user, the intuitiveness of use. Compared to their previous go-to CRM tool – Salesforce – the difference was stark and seeing their reactions was a really rewarding experience.

Soon after we’ve successfully started the production system for the initial team of Groupon’s sales reps, we flew back to Kraków – we still had a lot to do.

Krakow, welcome back

Back in Poland we focused on the architecture of our solution. We introduced a concept of workflows – chunks of code responsible for some specific business flows. We mitigated performance problems by introducing priorities of certain workflows over others. We extracted parts of the system to separate components responsible only for Groupon account. There were big decisions to be made, many were not easy, but the reasoning was obvious — we had a conviction that the shift we were introducing would really help people in their daily work.

This was a period of very intense work. I remember spending countless hours on nailing problems one-by-one, working late or weekends to deliver the product we promised. I know, I know… “working late on weekends” is not something you are happy with. In fact, neither am I. The thing is, I did that because I got to know the people on the other side, on the Groupon side. I knew these were real people doing their day-to-day work, now also with Base, and having real problems. With this in my mind it would be extremely hard for me to leave problems unsolved and not delivered on time.

I remember one particular situation when we faced a huge architectural rewrite a few days before going to production. When I look at it now, it seems that we were crazy to think we could make it work, but the sense of teamwork and common goal we developed together allowed us to succeed. Solving a problem on a Sunday evening and coding it until, probably, Wednesday was a huge achievement and a thing I’m proud of. We shipped what we committed to and the solution is actually working now, years later, after over a billion processed events.

The takeaways

If you were to remember anything from this article I’d like it to be this:

  • Dive deep into the nature of what you are working on as a developer. You’re not doing it in a vacuum, you’re not doing it for your PM, nor for your Team Leader. It’s going to be used by people on a daily basis, spending a lot of time interacting with what you – together with your Team – created. Solving technical problems is great, but seeing the value you bring to your users is what gives this work a meaning. In my opinion, this should be the thing to look for throughout your career. It is certainly the thing that makes me excited about going to work every day.
  • To succeed with the above you have to surround yourself with people thinking in a similar way. In tough situations, with deadlines approaching or when things are not going as you expect them to, it’s an invaluable asset to have people around you who will say “ok, let’s focus for a moment on how we can solve this” and who will not give up. A strong feeling of team spirit, can-do attitude and good mindset is something I didn’t pay too much attention to years ago. Now I feel it is indispensable, when working on big challenges – far more than the ability to “relentlessly code”.

Last but not least, just to give you a sense of what kind of a task it was for us, here are some stats around the system we’ve built:

  • 2-way synchronising around 7 million unique objects between Salesforce and Base
  • with a daily rate of around 1 million syncs
  • additionally around 2-3 million custom flows executed daily, designed specifically for Groupon and supporting their sales process.

Posted by

Michał Bugno

Share this article