The typical visitor to the BigDoor office, often comments on one of two things: The eerie silence or their inability to distinguish between developers, executives and anyone else. It’s true, the BigDoor office is one big buzzing space of activity, with every employee moving around from desk to desk, or tapping away at their keyboard furiously with a look of concentration. We all wear T-shirts, drink copious amounts of diet coke or red bull and argue over who gets the conference room, the comfy couches or the bar stools in the kitchen for their meeting. That fluidity of employees is one of the truly unique things about working for a start-up and we continue to see employees grow and learn in truly awe-inspiring ways. CTO and Co-Founder Jeff Malek took some time to talk about how BigDoor is organizationally structured and what that means for employees who work here.
One of our rockstars here at the company had questions about our organizational structure, trying to determine who was in each of our departments. He’d listed what he thought those department “labels” were (Bizdev, Development, etc) and who he thought belonged in each of those branches of our company. He’s recently been asked to improve our process and communication during customer on-boarding, largely because he’s very detail-oriented, organized, and process-driven. To get this done, he’ll need to be interfaced with other folks in the company that he hasn’t before, so asking about who does what and where in the company is totally understandable, expected and part of his diligence.
This approach and thinking around a company’s organizational structure is age-old, and for good reason. But it’s Org v1.0.
It’s human nature to try and departmentalize, categorize, bucket, silo, label, simplify or otherwise narrow down anything in life. In this case the context is “who does what and in what group”, an attempt to establish who falls into what departments at our company, and there were two (somewhat) flawed assumptions:
we have departments that contain people
person x belongs in department y
What we actually strive to have at BigDoor and will continue to work towards as long as we possibly can, is a team of people who wear one or more hats, and we call those hats “roles”. The internet has taught us that tagging is a much more flexible, powerful and realistic way to associate attributes with anything, more so than creating hierarchical taxonomies. For the database-minded, it’s the difference between a many-to-many entity relationship and a one-to-one.
A tag can be associated with many different things, and a thing can be associated with many different tags. In the same way, engineers who operate in many different roles (e.g. production developer, test developer, project manager, UAT tester, etc) grant both the company and themselves much more power and benefit than if we were to create a Quality Assurance department and put specific people in it, and only in it.
Once you create departments and put people in them, there’s no going back. The company is limited to asking Joe in the Foo department to fulfill Foo tasks. All or most Foo tasks go into the Foo department, agility and flexibility go out the window, and a manager ends up with being “accountable” for department Foo and tasks of type Foo. Department Foo is one tier on the multi-waterfall path toward the “done” that never gets done, and it will wind up being the managers fault, so they start getting cycled in and out of the company, along with the teams. Barf. I want to fight the Foo just thinking about it.
Once someone starts thinking in terms of belonging to the Foo department, it’s totally natural to become closed off to doing anything but Foo work.
Now, if I don’t live in a department, but I’m on the team that is supposed to take care of end-users, that’s a different way of looking at things. My team doesn’t “do QA” or “do Product Management”, it takes care of customers, which is what we all should be thinking about as a P0 (highest priority). That’s a great reason to have a group of people working together.
So we have a Player team, “player” being a euphemism for end-users. The purpose of that team is to meet the needs of our end-user customers. The Player team is cross-functional, it does it all: it determines what the next highest priority is for the customer, works out how to meet their needs, builds it, tests it and deploys it. Everyone required to meet the needs of the customer is on the team, whether it be someone to fix a problem with our build system, stand up a new server, design a new graphical interface, deploy an API performance optimization, or change the backend database schema. The team pushes to continuously improve and learn, on all fronts.
This non-departmental approach raises valid concerns for folks, around topics like accountability, ownership (“if everyone owns it, no one owns it”), and scaleability. But clearly, even without a Project Management department, someone can still own a publisher on-boarding project management role, for example. More about scaleability with regard to the organization here.
It’s true there are tradeoffs to this approach, but it’s better for the company and for our employees to leverage the multiple skills and talents buried deep throughout our awesome team.
All that said, we all can’t do everything, and it’s necessary to create categories at least at a high level for various reasons. It’s also true that some external customers may be more impressed with us if we talk about our QA Department, while others may be more drawn in by an agile approach to org structure.
So ultimately, I encouraged the engineer to avoid thinking along the lines of departments and silos as much as possible, and just question whether certain terms or departmentalizations are needed to begin with. Focus more on identifying the individuals you’ll be thinking of as stakeholders, and get to know what they’re specializing in.
Titles are another story altogether, and at BigDoor they’re much more valued and needed outside than within the company. We’re all engineers and salespeople to varying degrees, having additional strengths and attributes.
Strengths, attributes, tags, descriptors…too bad there wasn’t some way to quickly visualize these, and convey someone’s strengths and achievements better than with just a “title”. Like a badge. Kidding – of course we do that. Here are some of the badges that we put on the back of our engineer’s business cards, each of which are only attainable when specific criteria are met:
Full-stack employees are like gold, and we try hard to cultivate them here. But it takes a rare breed, someone with fire, adaptability, agility, ability, a clear communicator. If you think you’ve got what it takes, and all of this sounds fun to you, please get in touch with me directly – we’re always looking for good people to join our team. We don’t just look for people when we have an opening, that’s very “recruitment v1.0″.
(title is me tipping my hat with much respect to the Foo Fighters, the best makers of music, ever).
When talking to people about BigDoor, we often get asked about our backend database systems. Potential clients want to know whether or not our system can handle their traffic (yes, it can) and other start-ups want to know how we scaled to handle the high traffic levels of our awesome clients. We thought it would be useful to give a little bit more information about our system as well as share some of the things we learned in the process. There is no better expert in this topic than our CTO/Co-founder Jeff Malek. He took a break from working his daily magic to give some perspective and advice.
A friend was recently asking about our backend database systems. BigDoor’s systems are able to successfully handle high-volume transactional traffic through our API coming from various customers, having vastly different spiking patterns, including traffic from a site that’s in the top-100 list for highest traffic on the net. Don’t get me wrong; I don’t want to sound overly impressed with what our little team has been able to accomplish, we’re not perfect by any means and we’re not talking about Google or FaceBook traffic levels. But serving requests to over one million unique users in an hour, and doing 50K database queries per second isn’t trivial, either.
I responded to my friend along the following lines:
If you’re going with an RDBMS, MySQL is the right, best choice in my opinion. It’s worked very well for us over the years.
Since you’re going the standard SQL route:
If your database is expected to grow in step with traffic, and you’re thinking about sharding early – kudos. You’re likely going to have to do it, sooner or later.
Sooner vs. later if you’re in the cloud and running under its performance constraints.
Do it out of the gate, if you have time, after you’ve figured out how you’re going to do it (i.e. whether you’re going to leverage a tool, DYI, etc).
In other words, if you have time, don’t “see how long you can survive, scaling vertically”.
Sharding while running the race : not a fun transition to make.
I realize what I’m saying is counter to popular thinking, which is “don’t shard unless you absolutely have to”.
Without the assumption that your data set is going to grow in step with your traffic, I’d be saying the same thing.
Designing your schema and app layer for sharding, sharded on as few keys as possible, ideally just one, is not future-proofing, it’s a critical P0.
Since you’re going to be sharding MySQL, your options are relatively limited last I checked.
Ask for input from folks who have done it before.
The other sharding options I started looking at over two years ago all had disallowing limitations, given our business model.
At quick search-glance just now, it also does appear that dbshards is ruling this space at this point.
So barring any other options I’m missing, your best options that I’m aware of:
dbshards
Definitions we/they use, to help clarify discussion :
global tables : tables that contain the same data on every shard, consistency managed by dbshards.
shard : two (primary and secondary) or more hosts that house all global table data, plus any shard-specific data.
shard tree : conceptually, the distribution of sharded data amongst nodes, based on one or more shard keys.
reliable replication : dbshards-proprietary replication, more details on this below.
pros
The obvious : you’ll be able to do shard-count more reads and writes that you’d otherwise be able to do with a monolithic, non-sharded backend (approximately).
Alternatively, with a single-primary read-write or write-only node, and multi-secondary read-only nodes you could scale reads to some degree.
But be prepared to manage the complexities that come along with eventual read-consistency, including replication-lag instrumentation and discovery, beyond any user notifications around data not being up-to-date (if needed).
It was built by folks who have only been thinking about sharding and its complexities, for many years
who have plans on their roadmap to fill any gaps with their current product
gaps that will start to appear quickly, to anyone trying to build their own sharding solution.
In other words, do-it-yourself-ers will at some point be losing a race with CodeFutures to close the same gaps, while already trying to win the race against their market competitors.
It’s in Java, vs. some other non-performant or obscure (syntactically or otherwise) language.
It allows for multiple shard trees; if you want (or have to) trade in other benefits for sharding on more than one key, you can.
Benefits of just sharding on one key include, amongst other things, knowing that if you have 16 shards, and one is unavailable, and the rest of the cluster is available, 1/16th of your data is unavailable.
With more than one shard tree, good luck doing that kind of math.
It provides a solution for the auto-increment or “I need unique key IDs” problem.
It provides a solution for the “I need connection pooling that’s balanced to shard and node count” problem.
It provides a solution for the “I want an algorithm for balancing shard reads and writes”.
Additionally, “I want the shard key to be based on a column I’m populating with the concatenated result of two other string keys”.
It has a distributed-agent architecture, vs. being deeply embedded (e.g. there are free-standing data streaming agents, replication agents, etc instead of MySQL plugins, code modules, etc ).
Provides future-proofing, scaleability and plug-ability.
Easier to manage than other design approaches.
Streaming agents allow you to plug into the update/insert stream, and do what you like with changes to data.
We use this to stream data into Redis, amongst other things. Redis has worked out very well for us thus far, by the way.
Other dbshards customers use this to replicate to other DBMS engines, managed by dbShards or not, such as a column store like MonetDb, InfoBright, even a single standalone MySQL server if it can handle the load.
It supports consistent writes to global tables; when a write is done to a global table, its guaranteed to have been done on all global tables.
It doesn’t rely on MySQL’s replication and its shortcomings, but rather on its own robust, low-maintenance and flexible replication model.
Its command-line console provides a lot of functionality you’d rather not have to build.
Allows you to run queries against the shard cluster, like you were at the MySQL command line.
Soon they’re releasing a new plug-compatible version of the open source MyOSP driver, so we’ll be able to use the same mysql command line to access both dbShards and non-dbShards managed MySQL databases.
Its web console provides a lot of functionality you’d rather not have to build.
Agent management and reporting, including replication statistics.
Displays warning, error, diagnostic information, and graphs query counts with types.
Done via the “dbsmanage” host, which provides centralized shard node management as well.
Each shard is two (or optionally more, I think) nodes. We put all primary nodes in one AWS availability zone, secondaries in a different one, for protection against zone outages.
Write consistency to two nodes; in other words DB transactions only complete after disk writes have completed on both nodes. Secondary writes only require file-system (vs. MySQL) disk writes.
Managed backups with configurable intervals; MySQL EC2/EBS backups aren’t trivial.
Web-console based fail-over from primary to secondary; this is very helpful, particularly for maintenance purposes.
Proven to work well in production, by us and others.
We’ve performed 100K queries per second in load-testing, on AWS/EC2, using m1.xlarge instances.
Designed with the cloud and AWS in mind, which was a great fit for us since we’re 100% in AWS.
“dbsmanage” host
Drivers included, of course.
In addition to MyOSP, they have JDBC, PQOSP (native Postgres), ADO OSP (for .NET), and soon ODBC.
Go-fish queries allow you to write standard SQL against sharded data
e.g. sharded on user.id : SELECT * FROM user where FirstName=’Foo’;
will return all results from all shards performing automatic aggregation
sorting using a streaming map-reduce method
Relatively easy to implement and go live with; took us about six weeks of hard work, deadline-looming.
It’s the market-leading product, from what I can tell.
5 of the Top 50 Facebook apps in the world run dbShards.
It supports sharding RDBMSs besides MySQL, including Postgres, DB2, SQL Server, MonetDb, others coming.
Team : top-notch, jump-through-their-butts-for-you, good guys.
Ability to stream data to a highly performant BI backend.
cons
As you can see, some of these are on the pro list too, double-edged swords.
Cost – it’s not free obviously, nor is it open source.
Weigh the cost against market opportunity, and/or the additional headcount required to take a different approach.
It’s in Java, vs. Python (snark).
Doesn’t rely on MySQL replication, which has its annoyances but has been under development for a long time.
Nor is there enough instrumentation around lag. What’s needed is a programmatic way to find this out.
Allows for multiple shard trees.
I’m told many businesses need this as a P0, and that might be true, even for us.
But I’d personally prefer to jump through fire in order to have a single shard tree, if at all possible.
The complexities of multiple shard trees, particularly when it comes to HA, are too expensive to justify unless absolutely necessary, in my humble opinion.
Better monitoring instrumentation is needed, ideally we’d have a programmatic way to determine various states and metrics.
Command line console needs improvement, not all standard SQL is supported.
That said, we’ve managed to get by with it, only occasionally using it for diagnostics.
Can’t do SQL JOINs from between shard trees. I’ve heard this is coming in a future release.
This can be a real PITA, but it’s a relatively complex feature.
Another reason not to have multiple shard trees, if you can avoid them.
Go-fish queries are very expensive, and can slow performance to a halt, across the board.
We’re currently testing a hot-fix that makes this much less severe.
But slow queries can take down MySQL (e.g. thread starvation), sharding or no.
HA limitations, gaps that are on their near-term roadmap, I think to be released this year:
No support for eventually-consistent writes to global tables means all primaries must be available for global writes.
Async, eventually consistent writes should be available as a feature in their next build, by early October.
Fail-over to secondaries or back to primaries can only happen if both nodes are responding.
in other words, you can’t say via the console:
‘ignore the unresponsive primary, go ahead and use the secondary’
or:
‘stand me up a new EC2 instance for a secondary, in this zone/region, sync it with the existing primary, and go back into production with it’
Reliable replication currently requires two nodes to be available.
In other words, if a single host goes down, writes for its shard are disallowed.
In the latest versions, there’s a configuration “switch” that allows for failing-down to primary
But not fail down to secondary. This is expected in an early Q4 2012 version release.
dbsmanage host must be available.
dbshards can run without it or a bit, but stats/alerts will be unavailable for that period.
Shard 1 must be available for new auto-increment batch requests.
go-fish queries depend on all primaries (or maybe all secondaries via configuration, but not some mix of the two as far as I’m aware) to be available
DYI
I can rattle off the names of a number of companies who have done this, and it took many months longer than our deployment of dbshards (about six weeks, largely due to the schema being largely ready for it).
Given a lot of time to do it, appeals to me even now, but I still wouldn’t go this route, given the pros/cons above.
The latest release of MySQL Cluster may be an option for you, it wasn’t for us back with MySQL 5.0, and not likely now, due to its limitations (e.g. no InnoDB).
AWS RDS was an option for us from the onset, and I chose to manage our own instances running MySQL, before deciding how we’d shard.
For the following reasons:
>I wanted ownership/control around the replication stream, which RDS doesn’t allow for (last I looked) for things like:
BI/reporting tools that don’t require queries to be run against secondary hosts.
This hasn’t panned out as planned, but could still be implemented, and I’m happy we have this option, hope to get to it sometime soon.
Asynchronous post-transaction data processing.
This has worked out very well, particularly with dbshards, which allows you to build streaming plugins and do whatever you want when data changes, with that data.
Event-driven model.
Better for us than doing it at the app layer, which would increase latencies to our API.
Concern that the critical foundational knobs and levers would be out of our reach.
Can’t say for sure, but this has likely been a good choice for our particular use-case; without question we’ve been able to see and pull levers that we otherwise wouldn’t have been able to, in some cases saving our bacon.
Their uptime SLAs, which hinted at unacceptable downtime for our use-case.
Perhaps the biggest win on the decision not to use RDS; they’ve had a lot of down-time with this service.
Ability to run tools, like mk-archiver (which we use extensively for data store size management), on a regular basis without a hitch. Not 100% sure, but I don’t think you can do this with RDS.
CloudWatch metrics/graphing is a very bad experience, and want/need better operational insights to what it provides. Very glad we don’t depend on CW for this.
All of these reasons have come at considerable cost to us as well, of course.
Besides the obvious host management cycles, we have to manage :
MySQL configurations, that have to map to instance sizes.
Optimization and tuning of the configurations, poor-performance root-cause analysis,
MySQL patches/upgrades.
maybe more of the backup process than we’d like to.
maybe more HA requirements than we’d like to; although I’m glad we have more control over this, per my earlier comment regarding downtime.
maybe more of the storage capacity management than we’d like to.
DBA headcount costs.
We’ve gone through two very expensive and hard-to-find folks on this front, plus costly and often not-helpful, cycle-costing out-sourced DBA expertise.
Currently getting by with a couple of experienced engineers in-house and support from CodeFutures as-needed.
As I’ve seen numerous times in the past, AWS ends up building in features that fill gaps that we’ve either developed solutions for, or worked around.
So if some of the RDS limitations can be worked-around, there’s a good chance that the gaps will be filled by AWS in the future.
But it’s doubtful they’ll support sharding any time soon, there’s too much design and application-layer inter-dependencies involved. Maybe I’m wrong, that’s just my humble opinion.
At BigDoor, we believe firmly that a gamification solution without solid analytics and data is doomed to fail. Accurate recording of actions, points and shares ensures that users are seeing the results of their efforts, and companies are able to track and monitor the success of a BigDoor Gamified Rewards Program. Recently, our internal team headed by CTO/Co-founder Jeff Malek made some important updates to our backend databases that ensure BigDoor can handle the large number of transactions, points and data required by our clients as well as free up valuable engineering resources for the internal team.
Previously, our data came from a replicated slave of its MySQL transactional database and aggregated the results on an additional intermediary MySQL host. Following this process data was then pulled into Tableau for reporting. This custom aggregation and ETL was workable in the beginning, but as we grew along with our client base, the problems of this type of solution began to eat up engineer time and energy.
We found our solution with Full 360 and Vertica. The two companies were able to provide us a solution that was quick to implement and able to handle our complex set of data. By moving away from our custom setup, we are now able to monitor and report with much greater speed and reliability in reporting user actions.
To read more about our transition and the custom solution provided to us by Full 360 and Vertica, you can check out their case study here.
Our business development team has made some changes recently to streamline their processes and continue to quickly scale for our partners. We asked Paige Petersen, Account Manager on the business development team, to detail some of those processes and how they have affected the team’s success.
As BigDoor’s Gamified Rewards Program grows larger and scales to manage more partners, we often forget that the business development team, us folks you might see at conferences or chat with on the phone, also need to adjust to deal with the influx of inquiries and new partners. Since we announced our new product in early April, we’ve been busy, really busy! We embarked on an attempt to streamline our processes, focus on validated learning’s, and constant iteration. Interestingly, we turned to our dev team and their use of the SCRUM/Agile method to streamline and organize our onboarding of new partners.
When the idea to incorporate a SCRUM/Agile methodology and put into practice a few key aspects from Eric Reis’ The Lean Startup, there was some skepticism. Several questions surfaced right away: “Won’t this take up even more time, instead of save it?” And “Isn’t SCRUM/agile for developers?” But despite the skepticism, we decided to give it a try.
In the initial weeks, our planning meetings and daily stand-ups were far too long rather than quick updates on progress and sticking points. However about a month in to the experiment we saw a turning point. Not only have some important sticking points been identified, but we’ve also been able to recognize where time is being spent, re-prioritize, and/or brainstorm more efficient ways to reach the same result. Time to fix an issue that might arise has gone from a matter of weeks to a few days.
We’ve been able to…
Identify sticking points in our pipeline
Iterate on messaging and identify key features that resonate with our audience
Visually see/track the incremental development of each project
Digest customer feedback daily with the team which has helped re-prioritize specific development efforts
Startups are like giant testing environments, whether we are testing a specific product, service, message or related concept –our team is always trying to figure out what works and what doesn’t. The BizDev team has adopted a “test-measure-learn-iterate-test again” philosophy. We’ve been able to test assumptions we’ve made about our business, our partners and what features are really important to them. While we are still in trial mode, it appears that the SCRUM/Agile method may not be just for the devs anymore! Incorporating these methods has produced excellent results and is truly making us a ‘leaner’ startup.
Today we’re so excited to officially unveil the next generation of gamification: BigDoor’s Gamified Rewards Program!
Three things everyone should know about our new product:
1). It’s Easy to Implement - no matter what size publisher you are BigDoor is simple to integrate on your site. Our proprietary tools offer an easy-to-use web-based command center that manages publisher’s implementations.
2). We Provide Actionable Analytics and Performance Measurement - BigDoor provides the tools that site publishers need to take action on their implementation and measure success.
3). Get Real Results - Sites participating in our private beta saw real results including 153% lift in User Loyalty; 672% lift in User Engagement and 355X in Social Sharing.
Online publishers today are constantly challenged with trying to attract more visitors to their site and keeping those visitors engaged. Our new Gamified Rewards Program takes aim at both problems and creates a real solution. Any size website can now integrate a Gamified Rewards Program seamlessly.
We offer three solutions: Lite, Plus and Premium. Lite is a free offering for websites with fewer than 25,000 monthly visitors. Plus is a white-label and highly customized solution built for medium sized websites with up to one million monthly visitors. For enterprise customers, BigDoor creates a fully customizable Rewards Program as part of the Premium package.
Now publishers can reward their users within a gamified experience; think of it as a fun and engaging frequent flyer program that integrates seamlessly with your brand. Rewards, such as exclusive content, unlocked powers, exclusive virtual items, community status and even tangible rewards create deeper engagement with a site and rewards users for their loyalty and engagement. Implementing a rewards program is now a simple process and can be managed entirely through BigDoor. Publishers can also take advantage of many advanced services provided by BigDoor, including paid sponsorship and management of high value rewards through sweepstakes.
Today we’re also very excited to announce our next round of funding from Foundry Group and Brad Feld. We’re incredibly lucky to have an investor who has such a great history with game and technology companies continue to be a part of what we’re building at BigDoor!
Over the next few weeks we’ll be detailing some of the proprietary features available so stay tuned for more and please share your feedback!
Today’s post comes from our COO, Ring Nishioka. Below Ring reveals a little more about the culture here at BigDoor in his 2011 Startup Retrospective that recaps our recent company off-site.
On Wednesday we had an all company off-site. It was a great time to recap the previous year and look towards 2012 and where we’re headed as a company. As a startup we try to empower everyone to act and think like an owner. We all focus really hard on our product and our vision and try to keep the big corporation type stuff at a very minimum. We gave each group 5-7 minutes to do a rapid-fire recap of their wins and also losses this past year. Everyone did an excellent job with their retrospectives and our afternoon brainstorm was so productive that I’m really excited to see a lot of those ideas come to fruition!
One of our dev teams summed up things brilliantly in this tag cloud that was created from a series of developer chats. It’s evident from this visual the focus our company has on building great stuff and getting there quickly. I’ve always been proud of the work we do here and I’m even more proud to be surrounded by a world-class team.
One of the ways that we know we have stellar team members, is their commitment to the tech community here in Seattle. Two of our developers, Adam Loving and Brian Immel, recently participated in the King 5 Hackathon which partnered with Amazon and Adobe to host the competition. Brian’s girlfriend, Amanda Vilbrandt also participated in the event for the first time. Hackathons are typically weekend long events that bring together volunteers to build web programs and applications in a friendly competitive environment. They are often hosted by companies and organizations to solve tech-related problems or brain storm innovative ideas.
We are really proud to have these two working with us, and want to congratulate Adam Loving and the rest of team Dimensions on their win.
We are very excited to announce that the BigDoor family has grown by two. This week, we welcome Bill Dias and Gerry Narvaja to the team. Both Bill and Gerry will be working with the internal team, headed by Jeff Malek BigDoor’s Co-Founder and CTO.
Gerry Narvaja comes to us with decades of experience in the IT industry. He will be working as a MySQL DBA here at Bigdoor. He has a degree in electronic engineering and an MBA with a management info systems focus. He has worked extensively with databases and has focused on MySQL for the past decade, making his expertise invaluable to our team. He was at MySQL AB early on and left just after the Sun acquisition earlier this year. Gerry calls himself a certifiable geek with a passion for photography, computer strategy games and computer hacking when he is not at work. He also co-hosts the OurSQL podcast with MYSQL community leader and podcast creator Sheeri Cabral. When asked about his thoughts on BigDoor after a week on the team he said, “It’s all about the intensity and the fun of a startup in a new industry!”
Bill Dias is our new Systems Architect. Bill comes to us with an accounting degree with management info systems focus. He is originally from southern California. He has years of experience in the IT industry in support, operations and development. Bill previously worked at Zango, Keith Smith and Jeff Malek’s previous company and they are both excited to have him on the team again. Bill has prior startup experience as well, which makes him a great addition to our ever growing team.
We are a little behind in introducing another team member for this weeks profile, but Director of Program Management Sung Kim doesn’t disappoint. Sung is a vital team member that keeps track of the development teams, keeps everyone on course and also frequently reminds us to keep a bit of humor in the office. Sung is known for his high score abilities in office arcade games and for his “cats in yoga poses” mouse pad.
What do you do for BigDoor?
Run Program Management so our development teams are working on the most important things to the company and doing so in an efficient and sustainable manner. One of the things I do is play the scrum master role for our 3 Agile scrum teams.
What do you like most about BigDoor?
We get to pioneer work in an emergent field that will improve everyone’s online experience. We work in the most dynamic neighborhood in Seattle. I get to sit next to a guy with an Amish beard who can eat more butter chicken than anyone alive.
Technology that needs to be invented?
Sleep simulator to fool your body into thinking it got sleep.
iPhone or Android?
iPhone although I foolishly own Nokia stock and have a brother who works for Microsoft.
Star Trek or Star Wars?
I think Sunshine by Danny Boyle is the best space movie.
Favorite Jimmy Johns sandwich?
The butter chicken one, I think. Actually, I’m pescatarian.
Dog, Cat or Monkey?
Monkeys are delicious but I prefer dogs for virility.
Last movie?
I’m trying to watch all the movies on the Criterion Collection list and have seen about 200 (out of 600+) so far. But the last great movie I’ve seen is The Tree of Life by Terrence Malick.
Bionic limbs or ability to fly?
Probably a bionic limb, maybe a third leg.
What was the earliest game you played?
“Castle Wolfenstein” on a PC was the first game I spent serious hours on.
Game you’re currently playing?
At work, I hold the high score on the “Ms. Pac-man” arcade game in our office. At home, I’m looking forward to “Mass Effect 3″.
Favorite music to work to?
Sigur Ros, Au Revoir Simone, CocoRosie, Bob Dylan, Heidi Montag and the RZA.
Other fun facts:
My cat, Manga, has won several blue ribbons as ‘best in show’ in regional and national competitions. My previous cat, Nabi, means “butterfly” and she was surely as beautiful as one.
Posted in: 
At BigDoor, we believe firmly that a gamification solution without solid analytics and data is doomed to fail. Accurate recording of actions, points and shares ensures that users are seeing the results of their efforts, and companies are able to track and monitor the success of a BigDoor 
