Thread regarding SAS Institute layoffs

I don't know if our friends that need a few more years will get them.

Age and salary are big targets on their backs.

Congratulations on your retirement. Ex-SAS Pre-Sales Dude nailed it, described my experience also. It is deeply saddening, for those of us who hoped to build products of lasting value.

When a train hits a truck, it's a disaster for those in the truck. This is like a train going off the tracks, where everyone in the train gets hurt.

The saving grace is, it's happening in slow motion. That makes it hard to watch. But it means that our friends who only need a few more years will probably get them.

Ex-SAS pre-sales dude gave the best summary of my experience with SAS - first as a customer, next in SAS Pre-Sales, then in R&D -- and finally, as of last Thursday - a SAS retiree :-).

It is sort of like watching a Train plow into a Truck at a railroad crossing... in slow motion. You can see that it's gonna happen, you know why - but you are powerless to stop it.

So sad for me as SAS has been a part of my life for nearly half of it!, and I still have a lot of good friends who need it to survive a few more years before they bail out.

In SAS R&D I saw engineering efforts duplicated both internally and externally.

When code was duplicated internally, no one was incentivized to clean it up. Rather, they were incentivized to add features. But sloppy code increases maintenance costs, so over time you add fewer features. Understanding that requires understanding software engineering principles, but people didn't. So usually nothing was done about internal duplication.

Our internal duplication increased, I thought, beginning in the early '90s. Previously, R&D more often followed software engineering principles, and accepted ideas from outside the company. As time went on, more people could not reason about software from first principles, because they did not know those principles. This not only encouraged sloppy code; it encouraged insularity, the "Not Invented Here" syndrome, because when you can't tell the difference between two alternatives, you stick with the one you know.

Around that time, we also began to get more external duplication, in two ways. First, as the previous poster says, we repeatedly built similar projects. When one failed, after several years, we'd build the same darned thing again. I attribute this mostly to the Peter Principle: the people given control of these projects were not our best people. This happens when you can't identify your best people: everyone gets treated as interchangeable "cogs" or "commodities".

Second, we sometimes built similar projects at the same time. This was often a result of silos not incentivized to cooperate. Sometimes it was due to individual managers growing their fiefdoms. But these duplicate efforts were less costly, because they were highly visible. So upper management usually did not tolerate them for long; eventually, they'd remove resources from all but one of the duplicate projects.

If the pattern holds, that will happen with SAS9 and Viya: one of them will be discontinued. But this is a special case: the intention was that customers would switch from SAS9 to the new Viya architecture. They haven't yet, so I suppose that Viya is still lacking features. Someone still at SAS would know more about the current state of these projects.

Speaking of a waste of engineering talent, and not going into which products I supported, I must have tread the same ground I had treaded previously at least three times.
The first time it was in one technology. The second time in another, and the third as part of a larger consolidation effort.

There was not a single product improvement in each of these efforts. Not a single one. Despite the best efforts of many, the Develop Manager in charge of this product did not want to make any of the changes to the mid-tier technologies, regardless of how clunky they were to use, or how loud customers complained. Only later did I realize that making changes to the product would be a 'razing of the shrine' to this person's vanity.

I then watched other efforts intended to calibrate how products worked with one another fail. Every time there was one excuse or another as to why some product couldn't coordinate with another on some lower technical level that would make the products more seamless for customers.

On another project, I watched one of the now anointed ones push his new pet project, a vanity project intended to munge three products together under a single platform, rationalizing it with a series of far-fetched use cases. I watched as this manager waived his hands hoping for some grand technical powers to 'make it so', while not actually communicating and coordinating with them and strategizing how to do the actual work; if he wished it, so it would magically appear. Um, no. This was another mess. I watched how this guy introduced his product to customers, only to have them tell him "this is a bad idea, please don't do this", only to have him ignore them and continue on with his vainglorious achievement. Maybe the product is a success, maybe it isn't.

I'll stop there. The whole experience was frustrating, and there was nothing marketable to salvage from it. Nothing. Not a single thing.

"the best engineering talent is more critical to the success of commercial software than any product manager or marketing initiative"

I'm not a software engineer (not in the last 20 years at least, when I switched to presales), but I totally understand and largely agree with this statement.

I also think that to get the most out of engineering talent, the organisation must be structured the right way. One thing I frequently observed with the SAS9 and SAS Viya products, was how frequently I saw the same functionality being delivered across different products in different ways, resulting in a bad user experience. Of course, this is also massively inefficient use of engineering talent.

Whether this was because of a poor organisation structure with different teams working in silos and not collaborating effectively, or whether it was poor engineering talent who didn't understand how to properly utilise object-oriented programming techniques...or a combination of both, I don't know. Perhaps some other folks here might have some interesting insights from R&D on this...

Post from TheLayoff.com

You make some valid points here. However, there is a lot of cr-p software outside SAS, presided over by Product Management/Marketing and built, using modern “agile“ processes that basically treat engineers like cogs.

Here is some FYI from someone who had a long R&D career and can lend at least some perspective.

The reason SAS originally built it sound C compilers were that for the targeted hosts (the mainframe, especially), suitable optimizing compilers did not exist. Eventually, these compiler products were discontinued, and those used by hardware and major OS vendors were adopted. What is impressive is the level of innovation and first principles computer science that SAS possessed to build these compilers in the first place, not to mention that this expertise was tremendously helpful as we ported to various host platforms.

As for the “not invented here“ mentality, that is a point well made. I can assure you a significant number of the most competent and dedicated developers did not follow that mantra and were willing/proactive in partnering with other vendors and even looking to external expertise to help with the design of critical components. roadblocks to this occurred, when business people were not willing to step up with the level of dedication and commitment that Developers had shown in the due diligence phase.

As to your point about Developers being “commodity resources” outside of SAS R&D, that is not entirely true, especially for the most innovative and driven companies where top engineers are compensated in 500k+ range because their technical insight and rare skills are understood to be critical to the success of the products. I know this firsthand having had a professional life after SAS R&D. I’m all but certain that the best engineering talent is more critical to the success of commercial software than any product manager or marketing initiative. This is the hard truth but those who don’t truly understand the discipline of software engineering have a hard time accepting.

So the lack of sales were due to forced reductions in product quality caused by inept management from one or more departments outside R&D. I will agree with the inept management part, but not in the reduction of quality being the cause for SAS's downfall.

Regardless of who you want to label as inept, SAS had a closed culture which nurtured delusional beliefs of technical impotence. For whatever reason, there seemed to be a culture which believed that anything not invented there was substandard; SAS developers seemed to believe they could build better versions of whatever and the world would just be in awe of it and snap it up in droves. Whomever perpetuated that belief was delusional; it worked here and there, but it was inconsistent.

Additionally, the culture was big on this Montessori nonsense, where special snowflakes would work in silos to create their own vanity products, show them to 'daddy', get pats on the back, and create new products from that. This style resulted in tremendous, unorganized waste. Why are SAS developers creating custom C compilers? Why create custom HTML 5 and Flex versions? Why? Off the shelf not 'good enough' for whichever prima donnas advocated for it? Apparently not. SAS believes they can do it better.

Now for a harsh lesson in reality...
Outside of SAS, R&D and Developers are simply commodity 'resources'. Product Managers and Marketing team members determine product direction. They produce the plans, and R&D and Development simply looks for ways to implement and execute upon that plan, to a schedule, and to a specified quality level. If they don't produce on that, they are replaced. For better or worse, they aren't Gods, they are easily replaceable commodities. All of us are now, unfortunately.

Reality hurts. Sorry to burst your bubble.

Thanks SAS-Proud for your explanation of the decline in R&D - very insightful!

The post from "anonymous" that says "you just don't get it" and "your smugness" warrants a response.

You're right, I had nothing to do with SAS before 2004 (other than a brief stint near the start of my career as a SAS developer for a year in 1995), so you're correct that I don't get what was going on pre-2000, that "SAS-Proud" has shed some light on. My original post was based on my observations from 2004 onwards.

As for "smugness", no that's not one of my emotions when I reflect back...but some sadness and regret.

A little sadness, for the people (both employees and customers) who have been negatively impacted by poor decision making by certain individuals at SAS.

Also, regret. I have regret. I should have left 10 years earlier than I did. A lot of that's about missed opportunity from being stuck in a privately held company where I got paid decent market rates but enjoyed none of the spoils of a publicly listed company. I look around at my veteran colleagues at Salesforce who are in similar roles and have been there for 15 years. Their restricted stock units, and subsequent discounted stock purchases have gone up in value by over 2000% in that time and are now worth many many millions. Same is true for people working for numerous other tech companies whose valuations rocketed up over that period. I made my choices, I'm not envious of others, I'm just reflecting on what could have been different.

That leads me to the planned SAS IPO. It's ridiculous...everyone knows that there is no growth left in this company so the only direction a share price will head in, will be downhill. The IPO is all about JG sorting out his family's inheritance so they can enjoy the $. Employees won't benefit at all.

The two viewpoints are easily reconciled. Lower quality R&D produced lower quality products that were harder to sell. It was cause and effect.

The interesting question is why R&D declined. I can't explain it by arrogance, except in a few individual cases. Most of the decline is explained by the Peter Principle.

I've never seen sales more clearly correlated with R&D than in this thread. Thanks so much for posting.

42 minutes ago by Anonymous | no reactions
Post ID: @1bjw+1mvhMg6t

…. Likely has no history with SAS prior to the year 2000. You just don’t get it. Historically SAS R&D had a good relationship with our customer facing sales folks, many more of us attended SAS (and other important industry) conferences in those days and also knew customers first hand.

Of course the dynamics, are more varied and detailed than what has been expressed in these relatively short posts. Yet, in your smugness, you act as if you seem to have some kind of special insight into what could have made things different — perhaps you do?. That said, you’re really close to the prize when you point out the decisions likely made by one person, who essentially holds all of the real power.

Reconciling these two comments is fascinating, and quite telling. There's no reconciling them, and this is why SAS struggles.

On the one hand, there is the pre-Sales guy who interfaces directly interfacing with the customers and the competing technologies. This commenter hears the customer feedback, experiences the wins, the losses, and the explanations for those losses. They also saw how internal decisions, most likely by one individual, hampered any ability to move forward and achieve more sustained wins.

On the other hand, we have the SAS R&D person who waxes nostalgic about 'the great intellectual horsepower' of R&D, and how that intellectual 'greatness' was 'stunted' by the politics of middle management. "If middle management had just gotten out of the way, we could have continued with our greatness..." It sounds like Al Bundy reminiscing to Peg about his glorious high school football days:

"Hey......hey Peg.......bring me a beer. If only I could have continued on with that Montessori model of employment, and they let me play with my technical toys longer, I would have eventually scored a winning deal for the company!"

"Oh, Al. You weren't listening to the customers or paying attention to your competitors anyhow. Other people had better customer focus and discipline to move their technical toys ahead of yours...Here's your beer, honey (kiss on the forehead). I'm off to go shopping with Marci. See you later!"

(Al sits on the couch, grimaces, and with his hand down his pants)

It seems that customers were giving SAS plenty of messages and opportunities, and whomever at SAS just didn't want to hear it. It seems that the company was stuck on this mantra "Look no further, we have the greatest Statistics products available. Just listen to us (you d-mb customers), we know what's best for you." That worked for awhile, and then competitors appeared; it stopped working. It's technical arrogance.

There is no reconciling these two viewpoints, and that is one of the reasons why SAS is in it's current state.

I would add to this that MVA SAS (beginning in ver 6) and beyond was less user extensible than the earlier generations of SAS which provided documented interfaces and capabilities for user written PROCS, functions and formats. This created a tenuous relationship with then long-term SAS allies in the academic community, who were accustomed to being able to implement new statistical, and other applied math techniques as user written PROCS.

Eventually the SAS Toolkit was developed for MVA, but I don’t think it ever gained much ground. At that point the damaged been done.

I attribute all of this to SAS’ slow departure from its R&D roots, beginning as far back as the mid 90s.

On that note, many reading or commenting may not understand the deep level of innovation going on within R&D in the 80s to mid 90s.

At one point someone from the outside stated that “SAS, is either the world’s largest statistical software package, or the world’s smallest operating system”. The MVA Host and Core layers were rigorously designed and programmed to allow SAS to be ported to and run on virtually any OS or machine architecture, while mostly having to only compile the existing core and application layer code (PROCS, Data Step, etc.) on each target platform. A full complement of OS level services including memory management, task, management and highly optimized machine code generation was commonly defined in the core layer with OS/platform specific optimizations and features implemented in the host layer.

SAS R&D had world class experts in many areas, including very deep in host OS internals and machine architectures. We even built our own C compilers. There was a significant amount of knowledge sharing and “cross pollination”. By the late 90s, this began to wither and by 2004 a micromanaging middle-management layer had all but taken over. Some of them even used their “authority” to keep developers, who had long been innovative, collaborators from communicating at any meaningful level. This marked the rise of the “political class” within SAS and especially with an R&D. I was there for the entire ride and witnessed it all. There is much more that I could share.

Hopefully this confirms and complements what pre-sales dude shares in the OP. There was definitely a cause-and-effect relationship between the micromanaged “d-mbing down” of R&D and what he experienced in the field with our products

RE "massive strategic blunder that SAS made in stopping it’s free use of SAS for education purposes"

Yes. By far one of the biggest blunders ever for SAS. I hold a big grudge towards management for this.