Transitioning to a startup mentality

An inside look at how an IBM cloud development team transformed from manatee to dolphin

Authors: Todd Kaplinger with Greg Truty

Excitement is contagious at tech startups. Their goals often include creating an innovative solution to a problem, building developer mindshare, and growing revenue, the subscriber base, or both. Startups often start out operating at a loss and aim to show enough growth to be acquired by another company or grow into the next Facebook. It may take years for the company to incubate its big idea before achieving the desired outcome.

On the other hand, at large companies, especially ones that are publicly traded, investors exert pressure on executives to quickly grow the business and show rapid returns on investment. Shareholder tolerance for long-term incubations is notoriously low. Additionally, large companies struggle with change, either in processes or development technologies.

Our development team was responsible for a mobile solution to personalize user interactions. In developing our Software as a Service, we challenged itself to create a new development environment, embracing the new technologies and development philosophies often seen in tech startups. We focused on building a vibrant development culture, while achieving rapid growth of a new idea and getting executive buy-in.

“In this article, we share how we achieved the “sea change” on our project from bulky, slow-moving manatee to nimble, fast-moving dolphin.”

We hope our story and key takeaways from the experience are helpful to other development teams trying to build a startup culture in a large enterprise environment.

Development practices in startups

Ironically, working at IBM has given our development team great insight into practices in the startup community. How is this possible? Each year, IBM invests heavily in technology acquisitions, and many of our key acquisitions originated as startups.

This evolution is especially true in the last few years, as IBM has worked to transition its offerings to a cloud-delivered model. The most notable difference we have seen when integrating these companies into IBM is their approach to software delivery and cloud strategy. In startups, the conversation begins and ends with running in the public cloud, building a cloud-native architecture that is designed up front to run in the cloud, and one that ultimately will scale as users adopt the technology.

Market requirements dictate this approach. Getting to market as fast as possible — and working closely and iteratively with customers to help prove the ideas — are imperative. Leveraging cloud-hosted solutions allows this to happen at laser speed because customers don’t have to worry about setup, configuration, and management of the systems. Customers can instead focus on the true value of the solution.

Furthermore, the startup’s development teams are almost always on the hook for operations support of the solutions, so the less they have to manage, the better. These teams are more likely to choose proven out-of-the-box, open source cloud architectures and deployments to minimize delivery risks, as well.

Challenges to adopting startup practices in the enterprise

In contrast, in the enterprise company, the conversation often starts and ends with IT, whose goal is to control the infrastructure. The discussion quickly turns to the enterprise’s data center. The shift towards hybrid and public cloud is starting to change this focus, but market requirements for product deliverables and the speed of moving to cloud-native architectures are typically impacted by the enterprise’s ability to unleash the systems of record. Data is hosted in enterprise databases, and there is a separation of roles between development and operations.

In our speaking engagements at many conferences and in discussions with our team, the question comes up over and over: Why can’t the enterprise just act like a startup and be done with it? The answer is complex. As technologists, existing procedures and policies often hamper us. Let’s take a closer look.

While most companies in the technology industry have moved to agile methodologies, there are still strong, ingrained release patterns and processes that release management expects. This isn’t inherently bad. After all, process is typically good for optimizing delivery and quality. However, prior systems were optimized to reduce change and breakage, and to support thousands of customers, whereas in startups, the ability to quickly innovate with new technology and tools requires quickly educating whole teams of people.

Our team has spent a significant amount of time trying to break this paradigm, and we’ve looked hard at what the startup community has done to solve this. For the remainder of this article, we’ll talk through how we approached the necessary “sea change” on the project we called “Manatee to Dolphin.”

Transforming our technologies

For our project, we shifted to a continuous delivery model in which we actively release new function to the cloud on a sprint-by-sprint basis. We use Git workflows to encourage continuous integration, and we use tools to help accelerate our work efforts. To achieve this, we had to get the developers closer to the live running systems, and we adopted DevOps practices in order to deliver capabilities quickly.

We purposely sought out open source technologies and forked our codebase away from the legacy technology stack we had inherited. We embraced existing solutions for common functions to save the team time and effort. Our focus was on delivering value. Anything that took time away from our actual mission was considered noise and was not tolerated.

Several key IBM acquisitions were instrumental in our adoption of startup methodologies, including Xtify, Cloudant, Silverpop, and StrongLoop. IBM’s strategic investment in these technologies as part of its transformation showed us we were on the right path in our decision to use them in our project.

• The Xtify acquisition validated our decisions to use a cloud-centric architecture and NoSQL-based databases.
• The Cloudant acquisition taught us how to deliver NoSQL at scale, and we adopted their geospatial support for our service.
• The Silverpop acquisition taught us the value of microservices and messaging as the foundation for building cloud-native architectures.
• The StrongLoop acquisition confirmed our use of Node.js.

Most startups rely heavily on open source technologies, which combine the best of both worlds in terms of proven cloud-scalable features and cost (free). From the outset, we embraced open source technologies such as Node.js, Redis, and Elasticsearch as the foundation of our technology stack. We also leveraged IBM software such as MQLight and the aforementioned Cloudant (which is also open source under the covers with CouchDB) when appropriate.

The key to a vibrant open source community is developer engagement with the technology that drives the community. As adopters of open source technologies and, as good open source citizens, we invested in delivering our libraries and modules on GitHub. Our customers saw this as a great step because it gave them the leverage and confidence that they could control changes to the clients of the services. We also embraced open source dependency management solutions such as CocoaPods (iOS) and Gradle (Android) for our SDKs with an eye toward accelerating developer productivity and adhering to the best practices that we see for open technology development.

In addition, we were often able to find development resources and technical documents in these vibrant communities to solve problems that we were addressing. These communities were also great places to recruit new talent.

Transforming our team

The transformation of our team from an enterprise development team to a startup-like development team took about 6 to 9 months. One of our key goals was to make our team a place where developers wanted to work. While technology is critical to our success, real success was dependent on getting the right team and ensuring they embraced a new tool set, including GitHub Enterprise, Grunt, NPM, and other tools to speed up development. The team proactively partnered with New Relic to obtain operational insights into our deployments.

We relied on a core group of developers that remained with the project throughout the journey, and we had a strong focus on co-located teams with war rooms and constant interaction on Slack channels. We also created a microsite and jobs page to attract new developers from the startup community.

One of our goals for the organization was to recruit, onboard, and promote top technical talent to continue to drive our technology direction. We built a strong technical team that had a variety of experience levels and different perspectives on how to build software. Using an informal poll, we found that approximately 45% of the team had 0 to 4 years of experience at IBM, many with just 1 to 2 years. Of those with more than 4 years of experience, about 75% had less than 10 years of experience. We found that having this mix of experience levels helped drive our adoption of technology, while maintaining an understanding of what it takes to deliver services at scale. In other words, we had a nice blend of experience and youth.

We also found that having a cool technology stack and a clear mission to deliver a next-generation cloud-native architecture resulted in very low turnover. In fact, our team stated that the technology stack was one of the key reasons why they wanted to work at IBM.

Trailblazing is more than just coding

Once you blaze a trail, you need provide a map so others can follow! Our team has been active in communities such as Stack Overflow, which has allowed us to have close contact with our development community. Our team also drove developer outreach via a variety of Twitter channels to keep users apprised of our progress and new features.

Because of our successful transition to startup development practices, the team is often asked to present at IBM and industry technical conferences. We use SlideShare to share conference presentations and lessons learned.

Our developers are now considered to be innovators and technology pioneers across the mobile and cloud technology teams at IBM. Our hope is that as a role model for teams looking to move to cloud-native development, we can help share best practices and shape the direction for other teams using real-world deployments to validate our approaches.

Takeaways from our “manatee to dolphin” journey

The rewards to adopting the tech startup development model can help you transform your company and engage and motivate your development teams. Here are a few of the takeaways you should consider when transforming your team from manatees to dolphins:

• Document the steps of your journey to Software as a Service. Help others benefit from the lessons you learned and the choices you made.
• Adopt best-of-breed technologies. Open source solutions are great accelerators.
• Create a vibrant technical team. Attracting and retaining top technical talent is priority #1. Be the team that other developers want to join!
• Share lessons learned with the wider community through articles (like this one!), presentations, conferences, and social media.

Conclusion

The transition to acting like a startup is rewarding, but it does take time. Along the way, you’ll hit bumps that will require rework and redesign, but that investment will drive your passion for continual improvements. We started this project to see how an IBM development team could leverage the cloud to deliver significant value to IBM. We wound up with both a compelling solution for IBM and recognition as an innovative mobile and cloud development team. See how our team further transitioned to a cloud-centric architecture.

Originally published at www.ibm.com.