Struggling to Innovate? Set a Firm Deadline

The phone conversations started early today. Amy Katz and I were discussing some of our latest R&D efforts. We agree on the vision. But we're going back-and-forth on the execution. And frankly, the execution isn't easy.

Without revealing exactly what we're up to, I can say we're certainly focused heavily on software right now. And to use a familiar metaphor, we're knee-deep in operating system code (which looks and feels really promising) but struggling a bit with the graphical user interface -- the look and feel of our potential developments.

Now, throw in all the other variables and the complexity can become overwhelming.

  • How will we optimize the OS for specific underlying hardware and screen sizes?
  • Just how heavy or light should a modern GUI be -- and can the OS handle that load?
  • How can we leverage modular code to avoid the innovator's dilemma -- swapping out old piece parts for new offerings at a moment's notice?
  • And the list goes on.

Thankfully, our R&D team is pretty darn talented. We could all become overwhelmed by this software development journey. But our commitment to at least a rough DevOps framework has been really helpful. Yes, there are weekly code sprints (as much as I despise that term...). Yes, there are weekly fixes. Yes, there's a close of Friday recap to see just how far we've come -- and what hill we'll need to climb next. And yes, there's a firm deadline for some of the code we're working on.

Sticking with that deadline has helped us to break through a few big decision points and logjams. Amy has always pushed for "real" deadlines to ensure we're hitting our milestone goals. And as I used to tell my old boss at NYIT, "At some point you have to ship product." 

That doesn't mean you ship a buggy, subpar product just to get something out the door. But it does ensure that you don't suffer from endless slippage and so-called "feature creep" -- where "nice to have" items gradually overwhelm your design specifications.

Assuming we actually finish this so-called operating system and GUI journey, what will we do with the code base? That's a bit like asking a newly opened machine shop what they plan to manufacture. Ideally, your machine tools are programmable -- which means you can serve specific markets on demand... or pivot to address an emerging market that most folks had overlooked. And in a truly modern machine shop, machine-to-machine computing and self-service capabilities take over. You walk away while the robots sort it all out...

For now, we're locked away in our own machine shop. Deadlines loom. And that's a healthy thing as we wrestle with more OS and GUI decisions...

Subscribe: Want to receive our blog headlines in your inbox each business day (except when we go stealth on Fridays)? Then subscribe to our enewsletter. Thanks to those who already have.