Stay Focused

Generally, startup companies attract very talented and motivated individuals. They often join the startup with the hope that they can help mold and shape the company with their thoughts and ideas. Unlike larger companies, individuals thrive off of the possibility that they would have a chance to greatly influence the direction of the products of the startup. However, if not properly managed, the startup can suffer from “idea overload”.

When the products are in the early phases of development, there are many thoughts and ideas on the multitude of possibilities the direction that the products could take. Creative people often are very passionate about their ideas, and will hold strong opinions when it comes to products and product direction. This creates a natural tension in product development. You want the best ideas, but you also have to know that you can’t take all of the ideas. You have to draw a line somewhere in order to meet your objectives. This is especially true in the computer software world. There are many options and opinions on the best way to accomplish something. In many cases, there really isn’t a “wrong” way to do something as long as it works.

At DecisionPoint, we faced several challenges when it came to introducing new products, and upgrading existing technology. Some of the decisions that were made greatly benefited new and improved products, and other decisions did not. Unfortunately, hindsight is always 20/20, and I probably wouldn’t have made the same decisions now as I did then. A lot of it had to do with my inability to properly gauge what was best for the product and company, while at the same time, keeping engineers refreshed and motivated. Motivated engineers are an invaluable resource, and you do your best to keep them happy. That was my primary focus as I looked at the best way to carry our products forward. However, I should have spent more time trying to balance what was right with what was motivating.

Our largest hurdle was probably the first time we were productizing the original work that I had done within Sequent. We were given six months to finish the productization, so there was little time for deliberation and debate about what was best. Given the short timeframes we had to deliver product, we had to take several shortcuts. The original code that was written was built in C, and hardwired for Sequent’s implementation of Oracle Applications. Oracle Applications is highly configurable, so the code that was written would not easily plug into another customer site without modifications. Additionally, it was C code, so the modifications that needed to be made were not able to be done easily by the customer. To make the solution easier to implement, we continued to work in C, but we added integration with database technology to support the configurability aspects of Oracle Applications. One set of C programs could read the customer’s configuration of Oracle Applications into a database, and another set of C programs could read the information in the database, and then dynamically re-configure themselves to fit the customer’s environment. The code worked well enough, but was very difficult to install, and required quite a bit of expertise to install properly. Looking back, we should have taken the time needed to polish the code to make it more installable and supportable versus strictly worrying about time to market requirements.

In our second release, we made significant strides in improving the code from the first release. We used more robust development environments, and built a nice user interface on top of all of the programs, and made the software much easier to install and support. While the product still provided the same fundamental value to the end users at the customer site, we finally were able to overcome the technical issues that were our Achilles heel in the first release.

Our third release was probably the first really big mistake that I made in selecting technologies to leverage for our development. Our second release had user interfaces built in Visual Basic, which was very easy for the engineers to use in building software. It did have limitations, but from a customer perspective, the technology that we were using was not an issue. Our engineers desperately wanted to start learning new tools and technology. They pushed very hard to switch from Visual Basic to C++ claiming that they could be much more productive in that development environment. The problem was that none of them had experience developing in C++, and the technology itself was not only a technical change, but also required changes in the way that code was developed.

We assumed that we could send the engineers to training classes, and that all would be well. The mistake that I made was underestimating how long it would take the engineers to come up to speed not only on the technology piece, but also on the change that was required in the development approach. With no experienced engineer in the new technology, we proceeded forward. We managed to be able to build product with the new software development tools, but we made many rookie mistakes that could have been avoided if we either stuck to what we already knew, or if we brought on a senior engineer with experience in the new environment. We missed our schedule for that release, and as we learned later on in the company’s history, we also built an environment that was very difficult for new engineers to pick up and learn when we hired them onto the engineering team. At that point, I learned a very painful lesson that I would come to regret many times in the following years. We set ourselves up so that making even the simplest changes to our software was a long, tedious, and difficult process. While the older Visual Basic technology was “behind the times” as far as engineers were concerned, we probably should have delayed the switch until after we had more experienced engineers in that area.

A couple of years later, we would make a similar mistake in a different area. Up until this point in the company’s history, our strength had been more on what is known as the infrastructure components. Our software would virtually run itself after installed. The challenge was that when you present that type of software to customers, it’s like having them watch a submarine race. There’s not much to show or see.

About this time, we had a change in management. The new management team didn’t have a lot of experience in our core strength, which was getting data out of Oracle Applications into a usable format. Their experience was deep in building tools that allowed end users to easily browse and navigate data. In order to expand our market share and visibility with a broader audience, we decided to put together a series of complex tools that allowed finance personnel to easily browse and navigate the data. It was radically different than anything we had done before. The new management team decided that it would be best to take some of the senior engineers, isolate them to work on this new project, and have them develop the new product without any technical boundaries or guidelines. The engineers responsible for the project decided that the user interfaces would be built in Microsoft .NET and C#, and the server code would be written in java services using XML as a storage mechanism. All of the technologies were fairly new and relatively unknown. While the work that they did resulted in a very good product, we suddenly had a development environment that was different than our previous development environments, and also an environment that it was difficult to find additional engineers to develop with.

Some could argue that the switch in technologies was a good one as it gave us capabilities that we could not get in the existing technologies we were using. However, the resulting product was typical of what you get when you isolate very talented and creative engineers with no guidelines or boundaries. In many ways, we tied our own hands. The software that was built with the older technologies was solid, but very difficult to change. The software built with the new technologies was less solid even though it still worked, but we could not easily find engineers that could readily develop in that environment. Again, the lesson learned is that new technology for technology’s sake is not necessarily a good reason to change your entire engineering environment.

Since the completion of the previously mentioned products, we have spent the last couple of years unwinding the two sets of technologies and combining them into one. We have migrated the older technologies to the java environment, but have done it in a way that is more reasonable. Additionally, we have been unwinding the complexities of the existing java environment to make them simpler, and to cut down the product features that weren’t being actively used by the customer. Unfortunately, there is a tremendous amount of code and complexity that it will continue to take us months and years of work to get everything on the same technology platforms.

When it comes to engineering, you have to picture everything as a pay me now or pay me later proposition. Every time you decide to make a major technology shift, you have to do so in a manner that makes sense. Going to bleeding edge technology every chance you get will often create a deficit situation for you. It may work, but sustaining the code, and finding engineers to support the code that have the appropriate level of experience will be difficult. Additionally, when you are introducing brand new pieces of technology, you have to have a plan as to how you intend to move the older technology forward. You can’t simply ignore it and hope it goes away some day. Probably the two highest recommendations I can make in this area are to create and follow a manageable product roadmap, and have frequent technology reviews to ensure that everything being done fits in the overall strategy of the product roadmap. Engineers are very bright and creative people that can come up with amazing ways to solve technology problems. However, this has to be balanced with what is reasonable and makes sense from a product development standpoint.