Thread regarding SAS Institute layoffs

R&D - Why this org structure is weird and problematic for a software company

A lot of people who post here are from SAS R&D. Are you aware of, or have even thought about, the fact that products being developed for market by an R&D function is not normal for a software company?

It's normal for some industries like pharmaceuticals, or semi-conductors, but not enterprise software. These industries know more about the problems their products are trying to solve, than their customers. That's why they are research led.

Enterprise software, on the other hand, is about solving business problems that their customers understand better than anyone else. So while enterprise software vendors typically have research labs, those business units do not build the software products that are monetized. Instead, they have "Product Management" and "Engineering" business units. The first of which is about understanding what to build, and the second to actually build it. Research labs contribute, but they are typically small, agile units, that are not in any way customer facing.

The key point here, is that "Product Management" as a business function, is designed to provide the link between customers and sales, and "Engineering". So their role is to listen to what customers are saying, and research what competitors are doing. They are outwardly focused. Since leaving my pre-sales role in SAS, and taking a similar role in a more successful modern tech company, this is a stark difference. "Product Management" are always willing and keen to have a call with a customer to discuss their specific needs. It's part of their job description.

Contrast this to when I was at SAS, and it was virtually impossible to find anyone in R&D who was willing to listen to us in pre-sales who were engaging directly with customers, and even harder to get them to have a call directly with a customer. I can only assume, that nobody had the role to actually listen to customers.

And from my observation, this attitude came all the way from the top. The Big German certainly wasn't interested in hearing from customers - I saw that first hand at an EBC visit. His ego couldn't handle people providing negative feedback on his baby.

SAS's lack of a proper "Product Management" business unit, I believe this is one of the major reasons that SAS has failed. It's structured like a research institute, rather than an enterprise software company. That may have worked 1980's, but it's a totally inappropriate business model for a 21st century software company.

by
| 2871 views | | 22 replies (last January 11, 2025) | Reply
Post ID: @OP+1wdnm2Pu

22 replies (most recent on top)

“Had the company actually rewarded performance…”

I once had a manager tell me that I could continue working more than 40 hours per week if I liked — but that he had no authority to reward me. It was the kindest thing he ever said to me.

This business model worked, as long as the SAS campus and benefits were better than other employers’. That’s no longer true, but it was true for a long time.



What did us in, IMO, was not failure to reward good performers, but failure to promote them.

We ended up with leaders who were skilled enough to maintain an existing revenue stream, but unable to create new ones. 



Once our main revenue stream acquired Open Source competition, that flaw was fatal.

by
| | Reply
Post ID: @23g+1wdnm2Pu

People in R&D at SAS pretty much don't listen to anyone but themselves. It's the legacy of the company being founded by someone who codes.

SAS has been (past tense purposely used) successful in spite of itself and its significant flaws.

Had the company actually rewarded performance instead of those who are FOG (friends of Goodnite), it could have been wildly successful and not fallen behind as newer companies were formed that ate its lunch.

by
| | Reply
Post ID: @1zp+1wdnm2Pu

"The single idea of V9 compatibility would have guaranteed a ready market. And that’s not “armchair quarterbacking”: that idea was suggested by multiple people at the time."

It wasn't just suggested by multiple people, it was the key message we were all sold at the time. What did they call it? ..."One SAS" or something like that, I recall. It was this idea that v9 and Viya would converge into one seamless, backwardly compatible, glorious and righteous analytics platform that customers would fall over themselves to have, because it would solve all their problems faster than ever before. Many of us thought it was BS at the time, and so it was.

by
| | Reply
Post ID: @113+1wdnm2Pu

Thomas D. is over here. His first post was about SAS:

https://thomaswdinsmore.substack.com/p/whats-next-for-sas

by
| | Reply
Post ID: @10s+1wdnm2Pu

Some of the content on this thread reminds me of the pithy style of Thomas D. I miss his writings. Can't help but wonder if he randomly pops in here briefly...

I do like good(appropriate) sarcasm.

by
| | Reply
Post ID: @10m+1wdnm2Pu

"The single idea of V9 compatibility would have guaranteed a ready market."

But but but, Viya is so wonderful that no one will want V9!!! Full speed ahead, it is Viya or nothing!!!!!!!!

Sarcasm mode off. At least they got nothing. Sad that greatness spiraled down so fast. Gravity su-ks.

by
| | Reply
Post ID: @yn+1wdnm2Pu
I was focusing on all the armchair quarterbacking on this site.

Whatever. You do you.

by
| | Reply
Post ID: @wx+1wdnm2Pu

“The ideas we offered were not listened to” describes my experience also, on many projects besides Viya.

SAS promoted mediocre managers, who were threatened by ideas not their own.

Intolerance for ideas stifled innovation, and in Viya’s case, marketability. The single idea of V9 compatibility would have guaranteed a ready market. And that’s not “armchair quarterbacking”: that idea was suggested by multiple people at the time.



When I look back on my SAS career, I think, maybe that one idea wasn’t so great; or maybe I could have presented that other idea in a better way.

But fundamentally, SAS was a place that discouraged ideas. And a tech company that discourages ideas cannot grow.

So it shrinks.

by
| | Reply
Post ID: @ws+1wdnm2Pu

“ And in the context, what “great ideas” are you defending and why have they not borne positive fruit leading to a successful, growing company?”

Show me where I ever said I was defending great ideas at SAS.

I was focusing on all the armchair quarterbacking on this site. Why would you equate that to me arguing for the greatness of SAS? Making sh-t up?

by
| | Reply
Post ID: @wr+1wdnm2Pu

@w6+1wdnm2Pu

@w5+1wdnm2Pu is truth telling in way that has nothing to do with your assertions of “armchair quarterbacking”.

And in the context, what “great ideas” are you defending and why have they not borne positive fruit leading to a successful, growing company?

With inflation factored, why hasn’t SAS grown significantly, while the tech sectors it participates in have exploded over the last 20 years?

@w5+1wdnm2Pu just told you why.

by
| | Reply
Post ID: @wa+1wdnm2Pu

"The problem is the ideas we offered were not listened to, or initiatives we kicked off were given insufficient focus and resources to bear the fruit they could have."

Maybe your ideas were terrible? Maybe it would have born poisonous fruit if given resources?

armchair quarterbacking...

by
| | Reply
Post ID: @w6+1wdnm2Pu

@vj+1wdnm2Pu

Right on! Many of us were not only playing our roles on the team with excellence, but also expanding our vision to what was possible as technology and business models moved forward.

We did much of this outside of work hours and with very little to no monetary compensation for the time and resources we used to continue learning. The problem is the ideas we offered were not listened to, or initiatives we kicked off were given insufficient focus and resources to bear the fruit they could have.

It was as if new innovation had to be rooted in, or controlled by management structures and internal administrative or technical infrastructure put in for earlier generations of SAS technology.

This significantly impacted SAS’ Ability to become a major enterprise software vendor prior to Cloud Computing becoming a preeminent platform model, while virtually guaranteeing we would remain years behind in ever developing effective technology for cloud deployment and SaaS success as a mainstream data management and analytics provider.

Viya sadly represents the zenith of this trajectory — infrastructure is not cloud first; UX is bloated; enough traditional SAS carried forward to make customers desire compatibility with V9 but it’s not there.

by
| | Reply
Post ID: @w5+1wdnm2Pu
Unless you are one of them making the decisions then you are armchair quarterbacking…

No, not when you're also playing but the quarterback is ignoring you and the rest of the team, thinking he/she can win the game completely on his/her own.

by
| | Reply
Post ID: @vj+1wdnm2Pu

@2qaw+1wdnm2Pu Most of the criticism is of JG, Big German, Photographer, JP, BH

Unless you are one of them making the decisions then you are armchair quarterbacking…

by
| | Reply
Post ID: @vg+1wdnm2Pu
Correct. SAS is structured more or less like it was in the 1980s.

Really? With the ridiculous number of internal reorganizations instigated by C-level turnover, it is still structured like it was in the 1980s? How is that even possible?

by
| | Reply
Post ID: @th+1wdnm2Pu

“It's structured like a research institute, rather than an enterprise software company. That may have worked 1980's, but it's a totally inappropriate business model for a 21st century software company.”



Correct. SAS is structured more or less like it was in the 1980s. Back then, neither UX Designers nor Product Managers existed at software companies.

Now, both are present at SAS. But in my experience, UX Designers had little power. I saw R&D managers make decisions based on features, and I never saw a release delayed to fix usability problems.

It seemed to me that product managers had more power than UX designers. But neither had much influence on Viya.

Probably neither could have predicted disruptive changes; the Innovator’s Dilemma still applies.



But professional software development — using modern techniques, not those of the 1980s — could have ensured that Viya served its target market.

by
| | Reply
Post ID: @k5+1wdnm2Pu

We were anything but armchair when we were doing it. Thankfully, we got out in time. 😉

by
| | Reply
Post ID: @2qaw+1wdnm2Pu

armchair quarterbacks. Get out and do it...

by
| | Reply
Post ID: @2die+1wdnm2Pu

Good point made by the commenter who mentioned Forestry and Philosophy degress being ill suited for R&D leaders. Ore than one joke was quietly cast in disgust abot that.

Anything "sappy" is considered cheesy, saccharine, clichéd, ludicrous, or goofy.

Photographic(pun intended) memory not required to cipher the who.

What was Big Jim thinking....what possibly could go wrong!

by
| | Reply
Post ID: @2ebs+1wdnm2Pu

Imho there were a few product managers and engineers who did well enough "listening to customers". Easy to be order takers in the good times, and a very good strategy. However, the innovator's dilemma ki-ls the tech companies who can only do that. Listening to "customers" at the high end is not the same as listening to the overall market and the disruptions that come from "below". As articulated in many ways before, there isn't a proven way to solve the innovator's dilemma, but SAS failed pretty exceptionally in a classic way (sticking our heads into the sand, and having absolutely zero clue what is actually "research led" and what is not). There are probably many reasons for those willful and blind delusions, much of which has been covered in previous comments. TLDR - The chief reason was likely hubris, but of course there were various political machinations at fault as well. The people who made those countless mistakes also may not even realize it to this day.

by
| | Reply
Post ID: @1nki+1wdnm2Pu

Product Management is about a century old, but has been applied to software development only in recent years.

Listening to the customer does not require Product Management. Anyone trained in Software Engineering knows that User Experience is critical to product development.

However, recent SAS R&D leaders had no such training. They held degrees in Forestry, History, Philosophy, Communications, Statistics — not Computer Science, not Software Engineering, not Computer-Human Interaction.

They were never trained to let their customers inform their design. And if they decided not to let Product Managers do that either — then nobody did it.

In its early years, SAS succeeded because it was designed by statisticians, for statisticians. They didn’t need Product Managers, or UX Designers. They knew their customers, because they were their customers.

Viya repeated a development model that worked fifty years ago. But today, even a product designed for statisticians attracts few statisticians, because they have free alternatives in R and Python.

And if it wasn’t designed for enterprise customers, either?

To all SAS employees, good luck in 2025.

by
| | Reply
Post ID: @1jpj+1wdnm2Pu

Some summarized history.

What made the core SAS products successful was a cohesive architecture (MVA) portable to virtually any host target. It was mostly built by young, bright developers who worked cooperatively (with plenty of conflict at times) to create something of lasting value. I believe it is incorrect to conclude SAS was a “enterprise software vendor” prior to at least the year 2000. It is also true that many developers met with customers at regional and national users groups on a regular basis. The focus was on building rock solid data management/manipulation and analytics tools based on the original SAS language paradigms.

That’s what made the founders billionaires. Being a privately held company that did not offer equity, the hard work of those few hundred early developers, and other customer facing and tech-support people was not sufficiently rewarded such that they could move on with their lives/careers and open up opportunities for “new blood” to come in. Instead, they unique-for-the-time perks of SAS retained most employees as the company continue to grow. A problem was that not all of those employees grew their skills as the company grew nor kept up with industry technology and business trends.

Instead most people stayed in SSS R&D and several were promoted up the ranks Into senior line and Director positions. A few became VPs. By 2002 or so, micromanaging was the norm … just as SAS was trying to establish itself as an enterprise software vendor. The relatively small number of Directors and VPs in many cases acted as the de facto architects for V9, along with emerging vertical products.

These execs often played things “close to the vest” and some of the most trusted Innovative devs from the prior 20 years were not effectively utilized or allowed to have the technical decision-making that could’ve made a big difference. Project management was nascent at best and the company had already grown to a size where Devs no longer had much, if any direct contact with customers, especially as developer attendance at conferences got smaller and smaller. This created a malaise that continued on for at least another decade.

There were shake ups led by two R&D rockstars who ultimately became senior leaders in the company. One would be ceremoniously escorted off campus around 2010 or so. The other would go on to create a number of successful analytics procedures, and various high-performance computing and in-database analytics software. Ultimately he would lead the technology initiative eventually branded as Viya.

A handful of us in R&D who were not managers did go out to major customer sites, even in the case of Viya. The local pre-sales folks were always delighted and bonds were formed that made POC’s successful. The problem is an Dev IC could put their career at risk by doing this, especially by attempting to repeat it.

Political feathers could easily get ruffled within the management hierarchy. For some of us ICs, this and similar actions was simply stepping up and doing the right thing, but if it ran afoul of a Director or VP’s agenda, then look out.

Most of these problems exist everywhere because they are such a part of human nature, yet appear especially ingrown in the history of SAS.

by
| | Reply
Post ID: @1mmd+1wdnm2Pu

Post a reply

: