Community, Leadership, Technology

Hacking MasterCard (Culture)

It was a cold afternoon in January. Six small teams of MasterCard employees gathered together in the company’s NYC Tech Hub for the first internal hackathon focused on building innovative applications using MasterCard APIs. We had yet to receive a budget allocation for these types of events but were able to scrap together funds from different groups across the company in order to host the event. It turned out to be excellent and resulted in a wide range of technology solutions being created.

As we reviewed feedback from participants, we started to think of what the next iteration of the event would look like. Initially, the idea was to stream the NYC event presentations to corporate offices around the world so that the entire company could be involved. Very quickly, however, we realized that this was an event that needed to be experienced and not just watched, so we decided the best option would be to engage our MasterCard Labs unit with a proposition: work with us to take what we did in NYC and make it global and institutional. Fast forward, and the company’s first global internal hackathon was created.

Creating a global standard for local office facilitators and organizers to use and leverage, we created a fantastic platform for the event now and moving forward. Incredibly, we were able to host approximately 5% of the company’s employee base in the Tech Hubs of Dublin, New York City, St. Louis, San Carlos, Baroda, Pune and Singapore. Yes, nearly 5% of the entire company participated in this event. Teams of up to five individuals competed over the course of two days (many slept in the office, if at all) to build the best prototype focused on payments, security, and data solutions. Of course, we had a lot of fun throughout!

It was truly inspiring to see the excitement and solutions come out of this two day event from employees around the world. Not only were highly executable solutions created for the company, but we inspired employees to work together on projects they were personally passionate about. Embracing the identity of a technology company has to come at all levels of the organization, and this (now institutional) event has certainly helped MasterCard achieve that goal.

Standard
Leadership, Technology

Building a Developer Program (In Brief)

APIs. If you haven’t heard of them, then start reading. They will be the foundational fabric that binds the next generation of the web, and in many ways, they already are. Think about how many apps and website are connected to your favorite social network like Facebook or tools like Google Maps – those are powered by APIs.

For the past year, I have been working with our growing team at MasterCard to ensure we build awesome developer products and programs. This has been a great opportunity for a variety of reasons:

  • The identity of the company is rapidly evolving from a legacy financial services company to a cutting edge technology company. APIs are one way the company is doing that.
  • Employees and customers alike are excited about this. I am often approached excitedly at developer conferences and literally thanked for being there representing the company.
  • There is a tremendous amount of value that a company like MasterCard can provide, whether in be in the areas of payments, fraud and risk mitigation or data services, for example.

I thought I would share some recommendations from experiences I’ve had along the way:

Internal Education

If you’re working within a relatively large organization where many stakeholders are responsible for ensuring (and/or allowing) the growth of your group, then take the time to properly educate them on what you are trying to do and the importance of it in the context of the market. Once those primary stakeholders are excited about what you’re doing, that excitement will spread throughout the organization, and your efforts will be more easily accomplished and more rewarding.

Building the Right Products

At MasterCard, there is no shortage of API products that we could build. Like any individual or organization, however, there is limited capacity. Make sure you build products that prospective customers will actually use. Perhaps the best option is improving services you already have rather than creating new ones. In any case, you need to understand your own goals and plan appropriately.

Having a Capable Platform

Similar to building the right products, a platform capable of managing your API products is essential. US-focused products, for example, will require very different architectural support versus global products in terms of both content and usability. When building platforms, it is important to take a long-term and realistic view of your requirements. Your platform construction will also depend heavily on your product architecture. For example, if you are building a service that requires a server to make several calls to your API per use case it may make sense to test your own platform against a relatively high transaction per second (TPS) scenario – you don’t want unnecessary call failures because of the popularity of your product, after all.

Engaging Where It Matters

In my mind, there are primarily two different types of API customers who can be engaged: in typical sales / business development scenarios with larger companies, or within the general developer community. The former may very well be a continuation of existing processes. Just tell your sales people that they can sell products with similar or the same value propositions as existing ones but with significantly lower integration costs for customers and they will be all for it. The latter type of engagement is much more difficult, however, and could probably take up a post on its own. The best way to be successful is to be present in the developer community in a grassroots way. Attend meetups. Go to those demo days. Be recognizable. Be branded (not quite NASCAR-style, but not too far off, either). Build a community around you and the products you represent.

Support Can Be Tough

Supporting developers who are trying to or are currently using your API products can be extremely encumbering on both sides, but there are ways to make it easier and good things can come from this type of engagement. When it comes to in-person support, thorough understanding of the products and major languages is necessary. You can decrease the amount of support required by having awesome, humanized documentation. In-person support provides a great opportunity to help inform your development roadmap, as well. Digital support is best provided expeditiously. That means using Twitter, email, web chat, etc. Don’t forget about regional differences – while most software development occurs in English, there may be language barriers linked to (non-software) language.

Recruiting and Deploying the Right Talent

Everything about APIs is technical – the platform, the product, the documentation, and the customers. It is important, therefore, to have a team that knows or has the capacity to learn technical details. Everyone on the team doesn’t need to code, per say, but everyone must be able to communicate with each other clearly. You also want people on your team who want to be doing what they are doing and want to do it in the best possible way – as Steve Jobs said in 2005, “Stay hungry. Stay foolish.”

Measure

This goes for any type of product management, but it is very important to measure as much as possible. There has been a lot of material written about measuring success. I recommend watching this GV presentation on OKRs and reading up on the subject. Measuring correctly will allow you to quickly make course corrections as you build and scale your developer program.

What are your thoughts on building successful developer programs? Tweet at me with #dev, and let me know!

Standard