Our company has been building APIs and web services to solve data quality problems since 2001. Who creates these services? We do – the Engineering team here at Service Objects. In this blog, I would like to take you backstage and give you a glimpse at what we do, and how we do it.

Our primary goal is simple: take the most genuine, accurate data possible, and collect and build these data points into valuable services for our clients. Over the years we have built over 80 unique services, ranging from chartbusters to efforts that were a nice try. Today we maintain 24 live general-use unique APIs, along with literally hundreds of custom integrations and custom tools for specific needs.

An Agile development approach

So, how does the Engineering team work? First of all, we borrow heavily from Agile and Scrum project management approaches. (Some of you may be thinking, “doesn’t every project try to be agile?” In software development, Agile has a very specific meaning: it is a formal structured approach that involves compartmentalizing a project into small segments, known as “sprints,” that are individually coded and tested. You can find out more about Agile here.) While our needs did not fit perfectly with these processes, we were able to incorporate quite a few of their ideas and have become what we call Agile-like (since we do not adhere to all of its standards).

The Engineering team at Service Objects is currently a small but efficient group. The team is not always working on the same projects, and in a given month we may be working on 3 major and 3 minor projects within individual groups. We create sprints for each month that incorporate these projects, breaking them down into deliverable pieces in each sprint: for example, a major project that we know will take 3 months should be broken up into 3 deliverable segments, one of which can be completed each month.

Our team is very collaborative, both in individual groups and as a whole. Every day, the team comes together at the same time for a quick huddle to give an update on their projects and mention anything that might be in their way. Time is allocated after the huddle for any deeper discussion of problem areas, where interested parties can brainstorm potential solutions together. All of our groups follow a similar philosophy for performing in an Agile-like setting: all groups have 30-day sprints, and the managers do a quick huddle every day to synch projects and discuss any obstacles.

A collaborative development agenda

So how do we decide what to build, when and how? To stay agile and ready to respond to new problems, the managers meet offsite four times a year to do a deeper dive into projects and discuss the direction of the company. Most of our projects can be accomplished pretty quickly within our team, but this is a good time to reflect on old needs and new ones. Needs can be client driven, competitively driven or outside the box ideas we believe will benefit the company.

Our goal is to not get locked down into large projects that may have no future, and so the company is able to pivot very quickly to adapt to new needs. Two of these four meetings each year include a larger group, where we bring along our brightest minds to help brainstorm new ideas. The best ideas are brought to these meetings, analyzed and voted on to try and prioritize what we feel are the most important projects to work on.

Next, we collaborate within the Engineering team each month to make our own determinations of the most important needs we face. Our monthly sprints contain a mix of projects determined important in the offsite meetings, continuing key projects and smaller internal need projects. Every member of the group plays a role in building these sprints.

A customer-driven philosophy

Finally, where do you come in? Our customers and even prospects play a big part in determining future directions we may take for our APIs. We often look to clients to identify problem areas that can be adapted into enhancements for our services. In some cases, our services even allow custom solutions or rules that can be implemented for certain clients. We try to build our APIs to suit a wide range of needs as well as flexibility to expand in the future, and client and prospect feedback always gets factored into these discussions.

On a closing note, one thing that sets our team apart is that we love what we do, and have a real sense of mission about our work. Our core values of customer service and making a difference in the world drive what everyone does here at Service Objects, and the Engineering team is no exception. We are always seeking new challenges, and our flexibility allows us to rapidly address client requests for support and for new features. And ultimately, the beneficiary of our hard work and teamwork is you!