The first step of getting spun out of Sequent was actually simpler than one might have imagined. Since Sequent was still funding our operations, not a whole lot changed. Most of the changes were pretty simple. We were moved into our own organization, and given office space on the Sequent campus that was somewhat removed from the other organizations at Sequent. We picked up a marketing person from Sequent that was going to start driving us forward from a business perspective. We also picked up our first sales person and implementation manager, who would manage the process of selling our solution, and building a team to implement our solution for customers. Things looked promising as we had a lot of activity presenting to prospective new customers.
From about April of 1996 through July of 1996, we spent a good bit of time going through the legal processes to establish our own company, etc. At that time, we also started looking for our first CEO. There were several candidates, but I think we all felt it would be best to have a CEO come in from outside of Sequent. It needed to be someone that had a background in data warehousing, and was familiar with the market. We eventually settled on an individual who had spent quite a bit of his career with Teradata, a key player in the data warehousing market, and who most recently was working as a data warehousing industry analyst for one of the large IT advisory firm.
The group of us from Sequent had formed a tight bond. The new person coming in was an outsider, which was ok with us, but the transition with the new CEO on board was far from smooth. In my mind, there are two approaches when you are a new person trying to fit in with an existing tight-knit group. The first approach is to use caution, and learn what you need to learn in order to fit in with the team. The second approach is to come in wielding your power, and forcing yourself and your philosophies on the group. Unfortunately, the new CEO choose the second approach, and it represented our first major challenge for DecisionPoint as a company, and myself as a person.
The new CEO made it very clear that he was in charge, and that he was going to “break” our Sequent ways of doing things. That wasn’t necessarily bad, but the process he used was just appalling. They often say that in a startup the toughest decisions you make have to do with people. That was definitely the case for us. For a period of time, the marketing person from Sequent that we brought on had functioned as our leader. Yes, I had founded the company, but my role was to get the software moving in the right direction. The marketing person picked up the more business oriented functions. This person had a lot of respect from the rest of the team, and was well liked. The first thing the new CEO did was to fire the marketing person as he didn’t feel the person was the right fit for us.
The rest of us were shocked and horrified. We saw no reason for the dismissal other than the fact that the new CEO wanted to gain power by taking out the person that had the power. It was the first time I had ever experienced something like this in my career, and I was dumb founded. Being new to the experience, I wasn’t sure what I should do. Do I risk my relationship with the new CEO by confronting him about the decision, and turn my back on a co-worker I admired? Do I let it happen and hope all goes well? Do I have the power in the small organization to stand up for my views? It was all very confusing and disturbing. Ultimately, I decided to let the new CEO do what he felt he needed to do without a lot of resistance. I did voice my disapproval, but did not push things very far. I think part of it was that I just didn’t understand my power or value within the organization. Looking back on the situation, I should have been more confident, and put up a much stronger resistance to the decision the CEO had made. Hindsight is always 20/20, as they say. We did manage to get through that experience, but it would set the tone for the remainder of the new CEO’s tenure.
It was about this time that I faced my first personal challenge related to DecisionPoint. While everything was going on, we had managed to sell to two different customers in the US. I was the only person capable of installing the software to get these customers going. I spent roughly five out of six weeks traveling from my home in Portland, Oregon to both Boston, Massachusetts and Boulder, Colorado getting the customers installed and running our software. From a technical perspective, the software installed and worked well for the customers. However, the frequent travel was starting to take a toll on my relationship with my wife and young kids. It was a horrible sacrifice to make, but in order to get the company going, I had to do it.
In July of 1996, we were officially spun out of Sequent, and the business was starting to move along quite well. One member of the Sequent board of directors decided to invest some of his personal money into DecisionPoint. Plus, the new CEO had managed to convince the CEO of another large software company to invest some of his personal money. By the time it was all said and done, we had accumulated about two million dollars in what is called “angel money”. People that invest their personal wealth in a startup are traditionally called “angel investors”. Hence the term “angel money”. Unfortunately, that money would not last very long.
One of the first steps the new CEO did was to have a team offsite at a resort on Mt. Hood in Oregon. The goal of the offsite was to figure out where we were and where we wanted to go. The new CEO brought in two former associates to help with the meeting. One was a technical person that would work with the engineering team, and the other was a marketing person that would work with the sales and marketing teams. It became clear that the new CEO wanted to bring these former associates into DecisionPoint. We really like the engineering manager, but he wasn’t interested in joining. The marketing person wanted to be part of the organization, but he was extremely abrasive, and treated the rest of us like he was already guaranteed a position in DecisionPoint and was going to start calling the shots. There was a lot of conflict, and it was very clear that no one, including the engineers, like the marketing person. As a group, we expressed our views to the new CEO. While he was resistant to our opinion, he eventually gave in. It was very important that we stand our ground, and we did.
We began to solicit venture capital from different venture capital firms in the Bay Area. The goal was to find some investors that would invest in the company to give us a solid start. The challenge we had was that it was just the start of the internet boom, and what we did was not related to the internet. Unfortunately, the venture capital firms were mostly interested in companies looking to start businesses in the internet space. So, the odds were stacked against us in finding any level of funding. What was frustrating at the time was the fact that we had a business plan that showed a lot of solid growth. Most of the internet startups had a vision, but it was clear that their business plans were fraught with risk and the chances of their survival would be slim. However, the venture capital investors were only interested in making a lot of money quickly. If they invested in an internet company that went public and then fell apart, it was no big deal because they would have already made money on their investment. Their view was definitely long term, so no matter what we said, they weren’t very willing listeners.
We did manage to get pretty far along in the process with one venture capital firm, and got to the stage where they have an independent third party review the your technology. During the meeting with the third party we would have another major hiccup. The meeting included the new CEO, the sales person that joined us from Sequent, and the implementation manager that also joined us from Sequent. Throughout the day there were a lot of questions and answers, most of which were answered by myself, the sales person, and the implementation manager. We had done it several times before, so didn’t think much about it as the day went on. However, after the meeting, there was a huge problem.
The new CEO took offense to our ability to answer all of the questions, and felt that he was either left out or pushed out of the meeting. The bottom line was that he hadn’t been on board that long, so there wasn’t a lot he could answer in a technical meeting. He started to berate the three of us for taking over the meeting and keeping him out, which we never intended to do. He claimed that the three of us were “too much like Sequent”. Personally, I was ready to jump across the table and beat him to a pulp. I was that angry. Fortunately, the implementation manager kept his cool, and managed the situation quite well. He looked at the new CEO, and basically asked that if the new CEO felt we were too much like Sequent, he was interested in knowing what we were doing to cause that feeling. The simple response was “you all wear white shirts”. It seems ridiculous that anyone would say something like that, but it happened. I think it was at that point that we all realized that working with this CEO would be far more challenging than anyone had expected.
It was also about this time that the new CEO started to bring in his own management team. He ended up hiring two of his former co-workers at Teradata as the Vice President of Sales and Vice President of Marketing. The transition of those two individuals into the team went fairly smoothly. Additionally, the new CEO started to introduce several more of his former colleagues from Teradata. Some of them were good people that we ended up hiring, but several of them were also not a very good fit. It was clear that the new CEO was trying to bring in his own people to try and combat our core group from Sequent. Fortunately, we were able to stand our ground, and only bring in the people that would best fit into the organization. It was neither easy nor comfortable and there were a lot of arguments that started during the process.
Around the same time, there was also a major conflict that I had with the CEO that caused quite a stir within DecisionPoint. I had been asked to come up with an engineering plan for the next release of our product. I sent the plan to the CEO, and he sent me a one line response: “that’s not good enough, we’ll be dead by then”. That was the last straw. I had put up with so much from the CEO, and I was done taking his crap. I went to the CFO of Sequent, who was chairman of the board of DecisionPoint, and resigned. The CFO did not accept my resignation, and had me take a week off to cool down and see if we could resolve things with the CEO. At the end of the time off, I did reconcile with the CEO, but things between us would remain uneasy for the remainder of the time the CEO was with DecisionPoint.
As we continued to seek venture capital funding, a major software vendor decided that they would like to start the process of acquiring DecisionPoint. It was all very interesting in that we were a new company, and we needed to do a lot of work on our product in order to fit into that company’s software product line. The acquisition process was managed in a very informal manner, and it was a critical mistake on our part. We were to stop selling our existing product, which halted all sales and marketing activity. Additionally, we were required to complete engineering work that would make our product better integrated with other software solutions of the acquiring company.
I think we were all naïve in what would happen, and assumed that if we fulfilled our obligations as part of the acquisition process, everything else would go smoothly. This was re-enforced by the fact that the CEO of the acquiring company had been one of our “angel investors”. There were never any legal agreements signed during the acquisition process, and so all of the information being exchanged between our two companies was done so in a very open manner. We shared a lot of our intellectual property, experience, and ideas with that company.
Unbeknownst to us, there were a couple of things going on within the lower ranks of the acquiring company. There were several individuals within that company that felt that they should build their own solution rather than acquire DecisionPoint. Also, we had not known this, but whenever that company was looking to acquire another company, there had to be consensus amongst every employee from that company in order to move forward with the acquisition. In our case, the two people that wanted to build their own solution voted against the acquisition, and that was it. It was over within a five month period.
The acquiring company decided not to buy DecisionPoint. We had halted all sales and marketing efforts, and we were out of “angel money”. The acquiring company took all of the ideas that we had shared with them, and went off and built their own solution. In addition to that, some individuals within that company went out of their way to prevent us from bringing our solution to market that we had built as part of acquisition process. To say it bluntly, we were screwed, and there’s nothing we could do about it. I sunk into a fairly deep depression wondering what had gone wrong, and I was very angry about the whole situation. I learned a tough lesson from that experience. The one positive that did come out of the situation was that the CEO of the acquiring company personally called me to apologize for the situation. It was a small consolation for what had happened.
It was at that point that the decision was made to terminate our CEO. It was felt that he was running DecisionPoint into the ground, upsetting employees within DecisionPoint, and lead a very poorly managed acquisition process that failed. While it was a relief for me personally to see him go, it also presented another challenge for us. We were no longer under the CEO’s thumb, but what would we do next.
A lot of things happened as DecisionPoint was stalled following the acquisition process. We weren’t sure what direction to go, and a lot of employees were losing their confidence in staying with DecisionPoint. The implementation manager, who was a close friend at the time, decided to leave and find more stable employment. At one point, I even interviewed for another position within Sequent. It got to a point where I resigned from DecisionPoint and took the other position within Sequent. However, that proved to be a catalyst for the next phase of DecisionPoint. The CFO at Sequent, who was also the chairman of the board for DecisionPoint, did not accept my resignation, and decided that we would “re-start” DecisionPoint.
Sunday, March 28, 2010
Monday, March 15, 2010
Chapter 2 - The Events Leading to DecisionPoint
The story of DecisionPoint actually begins long before the company was founded. In May of 1988, I joined a large computer hardware engineering and manufacturing company based in the Pacific Northwest, Sequent Computer Systems (Sequent). At the time, I was assigned to help support their ASK/MANMAN system along with some other tasks in their Information Technology group. Shortly after I joined Sequent, the decision had been made to transition from ASK/MANMAN to Oracle Applications, which was software designed to support the accounting and manufacturing processes within a company. Oracle Applications was under development at Oracle, and Sequent was acting as a partner and the first alpha/beta site in testing the Finance, Manufacturing, and Distribution components of Oracle Applications. I was literally the first technical person outside of Oracle to ever work with Oracle Applications. Between 1988 and 1990, Sequent implemented the General Ledger, Accounts Payable, and Fixed Assets modules of Oracle Applications. The other finance modules would not be implemented until Sequent was able to convert to Oracle Manufacturing. In April of 1991, Sequent implemented all of Oracle Financials, Distribution, and Manufacturing in a production environment using the “big bang” (turn everything on at once) implementation approach. As far as implementations go, everything went relatively smoothly. The process of testing the software and converting historical data was long and tedious, but we had an excellent team and excellent plan.
As a sidebar, I was also leveraged as a resource to the Sequent sales force. My role was to help them sell Sequent hardware to run Oracle Applications. I took my practical implementation experience, and shared it with potential customers. This included traveling around the world with minimal notice to help in a variety of sales situations. In one instance, I had one day’s notice that I was headed to Hamburg, Germany with no idea of when I would be coming home. At the time, our oldest child, Andrew, was barely two years old. This meant for quite the juggling act trying to keep a computer system alive within Sequent, traveling to help the Sequent sales force sell hardware, and manage staying connected to a young family. Somehow I made it work, and it paid off both professionally and personally.
From a personal perspective, I got nice raises, stock options, and worldwide recognition as an expert in my field. In one year, we were able to close $30 million worth of hardware sales related to Oracle Applications. On top of everything else, I was able to win the Sequent “Employee Excellence Award” twice. This award was given to non-commission based employees, and the person had to be nominated by their peers with final approval by management. I was most proud of these awards as they were from my co-workers, not necessarily management. My co-workers understood what I was up against in my juggling act, and did a fantastic job supporting me in my multiple roles.
Back to our main story…
One of the goals of Sequent’s CFO for implementing Oracle Applications was to have better and faster access to information. Better and faster access to information was not achieved by simply using new and improved reports within Oracle Applications, but rather the ability to take that data and perform higher levels of analysis. The reports within Oracle Applications were adequate for running the operations of Sequent, but there was not much available for users in upper management and at the executive level to make strategic business decisions and course corrections. While the technology of Oracle Applications was more open and flexible than the old ASK/MANMAN system, getting information out of Oracle Applications in a way that upper level management and executives needed to use it was still difficult.
I remember a conversation that I had with the CFO at Sequent at the time. We were in a meeting to discuss what his vision was for the type of access and analysis he would need to better run the business. He relayed a conversation that he had with Oracle about the topic. His comment to Oracle was “You promised me great and flexible access to all of data that I’ve never had access to, where is it?” Oracle’s response was “It’s in there…you have to figure out how to get it out…” I’m sure there was much more to the conversation than what he relayed to us in the meeting, but that kind of sums up Oracle’s answer at the time. At that point, Sequent’s CFO would make a decision that would significantly change the course of my career over the next several years.
In the winter of 1991, the CFO of Sequent tasked me with figuring out a way to get the information out of Oracle Applications into a “usable form”. When the CFO talked about usable, he would jokingly say “if it has more than one button, I won’t be able to use it.” That was definitely an exaggeration on his part, but what he really meant was that it had to be simple to use, while at the same time providing maximum access to information. Having him, or any other executive at Sequent, learn to login to Oracle Applications and run inquiries and reports was not the right answer. This would have meant that they would have to learn a complicated application that they wouldn’t use that often, and that would not provide data at the summarized level they were looking for.
Around the same time, Sequent was trying to change the way that it was doing business. Traditionally, Sequent sold computer hardware to large companies. They left the job of software delivery and implementation to the customer or to consultants that the customer was willing to hire. Sequent decided to change course a bit, and made a bet that they could get into the consulting business so that they not only delivered the hardware platform, but could also get into the business of software implementation on top of that platform. Along with this, Sequent began to invest in developing software that would be layered on top of the Sequent hardware to make the hardware platform and associated software easier to implement and manage. The goal was to deliver a targeted set of software and consulting services that would add value to any customer implementation of Sequent hardware.
Sequent decided to create an entire new division that was focused on software development and implementation. The goal of the new division was to be able to make decisions somewhat independently of Sequent’s traditional hardware business. Given that the new business was in software and implementation, Sequent’s existing processes around the hardware business would be insufficient. Therefore, the new division was formed to focus on this new direction. Within the division, there were four primary areas that Sequent wanted to focus on. These were all areas that Sequent had strong existing expertise in.
The first area was an area known as enterprise architecture. Up until this point, Sequent customers would acquire the hardware platform, and then independently implement different software solutions on that hardware platform. Over the years, many customers had acquired multiple hardware platforms and software solutions. The goal of the enterprise architecture group was to help the customer come up with an overall strategy on how to manage all the different platforms and software solutions, and then produce a roadmap for how the customer should move forward when it came to future implementations. The goal was to get the customer out of the mentality of simply acquiring a new hardware platform every time they wanted to do something new, and get them into a mentality of acquiring the hardware with the goal of simplifying their computing environment in order to make it easier to manage.
The second area was targeted around online transaction processing (OLTP) applications. These applications had traditionally been the bread and butter of Sequent’s business. The Sequent hardware platform was outstanding at supporting hundreds or thousands of users entering specific transactions. When I say specific transactions, think of something as simple as entering a vendor invoice or purchase order. Part of this area of the business involved Oracle Applications, which Sequent’s IT team had deep experience working with. In this area, Sequent was not necessarily going to deliver any software. That was already handled by the software vendors. However, what Sequent could do was take the rich experience and knowledge that they had gained from implementing Oracle Applications internally, and building a consulting service that could help customers do the same type of implementation.
The third area was targeted around systems management. Similar to the situation for enterprise architecture, when a customer acquired new Sequent hardware, they would simply plug it in next to the existing hardware, install the software, and let end users begin using it. The problem was that each hardware platform was managed independently of the other hardware platforms. If a customer had ten Sequent computers, they would have to login to each system separately, and setup things like backup, etc. Sequent’s goal was to partner with existing software companies and build some of their own software to be able to manage the hardware platforms from a single location. Rather than login to each server, there would be a central console that would manage all the servers. So, if you setup something like backup on one of the computers, you could easily deploy that to the other computers in the environment without having to login to each one and do the same thing over and over again.
The fourth, and final, area was targeted around data warehousing. Up until this point in time, the data warehousing market was largely dominated by companies like Teradata and IBM. As described before, conceptually, data warehousing represents the consolidation of large quantities of data (millions or billions of transactions) to make it easier for end user to analyze the data for making strategic business decisions. Sequent was beginning to get into the data warehousing space because companies like Oracle and Informix (now part of IBM) started to make their software better able to handle the quantities of data required by a data warehouse implementation running on the Sequent hardware platform. Sequent had performed a couple of successful data warehouse implementations for different customers, and wanted to take that experience and knowledge to help other customers deliver data warehouse solutions to their end users.
Of all of the areas that Sequent was about to get into, data warehousing was probably the most promising as far as future business growth. It was a new market that Sequent was having early success in, and more importantly, it required very large Sequent hardware platforms to deploy the size of data warehouses that the customers needed. The other areas would drive moderate growth in the sales of hardware platforms and services, but if done correctly, the data warehouse area would represent the largest potential for growth. In many ways, it represented the future of where Sequent would draw most of its revenue from.
Because data warehousing represented the “next big thing” for Sequent, a lot expertise in building data warehouses and working with data warehousing technologies was developed. With my new project of implementing a data warehouse for use internally at Sequent, I was able to tap into great sources of expertise, and leverage it to help me design and build a data warehouse for Sequent that contained finance related data (General Ledger, Accounts Payable, Fixed Assets, Accounts Receivable, Order Management, and Purchasing) coming from the Oracle Applications installation. At the time, there were a lot of moving pieces in the data warehousing market. There was a whole new set of rapidly changing technologies, philosophies, and implementation methodologies. Without having to blaze the trail myself, I could leverage the collective expertise of data warehousing knowledge within Sequent to figure out the best way to move forward. It definitely made my job easier as I could focus on the implementation rather than trying to chase down and experiment with the latest and greatest new technology fad.
Rather than go through the details of each decision I made, we ended up implementing a data warehouse on top of the Oracle RDBMS running on a Sequent platform. These choices were easy because they were both technologies that we had experience with. We did experiment with one other database technology called Redbrick at the time, but we had no experience with it, and it would have represented significant changes to Sequent’s internal IT environment. At the time, there was no budget for additional software or IT resources to support the software, so we went with Oracle. As far as end user access to the data, we went with two different sets of tools. The first tool was Pilot Lightship, and was classified as an executive information system (EIS) tool. Its job was to provide summarized data to Sequent executives in a very easy to use format. All of the questions that executives wanted to ask were predefined, so it was a bit inflexible, but it was extremely easy to use in that most interaction involved a single click of the mouse. The second tool was called Clear Access and was designed for adhoc access to the data. Users could literally build a query to answer any question that they wanted, but it was somewhat difficult to use, and required that the user had pretty intimate knowledge of database tables and columns. It should be noted that both tools would be considered sub-standard in today’s world of data warehousing, but at the time, they were state of the art.
In the winter of 1992, I delivered the data warehouse to end users, including executives, cost center managers, sales management, and financial controllers. As stated above, the data warehouse was built on top of an Oracle database using a home grown Extract-Transform-Load (ETL) to extract data from Oracle Applications and load it into the data warehouse. The majority of the end users were given access to the data through Pilot Lightship with just a couple that had access through Clear Access.
There were some bumps in the road during the implementation as end users were uncertain of the accuracy of the data. It turned out that some of the revenue information could not simply be extracted from the source system due to the way that Sequent accounted for revenue in their international division. Sequent’s process was for headquarters to build, ship, and invoice the Sequent subsidiary in another country for the hardware, and then the Sequent subsidiary would ship and bill the end customer. There was limited correlation between the revenue information in the Sequent headquarters system and revenue coming from Sequent’s systems supporting the subsidiaries. We eventually had to build a series of complicated processes to merge the data, which included a couple of screens that allowed specific end users to make changes to how some of the data was merged. We worked through those issues, and eventually got the end users to sign off on the accuracy of the data.
Because Sequent was a beta site for Oracle Applications, Sequent would actively host Oracle’s prospective customers and do references for Oracle Applications. These were sit down Q&A sessions where individuals within prospective Oracle Applications customers could sit down with someone within Sequent who was equivalent to them in position, and talk about how their job would change, etc. These were typically all day sessions with separate meetings and breakout sessions. The Oracle Applications prospective customers were facing significant changes in how they would end up running their business, and Sequent was a good resource to help them talk about and work through the changes.
The Sequent CFO was very proud of what we were able to accomplish with the data warehouse I had built, and the types of access he had to information. Therefore, during the executive sessions of these meetings, the CFO of Sequent would proudly show the data warehouse environment that he was using. Given that the prospects we were talking to would be new Oracle Applications customers, when we talked about the data warehouse, we talked in terms of the types of things that you could do with the data after you implemented Oracle Applications. It was clear to the visiting executives that implementing Oracle Applications could help them springboard into other technologies, like data warehousing. As a result, almost every visitor that saw our data warehouse implementation would comment to the CFO that if they bought Oracle Applications, they wondered if they could also “buy” the data warehouse environment that I had created.
Over time, given the interest level of prospective Oracle Applications customers, and the fact that Sequent was making a big push into the data warehousing market, it was clear that if we could turn the data warehouse I had built into a commercially available piece of software, there was a market for it. Sequent’s CFO and I talked, frequently, about the possibility of Sequent branching out into the applications software market with the data warehouse solution. However, it was not an easy thing to do within Sequent. While Sequent was starting to get into the software market, it was strictly around tools and utilities to make the Sequent hardware platform easier to implement and manage. There were never any discussions or plans around application software. If we were to do this, we would have to try and accomplish it with minimal impact to the rest of Sequent’s organization. This would prove to be difficult for many reasons as delivering application software was much different than what Sequent had traditionally done.
Eventually, in early 1994, and as more prospective Oracle Applications customers came through Sequent, the interest in our data warehousing solution became much higher. Sequent was ready for us to break out into our own small team and start an applications software division within Sequent. In the spring of 1994, through a series of events, the CFO of Sequent decided to assign me to take the internal data warehouse (very specific to Sequent) and a small engineering team, and turn it into a solution that Sequent could sell as a product offering. The product offering would be called DecisionPoint. There were a lot of peaks and valleys in the process because we were very different from Sequent’s traditional business model and delivery mechanism. However, after approximately a six month development effort, we had completed turning the internal data warehouse solution into a product that would auto configure to support any implementation of Oracle Applications at any customer site.
On the sales front, we had a great start even though DecisionPoint represented a new software offering from a hardware company that had limited experience developing application software. We sold the DecisionPoint product to three different companies (two in the US and one in Australia) within the first three months the solution was available to customers. At the time, Sequent did have a consulting staff, but most of the consultants were familiar with hardware and database technology, not application software in the data warehouse market. More specifically, very few of them had experience working with application software like DecisionPoint, so even though we provided some training on our software, I spent a lot of time traveling between our US customers making sure that everything went smoothly. Our resource in Australia turned out to be quite a find, and with some support from our engineering team, she was able to implement DecisionPoint without any of us having to travel there. Overall, while the implementations were a bit painful, they were successful and the solution was used at each of the customer sites. It was a better start than any of us could have imagined.
One of our biggest challenges from a sales perspective was that given that almost all of Sequent’s sales were related to computer hardware, the sales force had a difficult time selling a software solution like DecisionPoint beyond the three initial customers. There were a lot of different factors that caused the lack of sales. However, I believe that at the end of the day, the biggest factor to the lack of sales had to do with DecisionPoint being a small software offering in what was predominantly a hardware company. A sales rep would have to sell ten copies of our software to make the same commission as they would get in selling one hardware platform. The odds were definitely not in our favor.
In spite of the lack of sales, the engineering team continued to improve the product and deliver new features to the existing customers. I was able to shield the engineers from the ups and downs of the sales process so that they could stay focused on getting our product releases out on time. At times, it felt much like combat where the opposition would throw a grenade, and I would jump on it to protect the engineers from getting injured or killed. It was definitely a learning experience that I still carry scars from today.
After a lot of thought and deliberation by DecisionPoint team members and the CFO at Sequent, who was our chief sponsor within the organization, it was decided that being a software group within a hardware company was detrimental to maximizing our potential. What we really needed was to be able to be independent of Sequent so that we could branch out on our own, and pursue the options we needed to pursue, like porting our solution to non-Sequent hardware platforms. We began to investigate what it would take for us to become our own entity, and be free from the restrictions we were under at Sequent.
As a sidebar, I was also leveraged as a resource to the Sequent sales force. My role was to help them sell Sequent hardware to run Oracle Applications. I took my practical implementation experience, and shared it with potential customers. This included traveling around the world with minimal notice to help in a variety of sales situations. In one instance, I had one day’s notice that I was headed to Hamburg, Germany with no idea of when I would be coming home. At the time, our oldest child, Andrew, was barely two years old. This meant for quite the juggling act trying to keep a computer system alive within Sequent, traveling to help the Sequent sales force sell hardware, and manage staying connected to a young family. Somehow I made it work, and it paid off both professionally and personally.
From a personal perspective, I got nice raises, stock options, and worldwide recognition as an expert in my field. In one year, we were able to close $30 million worth of hardware sales related to Oracle Applications. On top of everything else, I was able to win the Sequent “Employee Excellence Award” twice. This award was given to non-commission based employees, and the person had to be nominated by their peers with final approval by management. I was most proud of these awards as they were from my co-workers, not necessarily management. My co-workers understood what I was up against in my juggling act, and did a fantastic job supporting me in my multiple roles.
Back to our main story…
One of the goals of Sequent’s CFO for implementing Oracle Applications was to have better and faster access to information. Better and faster access to information was not achieved by simply using new and improved reports within Oracle Applications, but rather the ability to take that data and perform higher levels of analysis. The reports within Oracle Applications were adequate for running the operations of Sequent, but there was not much available for users in upper management and at the executive level to make strategic business decisions and course corrections. While the technology of Oracle Applications was more open and flexible than the old ASK/MANMAN system, getting information out of Oracle Applications in a way that upper level management and executives needed to use it was still difficult.
I remember a conversation that I had with the CFO at Sequent at the time. We were in a meeting to discuss what his vision was for the type of access and analysis he would need to better run the business. He relayed a conversation that he had with Oracle about the topic. His comment to Oracle was “You promised me great and flexible access to all of data that I’ve never had access to, where is it?” Oracle’s response was “It’s in there…you have to figure out how to get it out…” I’m sure there was much more to the conversation than what he relayed to us in the meeting, but that kind of sums up Oracle’s answer at the time. At that point, Sequent’s CFO would make a decision that would significantly change the course of my career over the next several years.
In the winter of 1991, the CFO of Sequent tasked me with figuring out a way to get the information out of Oracle Applications into a “usable form”. When the CFO talked about usable, he would jokingly say “if it has more than one button, I won’t be able to use it.” That was definitely an exaggeration on his part, but what he really meant was that it had to be simple to use, while at the same time providing maximum access to information. Having him, or any other executive at Sequent, learn to login to Oracle Applications and run inquiries and reports was not the right answer. This would have meant that they would have to learn a complicated application that they wouldn’t use that often, and that would not provide data at the summarized level they were looking for.
Around the same time, Sequent was trying to change the way that it was doing business. Traditionally, Sequent sold computer hardware to large companies. They left the job of software delivery and implementation to the customer or to consultants that the customer was willing to hire. Sequent decided to change course a bit, and made a bet that they could get into the consulting business so that they not only delivered the hardware platform, but could also get into the business of software implementation on top of that platform. Along with this, Sequent began to invest in developing software that would be layered on top of the Sequent hardware to make the hardware platform and associated software easier to implement and manage. The goal was to deliver a targeted set of software and consulting services that would add value to any customer implementation of Sequent hardware.
Sequent decided to create an entire new division that was focused on software development and implementation. The goal of the new division was to be able to make decisions somewhat independently of Sequent’s traditional hardware business. Given that the new business was in software and implementation, Sequent’s existing processes around the hardware business would be insufficient. Therefore, the new division was formed to focus on this new direction. Within the division, there were four primary areas that Sequent wanted to focus on. These were all areas that Sequent had strong existing expertise in.
The first area was an area known as enterprise architecture. Up until this point, Sequent customers would acquire the hardware platform, and then independently implement different software solutions on that hardware platform. Over the years, many customers had acquired multiple hardware platforms and software solutions. The goal of the enterprise architecture group was to help the customer come up with an overall strategy on how to manage all the different platforms and software solutions, and then produce a roadmap for how the customer should move forward when it came to future implementations. The goal was to get the customer out of the mentality of simply acquiring a new hardware platform every time they wanted to do something new, and get them into a mentality of acquiring the hardware with the goal of simplifying their computing environment in order to make it easier to manage.
The second area was targeted around online transaction processing (OLTP) applications. These applications had traditionally been the bread and butter of Sequent’s business. The Sequent hardware platform was outstanding at supporting hundreds or thousands of users entering specific transactions. When I say specific transactions, think of something as simple as entering a vendor invoice or purchase order. Part of this area of the business involved Oracle Applications, which Sequent’s IT team had deep experience working with. In this area, Sequent was not necessarily going to deliver any software. That was already handled by the software vendors. However, what Sequent could do was take the rich experience and knowledge that they had gained from implementing Oracle Applications internally, and building a consulting service that could help customers do the same type of implementation.
The third area was targeted around systems management. Similar to the situation for enterprise architecture, when a customer acquired new Sequent hardware, they would simply plug it in next to the existing hardware, install the software, and let end users begin using it. The problem was that each hardware platform was managed independently of the other hardware platforms. If a customer had ten Sequent computers, they would have to login to each system separately, and setup things like backup, etc. Sequent’s goal was to partner with existing software companies and build some of their own software to be able to manage the hardware platforms from a single location. Rather than login to each server, there would be a central console that would manage all the servers. So, if you setup something like backup on one of the computers, you could easily deploy that to the other computers in the environment without having to login to each one and do the same thing over and over again.
The fourth, and final, area was targeted around data warehousing. Up until this point in time, the data warehousing market was largely dominated by companies like Teradata and IBM. As described before, conceptually, data warehousing represents the consolidation of large quantities of data (millions or billions of transactions) to make it easier for end user to analyze the data for making strategic business decisions. Sequent was beginning to get into the data warehousing space because companies like Oracle and Informix (now part of IBM) started to make their software better able to handle the quantities of data required by a data warehouse implementation running on the Sequent hardware platform. Sequent had performed a couple of successful data warehouse implementations for different customers, and wanted to take that experience and knowledge to help other customers deliver data warehouse solutions to their end users.
Of all of the areas that Sequent was about to get into, data warehousing was probably the most promising as far as future business growth. It was a new market that Sequent was having early success in, and more importantly, it required very large Sequent hardware platforms to deploy the size of data warehouses that the customers needed. The other areas would drive moderate growth in the sales of hardware platforms and services, but if done correctly, the data warehouse area would represent the largest potential for growth. In many ways, it represented the future of where Sequent would draw most of its revenue from.
Because data warehousing represented the “next big thing” for Sequent, a lot expertise in building data warehouses and working with data warehousing technologies was developed. With my new project of implementing a data warehouse for use internally at Sequent, I was able to tap into great sources of expertise, and leverage it to help me design and build a data warehouse for Sequent that contained finance related data (General Ledger, Accounts Payable, Fixed Assets, Accounts Receivable, Order Management, and Purchasing) coming from the Oracle Applications installation. At the time, there were a lot of moving pieces in the data warehousing market. There was a whole new set of rapidly changing technologies, philosophies, and implementation methodologies. Without having to blaze the trail myself, I could leverage the collective expertise of data warehousing knowledge within Sequent to figure out the best way to move forward. It definitely made my job easier as I could focus on the implementation rather than trying to chase down and experiment with the latest and greatest new technology fad.
Rather than go through the details of each decision I made, we ended up implementing a data warehouse on top of the Oracle RDBMS running on a Sequent platform. These choices were easy because they were both technologies that we had experience with. We did experiment with one other database technology called Redbrick at the time, but we had no experience with it, and it would have represented significant changes to Sequent’s internal IT environment. At the time, there was no budget for additional software or IT resources to support the software, so we went with Oracle. As far as end user access to the data, we went with two different sets of tools. The first tool was Pilot Lightship, and was classified as an executive information system (EIS) tool. Its job was to provide summarized data to Sequent executives in a very easy to use format. All of the questions that executives wanted to ask were predefined, so it was a bit inflexible, but it was extremely easy to use in that most interaction involved a single click of the mouse. The second tool was called Clear Access and was designed for adhoc access to the data. Users could literally build a query to answer any question that they wanted, but it was somewhat difficult to use, and required that the user had pretty intimate knowledge of database tables and columns. It should be noted that both tools would be considered sub-standard in today’s world of data warehousing, but at the time, they were state of the art.
In the winter of 1992, I delivered the data warehouse to end users, including executives, cost center managers, sales management, and financial controllers. As stated above, the data warehouse was built on top of an Oracle database using a home grown Extract-Transform-Load (ETL) to extract data from Oracle Applications and load it into the data warehouse. The majority of the end users were given access to the data through Pilot Lightship with just a couple that had access through Clear Access.
There were some bumps in the road during the implementation as end users were uncertain of the accuracy of the data. It turned out that some of the revenue information could not simply be extracted from the source system due to the way that Sequent accounted for revenue in their international division. Sequent’s process was for headquarters to build, ship, and invoice the Sequent subsidiary in another country for the hardware, and then the Sequent subsidiary would ship and bill the end customer. There was limited correlation between the revenue information in the Sequent headquarters system and revenue coming from Sequent’s systems supporting the subsidiaries. We eventually had to build a series of complicated processes to merge the data, which included a couple of screens that allowed specific end users to make changes to how some of the data was merged. We worked through those issues, and eventually got the end users to sign off on the accuracy of the data.
Because Sequent was a beta site for Oracle Applications, Sequent would actively host Oracle’s prospective customers and do references for Oracle Applications. These were sit down Q&A sessions where individuals within prospective Oracle Applications customers could sit down with someone within Sequent who was equivalent to them in position, and talk about how their job would change, etc. These were typically all day sessions with separate meetings and breakout sessions. The Oracle Applications prospective customers were facing significant changes in how they would end up running their business, and Sequent was a good resource to help them talk about and work through the changes.
The Sequent CFO was very proud of what we were able to accomplish with the data warehouse I had built, and the types of access he had to information. Therefore, during the executive sessions of these meetings, the CFO of Sequent would proudly show the data warehouse environment that he was using. Given that the prospects we were talking to would be new Oracle Applications customers, when we talked about the data warehouse, we talked in terms of the types of things that you could do with the data after you implemented Oracle Applications. It was clear to the visiting executives that implementing Oracle Applications could help them springboard into other technologies, like data warehousing. As a result, almost every visitor that saw our data warehouse implementation would comment to the CFO that if they bought Oracle Applications, they wondered if they could also “buy” the data warehouse environment that I had created.
Over time, given the interest level of prospective Oracle Applications customers, and the fact that Sequent was making a big push into the data warehousing market, it was clear that if we could turn the data warehouse I had built into a commercially available piece of software, there was a market for it. Sequent’s CFO and I talked, frequently, about the possibility of Sequent branching out into the applications software market with the data warehouse solution. However, it was not an easy thing to do within Sequent. While Sequent was starting to get into the software market, it was strictly around tools and utilities to make the Sequent hardware platform easier to implement and manage. There were never any discussions or plans around application software. If we were to do this, we would have to try and accomplish it with minimal impact to the rest of Sequent’s organization. This would prove to be difficult for many reasons as delivering application software was much different than what Sequent had traditionally done.
Eventually, in early 1994, and as more prospective Oracle Applications customers came through Sequent, the interest in our data warehousing solution became much higher. Sequent was ready for us to break out into our own small team and start an applications software division within Sequent. In the spring of 1994, through a series of events, the CFO of Sequent decided to assign me to take the internal data warehouse (very specific to Sequent) and a small engineering team, and turn it into a solution that Sequent could sell as a product offering. The product offering would be called DecisionPoint. There were a lot of peaks and valleys in the process because we were very different from Sequent’s traditional business model and delivery mechanism. However, after approximately a six month development effort, we had completed turning the internal data warehouse solution into a product that would auto configure to support any implementation of Oracle Applications at any customer site.
On the sales front, we had a great start even though DecisionPoint represented a new software offering from a hardware company that had limited experience developing application software. We sold the DecisionPoint product to three different companies (two in the US and one in Australia) within the first three months the solution was available to customers. At the time, Sequent did have a consulting staff, but most of the consultants were familiar with hardware and database technology, not application software in the data warehouse market. More specifically, very few of them had experience working with application software like DecisionPoint, so even though we provided some training on our software, I spent a lot of time traveling between our US customers making sure that everything went smoothly. Our resource in Australia turned out to be quite a find, and with some support from our engineering team, she was able to implement DecisionPoint without any of us having to travel there. Overall, while the implementations were a bit painful, they were successful and the solution was used at each of the customer sites. It was a better start than any of us could have imagined.
One of our biggest challenges from a sales perspective was that given that almost all of Sequent’s sales were related to computer hardware, the sales force had a difficult time selling a software solution like DecisionPoint beyond the three initial customers. There were a lot of different factors that caused the lack of sales. However, I believe that at the end of the day, the biggest factor to the lack of sales had to do with DecisionPoint being a small software offering in what was predominantly a hardware company. A sales rep would have to sell ten copies of our software to make the same commission as they would get in selling one hardware platform. The odds were definitely not in our favor.
In spite of the lack of sales, the engineering team continued to improve the product and deliver new features to the existing customers. I was able to shield the engineers from the ups and downs of the sales process so that they could stay focused on getting our product releases out on time. At times, it felt much like combat where the opposition would throw a grenade, and I would jump on it to protect the engineers from getting injured or killed. It was definitely a learning experience that I still carry scars from today.
After a lot of thought and deliberation by DecisionPoint team members and the CFO at Sequent, who was our chief sponsor within the organization, it was decided that being a software group within a hardware company was detrimental to maximizing our potential. What we really needed was to be able to be independent of Sequent so that we could branch out on our own, and pursue the options we needed to pursue, like porting our solution to non-Sequent hardware platforms. We began to investigate what it would take for us to become our own entity, and be free from the restrictions we were under at Sequent.
Sunday, March 14, 2010
Chapter 1 – The DecisionPoint Solution
In order to fully understand some of the later discussions in this book, it is important to have a basic understanding of the problem that DecisionPoint was trying to solve. DecisionPoint represented a series of software and consulting processes to automate the analysis of financial information for large corporations. Overly simplified, DecisionPoint can be compared to the reporting capabilities of Quicken. In Quicken, you manage your checkbook and bank accounts to pay your bills. There is also a reporting capability that allows you to see where you’re spending your money, what categories, etc. DecisionPoint was designed to provide very similar capabilities for large corporations, but on a much bigger scale. For example, DecisionPoint could take financial information from multiple systems running in multiple countries and consolidate that information for the customer so that employees of the customer could perform complex analysis on that information in one place without having to go back to the source systems. This would, hopefully, lead to better decisions about what direction the business should go.
DecisionPoint was in what is known as the data warehousing market within the computer technology market. When you simplify the meaning, data warehousing is the ability to take very large quantities of data from many different sources, and assemble it in a central location that is fast and easy for non-technical people to access and make decisions. From a personal perspective, picture it like doing your monthly finances. You have your pay check along with your typical monthly expenditures. You use this information to decide what bills to pay, how much money is left over, and what you want to do with the left over money. Now picture that same situation for millions of people that have to make the same decisions. There are millions of people accessing millions of pieces of information with minimal knowledge of how to use a computer other than a home PC. That’s pretty much what a data warehouse is like. It involves a lot of people looking through a lot of data to try and figure out what to do next.
As an example, a data warehouse in a grocery store is something that most everyone can relate to. You go into a grocery store to buy a lot of different products including food, beverages, bathroom supplies, and many other items that you use in your home. Each time you go to the grocery store, they scan the products that you intend to purchase. When you initially look at the scanning process, you fundamentally believe that the primary purpose of scanning is to help determine how much a product costs, and therefore, how much you pay for it. While this is the fundamental purpose, there are other things that go on behind the scenes that you never see. In addition to scanning products for price, the grocery store also tries to track the frequency at which products are purchased, and what products are typically purchased together. For example, in the summer, you may find that not only do people purchase a lot of steaks for grilling, but when they do so, they also buy other supplies such as steak sauce, meat tenderizer, even things like charcoal for the grill. The goal of knowing this information is two fold. First, the grocery store wants to track what items are purchased frequently at what time of year. This helps them to determine what products and quantities of those products they need to have in the store to make sure they have enough supply for everyone that comes to buy those products. Second, the grocery store also knows what products are typically purchased at the same time. This may lead them to place the items closer together in the store to make it easier for shoppers to find. In our steak example, a store might choose to put the steak sauce, and even possibly the charcoal near the butcher section making it easier for shoppers to find the products most closely related to steak and how people choose to cook it.
Now you may ask what this has to do with data warehousing. As you might notice when you go to the grocery store at a busy time, there may be hundreds of shoppers in the store. Additionally, there are literally thousands of products that those shoppers can buy. In any given day, a grocery store may scan literally millions of product transactions. Imagine having to sort through the scanned data by hand trying to determine the most frequently purchased products along with trying to correlate what products are commonly purchased at the same time. This is an exercise that could take weeks to do by hand for just one day’s volume of transactions. The role of the data warehouse is to use a computer to take all of those scanned transactions, and organize them in a way that the manager of the grocery store can quickly determine, with the press of a button and in a matter of seconds, the most frequently purchased products for a day, week, month, season, or year. So, literally in seconds, the grocery store manager knows what products to order for what time of year. Additionally, with the press of a button, the store manager can correlate what products are frequently sold together, which may help them to determine where to place products on the shelves to make it easier for shoppers to find them.
Fundamentally, the goal for the data warehouse for a grocery store is to sort through what has been bought, and allow the manager to ask both basic and complex questions to help them more effectively manage the store with the goal of selling more products to more people. A data warehouse can apply to more than just a grocery store.
Some other examples of the usage of data warehousing to enhance business opportunities include:
• Cell phone companies analyzing call and call volume data to determine new
and different programs they can offer to their customers
• Manufacturing companies analyzing what they buy and who they buy it from to
determine if there are any products or vendors they should negotiate to
obtain discounts on future purchases.
• Retailers that analyze product purchases to be able to advertise and send
coupons to offer discounts to customers on frequently purchased items.
• Companies that collect and analyze their travel expenses to determine where
employees are traveling and what it is costing the company. This can help
to determine most frequently used airlines, hotels, car rental companies,
etc. so that the company can negotiate volume discount with those vendors.
There are many other situations where a data warehouse can be used, and these are just some cursory examples to help you see the possibilities when using this type of technology.
DecisionPoint was in what is known as the data warehousing market within the computer technology market. When you simplify the meaning, data warehousing is the ability to take very large quantities of data from many different sources, and assemble it in a central location that is fast and easy for non-technical people to access and make decisions. From a personal perspective, picture it like doing your monthly finances. You have your pay check along with your typical monthly expenditures. You use this information to decide what bills to pay, how much money is left over, and what you want to do with the left over money. Now picture that same situation for millions of people that have to make the same decisions. There are millions of people accessing millions of pieces of information with minimal knowledge of how to use a computer other than a home PC. That’s pretty much what a data warehouse is like. It involves a lot of people looking through a lot of data to try and figure out what to do next.
As an example, a data warehouse in a grocery store is something that most everyone can relate to. You go into a grocery store to buy a lot of different products including food, beverages, bathroom supplies, and many other items that you use in your home. Each time you go to the grocery store, they scan the products that you intend to purchase. When you initially look at the scanning process, you fundamentally believe that the primary purpose of scanning is to help determine how much a product costs, and therefore, how much you pay for it. While this is the fundamental purpose, there are other things that go on behind the scenes that you never see. In addition to scanning products for price, the grocery store also tries to track the frequency at which products are purchased, and what products are typically purchased together. For example, in the summer, you may find that not only do people purchase a lot of steaks for grilling, but when they do so, they also buy other supplies such as steak sauce, meat tenderizer, even things like charcoal for the grill. The goal of knowing this information is two fold. First, the grocery store wants to track what items are purchased frequently at what time of year. This helps them to determine what products and quantities of those products they need to have in the store to make sure they have enough supply for everyone that comes to buy those products. Second, the grocery store also knows what products are typically purchased at the same time. This may lead them to place the items closer together in the store to make it easier for shoppers to find. In our steak example, a store might choose to put the steak sauce, and even possibly the charcoal near the butcher section making it easier for shoppers to find the products most closely related to steak and how people choose to cook it.
Now you may ask what this has to do with data warehousing. As you might notice when you go to the grocery store at a busy time, there may be hundreds of shoppers in the store. Additionally, there are literally thousands of products that those shoppers can buy. In any given day, a grocery store may scan literally millions of product transactions. Imagine having to sort through the scanned data by hand trying to determine the most frequently purchased products along with trying to correlate what products are commonly purchased at the same time. This is an exercise that could take weeks to do by hand for just one day’s volume of transactions. The role of the data warehouse is to use a computer to take all of those scanned transactions, and organize them in a way that the manager of the grocery store can quickly determine, with the press of a button and in a matter of seconds, the most frequently purchased products for a day, week, month, season, or year. So, literally in seconds, the grocery store manager knows what products to order for what time of year. Additionally, with the press of a button, the store manager can correlate what products are frequently sold together, which may help them to determine where to place products on the shelves to make it easier for shoppers to find them.
Fundamentally, the goal for the data warehouse for a grocery store is to sort through what has been bought, and allow the manager to ask both basic and complex questions to help them more effectively manage the store with the goal of selling more products to more people. A data warehouse can apply to more than just a grocery store.
Some other examples of the usage of data warehousing to enhance business opportunities include:
• Cell phone companies analyzing call and call volume data to determine new
and different programs they can offer to their customers
• Manufacturing companies analyzing what they buy and who they buy it from to
determine if there are any products or vendors they should negotiate to
obtain discounts on future purchases.
• Retailers that analyze product purchases to be able to advertise and send
coupons to offer discounts to customers on frequently purchased items.
• Companies that collect and analyze their travel expenses to determine where
employees are traveling and what it is costing the company. This can help
to determine most frequently used airlines, hotels, car rental companies,
etc. so that the company can negotiate volume discount with those vendors.
There are many other situations where a data warehouse can be used, and these are just some cursory examples to help you see the possibilities when using this type of technology.
Preface
People get involved in startups for a variety of reasons with many different goals. It usually starts with a good idea that someone is passionate about. However, deep down, I believe that many people that get into startups are looking for fame and fortune. What drives and motivates individuals is that recognition or money that you were unable to achieve when you worked for a larger organization. The goal is to get out from under the stifling environment of a larger company and be able to do something with a new freedom and flair that you couldn’t otherwise try.
When I think back about what motivated me, there were a lot of factors. At the time, I was working for Sequent Computer Systems, which was a large computer hardware manufacturing company that was eventually acquired by IBM. I started with Sequent as an information technology resource, employee number five hundred. Because of Sequent’s size, there were many opportunities for individual growth and reward, and I certainly took advantage of those opportunities. My specialty was getting finance and accounting software, known as Oracle Applications, to run fast on the Sequent hardware platform. While my primary function was an internal resource, supporting Sequent’s internal implementation of Oracle Applications, I also spent a lot of my time traveling to customer sites to help them do what we had done at Sequent. Additionally, I spent a lot of time traveling around the world to help sell Sequent hardware for customers that wanted to run Oracle Applications.
Like any other company in the hardware technology market, there was a lot of risk, but also a lot of reward. Between stock options, bonuses, salary increases, and even two employee excellence awards that involved very nice vacations for my wife and I, I had done well for myself. I had a fantastic reputation and a good career. On top of that, I had a great family, which included a wife and two young children. However, even with all of that, I kept having the feeling that there was something missing. From a career perspective, I wanted more. Sequent had grown a lot in my time there, and I had moved on from being an information technology resource to being more focused on helping Sequent’s sales force sell more Sequent hardware. As Sequent grew, like any company, it began to lose the qualities of a company that I enjoyed. There was less freedom, more rules, and more bureaucracy. As many will tell you, I’m not the best bureaucrat, and I’m too honest and blunt to be a good politician, so I began to think about my next steps.
Those next steps would be DecisionPoint, the company I founded, which is the center of the story for this book. While the book has information about what DecisionPoint was, and its evolution, I believe the real value was the lessons learned that I took away from the experience. That’s what I hope to share with other folks that are thinking about starting a company or becoming part of a startup.
Often, the people that get involved with a startup do so thinking that they are prepared for the challenge, but after getting involved, realize that the situation was more than they bargained for. In a startup, the stakes are high and there is quite a bit of personal risk in the form of salary, benefits, etc. Additionally, everyone involved in the startup is faced with a series of many highs and many lows in the quest to make the startup viable. In many cases, the goals of the individuals that founded the startup are never met, or fall short of the dreams these individuals had when founding the startup.
The chances that a startup either goes public or gets acquired is very small. Most startups die somewhere along the process, and that’s just a fact of life. When the startup fails, can you answer the question “what happens when my best was not good enough?”
When I think back about what motivated me, there were a lot of factors. At the time, I was working for Sequent Computer Systems, which was a large computer hardware manufacturing company that was eventually acquired by IBM. I started with Sequent as an information technology resource, employee number five hundred. Because of Sequent’s size, there were many opportunities for individual growth and reward, and I certainly took advantage of those opportunities. My specialty was getting finance and accounting software, known as Oracle Applications, to run fast on the Sequent hardware platform. While my primary function was an internal resource, supporting Sequent’s internal implementation of Oracle Applications, I also spent a lot of my time traveling to customer sites to help them do what we had done at Sequent. Additionally, I spent a lot of time traveling around the world to help sell Sequent hardware for customers that wanted to run Oracle Applications.
Like any other company in the hardware technology market, there was a lot of risk, but also a lot of reward. Between stock options, bonuses, salary increases, and even two employee excellence awards that involved very nice vacations for my wife and I, I had done well for myself. I had a fantastic reputation and a good career. On top of that, I had a great family, which included a wife and two young children. However, even with all of that, I kept having the feeling that there was something missing. From a career perspective, I wanted more. Sequent had grown a lot in my time there, and I had moved on from being an information technology resource to being more focused on helping Sequent’s sales force sell more Sequent hardware. As Sequent grew, like any company, it began to lose the qualities of a company that I enjoyed. There was less freedom, more rules, and more bureaucracy. As many will tell you, I’m not the best bureaucrat, and I’m too honest and blunt to be a good politician, so I began to think about my next steps.
Those next steps would be DecisionPoint, the company I founded, which is the center of the story for this book. While the book has information about what DecisionPoint was, and its evolution, I believe the real value was the lessons learned that I took away from the experience. That’s what I hope to share with other folks that are thinking about starting a company or becoming part of a startup.
Often, the people that get involved with a startup do so thinking that they are prepared for the challenge, but after getting involved, realize that the situation was more than they bargained for. In a startup, the stakes are high and there is quite a bit of personal risk in the form of salary, benefits, etc. Additionally, everyone involved in the startup is faced with a series of many highs and many lows in the quest to make the startup viable. In many cases, the goals of the individuals that founded the startup are never met, or fall short of the dreams these individuals had when founding the startup.
The chances that a startup either goes public or gets acquired is very small. Most startups die somewhere along the process, and that’s just a fact of life. When the startup fails, can you answer the question “what happens when my best was not good enough?”
Subscribe to:
Posts (Atom)
Visitors
