Data Warehousing and Psychology…Who knew???

There is a dark secret about the data warehousing industry that no one ever seems to acknowledge, which I’m going to expose in this section. You often hear of the failure of a data warehouse along with a lot of different technical reasons why it didn’t work, why users found it too hard to use, etc. Surprisingly, even data warehouse implementations that were consider a success from a technical standpoint can be deemed a failure by the business users. Why can that happen? You’re about to find out…

Before we get there, let’s have a discussion about computer systems. In my mind, there are two classifications of computer systems: the must haves and the nice to haves. The must haves represent systems that the business would crumble without. These are systems like financial systems where you enter vendor invoices so that they can be paid, or you enter customer invoices so that the customer can be billed and they can pay you. Without systems like these, it would be very difficult, if not impossible, to run your business efficiently. Some would argue that without these systems, your business would die. The nice to haves are systems that could be considered to be optional. These are systems that if they are not in place, the business will survive. The business may run a bit less efficiently, but there’s not a worry that the business would crumble. In many industries, data warehouses are considered a nice to have. There are a few industries where without them a business would be extremely limited, but not a whole lot of cases where a business would die without one.

In my years at DecisionPoint, I experienced a lot of sales situations where we would get really close to closing a deal, but the customer would lose their budget, the money they had budgeted would go for another IT priority, or something else of that nature. If the customer walked away from us, the business was not going to die. Sure, the company could greatly benefit from the data warehouse, but there was no risk to doing nothing. No money spent, no risk of failure, etc. I think that’s what makes selling data warehouse solutions such a tough business. Anytime the customer has a “do nothing” option, it’s always something to worry about. There has to be a motivator or compelling reason that causes them to not choose the “do nothing” option.

There’s another “do nothing” option that never gets mentioned by IT shops, consultants, or vendors. That “do nothing” option lies on the other side of a successful implementation. Let’s assume that you went through a lot of trouble and hassle, but you got the data warehouse up and running with end users actively using it. You think all is well and good, but there doesn’t seem to be any benefit from the data warehouse. All of the business value (i.e. increased revenue, reduced cost), etc. just doesn’t materialize, and you wonder why…The answer lies below, and involves something that is often referenced in terms of Psychology.

Anyone that has been through or knows about counseling should know the answer to this question. If you’re going to a counselor, when do you start to get better? The answer is you start to get better when you decide to get better. The counselor can talk to you for hours and make many suggestions and recommendations. However, if you don’t decide you want to get better, you won’t try the suggestions or recommendations. The counseling sessions will simply be an hour or so of your time talking to someone. There is no benefit, and you’re probably wasting a lot of money.

Now, let’s spin this in the direction of the data warehouse. Using our scenario above, we’ve done everything that needs to be done and the users are using the data, but nothing changes in the business. It’s quite possible that the data warehouse is providing valuable information, but the users are too afraid or unable to use the data in making changes in the business that will improve revenue or reduce expenses. Just like a counselor, the data can tell you all of these wonderful things about the business, but unless the users are willing to use that information to make changes in the business, nothing will happen. Your data warehouse is just like the counselor…you’ve spent a lot of money, but nothing changes because you haven’t decided that you need to get better.

It amazes me how often this happens, and what a difference it makes when you have end users that are willing, able, and brave enough to do what needs to be done after the data points them in the right direction. Far too often, I have seen data warehouse projects go down in flames or be viewed as wasted money simply because the end users didn’t have the guts to do something, or worse yet, management wouldn’t let them do what needed to be done. Generally speaking, people hate change. A data warehouse is the first step to change. It tells you how things are so you can see where you need to go. Getting there involves change, and in some cases, change represents a bad thing. Don’t rock the boat…you might get in trouble or be fired. Willingness to accept and use the data as a “business weapon” is the only way to succeed.

A couple of examples to make my point… The names are left out to avoid any kind of aggravation I might receive from the people that were involved.

In the early days of DecisionPoint, I was helping a customer in the Northeast United States implement our data warehouse. It was about 8-12 weeks of me flying back and forth across the country to put it in for them. We had some bumps along the way, but after we worked through the bumps, we ran into a brick wall. Everything was looking good, and I was demoing it to an end user and we started to look at some data. We got to one section of the data and she made a comment to me something like this. “You have to turn this off!” My immediate response was to ask why we had to do that after everything we had done. Her response went like this: “Your numbers are correct, but that’s not what the CFO believes the business looks like…” It turns out that they did have some minor problems with some of the transactions where the data came from. That was fixable. What was not fixable was her unwillingness to go to the CFO, present the information, and figure out a way forward. I left that company and have not heard back from them since.

On the other side of the equation, we have two really positive stories to tell.

In our fist example, it was again the early days of DecisionPoint. We were working with a local company implementing our software. It was fun because they were a retailer, and when it comes to change retailers don’t mess around. If they find something that will eliminate costs or increase revenue, they’ll do it…no questions asked. However, it does get a bit cut throat as there is “no mercy” in what they do. They may make a change in one day that puts 100 people out of work, and their attitude is “so be it, we had to do it for the good of the business”. In any event, we were only a couple of weeks into our implementation when we gave the end users their first glimpse of the data. They were focused on the profitability of the stores. They started to look at the unprofitable stores, and guess what? For the ones that were in real trouble, they literally started to shut them down the next day. No questions asked. This was long before they were even actively using the data. They saw a problem. They fixed it. In the end, it did help them save a lot of costs and have a higher profitability than they would have had, so it was a good thing.

Another example at this same company came later on in the implementation. We were extracting vendor invoices, and everything was going smoothly. Then, we got to a point where we were extracting data for the month of December. Suddenly, the vendor invoice volume quadrupled. We were shocked and puzzled, and when we presented it to the end users, they had the same reaction. They were determined to find the source of this phenomenon, and proceeded to do research. To make a long story a bit shorter, here goes. When they would hire a store manager, the manager would get a bonus each month related to the profitability of the store. So, the managers had creatively figured out that if they didn’t turn in their vendor invoices (i.e. expenses), the store was more profitable. So, for the first eleven months of the year, they wouldn’t turn in any expenses. Then, in December, they would send in all of the vendor invoices they had collected over the year. The problem was not only vendors that were upset about not being paid, but it ran deeper. It turns out that the stores were also getting late notices on vendor invoices. So, what happened in December is that the AP clerks would enter the original invoice, then enter the late notices, etc. In some cases the company was double, triple, or even quadruple paying vendors. What seemed to be a very simple problem was costing them a lot of money. Needless to say, the bonus program was changed, and the problem disappeared.

My last example is a story of a user using some data in a way that even I wouldn’t have guessed. This person gets the gold star from me on “data creativity”. At another one of our retail accounts, there was a user in what is called their “Risk Management” department. Part of that department involved insurance policies. This particular business had a lot of delivery vans throughout the US that they were using along with associated insurance policies on each van. This particular person did some analysis using some vendor invoice data that allowed her to compare what they were spending on new tires for the vans in each region of the country, and then compared that to the insurance rates they were paying on each van. It turned out that the regions that spent more money on tires for the vans had vans with fewer accidents, which meant that their insurance rates were lower. Using this information, the user instituted a corporate wide policy on how often the vans would get new tires, so that all regions were doing the same thing. Once she changed the policy, they began to save millions of dollars on their insurance policies. In this case, not only did you have an end user willing to act on the data, but also one creative enough to find out something about the business most people would have overlooked.

OK, so what’s the moral of the story? It’s very simple. When it comes to a data warehouse, the business only improves when the users are willing and able to act on the information that they see. If they are unwilling or unable due to a management policy or something like that, the data warehouse will die a slow painful death. Could it have been useful? Yes. But, potential only goes so far…you have to use the potential before anything changes.

Dare To Do Things Differently

At DecisionPoint, I often describe our evolution as a company in the form of management regimes. When I use the term regime, I talk about the management team. Generally, in any company, when a CEO is hired, they will more than likely bring in people that they have worked with before at other companies, and that they also trust. Trust is an especially important trait as you want to make sure that when it comes time to make tough decisions, you are working with the people that you trust will help you make the right decision.

I experienced four different management regimes at DecisionPoint, each with its own “personality”. In other words, there were four different CEO’s that I worked for, each of which brought in their own set of management team members based on past work experiences and relationships. While regimes can provide a consistency from a management team perspective, there is also a pitfall associated with a regime. In this chapter of the book, I will describe each regime, but then follow it up with what I consider to be the pitfall to the regime concept.

Our first regime at DecisionPoint was what I called the “Teradata Regime”. Our first CEO was an ex-Teradata employee, and when he was brought on board as our CEO, he proceeded to hire a VP of Sales, a VP of Marketing, and several other non-management personnel that were either people he worked with directly or indirectly at Teradata. In some respects, what the first CEO wanted to do was to bring the positive traits he experienced at Teradata to DecisionPoint. Under the “Teradata Regime”, there was a good understanding of our product as both Teradata and DecisionPoint were suppliers of data warehouse solutions. However, in the world of Teradata, hardware and software were bundled, and in the world of DecisionPoint, we were focused solely on software. So, some of the things that the “Teradata Regime” wanted to implement did not apply to what we did at DecisionPoint as those things were more related to how you sell bundled hardware and software versus a pure software solution.

Our second regime at DecisionPoint was what I called the “Sequent Regime”. Our second CEO was an ex-Sequent employee. Initially, the main employees that came from Sequent were the team he inherited (i.e. the engineer and sales teams that were spun out of Sequent). The one thing that the second CEO initially did, which was good, was he understood our product was software, and began looking for sales people that sold software rather than try and convert hardware sales reps from Sequent into software sales people. However, as the second CEO began to build the headquarters staff at DecisionPoint (i.e. marketing, professional services, etc.), he tapped into his network of people he had worked with at Sequent. From a marketing and professional services perspective, Sequent understood data warehousing and the separation between hardware and software. However, all of Sequent’s data warehouse experience was based on professional services people building custom data warehouses specific to each customer where as DecisionPoint was providing a packaged data warehouse environment. What happened over time is that our product became less packaged, and our staff of professional services people grew significantly. A lot of the customers ended up spending more money on the professional services than they did on the software, and that was contrary to what our goals were at the corporate level.

Our third regime at DecisionPoint was what I called the “Brio Regime”. Our third CEO was the founder of Brio, but no longer part of Brio. Like the other CEO’s, he brought on board a lot of ex-Brio people. Brio provided an end user tool that made data easier to access. DecisionPoint’s product was based on building a robust set of data and infrastructure, not on the tools the end user uses to access the data. The folks that came from Brio were intensely focused on the tool that users used to access the data versus the content of the data. Through the “Brio Regime”, DecisionPoint spent a significant amount of money making a robust tool that was integrated with the data warehouse environment, and provided an easy environment for end users to access data in the data warehouse. Unfortunately, we lost focus on our core value (robust data warehouse environment), and spent a lot of engineering time and money on tools that were good, but not really part of the core value of our product offering.

The fourth and final regime was what I called the “Informatica Regime”. Our fourth CEO was and ex-Informatica employee, and was someone that was introduced to us via the venture capitalist that provided us one of our rounds of funding. The fourth CEO did not immediately replace the existing management team with ex-Informatica people that he had worked with. However, over time, our VP of Sales, our VP of Marketing, and several sales people were ex-Informatica people. From a data warehousing perspective, our fourth CEO understood our value proposition from a data warehouse solution perspective very well. What we were doing with our products matched something he was trying to do at Informatica. However, Informatica was an infrastructure (i.e. ETL – extract, transform, load) company, and really understood the requirements for moving data from a variety of source systems into a data warehouse. While DecisionPoint had infrastructure components, the real value was in the type of data we provided, and how we structured that data for end users.

I will not judge what I thought were the good and bad points of each management regime. That is water under the bridge. However, the point to take away from this is the effect that regimes have on a startup. In each regime we had at DecisionPoint, they all came from the data warehousing industry, but each had a different focus within that industry. Because DecisionPoint products span many different aspects of the data warehousing industry, we had components of our product set that each regime understood really well and others they did not understand very well. Generally, each regime tended to focus on the components of the DecisionPoint products that they understood the best, rather than focusing on the overall DecisionPoint solution. This led to different sales and marketing positioning that each regime used even though the DecisionPoint product was the same across all regimes.

The good thing about regimes is that they bring valuable past experiences about what has worked for them successfully. However, the pitfall of the regime mentality is that you don’t think “out of the box” in many cases. Management regimes will often do what worked for them in the past, especially when it comes to sales and marketing. In many cases, what worked in the past does not apply to the current situation. Probably the most obvious example I have from DecisionPoint is in how our product was sold. The consistent theme across all management regimes at DecisionPoint (and is generally true in the high end software market) is to establish a high touch sales force goaled on selling a lot of software to large customers. Each regime thought that they would be the one to finally make the high touch sales model work better than the last one did. They each thought that if they worked at it a little harder (better sales reps, better training, etc.), they could crack the code for how to sell DecisionPoint products with a larger high touch sales force. None of them put any serious effort to completely rethink how the product should be sold. In the third management regime, we attempted a low end offering that would be ideal for middle and small market customers, but the sales force quickly rejected it. The bottom line is that if your sales force rejects it, they won’t sell it. Unfortunately, management at the time did not address the issue with the sales force, so the product offering died a slow, painful death.

The bottom line of the whole story and our different management regimes is that no matter what you do or who is involved, you have to be willing to try new and different things. Doing the same thing as you've done, unsuccessfully, before while working just a bit harder doesn't necessarily result in improvement. You always have to be willing to look at what you're doing, where you've been, and change course appropriately. Everyone brings valuable experience to a startup. However, if you only use that experience to do what you've done before, you're selling yourself and the startup short. Be bold, do something differently than it's ever been done before, and be confident that no matter what you do, you can adjust and move forward.

A Newer Image Is Not Always Better...

In the last chapter, I spent a lot of time reviewing why newer is not always better from an engineering standpoint. However, I believe this also applies to all aspects of the business. The other two areas where you have to be very careful with this are in sales and marketing. Like engineers, sales and marketing people are very creative, but their creativity shows up in different ways than it does for engineers. Sales people are very creative in taking your product and making it look in the best possible light to potential customers. Marketing people are very creative in taking your product and wrapping it with just the right advertising and collateral whether it be web sites, magazine ads and stories, or brochures.

The biggest trap we fell into at DecisionPoint was having sales people convince us that if we built something, they would sell a lot of it. More often than not, the opposite was true. The phrase I remember almost every sales person saying to me was “if we just had X, I could sell more product”. So, we would go off and build X, and it would not help them sell our products any better than they had in the past. I spent more time at DecisionPoint building products that were never sold, also known as shelf-ware, than I ever anticipated I would build in my entire career in the software industry.

When you follow the needs of sales too closely, your product portfolio does increase. However, this also increases the amount of time, money, and people that you have to sustain to support the new product portfolio components. Rarely can you build and market something, and then just suddenly drop it. You have typically spent a lot of money not only in building the product, but also marketing the product. When you’ve spent that much money, which for a startup is significant, you don’t want to just throw the work away.

The other non-tangible side of this equation is the impact it has on morale. Generally, when engineers work on something, they work on it in hopes of seeing it used at a customer site to help the customer improve their business in some way. As an engineer, when you continue to build product that never gets sold, it gets demoralizing over time. You look at every new project with a great deal of suspicion as to whether it will ever see the light of day at a customer site. This, in turn, makes you approach every project very cautiously. And, while you would like to be able to think you would give it your best effort, you probably do not. It’s not to say that engineers become lazy, but after a while, they get gun shy wondering when the rug is going to be pulled out from under them next. Eventually, this leads to a huge rift between sales and engineering. Sales keeps asking for new things, and the logical engineering response is “you didn’t sell the last thing I built for you, what makes this any different?” Over time, it leads to engineers believing that sales people will never be able to sell what they build, and sales people believing that engineers never deliver what they truly need (which seems to change on an hourly basis).

On the other side of the coin, marketing lives in a world of “never good enough”. No matter how good your product is, and how well you market it, someone always seems to be doing it a lot better and faster than you can. I find that marketing departments will often have to “keep up with the Joneses.” While some of this will fall back to engineering in the form of product enhancements, most of these have more to do with how to better market the product that you have.

At one point in DecisionPoint’s history, we decided to completely re-brand the company and the company’s products. This included a new logo, a new company name, a new tag line, a new web site, new collateral, etc. All of it was in the guise of giving the company a new image. At the time, we were doing just fine as far as revenue goes. Customers were buying our products, and having a lot of success with them. However, no matter how much revenue you have, it could always be more. No matter how much collateral you have it could always be better. Looking back at it, we got too caught up in comparing ourselves to other companies rather than just continuing to do what we were already doing well. You do want to keep an eye on what the competition is doing, but you should use that as just one data point when it comes to your marketing strategy. Too often in the software world, companies are too focused on comparing themselves to the competition rather than emphasizing what they do well independent of any comparisons.

Probably the best way to tell the marketing story and lessons learned is to go through the different logos and company names that we went through at DecisionPoint. While all of them represented change in the company, none of it fundamentally made a difference in our ability to sell our software to customers. As you will see through the various examples, the names changed, but the core value of the product stayed the same. Describing the same thing differently with a new fresh face doesn’t always mean that you will be better at selling your product.



The above logo represents the first branding of our products and the company. This particular logo has an interesting heritage. The “cat scratch circle” as it has been referred to was actually inherited from Sequent. Prior to the spin-off of DecisionPoint, Sequent re-branded a data warehouse database product called Redbrick, which was later bought by Informix, which later was bought by IBM. Sequent’s version of Redbrick was known as DecisionPoint, and the “cat scratch circle” was the logo. By the time that DecisionPoint was spun out of Sequent, the re-branded Redbrick product was no longer being sold. So, since all of the logos and trademarks were already owned by Sequent, we decided to inherit the name and the logo. When we were spun out of Sequent, we discovered that the name DecisionPoint was already being used in other countries. So, we formally registered as DP Applications, Inc. but doing business as DecisionPoint. This is also when we developed our first tag line “decision making by the numbers”. In usual startup fashion, the company name, logo, and tag line were all “free” so they came at a very good price.



The second variation of the logo was also fairly cheap. We added some color to the “cat scratch circle”, and made the letters appear more dynamic and aggressive. Again, the cost was right as it was all work that we could do internally without spending money.



The logo above was the first time we spent significant money re-branding the company. At that time, we had a marketing manager, and had just received a large influx of cash from our investors. Our marketing manager decided that it was time for a new image. We spent a lot of money with a firm to come up with a new logo, and new way to show the company name, a new tag line, along with all the usual types of collateral like a web site, brochures, stationary, envelopes, etc. The logo actually was from a picture of a light shining through a crack in a cavern illuminating a spot on the cavern floor. The logo color didn’t have an official name, but was referred to by its Pantone Matching System number, which is owned by PANTONE, INC. The number was PMS 384 or PMS 386. I can’t remember which it was, but the color didn’t even have a name. The grey shape at the bottom of the logo was actually gold in color. The theme was that our software provided the light that shown through the darkness to help you find the pot of gold in your financial information.

At the time, this investment seemed like the right thing to do. We had received a fresh round of cash from investors, so it seemed like a good investment of money. As stated many times before, the investment really wasn’t justified by the return we received on that investment. In addition, the original tag line that the agency found for us was “Now You Know”. Only after everything was done did we discover that it was already being used by another company, and that’s when we defaulted to using “Uncommon Insight”.



The logo above represents what you do when you want to try and define a new market for your software. Each time we had a new management team come into the company, they always were looking for a way to re-brand the company that would draw attention from potential customers. Also, as stated previously in this book/blog, marketing folks are always trying to catch the attention of industry analysts by defining a new sector within an existing market. The structure of the logo changed, but more importantly, we changed the tag line. Up until this point, decision support software was largely defined as passive, which means show me what happened. We were trying to define a new market to make decision support more active. This meant that it would retain its current passive nature, but would also help in molding how you ran your business in the future with analysis based on prediction. In other words, the ability of people to perform the analysis of data to predict future events in the business. Unfortunately, this lead to the “double whammy”. We didn’t attract any more attention from industry analysts, and we didn’t attract new customers with this new concept. I think one of the most important lessons learned from this experience was that it is very hard for a small company to define a new market. Because you are small, and only have a few customers, you don’t have the clout to define a new market. However, larger companies with larger customer bases can define new markets fairly easily.





The last two logos were the ones used by the final management team before we were acquired. At first, we went back to the basic logo with no tag line. Then, it was decided that the word Applications had a somewhat negative connotation in the software industry. So, we switched to the DecisionPoint Software name. Once again, new web site, new brochures, new stationary, new collateral, etc. But, once again, little return on investment in this area.

Overall, the lesson learned for me when it came to marketing was that you need to be clean, but you don’t need to be great. Fancy logos and tag lines aren’t what sells your product to customers. The people within your company, and their ability to convince customers that they need your software is really what is important. Potential customers may go to your web site to get information, but at the end of the day, they buy software from people they trust, and people that can convince them the software will make a difference in their company’s success. No amount of fancy logos and pictures can replace the face to face contact that gives a customer a comfort level that they are buying a good software product from a quality team of people.

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.

Know Who You Are

At DecisionPoint, one of the stress releases that we used was to tease each other about our actual and “perceived” shortfalls. In some cases, we joked with individuals because they were from other countries, memory lapses due to age, and many other things. While this may seem cruel to people outside of the company, it was our way to maintain our sanity in a very tense situation. During the joking, we all used a common phrase to respond to each other, which was “know who you are…” In other words, we were all comfortable enough with ourselves that we accepted our limitations.

I use this story as an introduction to the struggles that we faced at DecisionPoint with marketing our product. Overall, our solution was pretty simple by design. As stated before, the goal was to allow customers to implement a data warehouse in record time to facilitate the type of robust reporting and analysis that helps personnel at the customer site find financial anomalies. The goal being that end users could help to maximize the financial performance and efficiency of the organization. Yes, it was a revolutionary idea, but we felt we could change the data warehousing market significantly.

Even though we had a bold new idea and strategy, we still faced a problem at DecisionPoint. Throughout our history, the fact was that we didn’t “know who we were”, or more aptly stated, we didn’t accept who we were. It would prove to be a significant Achilles heel for us, and caused us to stumble several times throughout the company’s history. I often think back of what might have happened had we “known who we were”, accepted that, and used a strategy more in line with what we were. Regardless, I learned a big lesson from this that I think is very important to understand.

Unfortunately, the world of high technology has become one of taking very simple and basic concepts, and marketing and selling them to be much more than they really are. No matter how good our solution was, it always had to be positioned larger than life. It’s expected not only by the industry, but also the analysts that follow the industry and write reviews on new products. We at DecisionPoint fell into that trap several times. Every sales and marketing regime that we had at DecisionPoint would fall prey to this. The solution had to be marketed and sold to be the cure-all for financial anomaly detection and resolution. In some cases, we even built specific products that were marketed to help with Sarbanes/Oxley compliance (SOX), even though our product only helped with a very small part of SOX compliance. As we found out, bigger and more complex was not always better, and it worked against us in many of our sales cycles.

At one point, I did a study of the different types of customers that bought our product, and the marketing message that we were using at the time. In just about every case, customers bought our solution for exactly what it did, which was facilitate efficient financial analysis to improve the financial performance of the corporation. Rarely did they buy it due to the grandiose positioning we were using at any given time. In many cases, we drew false conclusions about the effectiveness of our sales and marketing programs as it related to revenue because we didn’t look closely enough at why customers were buying our product. Customers needed something simple, but effective, and the customers that understood what the solution was truly capable of bought the product for exactly that purpose. We ended up spending a lot of money on “marketing spin” for a product that was so simple and basic in principle. It was a big mistake.

The lesson learned in all of this, and my advice to people considering a startup is very simple. Know what you do well, accept that, and create your sales and marketing programs that exploit that. Don’t try to be more than you are. At the end of the day, grandiose positioning may get you in front of more customers, but the sales people need to be able to understand what you do well and position it appropriately. If the marketing message doesn’t match what the sales people need to sell, you end up training them on a lot of positioning that does not help them more effectively sell your products. It takes a lot of intestinal fortitude to accept what you do well, and position it in a way that it can be effectively sold. If you try to over-position what you do, it just confuses not only your sales people, but also the customers that are considering whether to buy your product or not.

People Matter

I thought it would be best to start this chapter with an analogy about people. Many of my friends and family are familiar with the fact that I'm a big fan of military books and movies. My favorites are the ones that are based on a true story. Part of my interest has to do with how military personnel are able to survive in some of the most extreme circumstances in the worst of conditions. I am amazed at what some of these individuals have endured in order to protect the freedom that we have each and every day.

One of my favorite movies is "Black Hawk Down". The storyline is fairly sad when you reflect on it. What was supposed to be a simple capture of a military leader in Somalia turns into a disaster after a series of unfortunate events. However, what I find most interesting throughout the movie is the dedication that each member of the armed forces has to other members. Whether it be a close friend in their own squad, or even a member from another squad they don't know, there is dedication to helping each other in some pretty dire circumstances. No matter how dangerous things got, each member of the military wanted to go back out to make sure that everyone got back to the military base safely. Unfortunately, many men didn't make it. However, there were some really remarkable events and feats of heroism throughout the movie. One of my favorite characters in the movie is a character named "Hoot". He is completely fearless, dedicated to his job, and has a very subdued attitude about death (i.e. sh*t happens). Anyway, near the end of the movie, he's getting ready to go back out to save more men when he runs into someone else while eating quickly. His line goes somewhat like this: "When I go back home and people asks me 'Hoot, why do you do it? Are you some kind of war junkie?' I ain't gonna say a god damn thing. They won't understand. They won't understand that it's about the man beside you, and that's all it is..." He then leaves to go back out and find more men. This hits me every time I watch the movie because it's a pretty simple equation. I think people in a startup in the early days are in the same situation. You're all working to achieve something, but at the beginning, all you have is each other. Each and every day you get up and go to work at the startup, it's about the goals of the company, and the people working beside you, and that's all it is.

This leads to the first non-historical topic of this blog that I think is important to cover. It has to do with people. There are a lot of challenges finding the right people when you're in a startup, and when you do find them, setting appropriate expectations. Startups are not easy, and not everyone is cut out to be part of a startup. Some people seek jobs at a startup thinking that they are ready for the freedom and challenge, when in reality, it's just not the case. Also, a hiring mistake at a startup can be catastrophic if there's not a good fit, especially in the early days of the startup where each new person you add brings something important to the table. When I reflect back on our hiring at DecisionPoint, there were definitely a couple of different lessons learned.

My first lesson had to do with mistakes that I made in my expectations of myself and others that came into the organization. Being the founder of the company, I was often the most passionate person about what we were trying to accomplished. I worked many long hours at it because I enjoyed it, and I was passionate at what we were doing. For my entire career, I was a driven individual able to accomplish some pretty amazing feats regardless of the odds. I was an adrenaline junkie. The more stressful and exciting the situation, the harder I would work to deal with it. As stated earlier in the blog/book, I won some pretty fantastic awards as a result of the drive and energy. However, there was a down side to all of this. I had several instances where I ended up in the emergency room for lack of sleep, general fatigue, chest pains, and a body on the verge of physical collapse induced by high levels of stress. I would say that I am far more balanced today, but like any addiction, I always have to be careful about over doing it. If I'm not careful, the next stop at the emergency room is right around the corner.

Probably more importantly was that I carried my expectations of myself, and attempted to measure other people that joined the organization according to the standards and expectations I had of myself. This was a key mistake on my part. As seen above, I could barely keep up with my own expectations. How could I possibly expect others to live up to those same expectations? The bottom line is that those expectations were unreasonable not only for me, but also for the people I worked with. Those expectations did cause a lot of chaos and conflict when I was working with other individuals within the organization. People who had a more balanced approach to work didn't have the drive or stamina that I had, and it was frustrating to me when they were unable to step up when needed. I think everyone in a startup has times when they need to step up and push through a large challenge. However, expecting people to be able to do this all the time is not a very reasonable position to take.

My lesson here is balance, both with myself and with others...

I was such an adrenaline junkie that I honestly believe that some people that joined the organization thought I was truly nuts. The other part of that was that the highs were really high and the lows were really low. I willingly let myself ride the roller coaster of every success and failure, which there were many of both. For me, trying to get off the roller coaster and get more balanced felt like getting off to get on one of the kiddie rides at an amusement park. Just not something I was interested in. Only now, with the chance to reflect on things can I honestly see how destructive this was on my own physical and emotional health. Even today, I suffer bouts of severe depression when a series of negative events happen, yet also experience bouts of mania when things are going well. As I continue to work at taking a more balanced approach to work, it's a daily struggle that I wrestle with much like an addiction to drugs.

When it comes to other people, I still struggle with my expectations of people I work with. Especially in a larger organization where things move a lot slower than they did when we were a startup. I haven't found the right answer to what is appropriate to expect of others. In a startup, you have to make it very clear that the person joining the organization is probably going to have to work harder than they ever have at any other job. And while that is the case, that doesn't mean that you can expect them to just keep going and going for long periods of time. Part of it has to do with setting proper expectations with individuals up front about what they need to do. The other part of it has to do with ongoing expectation setting and communication so that if something changes with the individual or the company, appropriate adjustments can be made.

We had many instances at DecisionPoint where we missed when setting expectations with people joining the organization. As a result, some left only after a couple of months while others stayed on board and remained miserable for the time they were with the company. Neither is a healthy situation. With some better communication and expectation setting, we probably would have done a better job in this area. We had situations where it was an individual's first attempt at working at a startup. The individual was very good at what they did, but just didn't have the stamina required to succeed in a startup. They were used to larger organizations where projects and plans had reasonable goals and expectations. They weren't ready for an environment where projects and plans had to be done much faster and required more persistence and endurance at work.

As I look back at what we could have done differently when it came to interviewing and assessing candidates to join the organization, a couple of things come to mind.

First, I think it's a good idea to get a perspective on the projects that a person has worked on in the past. If the projects were fairly aggressive and of critical importance to the organization they were working for, then the person was probably ready for the startup. If the projects were fairly conservative with many delays and "re-plans" the person was probably not ready for the startup. In a startup, delays can be disasterous, and you need people who are not used to working on projects where delays are the norm. They need to have worked on projects where the deadlines don't move, and you have to push yourself at times to meet the deadline.

Second, has to do with a person's expectations regarding salary and rewards. If the person is used to getting good pay and consistent raises along with bonuses upon successful completion of projects, they're probably not a good fit. In a startup, you get paid a salary (in most cases), but the concept of raises and bonuses is foreign. Generally speaking, the only bonus you can get are stock options. However, unless the company goes public or gets sold, the stock options are about as useful as a piece of toilet paper. It can take years before the stock options are worth anything, and in far too many cases, the stock options end up being worthless. People that work well in a startup are those where they get a base salary and bonuses are a "nice surprise" to them.

Third, is a much more controversial topic because there are a lot of legal repercussions associated with this information. As much as you're not supposed to do it, it definitely helps if you can get an assessment of an individual's personal situation. If a person has a new home, kids in college, or anything else that has a consistent financial obligation to it, they're probably not a good candidate for a startup. There is always a chance that the startup runs out of money and misses payroll. Individuals with significant financial obligations can be put under severe stress when these events are looming, even if they never happen. Imagine how much stress a person might go through if they don't get paid once or twice and they fall behind on their financial obligations. Obviously, this is a situation that almost anyone can face. The difference is in how well prepared the person is to handle the situation should it happen.

The last part of this blog entry centers more around ongoing expectation setting rather than trying to hire someone. Many people have worked for larger companies where the expectation of their role in the organization is well known and understood. In a startup, things are constantly changing, which causes roles and responsibilities of individuals within the organization to change on a regular basis. It's important that regular communication happen so that people always know where they stand, and what's expected of them.

There may be situations where you feel an individual is not meeting your expectations. In those cases, it's best to ask yourself "have I clearly communicated my expectations, along with any adjustments in those expectations I make?" In many cases, you'll find the individual isn't meeting your expectations because you failed to communicate the expectations to them effectively. I have had many situations where I've done this well, and many where I have not done it so well. Where I have not done it so well, it was usually the case that the individual would have been more successful if I had communicated my expectations more clearly. It's sad when you lose someone who could have been very good if they had just better understood what was expected of them. However, you also need to be realistic that some people can't handle regular change in expectations no matter how well it's communicated, so there will always be those cases. For those individuals, a startup is probably not a good choice.

One last point on effective communication of expectations. It's vital that you have regular voice to voice communications with people to make sure they know where they stand. The communication should not be electronic, such as email or text messages. Too many misunderstandings happen with that type of communication. It needs to be voice to voice where questions can be addressed and confusion cleared up. This is especially true in today's world where teenagers and young adults are used to using their cell phone more often for text messages than for voice to voice calls.

Chapter 9 - Parting Thoughts

As I sit here today typing this, I continue to work for the company that acquired DecisionPoint, pretty much doing the same thing I’ve been doing since I founded DecisionPoint, back in 1996. So, it’s been roughly 14 years from the beginning, and the journey continues even though we are part of a much larger organization that has a much wider variety of product offerings. As I reflect on the experience, there were a lot of ups and downs, and a lot of positives and negatives. Has the experience made me better? Yes. Has the experienced aged me quicker than I had hoped? Probably. However, as I reflect on what has happened, I feel good about what we tried to get done and how we tried to do it. It would have been far easier for everything to go well and for every decision we made to be the right one. However, I wouldn’t have learned as much as I have, and wouldn’t be where I am today without the experience.

I started writing this with the title of “What Happens When Your Best Isn’t Good Enough?” While some would argue my best was good enough because DecisionPoint had some success and was eventually acquired by a larger organization, which has extended its life, albeit in another form. To that, I would agree. However, when I reflect back on my original goals, we weren’t necessarily as successful as I had hoped we would be when I started this journey. I guess what I am saying is that no matter how much I tried or how hard I worked, things were just going to happen the way they did. Does that make me less successful? No. What I learned from this experience is that sometimes your best isn’t good enough, and that has to be ok. You can only do what you do, and things will play out however they do. What you have to feel good about is that you did everything you could, and you did it in a way that was honorable and respectable. If we had been more successful, like going public, but I compromised my ethics and morals, I doubt I would feel good about it. To me, that’s not success. That’s cheating the system. I’d much rather be less successful financially and still be able to hold my head up high, and today, that’s where I am.

The remaining chapters of this blog will cover what I consider to be critical success factors when starting a business along with the lessons that I learned along the way.

Chapter 8 - Acquisition Is Our Last Hope

Going into the New Year, we got a piece of bad news from our venture capital investors. We found out that they had taken their investment in DecisionPoint as a loss, also known as a write-off. Basically, they were saying that they didn’t think DecisionPoint would succeed, so they were no longer counting on making money from that investment. At their request, DecisionPoint was to be sold to another company. The challenge was that since our venture capitalists had already written off their investment in us, we had little leverage when it came to how much the acquiring company was willing to pay in order to acquire DecisionPoint. This was a tough one for me to accept as I thought our company was worth a lot more than other companies were willing to pay. However, we just didn’t have a strong position in the negotiation.

The challenge that we had during the acquisition process was that we had to keep it quiet, so only the management team and a few select other individuals knew what was going on. Most of the employees were not directly aware of what was happening, which is how we wanted it, so they stayed focused on the task at hand rather than giving up and waiting for something to happen. It was personally very difficult for me to be in this situation as I had close relationships with a lot of the employees, and it hurt me to not be able to tell them what was going on, especially given that my travel to the Bay Area had significantly increased. While I really wanted to talk about it with everyone, I didn’t. It was difficult as there was a part of me that felt that I was lying to them, even though I really was not.

There were several organizations that expressed interest in acquiring DecisionPoint, and we had several different meetings with each organization. However, when it came down to it, there were two organizations that were seriously interested in acquiring DecisionPoint. One was a software company, which I thought would be the more likely acquirer. The second was a hardware company that had purchased several software companies over the past years, and was looking to add DecisionPoint as part of that portfolio. After a series of meetings and negotiations, it turns out that it was the hardware company that ended up with the highest interest in DecisionPoint, and eventually would be the company that acquired DecisionPoint.

During the acquisition process, there was a lot of activity once the final decision was made by the company to acquire DecisionPoint. There was investigation into the software being used along with quality information. There were interviews with existing DecisionPoint customers to make sure that we were doing everything we said we could do. There were also discussions about which employees within DecisionPoint would continue on with the new company, and which ones would be let go. I was officially part of the management team, and I was the only member of the management team that would be asked to continue with the new company. Everyone else was given what I call the “paid to go away” contract. They all made some pretty good money just to go away and not come back. I did get a nice job with a good salary and some extra benefits like stock options in the new company. I also got a small amount of money from my DecisionPoint stock as part of the acquisition. It wasn’t nearly what I hoped it would be, but it was more than zero, so it was still pretty good.

Chapter 7 - Another Management Team, Another Set Of Ups And Downs

When the new CEO started, it was clear to everyone in DecisionPoint, he knew what our strengths were, and where we needed to go. He had formerly worked for a company that DecisionPoint competed with and knew the market quite well. He backed away from the end user access tool strategy of the previous CEO without completely leaving the market, and re-focused the organization back to our original product line. Additionally, the new VP of Engineering was going to work on re-organizing the engineering organization to align with the new direction and priorities. There was a renewed focus and energy all throughout DecisionPoint, and we were once again optimistic about where we were headed.

Both the new CEO and VP of Engineering were from the Bay Area, and they had no intention of moving to Portland. They wanted to establish a base in the Bay Area, but all of us that were based in Portland would be able to stay in Portland. There was a twist to this early on. We had three key engineers working in Portland, and they had spent the last couple of years working on the end user access tool. Originally, the new VP of Engineering wanted to re-establish the base of engineers in the Bay Area, and convert the three engineers in Portland to implementation resources. I knew that this would be a mistake as they represented the core of DecisionPoint’s collective engineering experience, and that if they were moved from engineering they would eventually leave. I fought hard to keep the three of them in engineering, but ended up settling for having two of them stay in engineering with the third moving to implementation. As expected, the third engineer left shortly after his first customer implementation assignment.

The VP of Engineering also brought in one of his former colleagues as an engineering manager. This individual split his time between Portland and the Bay Area for a while, but his assignment was to start building out the engineering organization in the Bay Area. The engineering manager was quite good at both people and project management, and he was very much a realist when it came to schedules. Also, he already came with the respect of the VP of Engineering, so he was able to accomplish a lot of things to solidify the engineering organization. When we released the end user access tool, it was clear that there were some quality issues, so the first goal of the organization was to clean up all of the quality problems and establish a more rigorous testing of our products before they were released. The engineering manager was pretty picky about the people he hired, and shortly after he came on board, he found two good engineers for the Bay Area office. The goal was to transition some of the responsibilities of the three engineers in Portland down to the engineers in the Bay Area.

The first product to be transitioned to the Bay Area engineers was our original product line, which I have called “plumbing”. This represented our oldest and most stable product line. The technology was a bit dated as the server code was written in C and the client code was written in C#. Additionally, the C# implementation had been done several years prior by engineers that were learning C# as they went. This meant that the client code needed a lot of cleanup and fine tuning. Also, the server code was to be converted to java in order to bring it up to the latest technology. Overall, the transition of the older product lines to the Bay Area engineers was relatively smooth. They handled the transition, conversion, and cleanup quickly, and customers that upgraded to the new code had a seamless transition.

The bigger challenge was how to resolve the quality issues that we had with the end user access software we had built and released. Again, with hindsight, the product was probably released prematurely. We did a lot of unit testing (testing individual pieces) on it, but there wasn’t a lot of integration testing (testing of how things worked together). Plus, we probably should have classified the initial release of the software as either an alpha or a beta rather than production quality. The goal was to get this tool up to the same production quality as the rest of the product line. So, the two engineers left in Portland were assigned the task to do that. Additionally, another engineer had been hired in the Bay Area to help in this area. The challenge would be getting this engineer up to speed quickly. As stated previously, the end user access tool was very complex, and was built using a lot of new concepts and technologies. So, getting any new engineer up to speed on it was going to be a difficult challenge to say the least. We did manage to get the third engineer in the Bay Area up to speed, but it took a lot longer than any of us had anticipated.

Turning back to the sales and marketing side of the equation, we were making real progress. The new CEO came on board with a lot of marketing experience, and he managed to retain our existing VP of Marketing from his predecessor. The goal was to spruce up and improve upon what we already had. He also retained the VP of Sales, so we had some continuity in our sales force as well. We were heading into a new year with a new attitude and new motivation. Our first quarter ended up quite well, and we hit our sales targets. Even better, we hit our sales targets for the second quarter after only being two weeks into the quarter. This was thanks to a large order from a company in the UK. We had done business with this company in the past, but our UK team persisted for close to two years with the customer, and ended up significantly growing the number of products we were selling the customer, as well as, growing the number of different divisions in the customer that were using our product. Out of all of our time as DecisionPoint, this is probably the best success we had experienced in the shortest timeframe. It was also at this time that our venture capital investors decided to give us another $5 million dollar investment.

With the revenue growth and the additional venture funding, we started to grow the business again. However, this time around, we were a lot smarter in how we were growing the business. We had a sales, marketing, and product plan that were in place, and our goal was to add people that would allow us to better execute that plan. Unlike other growth spurts, we weren’t heading in a lot of different directions at once. We simply wanted to execute what we were doing better and faster. It was working well as we finished the year very strong, and were able to have our first official sales reward trip for sales people that exceeded their quota for the year. It was quite a good feeling, and I was feeling like the people that we were adding to the organization were high quality. A lot of things were moving in the right direction for us, and it felt good.

Shortly after we returned from the sales trip, we realized that we were up against our first hurdle with the new management team. We were staring at our first quarter of the new year wondering where the revenue was going to come from. We had a lot of customers in our pipeline, but the question became how many of them would buy something before our first quarter would end. It became a real challenge with a lot of sweating from all of us as customers we thought would buy in the first quarter ended up holding off on their purchase until later in the year. We did manage to find a large retailer that we were able to get closed by the end of the first quarter, and it helped us make our sales target for the first quarter as the deal was quite large.

We were hopeful of the second quarter given the number of customers that had deferred their purchase from the first quarter. However, as the second quarter approached, things were not looking good. Again, there were a lot of customers in the pipeline, but nothing that seemed imminent to be closing. As the second quarter came to a close, we missed our sales targets badly. The management team got together to come up with a plan for how to avoid that from happening again. There were some ideas that were thrown out, but we didn’t have a lot more that we could do other than close deals faster. We did offer our sales people some additional incentives, and even extended some discounts to customers. However, both of these had limited impact on our sales, and we would close the year significantly short of our sales targets.

As we were winding down the year, several employees decided that our future looked unstable, and that they were moving on to other companies. It was a difficult thing for me to accept as we had hired a lot of good people. However, the fact that they were good made them appealing to other organizations that were having more success. So, I really couldn’t blame any of them for wanting to leave. It was just a result of the situation, and there wasn’t a whole lot I, or anyone else could do about it. It is what it is as they say.

Chapter 6 - A New CEO and a New Product Frontier

We had trimmed back, and our board of directors was well on its way completing the search for a new CEO. Along with the new CEO, it was decided that we could use a new round of funding. So, they were looking not only for a new CEO, but also one that would attract additional venture funding. One of the requirements of the new CEO was that they needed to be someone that not only started a company, but also was able to see it through until the company went public. We, at DecisionPoint, weren’t necessarily looking to go public, but we were looking to some sort of outcome whether it be going public, being acquired, or another positive outcome. The board of directors did let us interview the final candidate, but it was more of a formality than anything else. They would end up making the final decision unless there was something concerning about the CEO. There weren’t any major concerns so we moved forward hiring the person.

The first assignment of the new CEO, as stated above was to find additional financing from venture capitalists. Through this process, I did get to the new CEO quite well. He was driving the process, and I was the main technical resource that could explain what we were doing and how we were doing it. The new CEO was based in the Bay Area as were the venture capitalists we were talking to, and the rest of us were in Portland. So, there were a lot of trips between Portland and the Bay Area for me as we had the meetings with each venture capitalist. The meetings were the typical meetings where the venture capitalists are most interested in how you’re going to make them money in the fastest amount of time you can. Technology is typically a sidebar conversation that happens after the money discussions. As a technologist, it was frustrating as you wish the people investing in your company would take a bit of time to understand what you do and how you do it. However, that’s not the way “the game” works, so you just have to go with it.

At the end of the process, we were able to get an additional $5 million in venture funding, which was a good amount of money. We continued to do what we do in all areas until the new CEO had formulated a plan for how he wanted to move DecisionPoint forward. This is where things got a bit complicated, which I will mention here briefly, but cover in a lot more detail in another chapter called “Regimes”. With each new CEO that took over DecisionPoint, they would always bring in some of their “trusted staff” from previous companies they have worked with. Sometimes this works, but in a lot of cases, it causes a lot of friction. The friction is that the new people have the CEO’s ear, and may have a much different perspective on things than existing employees. Resolving disagreements between the two groups of employees is absolutely critical. You can’t let things fester. Unfortunately, our new CEO let things fester in a lot of different areas hoping that things would resolve themselves. That just never happened.

One approach that the new CEO had was to bring in executive level “trusted staff”, and then let them build out the organizations the way they felt would be best. There were some individuals already in these positions, such as myself, but there were a lot of new faces also. This created quite a bit of chaos within the organization as there was a lot of confusion amongst DecisionPoint employees about why we were becoming so top heavy with management. Also, many of them were worried whether they would fit in with the plans of the new management team. Generally speaking, everything was resolved fairly quickly, but there were some employees that did end up leaving DecisionPoint as they discovered they weren’t in the long range plans of the new management team. For me, it was sad as there were quite a few people that I had worked with for a couple of years, and it was tough to see them go. Like always, I soldiered on even with the changes.

There was one radical change in product direction that would come about as the result of a combination of events. Traditionally, DecisionPoint had focused on simplifying complex data so that end users could use it to analyze the business. We were always focused on what could commonly be called “plumbing”, which was the process of getting data out of source systems and into a useable format. There was another part of the equation that we dabbled in, but never made a serious effort at participating in. This area involved providing tools for end users that made it very easy to access the data that we had simplified. We always stuck to our “plumbing”, and left it to other software companies to provide the access tools.

Our CEO had come from a company that he had started, and his specialty along with the other members of the management team that he brought on board was creating the access tools. Additionally, DecisionPoint had a couple of talented engineers that were interested in doing something new. They were growing tired of continuing to work on making our “plumbing” better. So, with the new CEO and his staff along with a group of engineers wanting to do something new, a decision was made that DecisionPoint would go full force into the market of access tools by building our own.

In hindsight, this probably wasn’t a good choice for a lot of reasons. There were a lot of other companies already in that space of the market and we were roughly starting from scratch. It would take a Herculean effort for us to build a product that could adequately compete in that market. Probably more importantly was that this direction caused chaos and confusion in our customer base. Our existing customers weren’t necessarily interested in buying an access tool from us as they already had one they were using. So, they were naturally concerned whether this new direction would significantly hamper our ability to improve the “plumbing” products that they bought from us and were so dependent on. It wasn’t as big of a disruption as I thought it might be, but we did lose a couple of customers that decided to do something different when their maintenance had expired and was up for renewal. This also created a bit of a rift in the engineering organization as there was a clear division between those engineers working on the new direction with the access tool, and the engineers that continued to work on the base product that we had been selling for years. There were a lot of internal conflicts and a lot of undercurrent within the engineering and product management organizations as the result of this, and it was never dealt with or managed properly.

We continued to sell our existing product line with moderate, but not great success. We did close a couple of important deals with new customers, and even had some add-on business that we did with existing customers that decided to buy additional products from us. However, we never really took off like we thought we would. Part of it had to do with the confusion for customers between what we were selling (the existing product), and where we were going (the new product – access tools). Another part of it was that we were seeing more competition than we had in the past. Existing software companies and new companies were starting to creep into our space with new and different products. None of them really could do what we did as well as we did it, but they were able to confuse the market a bit and appear as they were a better option than what was available from DecisionPoint. It was fascinating and frustrating to me that these companies could appear to compete with DecisionPoint from a marketing message perspective, but did not have nearly a complete a product as we had at DecisionPoint.

As if things weren’t as chaotic and confusing enough, I had a personal event that contributed to everything else that was going on. While playing soccer as a goalkeeper, I ran out to make a save, and when I bent over to pick up the ball, my hip socket popped. It’s a very long story, but I had fractured my hip socket years prior to that, and as time went on, the hip socket would re-fracture and the fracture would fill in with scar tissue. So, even though what I was doing on the soccer field was something simple I had done over 100 times before, the hip socket finally completely gave way. I was taken to the emergency room and admitted to the hospital where they conducted several xrays, cat scans, and MRI’s. Late in the day after I was admitted, my wife Leslie and I met with a doctor we thought would be performing the surgery to repair my hip socket. He gave us the news that there was a lot of scar tissue in the fracture and he wasn’t sure what it was. There was a chance it was nothing, but there was also a chance it was bone cancer. I was being transferred to another hospital where I would be under the care of one of the top bone oncologists in the area. Leslie was devastated by the news, and I was too drugged up on pain killers to really understand the seriousness of what was going on.

Things got even more complicated as I was scheduled to be transferred to the new hospital and the doctor was waiting for me, but the new hospital didn’t have a room to put me in. So, my only option was to lay and wait and think about all of the different possible outcomes. I tried to push it out of my mind, but when you’re potentially facing something as serious as bone cancer, you have a lot to think about. It turns out that I was in the original hospital for about two days before I could finally be transferred. My kids, Andrew and Becca, were in 8th and 5th grade respectively, and they both played competitive soccer. So, Leslie had to deal with a lot on her own. Fortunately, she was working at the local elementary school part time, and they gave her the time off she needed to deal with things. We also had some fantastic friends that helped take care of our kids and get them where they need to be when they needed to be there.

In the end, I had the surgery and the scar tissue in the bone was not cancerous. I do have a 13 inch scar along with a plate and six screws behind my left hip socket as a result of a bone graft along with the repair of the hip socket. From start to finish, which when I started walking around again, it was about eight weeks of recovery. In some respects, it was like I was taking a forced sabbatical from DecisionPoint. I remained in contact with different employees within DecisionPoint to stay in touch with what was going on, but I was given a temporary break from the day to day activities. As I reflect on it, while the hip socket injury was pretty traumatic, it couldn’t have come at a better time. There were a lot of changes and associated chaos within DecisionPoint, and I had been with the company since the beginning. Having a forced break from it probably helped me keep my sanity so that I could stay with DecisionPoint.

While I was away, the engineering team working on the new end user access tool had made significant progress on the product. I returned in time to witness the completion and release of the new end user access tool. We had a couple of customers that bought the tool, and continue to use it today. Generally speaking, it was successful as a product. However, it was a very complicated product based on some brand new technology in the market, and we built a lot of different features and functionality into it. As we started to install it at different customer sites, there were several problems that we had to work through. It was a lot more complicated than anything we had built before, and therefore, required a much deeper level of implementation and customer support than we had planned for or had experienced with our other products. Additionally, there were very few engineers that understood the entire product as many of them had been working on individual pieces with only a few working across all of the pieces.

There was a big lesson learned from this experience. As I said before, we were entering a market where there was already a lot of stiff competition. So, not only did we have to build what we thought was needed, but we also had to build something that would allow us to adequately compete in the market. Additionally, our engineering team was quite small with about 10-15 people compared to our competition, who had hundreds or thousands of engineers working on their products that were equivalent to ours. We also dramatically expanded the number of users for our product at each customer site. With our “plumbing” product, we had one or two IT administration folks at a customer site that worked with our products. With the new end user access tool, we would suddenly have hundreds of users that were using our product. Both the depth and breadth of our product and types of users had greatly expanded with the release of the end user access tool. This caused quite an additional burden on our implementation and customer service staff, and they were not quite setup to handle the change in their world. However, they did the best they could and managed to maintain a high customer satisfaction level in spite of everything that was going on.

In the sales arena, we had done some additional customer business, but we were sort of at a plateau. With all of the changes in the product line and marketing messages, the sales teams had a tougher time selling and communicating to customers exacting what our product did for them. We made a technology decision to venture into a market we had not spent a lot of time in before without thinking about the repercussions on our marketing, sales force, or even our customers. This is pretty typical of what happens when you make technology decisions without thinking about the downstream or long term effects on other parts of the organization. The new product line wasn’t directly responsible for our stall in sales, but it was a contributing factor. What turned out to be a good outcome in engineering was not the case for the rest of DecisionPoint.

It was around this time that the venture capitalists that gave us the $5 million started to send in some people to “snoop around”. This is somewhat typical for struggling companies. When a company is struggling, the venture capitalists will find someone that understands the product and the market you are working in, and have them do an assessment of where things are at. This is the first warning sign that the venture capitalist is concerned about things, and may be looking to make a change. We had two guys come in to look around, and they were both very sharp and understood the market very well. A lot of different people spent time with them, but I spent the most time with them getting them up to speed on our products, what markets we were in, and what I thought we should be doing moving forward. I had several very good meetings and interactions with both individuals and came away impressed with both of them.

What I didn’t understand at the time is that the venture capitalists had pretty much already decided that our CEO was not doing a good job, and it was the job of the two individuals to help decide DecisionPoint’s fate. There was a chance we could be shut down, a chance we could be sold, or a chance that we could give it a go with a new CEO. It turns out that both individuals felt we had a viable business, and recommended to the venture capitalist that we continue to try. It also turns out that these two individuals would join DecisionPoint in prominent roles. One would become our CEO, and the other would eventually join as our VP of Marketing after a short stint at another company.

Throughout this process, there was an interesting dynamic going on. We were scheduled to have a board meeting, and the member of the venture capital firm responsible for managing their investment in DecisionPoint was flying up the night before, which was unusual. He usually flew up the day of board meetings. Something didn’t seem right. Our existing CEO was in the process of hiring a new VP of Engineering, and had finalized his decision on the person he wanted to hire. Also, sensing that something was going on with the two individuals “snooping around”, our existing CEO decided we should have a layoff to reduce expenses. So, we had the layoff the day before the board meeting, and our CEO was fired at dinner with the member of the venture capital firm later that evening. The next morning, everyone arrived at work to see the existing CEO pack up his desk to leave, and see the two individuals show up at the board meeting where one of them was introduced as our new CEO. Everyone knew that something was up, but this was a lot more dramatic than anything we had anticipated.

There was a bit of a shock within the organization, and it would take a while for all of the changes to sink in. However, after watching the management team dramatically grow and then shrink under our existing CEO, it was clear a change was needed. Our existing CEO was a nice guy, but after he was let go, we all seemed to agree it was the right decision. A lot had happened under his leadership, and so there were a lot of things we had to clean up and deal with. Fortunately, the recovery wouldn’t be as painful as we had anticipated. And, as it turns out, the person who was hired by the existing CEO as the VP of Engineering decided to stay with DecisionPoint even after the change in CEO’s.

Chapter 5 - Progress and the Ups and Downs of Growth

DecisionPoint had just experience what could be called “strike two” in its attempt to get off the ground. First, a large company had decided not to acquire DecisionPoint. Second, a management team that was hopeful in taking over and running DecisionPoint had to back out because of lack of exclusivity they felt was needed to solidify the market for DecisionPoint’s products. Up until this point, I had remained fairly optimistic that we could make a go of it. However, after the second strike, doubt started to creep into my mind. Could we find the right management team? Could we secure appropriate financing to give us the start we desperately needed? Or, would we have to become yet another startup that failed to get off the ground? These were all questions that ran through my mind on a regular basis. I certainly had a lot of doubts at the time.

While DecisionPoint was going through several ups and downs, there was another side story going on at Sequent that DecisionPoint would eventually benefit from. One of Sequent’s first individuals to get involved in the marketing and partnerships in the data warehouse space had decided to leave Sequent to take his career in another direction. About the time the management team backed out of running DecisionPoint, this individual decided that leaving Sequent and the data warehousing market to pursue a new career was a mistake, and he wanted to return to what he loved doing. One of our angel investors had maintained contact with that individual, and when that individual decided he wanted to return to data warehousing, our angel investor hooked him up as our next CEO.

This individual not only knew the market we were in, but was well known as a creative thinker with innovative ideas within the data warehousing market. Additionally, he was a very dynamic speaker and presenter, which would help DecisionPoint get into places we had not been before. In many ways, I was relieved when this individual came on board. While I didn’t always agree with his decisions and actions when he was part of Sequent, I knew he would bring a lot of value to our team. I finally felt I would not have to be the only one to carry the torch for DecisionPoint to people outside of the company.

Our first mission, once this individual came on board was to start ramping up the process of selling DecisionPoint. Sequent was becoming impatient with our inability to sell to more customers even though we were going through a very rocky period. Sequent wanted signs that we could make a go of DecisionPoint by proving that we could close some new customer accounts. The push from Sequent was natural, but it also complicated things for many of us on the team. We didn’t have a whole lot of formalized collateral on the product, we didn’t have a formal pricing strategy on it, we didn’t have the appropriate legal contracts in place, and we had no sales proposal process along with the related documents. We were going to have to build a lot of this on the fly, and a lot of it fell on my shoulders as I was in the best position to understand the product along with the customers, which meant I had the deepest background on how the documents should look to customers. Fortunately, Sequent gave us a lot of help and support in this area, especially with legal agreements and contracts, which we could have never developed on our own.

The good news is that we had made some early traction with three large retailers, and a service based company. We were coming to the end of our fiscal year, and we desperately needed all four deals to close, and they did…literally on the last minute of the last day of the year. Two of the retailers were fairly simple to close as we made connections via the Sequent sales force. That’s not to say it was a completely done deal when we were introduced to them. We had a lot of work to do to close the deals. However, having the initial introduction and contacts made for us was a big head start.

We were able to gain access to the third retailer via an IT person that I had worked with at Sequent, who had left Sequent to go work for the retailer. He made the initial introductions for us, and we were able to make the right contacts within the account in order to make several presentations. At that time, that retailer’s information technology (IT) department was very distributed, which worked to our advantage. Many of the groups within the retailer didn’t have the money to buy our solution. However, a group out of the Canadian operation had a manager that was desperately looking to be the first to do something new within the retailer and he was pretty creative with the whole budgeting/financing process. He would be the first to implement DecisionPoint, which would lead to a global site license of DecisionPoint with the retailer. Eventually, DecisionPoint would be implemented at fourteen different sites within the retailer. The site license deal was a steal for the retailer and we desperately needed the business. Hindsight being 20/20 once again, we should have negotiated a better deal. But, given where we were at, we didn’t have a lot of time to negotiate and the retailer used that to their advantage.

The service company was a bit of a surprise for DecisionPoint as we didn’t really have connections into that company. However, a driven sales team in the Midwest (Chicago) pushed into the company and made enough progress to give the customer confidence in our ability to deliver. The company had a fairly small operation, so the amount of money they would have to spend for the DecisionPoint software was at a level that would not draw any attention if the implementation of DecisionPoint failed. So, they were able to take a small risk implementing software from a very small software startup.

Our CEO and I put our heads together and came up with a bold sales and marketing strategy about the same time all of this customer activity was going on. A typical data warehouse implementation was often categorized as “2-2-50” by analysts in the data warehousing industry. The categorization meant that the average data warehouse project took two years and two million dollars to complete, and at the end of the project, there was only a 50% chance that the data warehouse implementation would bring any level of benefit to the business. That was a very high risk proposition, which caused many companies to not even consider a data warehouse implementation.

DecisionPoint was built with a full set of integrated data warehousing tools along with the concept of pre-configuration of the data warehouse, which was unheard of in the industry. We called this concept a “Source Expert”. We had determined that by targeting our data warehouse solution at customers with specific source applications, we could pre-configure 75% of the data warehouse for those customers with minimal implementation effort and before we ever stepped on the customer site. However, we took this one step further. For the 25% that could not be pre-configured, we came up with software that would read how the source application was configured for the customer, and automatically re-configure the data warehouse environment based on the source system configuration. There would again be minimal implementation effort as all of it was done in software.

This capability within DecisionPoint allowed us to come up with two groundbreaking concepts within the data warehousing industry. First, we came up with the concept of a proof of concept where we would implement the DecisionPoint solution at the customer’s site within two weeks. Second, as an extension of the proof of concept, we instituted a try before you buy concept where after the proof of concept, the customer would have several weeks to run and evaluate the solution at which time they could decided whether or not to buy the solution.

As far as the proof of concept goes, we couldn’t have been happier with the results. At the end of the two week implementation, end users at the customer site could start using the solution just like it was a full production implementation. The reason we implemented the proof of concept was because we were completely breaking the mentality of the data warehousing market. Every customer was painfully aware of the “2-2-50” phenomenon, and they were baffled how our solution could be implemented so quickly and completely in a small fraction of the time of any other data warehouse solution available on the market. Our goal was to completely shatter the previous mentality associated with the data warehouse market, and it worked.

The try before you buy concept did not go nearly as well. We didn’t plan well enough, and so we went into many try before you buy situations with a lot of faith that if we did what we said, customers would naturally buy from us. As a result, we didn’t put a lot of rules or legal agreements in place that would bind the customer to buying the solution after we were successful. Additionally, we didn’t charge for the proof of concept or try before you buy program, so it was difficult to differentiate between the customers that really wanted the solution versus those that were just testing the waters. We had a lot of customers back out buying the solution as a result of the try before you buy program even though in every situation, we had successfully implemented our solution for them. It was both a painful and costly lesson. Over time, we would develop more stringent rules for the try before you buy program along with charging the customer for the time we spend implementing the solution and the appropriate legal agreements and commitments from the customer. Even with those things in place, our proof of concept to close ratio was terrible.

At this point, customers that we had closed at the end of the year were starting to complete the implementation of our solution and starting to see real benefit from the implementation. We had some really good success stories, including one of our retailers that started closing unprofitable stores after looking at the financial information that we showed them for their stores. We were only two weeks into the implementation, and the solution had not been fully implemented, but the customer was already using it to make critical business decisions. It was really cool and really scary at the same time. Our solution was working as advertised, but created an interesting dynamic within this retailer as far as how long they were willing to let an unprofitable store recover. It was at that point I realized how cut throat the retail industry was. Profit margins are slim at best, so if there was a store that was not performing, they didn’t have a lot of time to make it profitable and they would close it to stop losing money at that location. Our goal was to help companies make better business decisions to make them more profitable, but it wasn’t necessarily our intention that would be done by scaling down operations so radically. We certainly did not want to be known as the company whose software caused stores to close or get people fired. We would have to fight that image on an ongoing basis from this point on.

By all accounts, things were going well for DecisionPoint. With our new found success, we were starting to attract more attention from investors that wanted to put money into DecisionPoint so that we could grow the business faster. Additionally, we were starting to sell the solution to companies that had never bought software from a startup ever before. These were huge, international, organizations that had a lot to risk, and yet they were taking that risk to implement our solution with hopes it would bring them the same value that our other customers achieved. While the implementations did have some bumps along the way as most do at some point, we were successful overall. At the time, it seemed like nothing could stop us. We were going to take the data warehousing market by storm by changing the game on the established data warehousing software providers and establish a trend that our competition would have a tough time keeping up with.

Many people often say that it’s never as bad as it seems and it’s never as good as it seems. Unfortunately, at DecisionPoint, it was good, but definitely not as good as it seemed. Three critical events would occur that would present a huge problem with DecisionPoint’s ability to grow as a company. The first two events would not necessarily be viewed as negative on their own merit. However, they would contribute to the third event, which would pose huge problems for DecisionPoint’s future.

The first event was that Sequent was in the process of being acquired by IBM, and to IBM, DecisionPoint was like a wart on Sequent’s butt that IBM wanted no part of. While DecisionPoint was starting to become self sufficient, we always had the Sequent backing in the event that something went wrong. IBM was unwilling to continue that relationship. They insisted that DecisionPoint go out and seek additional investors that would provide DecisionPoint with enough operating capital that the relationship with Sequent and IBM could be terminated. This meant that we would have to scramble to find the additional funding. Behind the scenes, we had continued to seek additional investors, but now it was an urgent priority, and we only had a couple of months to get something done.

As an aside to all of this, we did have one very funny event that happened as a result of this process. Sequent had provided DecisionPoint with quite a bit of money to keep operations moving. Additionally, DecisionPoint had brought on a brash new CFO that was a master at managing money. During the negotiations with IBM, at one point, the IBM representative asked what DecisionPoint intended to do about paying accrued interest on the loan that Sequent had provided us. Without even thinking or flinching, our CFO raised his middle finger at the person from IBM, which was basically a sign that if IBM was expecting interest to be paid, it wasn’t going to happen. It wasn’t the most appropriate response in that setting, but it gave us a story that all of us laugh about to this day.

Getting back to our story, the second event that happened was a result of the first event. Because of everything going on with IBM and our critical need to find other financing, one of our angel investors connected us with a large European telecommunications company that was willing to provide financing to DecisionPoint. At the time, it was before companies like telecommunications, cable, and satellite service providers were providing internet service. They were all looking to get into the business, but needed a good first step.

To the European telecommunications company, we represented a way for them to get that first step into what was known as the data center outsourcing business. At a high level, that business is designed so that the telecommunications company would run the computer systems of other companies on a site that the telecommunications company provided and managed. Given that our solution was very fast and easy to implement and support, it was a way for the telecommunications company to get into the business known as outsourcing without having to make a huge up front investment in people and training. They could focus their attention on the computers and facilities, while at the same time implementing a solution quickly that customers would get a lot of value out of without a lot of human costs

This lead to the second event mentioned above, which was that the large European telecommunications company became our first real investor. As part of the investment, DecisionPoint established a partnership with the telecommunications company in the data center outsourcing business. To make things even more complicated, the telecommunications company was running the software that DecisionPoint supported, so they also became a customer. And, over time, they would become one of our largest customers worldwide. Eventually, the partnership in the data center outsourcing business would dissolve. However, to this day, that large European telecommunications company remains one of our largest and most loyal customers. It’s been very interesting to watch the relationship evolve.

As I said before, as a combination, these first two events weren’t necessarily a bad thing. The relationship with Sequent was being ended by IBM, but we did manage to find an investor that would help us continue to do what we needed to do. In fact, if memory serves, they invested close to $20 million in DecisionPoint. A percentage of that money went towards paying off some of the bills we had put on hold during the transition from Sequent/IBM to having our own cash. It was definitely a relief to get those bills paid and taken care of as the vendors were starting to worry if we would ever pay them. Even after that, we still had a pretty substantial amount of money in our bank account.

However, this would lead to the third event, which would become a problem. We were very much in the same situation as a person that was starving, and then suddenly put in front of a large buffet table to eat as much as they could. For a long period of time we had gone along “starving” ourselves to do what we needed to do to stay alive. Now, we were like that starving person. We had all of this cash to do what we had never been able to do before. We had a lot of plans and great ideas that had been on hold, and we wanted to start pursuing those ideas. But again, like a starving person, rather than have a methodical plan of attack, we started sampling a little bit of everything from our “idea buffet”. This lead to a spending spree, and that became a huge problem.

For a long period of time, we had been very careful about the people we had hired. Now, we started to re-organize, and began hiring at a break neck pace. Some of the hires were field sales and consulting resources, which were desperately needed to try and land more customers. However, a lot of the new hires were in the engineering organization. We would come up with a new idea for a new product line, and then hire engineers to build that product line. We did this without any market research into who our competition would be, or what the potential sales revenue would be. We simply believed that if we built it, we could out maneuver the competition, and achieve enough customer sales to sustain the new product line. Nothing could have been further from the truth. We were extremely disorganized, and we ended up with a lot of half finished products that were never sold, and engineers that weren’t necessarily needed.

In the course of a couple of months, we had hired so many people that we not only filled the office space that we originally leased, but we also leased space on another floor in the same building plus another floor in an adjacent building. At the time, it was extremely baffling why we couldn’t complete more products in a faster period of time. But, looking back on the situation, we were again like the starving person at the buffet table. While the starving person gorged themselves on food until they were too full to move, we gorged ourselves on new employees to the point where we couldn’t move in any product direction easily. There were a lot of ups and downs, and a lot of employees that were only around for a couple of months.

We did end up hiring a VP of Human Resources and a recruiter to help get some sanity to how we were hiring, how we were deciding to pay people we were hiring, and many other things. It definitely helped, but was not a cure to our problems. It just brought some organization to what we were trying to do from a staffing perspective. It was also at that time that we decided that we needed to move to a new facility where we could get all of the employees into one floor on one building. It was also at that time that we started to realize that we were spending money faster than we could sustain, and that we weren’t closing new customer sales at a rate that we needed to sustain the spending levels. Our first meeting about cutting spending wasn’t terribly difficult as there were some marketing programs that we could put off, and there were some open job requisitions that we would not hire people for. This seemed to offer short term relief to our fears.

Shortly after we moved into our new facility, things started to unravel pretty quickly. The first event wasn’t necessarily a business event, but was emotionally traumatic. Our VP of Human Resources, who was a man, found out that his breast cancer had returned. I never knew that a man could get breast cancer, but it does actually happen even though it’s rare. He had several previous battles with breast cancer, and beat them all, but this seemed to be a more severe case of the disease this time around. Eventually, he would have to leave DecisionPoint to focus his efforts on his battle with breast cancer. Again, it wasn’t a business event, but it had an emotional impact on the entire organization. He was a wonderful person, and an excellent VP of Human Resources. Unfortunately, he would pass away shortly after he left DecisionPoint. He was a fighter, and wonderful person. A disease so awful should not strike someone who is as wonderful as him.

We also reached a point where we were starting to run low on cash, and our sales weren’t picking up as quickly as we had hoped. We had reached approximately 120 employees at the time, so there was no easy way out of the difficult situation. It became so critical that we were dependent on one customer making their payment on time in order for us to be able to pay our employees. In the management team, there was a lot of nervousness and frustration. No matter how we looked at the situation, we were going to have to layoff employees. This would not be a small layoff, but a significant cut in staff. We had grown so fast, and ended up in a new facility to handle the new staff. Now, we were in the new facility and cutting staff, so we really would have been ok in our previous facility. It was a serious twist in events.

I think of all of the things you have to do as a manager or high level executive, the hardest thing to do is terminate hard working employees for reasons that had nothing to do with them. The only way to describe it is very simply that it stinks. The sole redemption for me was that I didn’t have to personally lay anyone off. It was still difficult as I had formed bonds with most of the employees, and I felt obligated to say goodbye to all of them. They were all pretty good spirited about their situation, but it was still tough knowing that we were letting them go, and they had to scramble to figure out where they were going to go and what they would do next.

We did give ourselves some breathing room as far as cash goes, but we would have to run DecisionPoint in a very Spartan manner. We could only spend money we absolutely had to spend, which meant that we could only spend money related to closing new customer business. Additionally, the DecisionPoint board decided that it was time to start looking for a new CEO. Our CEO did a fantastic job getting us off the ground, but he had limited experience in taking the business to the next level of growth, which was emphasized by how quickly we grew and then shrank again. The goal was to bring in a CEO that had the experience to take DecisionPoint to the next level.

Our current CEO continued on with his role in the company, and did his best to help us move forward. However, we were continuing to struggle in sales and cash was still dwindling. It was clear that we were headed for another round of layoffs regardless of what we did. Eventually, we made the decision to have the layoffs. Unlike last time, I actually had to lay off one of my employees this time. He was a great programmer, who really knew what he was doing and worked as hard as anyone could have asked. It was a painful discussion, and while he understood the reasons, it was still difficult to let him go. He had done everything I had asked and more. After my discussion with the employee and a post-layoff company meeting, I went home to spend some time by myself and contemplate what had happened. I felt absolutely horrible, and like I had let the employees down for not doing a better job with the rest of the management team to prevent what was happening. I still carry some guilt about that today. I look back and think about all of the things that could have been done or all of the different choices that could have been made. I know that you can’t change the past, but I was determined to examine the past and be able to use the lessons from the past as a guidance for how or how not to do things moving forward.

We were slowly skidding towards the end of DecisionPoint, but there was still time to make some changes and get going again, and that’s what we were determined to do.