Market-shaking innovations aren’t magic, even though it may sometimes seem that way. Whether it’s the electric car, the first desktop computer, the first streaming video or the first cloud-based software, it all started with an idea – and resulted in an enormous amount of work. A snap of the fingers won’t make it happen, and just coming up with an idea is not good enough. Thinking about the next thousand steps after that initial big idea can be daunting for many people, invigorating for others and most people experience both feelings at the same time. What does it actually take to make that vision a reality?
Simplify your systems and align your people
Start by looking at the team you have to make this vision real. Is it forward-focused and capable of taking on strategic objectives? Or is it a step behind, focused on reacting to customer requests and complaints? While customer inputs are certainly critical, it’s important that your talented people use their gifts to build future products and revenue features. Make sure they’re focused on anticipating customer needs and developing new functionality and solutions before the market even realizes what it wants.
Consider if your team is even a “team” at this point at all. Or it is a collection of disparate groups doing their own things? To take on change or new-focus, your engineering departments need to be marching to the same drummer, in the same direction. There needs to be a foundation of discipline, even among the most innovative teams.
Forcepoint was created by joining together five different companies, we had just as many or more tools and processes for software development. Each group was focused on its own product with different source code management, different communication tools, and different escalation paths. We had 12 different repositories for source code, nine different documentation repositories and seven different JIRA instances. It was very siloed. We had to reimagine how we could function as a team.
Fast forward to today and we have a common GitHub enterprise instance, one Jira instance, and one common toolchain that is developed by a core team. We still honor legacy processes when necessary, for example, we have kept the legacy product’s test automation systems that have decades of investment in them, but the whole team gets the benefits of a modern development structure. Having your culture aligned and your tech stack simplified means your people can forget about process and politics and just do the work. If you are a software company, be damn good at building software. It should always be one of your core competencies.
Focus on what the business and your customers really need
While a big idea might be an interesting academic exercise to consider, the true game-changing projects get traction when they fill a crucial need for the market, the company or ideally both. At Forcepoint, we needed a way to deliver the adaptable security solutions our customers required, flexibly and quickly. For us, the solution was to build a platform that would be engineer-agnostic and enable the extremely talented developers we already had within the company to build great security services. Once we moved that direction, it quickly became clear it was the right choice. You know you’ve built a successful platform if developers will build for it because they’re always looking for the path of least resistance. We’ve already seen the results: from a development perspective, we can already operate almost 30% faster by building new services on our platform. That’s a tremendous advancement for any company and allows us to roll out new solutions and features to our customers faster. When you tap into a true need, the momentum comes quickly.
Keep in mind that what you know and what you don’t might change throughout the project
It’s important to have definite goals in mind, but don’t forget, you can’t know everything about something that’s never been built before. My management team has 150 collective years in the security industry and some have deployed hundreds of millions of endpoints, built the largest security clouds in the world, and a number of “firsts” in the security industry. However, we all had to keep in mind that just because it worked in the past doesn’t mean it will work now, and there are always new tools to use. This is all new and the key is to take the lessons from the past and use it to chart the path forward in an intelligent fashion.
It also helps to build for agility and compatibility. We started we defined core APIs, architectural precepts and we defined our initial common information model. This was done in a way to try to maximize the potential use cases and to leave room for further customization. Throughout the process, we changed our common information model two or three times, but it’s still compatible. If you plan for change from the beginning, it helps you move quickly and adjust when necessary. You can’t think about everything, but as one of the past lessons, you can think about the limitations and refine from there.
This applies to measuring “success” as well. When creating something entirely new it’s challenging to know what the baseline really is. We ended up doing an approximation based on similar historical projects and very complicated analytics and simply declaring that our “ground truth.” The challenge from there was to figure out where to go next. We find that as the system is learning, we have to adjust constantly. And that’s what keeps it interesting.
Conclusion
When we kicked off this project three years ago, we tried to map a path to where we thought the cybersecurity puck was going and how we could help take Forcepoint there. If you’re starting from scratch you may have fewer hurdles to overcome, but it’s still a tremendous task to build this vision and have the fortitude to follow through. Letting your people focus on the job at hand, prioritizing what’s truly needed for your company and customers, and keeping in mind that you’ll always be learning are all key to taking that idea from vision to reality. And then you get to move on to your next big idea.
