SOCi R&D Values and Principles

Job #1 is to learn; job #2 is to teach

In the knowledge economy, the first job for each and every one of us is to learn - we’re learning about new technologies, new customer problems worth solving, new market opportunities, we’re learning how to work better with each other. But having learned something doesn’t mean the job is done - we have not achieved an outcome until we’ve taken our knowledge and passed it onto the next person. A product manager who learns about a customer problem hasn’t achieved an outcome until they are able to describe it to an engineer who can actually do something about it.

We innovate on behalf of our customers

Results of an organization only exist outside the organization that produces them. Writing a piece of code isn’t a result; getting it merged isn’t a result; even getting it deployed isn’t a result. Only when a customer is able to achieve a business outcome of their own have we achieved results. We thus measure our success not through activities, but true customer outcomes, the results that our customers are able achieve using our technology.

We build the right things, right

At SOCi, first, we ensure that we are working on the most valuable problem by performing significant amount of product discovery through customer conversations, usage data analysis, market analysis and domain expert conversations - the biggest waste would be to build something nobody needs!

We pay for quality as early as possible

Quality has to be paid for at some point in the process; the earlier we’re able to pay for it, the cheaper it is to achieve it. If we wait for a customer to report a bug to us, we’ve incurred a significant cost - negative customer sentiment, rework of code, re-testing and re-deployment. We could pay for quality during integration / release testing - but it would still lead to significant rework and aborting of a release, disrupting teams, release plans and requiring rework. We could pay for quality by having a QA team, yet that will still require rework and context switching between new work and past work coming back from QA.

When engineering starts considering the solution, we look for innovative ideas through the use of new available technologies; we pay for quality by upfront architectural design diagrams and flow charts to ensure we account for all use cases. These are driven by engineers, and reviewed by management - a bottom up approach. We practice TDD and mob programming to ensure highest quality software.

Mob Programming - A Whole Team Approach

Nobody loves context switching between tickets or spending hours reviewing other people’s code. We recognize that software development is and has always been a team sport. Mob programming is the next evolution of former practices such as Pair Programming and XP. In mobs, we have 3 engineers working in real-time together on a zoom call, on the same ticket, from beginning to completion. Furthermore, the rule is that code has to go through someone else’s hands - one engineer is the Navigator, driving the solution forward, one engineer is the Typist, writing it up, and the third is Support, doing research on the side or watching for errors in thinking or implementation. Every 10 minutes, the team rotates the roles - the Navigator becomes Typist, the Typist becomes Support and Support becomes the Navigator. Through rapid iterations, the team achieves a joint “flow” state where high-quality, innovative solutions flow from minds to the screen. Mobs stay together even if projects change, so you build a great team dynamic for long-term success.