“Disruptive technology” is a term we hear so often (and so often misused) that many of us roll our eyes when we hear it. But the truth is that just about every tech startup in the world wants to build something truly disruptive.
Turns out, that’s pretty damn hard to do. So when we run across companies actually shaking things up, we take note.
Read on to hear from six local engineering leaders about how their tech is disrupting their respective industries — and what advice they have for fellow engineers hoping to do the same.
At niolabs, they’re using cutting-edge AI and IoT to simplify the complex task of building interoperable, interconnected systems for a range of industries and applications. CTO Matt Dodge explained how he and his team drive innovation in an industry that is still, in many ways, in its infancy.
Share a little insight into your engineering team's development process. What makes your process unique?
At niolabs, we operate with a design-led development culture. This means that, before any engineering decisions are made, our design team determines the best way to solve the problem from the user's perspective. Ideally, this prevents us from doing something that isn't customer-friendly just because it is easier to build that way.
How do you and your teammates stay ahead of the curve in your industry?
To stay ahead of the curve in IoT, we rely on a patent-pending, one-of-a-kind niolabs crystal ball, which we keep locked in a highly-secure vault. It’s served us pretty well so far. In all seriousness though, the IoT industry is interesting because it is moving so fast and no one really knows where it is going to end up. Being a flexible team that is always willing to try out a new idea and then share the results with others makes us able to quickly adapt to a rapidly-changing industry.
What advice do you have for other engineers trying to build a disruptive product?
You need to have a philosophical stance on an industry before you can have a technical stance on it. There is not going to be a how-to guide on how to build your product if it is truly disruptive. That means you're going to be faced with tough technical decisions along the way, and without a strong philosophical guidepost to lean on, you will keep floundering.
Mike Scarborough is chief technology officer for Denver-based travel tech company Travelers Haven. He gave us a glimpse into his team’s process and explained how individual autonomy makes them stronger — and more innovative — as a team.
Share a little insight into your engineering team's development process. What makes your process unique?
Since we are a bootstrapped company, we’ve built everything from the ground up, with features primarily based on the market and our customer feedback. Our engineers are given all the responsibility they can handle, including deploying their code to production daily after it passes code review, continuous integration and QA.
Our process is fairly unique in that our engineers have a high degree of autonomy and are directly responsible for the success of our products and our company overall.
How do you and your teammates stay ahead of the curve in your industry?
We are always looking for new ways to stand out by researching and sharing software best practices. Our engineers then collaborate on which new concepts should be implemented. This could take the form of sharing links from our learning platform in a Slack channel, during code review, in demo pull requests or in team lunch sessions.
What advice do you have for other engineers trying to build a disruptive product?
In order to make a disruptive product, you have to put all of your focus into the product itself and customer features. If you spend a lot of time up-front architecting for growth that may never come (or come in a way you didn’t expect), then your product won’t live up to its full potential. Also, use proven open source software and avoid the “new shiny.” Delivering customer features is cool, but debugging the newest framework isn’t.
Tack Mobile is a mobile design and development agency, working with a variety of mobile and connected devices. According to development lead Erik Wolfe, his team builds disruptive tech by sharing feedback often and iterating, iterating, iterating.
Share a little insight into your engineering team’s development process. What makes your process unique?
Once we have a focused set of requirements for the idea, we start thinking about the best ways to display them. Our design team will put together some mock-ups and iterate with the team before development starts. After we have a solid design foundation, a developer will start building the prototype. This part of the process moves quickly, as the developer and designer iterate to once again establish a solid foundation for the rest of the work. It’s around this time that more people may jump in to contribute to the project, and a more formal process will organically grow — typically some form of scrum.
How do you and your teammates stay ahead of the curve in your industry?
Mobile and IoT move fast. We have to keep an open mind when solving a new problem. In order to stay ahead of the curve, we all work hard to stay up to date with shifting standards and put those standards into practice as quickly as possible. By building internal products, we test those standards and learn what works and doesn’t work. That experience compounds quickly to a general understanding of what a “good” direction to take may be.
What advice do you have for other engineers trying to build a disruptive product?
In the ideation stage, share unabashedly. When working with a team, it’s usually the combination of ideas and points of view that form into a better, more concrete idea.
Post-ideation: Prototype. There are all sorts of great prototyping tools available, and it benefits everyone involved to quickly explore options before writing a line of code. Many of these tools are developer friendly and allow people to build out flows and navigation quickly to test, before spending days implementing.
Brian Williams is the director of global platform architecture and network for IT services and software provider CSG International. Despite being part of a large, global organization, William’s engineering team operates much like a startup, working closely with operations to ensure there’s buy-in on both sides from the start.
Share a little insight into your engineering team's development process. What makes your process unique?
We’re an agile shop operating in two-week iterations within four program increments (releases) a year. We drive the entire stack cohesively. Our development and operational architects work side by side to drive product, operational and technical needs into the platform holistically.
It’s unique in that we’re not bounded by red tape that sometimes gets in the way between operational needs in one arm of an organization and engineering/development needs in a another.
How do you and your teammates stay ahead of the curve in your industry?
We’re always evolving and looking for better ways to develop, operate and architect the platform. We hire folks who have the aptitude and love to learn new technologies, and who don’t have a lot of biased views on why we should stay with one technology or not explore new ideas.
What advice do you have for other engineers trying to build a disruptive product?
Embrace controlled chaos. Technology — and the way platforms are built — are evolving so rapidly that its difficult to keep up. Learn how to walk the fine line of encouraging the chaos that comes with innovation and ever-changing direction and technologies, while ensuring you have a deep understanding of your business. At the end of the day, controlled chaos is great if you can embrace it while keeping platform stability metrics in line!
At NextHealth Technologies, senior data scientist Jeremy Schendel is behind the scenes ensuring healthcare consumers have the information and insights they need to make the best decisions for their health. Here’s how his team finds inspiration for their next innovation.
Share a little insight into your engineering team's development process. What makes your process unique?
We generally get product ideas from two sources: clients and conferences/papers.
Product ideas that come from clients are generally routed through our product team, which will coordinate with the client to determine the technical requirements needed for us to implement the idea. Ideas from conferences/papers typically involve newer, domain-specific techniques and tools that we're interested in. These ideas usually come from within the team and are scoped out internally with some coordination with the product team to determine how the idea integrates with the product.
How do you and your teammates stay ahead of the curve in your industry?
We use a wide variety of sources to keep up to date with the industry. To name a few: conferences, meetups, podcasts and GitHub. Conferences and meetups provide a good way to learn about new techniques and tools, and many post videos of talks online, so attendance isn't strictly necessary. Podcasts provide a good way to passively gain information during commutes, workouts and similar types of activities. Many of the tools we use are open source and developed on GitHub, so we keep an eye on issues and pull requests for many of the packages we use to get a peek at upcoming fixes and features.
What advice do you have for other engineers trying to build a disruptive product?
Every component used within your product doesn't need to be "disruptive." Using the latest tools and technologies is great, but don't use them simply for the sake of using them. Be sure to consider well-established, existing tools and technologies; they often come with a fuller set of features, better documentation and better stability and maintenance. Take the time to understand the problem that motivated the creation of the latest tools and technologies, why existing solutions didn't work, and how this ties into the problem you're trying to solve.
Josh Schwalm is the lead software engineer for Denver-based healthtech company Healthgrades. There, the engineering teams are broken into smaller, more focused groups — but that’s not to say they’re siloed. Schwalm shared how this unconventional dev team shares new findings and ideas.
Share a little insight into your engineering team's development process. What makes your process unique?
We practice a Lean Agile methodology and focus as a team on a particular functional experience (Search) for our website. Given that we are a large organization with many engineers working on our primary product, breaking the teams into smaller focus areas helps us to innovate quickly and offer an environment that feels more like a startup mentality.
As part of our methodology, we are leveraging many of the best practices of agile: user stories, backlog grooming, sprint iterations, daily standups, constant demos and frequent deployments of code into production. We also spend a lot of time as a team discussing our “definition of done,” which helps to set expectations in keeping up with automation test coverage, alerting and monitoring, performance thresholds, and other functions that help to deliver great product results.
How do you and your teammates stay ahead of the curve in your industry?
Given that we are structured into smaller delivery teams, we have organized larger “chapter” discussions (for like skill sets) to help evaluate and share tech ideas across all engineering teams. The chapter will meet weekly, bring in drinks and snacks to keep it light hearted, and use the forum to discuss prioritized topics.
We recently participated in a chapter-led technology radar discussion, which helped drive conversation about which new tech we should evaluate, attempt or adopt. This helps us to stay aligned within our engineering group to support and share new ideas and keep us current. The best chapter discussions are those in which team members are demonstrating functional code in production that stemmed from a previous chapter meeting.
What advice do you have for other engineers trying to build a disruptive product?
Move fast, but make your iterations small. Don’t overthink the use of heavy explorations into tech and features, but rather, get your hands on live prototypes and test them in a way that you can easily manage your risk of pushing code into production — things like feature flags, solid rollback plans, good regression test practices, etc. Moving with speed will help you vet your ideas faster, determining what is and what is not working, and adjusting as needed.
