Why Do We Do What We Do? Because We’re Good At It? Because We’re Expected To Do It? OR Because We Enjoy It?

I was out with some friends after work on Friday, and the discussion got me to thinking about something I thought would make a good blog topic. We were out with someone who was leaving the organization, and when I asked her what her next career step was going to be, she mentioned that she was still trying to figure that out. She wasn’t sure what was next or what she wanted to do next, and was going to take some time to figure that out. Later in the evening, we were having other discussions about different definitions of success. Some felt success was about the amount of money you made while others felt success was defined by doing what you want to do and enjoying it. I got to thinking about how those two things were closely tied together.

As my wife and I were doing our weekly house cleaning chores, it gave me some time to think. I often think about things when I’m doing things like cleaning the house or doing yard work. It’s a good time to clear my head and think about things. I started to think about the conversations Friday night along with the choices I made in my own life and career. It led me to think about why I’ve done the things I’ve done in my life. Did I do the things I did because I was good at them, because I wanted to do them, or because it was expected of me?

Before I reflect on my own choices, some people will immediately say that I did things because I felt I had to, not because I wanted to. However, that’s not the case. Whether I regret former choices I made is not the point. What’s more important is why I make the choices I make, and why I continue to do so. Also, it could be argued whether I’m good at the things I choose to do or not. Again, that’s subjective, and not the point. Some would argue I was good at it while others would argue that I am not. Each person has their own opinion on that.

Before tying this to my experiences at DecisionPoint, I thought I’d talk about something else I do, coaching youth soccer. When I first started coaching youth soccer, I think the initial reason had to do with my son entering kindergarten and choosing recreational soccer as his first experience with organized sports. I thought it would be a good way to spend more time together, and it was. I continued to coach the following years, and even coached my daughter’s teams. As my kids decided to play competitive soccer, I chose not to coach their teams. My own experiences with my dad as my coach were not terribly positive, and I didn’t want to get into those same situations with my kids. However, I had some success working with the rec soccer players, and wanted to try my hand at coaching at the competitive level. I continue to coach competitive soccer, almost 12 years later.

When I look at it, I often ask myself why I do it. As I get older, dealing with today’s youth is much harder. While some players play competitive soccer because they’re good at it and want to get better, others think they want to, except when they have to work hard at it. There’s a mentality that you can play a competitive sport as long as you don’t have to work very hard. I often reflect on why I continue to coach. I have enjoyed it. However, do I enjoy doing it now or do I do it because I’m good at it, and it’s expected of me? It’s a tough question to ask yourself. You reflect on your reputation as a coach and whether people expect it of you because you’ve always done it. You reflect on whether you're still good at it, and as a result others expect you to do it. What also makes it difficult is that I often put the happiness of others over my own happiness. So, the fact that others expect it of me, I feel I will be disappointing them or letting them down if I don’t do it. I’m starting to think that I continue to do it because I’m good at it and it’s expected of me. I can’t say whether I enjoy it like I have in the past. It’s an especially tough situation because when you’re good at something, you often feel pressured to continue to do it well after you’re done enjoying it.

Now, I will reflect on my career starting DecisionPoint.

When DecisionPoint was initially spun out of Sequent Computer Systems, it was a hallmark moment in my career. I was doing something I really loved, which was building data warehousing software that could help businesses implement a data warehouse faster than they could before with the potential of significant positive impact on their ability to analyze financial information for improving the business. Also, I was pretty good at it. I was leading the engineering team and providing them guidance on how the product should evolve. Additionally, I was heavily involved in the sales and implementation aspects of the business where I was helping to convince companies to buy our software, and then helping them successfully implement our product. There was one area that I didn’t enjoy, which was helping customers implement the software. This involved a lot of travel and time away from my young family. In one case, I was back and forth from Portland, Oregon to Boston over the course of eight weeks. In that case, I did it because I was good at it, and it was expected of me. I endured this because I knew it would only be short term. I think the thing that I enjoyed most about that time in my career was the diversity in my role. There was a lot of variety in what I was doing.

As DecisionPoint grew, I continued to enjoy what I was doing, and continued to be pretty good at it. We were a young company with a small set of employees, who were working together towards success. We didn’t have a lot of politics or hierarchies. We knew what we had to do, and we went and did it. We weren’t sloppy, but we were nimble, and could do what needed to be done.

When I look back on my experience at DecisionPoint, I realize that I reached a point where it was no longer fun. We did go through four different management teams, and there were a lot of changes in direction with each management team change. It was messy, and highly political each time. We stopped doing things because they needed to be done, and started to do things because that’s what the management team wanted to do, whether we the employees felt it was right or wrong. Also, the sense of teamwork was disappearing. There were cliques and subgroups forming, and a lot of sniping between employees. While I realize that some of it was an inevitable factor of a growing company, it just wasn’t something I wanted to do any more.

While I can’t pinpoint the exact moment, but I began to hit a phase at DecisionPoint where I was good at it, and I was expected to do it. The enjoyment was there every once in a while, but for the most part it was gone. As the founder of the company, I felt an obligation to stick it out. I felt that if I left, I would be letting too many people down. And, as I said before, I’m the type of person that’s pretty good at sacrificing my own needs for the needs of others. Not healthy at all, and I get that, but it’s a lot of pressure when you feel responsible for close to 100 employees.

I think the other thing that changed had to do with the philosophy change. I’ve said more than once that when I started DecisionPoint it was because I was passionate about what we could do. When I look back at what changed and caused me to like things less, I think it had to do with when we shifted to focus more on money. We hired some people that joined a startup because they thought it was a good way to build their resume, and hopefully make a lot of money eventually. Sure, that wasn’t everyone, but that element was starting to creep into the picture. Also, it was hard for me to accept that we were hiring people that weren’t as passionate about what we do as I was. In many cases, I again was doing it because I felt I had to do it. The enjoyment wasn’t completely gone, but it certainly wasn’t there most days I went to work.

We were struggling badly with sales of our software at DecisionPoint and started soliciting offers to buy the company. We attracted several potential acquiring companies that would benefit from our technology. One of the things that was re-motivating for me was the potential to enjoy what I was doing once again. No matter which company acquired us, we were looking at having to make significant changes to our product line. Also, the management team was not coming along to the acquiring company, so we were going to go back to the days where we were a core engineering team doing what needed to be done to convert our product to a new technology. That potential really appealed to me and motivated me.

It turns out that we were acquired by Teradata, and it was exactly as I had expected. Teradata was going to continue to sell our product, but the major focus was going to be on our effort to convert our product to support their technology. Teradata was a much larger organization, which might have been problematic. But, the way they handled it was absolutely brilliant. They gave us our direction as far as what we needed to do, and let us execute it. It was just like the early days of DecisionPoint. The core team working together to hit a target. We definitely had our struggles along the way, but I was back to a point where I was enjoying what I did, and I was good at it.

At the time of the acquisition, it was also nice because I was offered a “contract” to join Teradata. If I made a certain time commitment, I would get some rewards at the end of that time commitment. While that was very nice and flattering, that was less of a motivator for me. Money was always a good thing, especially when you have a family. However, having money and not enjoying what you do was not something I wanted to repeat.

Like DecisionPoint, after we finished our conversion of our product to work with Teradata (about two years later), we got more into the mainstream of the rest of the Teradata organization. That wasn’t necessarily a bad thing for our product, but was not necessarily something that was good for me. There were more people and politics to deal with, and more elements that influenced what we did or did not do with the product. Also, my job became less diverse. At first, within Teradata, I was leading the engineering team, but also doing a ton of work on the sales and marketing front helping people learn the value proposition of our product and how to sell it. It was a lot of fun. However, it was also slowly disappearing.

I fulfilled my commitment with Teradata, and continued to work there. However, I was again doing it more because I felt I had to do it and it was expected of me, not because I enjoyed it. My tenure at Teradata ended, and a couple of days after my last day, my daughter who had just graduated high school came to me and said “dad, I’ve never seen you this happy”. It hurt at first, because she was right. However, I realized her comment matched how I was feeling. I was working there because I was good at it, and felt I had to do it. I was too committed to other folks and the survival of the product. I really didn’t enjoy what I was doing any more.

When I started the job search after leaving Teradata, I was at a crossroads. I was making very good money at Teradata, but also realized I wasn’t doing what I loved to do. The challenge was to find something I enjoyed doing, but also being able to stay afloat from a financial perspective with two kids in college. My wife was very supportive, and we decided to use some of the money I had made from Teradata, and pay down our bills so that I didn’t have to take a job simply for the money. I had to enjoy what I was doing again. That was a must. I found that opportunity in Seattle, and we eventually moved from Portland to Seattle.

As I look at it today, I couldn’t have made a better decision. Generally speaking, I’m good at what I do, and I enjoy it. There are many days where I get frustrated and upset because the environment doesn’t move as quickly as I’d like. However, when I go to work and do the hands on work, I really enjoy what I’m doing. Sure, the money isn’t as good, but you can’t put a price on happiness. I know a lot of people hear that and think “yeah, right”, but it’s true. When I made the job change, I really did look for something I would be good at and be happy with. It has made a difference in my outlook. I do struggle at times with wondering whether I’m doing everything I’m good at, and whether I should be doing more because it’s expected. However, I always have to remind myself what happens when you start to do what’s expected even though you don’t enjoy it.

To round out this blog entry, it also factors into the definition of success. Many people feel that I wasn’t successful. I started a company that didn’t go public that was acquired by a larger company. I made some money, but not a lot. I don’t own multiple houses or “toys”. Many would feel that I should go back and do it again until I am successful, as defined by financial rewards. However, I would counter that argument with the fact that I wasn’t successful with DecisionPoint and Teradata because I wasn’t happy. Today, I don’t have as much power or authority as I used to have, and people would think I have to look for that again. However, I’m happy with what I’m doing, and I’m good at it. There are aspects of this job that I don’t enjoy, but the work is generally fun for me. I don’t need to be rich or famous. That’s not my definition of success. Sure, that doesn’t match a lot of how people view success. However, I have a job that I enjoy and a family that loves me, including two kids we are putting through college. So I leave you with this thought. What is the point of doing what others expect of you and something that you make a lot of money at if it makes the rest of your life miserable?

The Difference Between "Doesn't Know How" and "Doesn't Want To Know How"

Once again, a couple of recent events have inspired me to post another blog entry. This one is probably going to stir the pot a bit, and I'm sure there will be at least a few people that get upset with this post. However, it's something I think that needs to be said. I have heard a phrase that life isn't easy because it's not supposed to be easy. Each and every day we are tested by something new and different. It's a chance to help us learn and grow as individuals. It's not always fun, but some of my toughest life experiences are also the ones that I have learned the most from either about myself or about people I work with. In my personal email, I end every message with the quote "Hard work beats talent when talent fails to work hard". I absolutely believe this is true. I am a case study in what you can achieve when you work hard. I definitely haven't always been the most talented at things I've tried to do, but I've always dedicated myself to working hard no matter what I was asked to do or how I was asked to do it. To me, hard work is a critical component to success. I'd much rather have failed at something while working my hardest than getting a reward when I know I haven't given my best effort. There's an inner drive to everything I do that no matter what I am asked, I MUST do my best. Some people would call it OCD, and I'm ok with that.

Before I tie this back to my startup experience, bear with me for a bit of history...

Growing up, my mom's parents were farmers. When I was younger, it was a mix of animal and vegetable farming. As I got older, it was more vegetable farming. Both of my grandparents worked very, very hard their entire lives. They didn't make a lot of money, much like many farmers, but they were proud of what they did and their role in providing fresh meat and produce for others. They were both born and raised as farmers, and that's all they really knew. My mom and her sisters were also heavily involved on the farm growing up. It wasn't an easy life, but it's the one they knew, and all family members were committed to being the best at it that they possibly could. It was all about doing what was right for the family. They didn't like everything they had to do, but not doing it was never a choice. If animals needed to be cared for, or vegetables needed to be harvested, you had to do it. No one was going to come and do it for you. There really was no such thing as a day off when you're a farmer.

My sister, cousins, and I were also all expected to help on the farm when we were needed. The more hands we had doing the work, the less work each of us had to do. Probably my most vivid memories of the farm involved doing what we called "picking potatoes". This involved taking a plow, which sunk deep into the dirt and dug up long rows of potatoes. The plowing was the easy part. The hard part came after the plowing was over. After plowing, we had to get down on our hands and knees, pick up all the potatoes, and put them in a basket. After that, we had to move the dirt around to find any potatoes that were still covered, and put those in the basket also. When we filled the baskets, we put them in a wagon. When the wagon was full, we took the wagon to the house, and carried all of the baskets down to the basement of the house where they would stay until they were sold. It was something we did every August in temperatures between 90 and 100 degrees. We worked 8 to 10 hours a day for almost the whole month of August. People would ask why we didn't just use a machine. The reason was that using machines could damage the potatoes, which means that we couldn't get the most from the crop. Taking a day off was not an option because the potatoes needed to be harvested. No one was going to do it for us. It was just one example where I was "programmed", if you will, to do what needed to be done and do it my best no matter whether I wanted to or not. It's a trait that continues to run deep in my veins to this day.

Recently, in the local paper (Seattle Times), I was reading where there was a shortage in apple pickers and there was risk of losing some of the apple crop. They talked about how there was an attempt to take some of the unemployed in the area, and teach them how to pick apples so that they could make some money and provide for their families. The farmers that were interviewed admitted it was hard work. They also said that most people that tried it lasted less than a week because the work was so physically demanding. Even the people that tried it said it was the most physically demanding thing they had ever done. Even though they needed the money, people just quit because it was too hard. They weren't willing to do what needed to be done even though it was a way for them to make money and support their family. They would rather take it easy and take an unemployment check instead of trying to do what needed to be done. They were taking the easy way out, which I just don't understand. I haven't picked apples, but it did sound very similar to picking potatoes. Yeah, it's hard, but you do what you need to do. And...for the record...I wasn't paid to pick potatoes. It was just part of what was expected of you as a member of the family.

The reason I tell these stories is that they highlight something that is all to prevalent in our society these days. Not only did we run into this problem throughout our years in DecisionPoint, I also see it with people I have worked with since DecisionPoint. I hear some people say that they don't want to do something because it's hard or tedious. In some cases, if they don't know how to do it, they don't want to learn how to do it so that they don't have to keep doing it. They choose not to learn to do something because by not learning to do it, they won't be expected to do it. It's a simple way to avoid doing something you really don't want to do. This even includes things that are very simple to do, but are repetitive or tedious. We all have parts of our jobs that we don't like doing. That's just the way it goes. However, what I really don't like to see is someone that won't do something because they don't want to or don't want to learn how. As a society, we have become spoiled and pampered, and we are taught from an early age that if we don't like to do something, we don't have to. It's ok not to do it because someone else will eventually come along that will do it.

There were a number of times when I was working at DecisionPoint where people would not do something because they didn't want to, felt it was beneath them, or some other excuse. We had a lot of people that did what needed to be done regardless of the task. However, we also had a large number of people that would pick and choose what they wanted to do based on what they felt like doing or what they felt was worthy of their effort. It got really difficult to manage because eventually the "do whatever it takes" group looks at the "do what I want when I feel like it group", and they start to feel ripped off and resentful. Also, the HR rules and threats of lawsuits have become so overwhelming that it's nearly impossible to deal with the "do what I want when I feel like it group". As an employer, they feel you're expecting too much or being too unreasonable. For me, this situation generated the majority of my frustration at DecisionPoint. With my history growing up, it was just understood you did what needed to be done, and also understood that there were things you didn't want to do, but you did them because it needed to be done. I have termed this "situational effort" meaning that you're going to get someone's best effort based on the situation in front of them, and whether they're willing to do what needs to be done. I admit that I hated it and that it made getting something done very unpredictable, which can often spell death for a startup.

Over the years, I saw this type of behavior more and more. Even after DecisionPoint, I still see this behavior in coworkers. And, the older I get, the less patience I have for this. There are times that I think that I take it too seriously and let it get to me, but then I also think that we're letting people get off too easy these days. I believe that part of the cause of our current "great recession" is partially fueled by people that aren't willing to do what needs to be done because it's too hard or they don't feel like it. They do what they want when they want and the rest of society let's them off the hook because it's easier to accept it than try to correct it. When talking to people that I work with that share the same values and work ethic, I use a term for these types of people. I refer to them as "Generation Me". They are only interested in doing something or working hard when there's something in it for them. They don't have a concept of doing something for the greater good or because you have to do it.

I also see this in another aspect of my life, coaching youth soccer. In many circles, I am known as a coach that is tough, but fair. It's also well known that I expect a lot from my players. Not from a talent perspective, but from a work ethic perspective. I am far more accepting of a player that makes mistakes trying their hardest over a player that makes a mistake because they just didn't feel like trying or it wasn't worthy of their best effort. Players will tell me "hey, that's really hard...I don't think I can do it". The ones that try hard even though they're not sure what will happen are usually surprised that they can do it if they're willing to keep trying. I call this relentlessly trying. They're going to keep going and going until they're successful. The players that I have coached that show these traits not only become very successful in soccer, but more importantly, they become successful in life. It shouldn't surprise anyone to hear that the players that possess these traits are not the most physically gifted players. They've always had to work hard just to be able to keep up. Asking them to do a little more is no big deal because they're used to it. The more talented players will usually give up because they're not used to having to work so hard at something, and they don't understand why they should work hard. Part of being a good coach is setting goals for your players, teaching them how to work hard to achieve those goals, and then helping them celebrate when they've accomplished the goal.

This also carries over from the parents. The parents that I have had the best relationships with are the ones where the player has had the drive to work hard and has accomplished far more than anyone thought was possible. The parents I struggle with are the ones that think I push their player too hard and expect too much from them. Those parents would rather make an excuse so that their player doesn't have to work hard rather than expect the player to step up to do what is required. They are doing their children a great disservice when it comes to dealing with things in other aspects of their life.

By now, I'm sure this blog post hasn't been scrambled and hard to follow. It's a particular subject that I am passionate about and have some strong opinions about. In general, I think we have become a softer society because we have lowered our expectations of others rather than asking others to step up and meet higher expectations. They often say that people will only meet the expectations that are set for them. The best advice I have is for each person to learn to expect more from themselves. Try not to leave a trail of missed expectations and excuses that you may regret later in life.

It Shouldn't Be About The Money

It has been an interesting couple of weeks for me, which has prompted me to write a new post to this blog after taking a break. A couple of things have caused me to think deeper about my startup experience. First, the current political environment and the outrage towards the wealthy in our society. Second, there has been a lot of discussion amongst my former colleagues at Sequent where several are pondering how to get more traffic for their businesses. Third and last, the Sequent office in Weybridge (outside of London) closed down. This was the place I gave my last international class on the DecisionPoint Software. All of these events caused me to reflect on my experience starting DecisionPoint and what motivated me to start it versus the motivation I see these days.

I have stated several times in previous blog posts that I started DecisionPoint based on a passion. I was passionate about data warehousing, how people use data to have a positive impact on the business, and how we could take what was a traditionally a data warehouse market that was heavy in consulting and package that knowledge in software. The goal was to do something bigger and better in a way that had never been done before. In the back of my head, I knew there would be the opportunity to make money as we were getting started because the internet bubble was starting to grow. However, I couldn't look at it as just a way to make a lot of money. If it wasn't something I could get passionate about and throw all of my energy into, I couldn't see a reason to do it.

The reason I bring this up is that I see so many cases these days where people decide to try to start a company because they see something that's never been done before and want to be the first to do it so that they can "make a lot of money". I once heard a rumor from someone that said that the guy that built the iPhone flashlight app made over one million dollars from that simple invention. It was someone that was using as an example of how he might "get rich quick". Especially in the case of mobile computing, there are many examples of people that jump into something because they might be able to get rich quick without a lot of effort. Often, when you talk to these people about why they do it, there is really no passion behind their idea other than the potential of making a lot of money. The whole concept of building or doing something for the greater good is missing. Even the venture capital community facilitates this behavior. Venture capitalists want to invest in something that can make a huge return on their money, and do it as fast as possible to keep their investors happy.

There is a part of me that can see the motivation behind this. We are a society that is driven by money and social status. There is a lot of opportunity (both legal and illegal) to make a lot of money quickly depending on what you're willing to do or not do. You see it every day in a lot of different ways. There are companies and individuals that take investor money and rather than use it to better a company or group, put it in their own pockets for personal gain. There are internet ripoff schemes that take thousands of dollars from unsuspecting individuals. There are even individuals and groups that donate to political campaigns so that the politicians that get elected back their cause and influence rules and regulations to benefit their donor communities. When I look at this, I am saddened by how much we have become a society focused on money and power rather than a society that is passionate about what they are working on and trying to accomplish.

When I look at the team we formed when DecisionPoint was started, there was a lot of passion about what we were trying to accomplish. It was great because you knew the people you were working with would do almost anything to keep our dream alive. It wasn't about money. It was about doing something great that would benefit both companies and individuals within those companies. We couldn't just squander investor money and walk away from it. It was larger and more important than our individual goals and motivation. It was simply about doing something great we were all passionate about. It was so much fun working in that environment, and very stimulating.

The unfortunate thing that happened at DecisionPoint was that the last management team we brought on board started to focus on the money. We needed to make a profit, but several members of the management team were more interested in their own personal gain and reputation rather than doing the hard work to figure out how to move forward. It was easier for them to sell the company because they didn't have the same level of passion and commitment to the cause that the founding members had. For me personally, it was the beginning of the end. While I continued to work with some great people, they generally weren't as passionate about what we were doing as the founding members. In many ways, the passion was gone. I think that was more disappointing for me than the fact that the company was being sold to a larger organization. I did ok financially from the sale of DecisionPoint, but working for the larger organization was difficult because the same level of passion just wasn't available in the larger organization.

At the end of the day, I guess everyone gets involved in a startup organization for different reasons. However, it's my opinion that the highest quality organizations are started based on passion around a concept or idea. Something that the employees can rally around and commit to. If it's only about the money, people will only hang around long enough to see if the opportunity to make a lot of money is a reality or not. The commitment will only last as long as that opportunity exists. If the company is based on an idea that people are passionate about, the commitment to the organization will last as long as the passion exists.

I reflect on the non-work activities that I choose to participate in. The first is coaching competitive soccer, and the second is as a volunteer for the Congo Rescue Mission. Neither opportunity is one that I will ever make a lot of money at. However, I do it because I'm passionate about the cause. In the case of soccer coaching, I do it to help young soccer players grow to become better soccer players and individuals. It's about helping young people be the best they can be. In the case of the Congo Rescue Mission, it's about helping a close friend start an organization dedicated to helping others that are less fortunate and dealing with horrible living conditions. That friend did not start the organization to make money. He started the organization from a passion to help other people. Now that's something I can sign up for every time!!!

Life is not about the money I make. It's about the lives I've influenced and the people I've helped. That impact will last long after the money is gone.

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.