TSR TSR's Amazing Accounting Department

[Parmandur]

At first, TSR was run by gamers who knew very little about business. Later, TSR was run by business people who knew very little about gaming. Neither worked well.

Worse, the business people didn't seem to know about business, either.

 

[Tyler Do'Urden]

Speaking as a businessman (an MBA, no less!) living in 2019, looking back at business practices just a few decades ago... the idea that a company like TSR would be run by people who weren't enthusiastic about the product seems absurd. Today, upper managers are expected to be obsessive about everything their company does - it's product, it's history, the contours of the industry... the management-is-management model is dead. Even in the massive, dull megabank that I work for, we're expected to be "passionate team players", and while I'm a pretty deep cynic about my firm, I'm pretty obsessive about my industry - delving into history, the dynamics of the industry, new product, etc. The idea that the heads of a game company wouldn't be even more focused just seems nuts, especially given that's not exactly an industry known for generating great fortunes (Peter Adkison's Poke-Millions aside)...

 

[Joshua Randall]

Also, I hate Agile. I can see the benefit of Agile, but in my experience using it (I am a project manager for a large company), the actual amount of work you get done compared to waterfall is much less.

I roll to disbelieve.

 

[BookBarbarian]

At first, TSR was run by gamers who knew very little about business. Later, TSR was run by business people who knew very little about gaming. Neither worked well.

It seems like a few of them were business people who knew very little about business.

Double posts aren't unusual. But 12 minutes apart? LOL.

Also, I hate Agile. I can see the benefit of Agile, but in my experience using it (I am a project manager for a large company), the actual amount of work you get done compared to waterfall is much less. Spending so much time talking about backlogs and burn down charts and stand up meetings, that you have less time to actually work on your project. Sprint planning never goes as planned or is finished on time, which causes delayed sign off, and people keep trying to change the acceptance criteria after user stories have been signed off. People seem to think that because there is no formalized and approved FSD or BRD, that means requirements are fluid and can change at any time, even after the QA process has begun. It's frustrating. But it's the big thing right now. Like Six Sigma (also garbage for any non-production line environments) was 15 years ago.

It hurts me to see Agile automatically associated with Scrum.

This remains the Manifesto for Agile Software Development:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

A lot of very smart people came up with it or at least put their names on it.

Strict adherence to Scrum process flies in the face of all that. And I say that as someone who actually likes a lot of the scrum ceremonies as they seem to take a lot of the the random willy-nilly conversations I every 15 minutes often the same conversations multiple times a day just with different people, which really kills productivity, and regiment them. But it's certainly not the only way to curb the communication problems common to development. And should never be held with religious like reverence.

 

[JLowder]

I suspect Jim means the 1980s for getting the catalog material done further in advance. In 1988, when I started with TSR, the company was already working with advance catalog copy and cover art. Editors and line heads had to provide summaries of content for each product, along with cover art orders, months ahead of time, frequently well before the books were written. (That's how you end up with the occasional cover–product mismatches, like Tantras, both novel and module. The Avatar covers were painted long before the novels and the modules.)

RPG Geek has entries for many of the TSR company catalogs from the late 80s and 90s here: https://rpggeek.com/rpgseries/19204/tsr-product-catalogues

Between 1988 and early 1994, when I stopped working with TSR, the overall movement had been to complete products earlier, for a variety of reasons (to provide near-finished books to fiction reviewers who wanted galleys six months before publication, to have more time to schedule for the best print costs, to increase overall schedule flexibility, and so on). By the mid-1990s, the company was completing RPG and fiction material further ahead of ship date than they had in the late 1980s. And that meant an increase in the time gap between when the freelancers were being paid for a product and when the company brought in any money from that same product. (Random House typically paid TSR on ship.)

TSR's cash flow problems made themselves known outside the company by 1995 or early 1996, when the company started to pay bills late. By 1996, they had stopped paying me and many of the fiction authors the royalties that were due quarterly. They owed a long list of individual writers tens of thousands or hundreds of thousands of dollars. And that's just the debt for late/unpaid fiction royalties. Freelancer payments of other sorts had become routinely late, too. As we know now, TSR was in a financial tailspin.

If a dictate on the production schedule--shortening up the time between project completion and ship--came down from upper management, that would have been why. The completion–ship gap was one of the few areas where TSR could control the pace of the cash outlay for products. Shortening the gap to one month is ludicrous, of course, but it would not have been unusual for management to go completely overboard on such a dictate. That's just speculation, though. I was outside the company at that point and did not see that dictate play out firsthand.

--James Lowder

 

[Sacrosanct]

I roll to disbelieve.

I'm sure part of it has to do with what type of environment you're in (I imagine a smaller shop would be much better suited for Agile), but I've done waterfall for 16 years, and Agile for the past 4. I'm telling you, in my experience, Agile slows down how much work actually gets done because you're spending more time bouncing around ideas no one ever comes to consensus on on rather than have a stricter timeline of checkpoints and documentation to follow. Not once did I have requirements change in the FSD after it had been approved with waterfall. Happens all the time in Agile, which drives the testers mad because the stuff they just spent their time testing now and suddenly becomes irrelevant. LOTS of wasted effort in Agile, especially around that area of QA testing with stories constantly overwriting previous ones that haven't even had that sprint finish yet.

 

[Sacrosanct]

I suspect Jim means the 1980s for getting the catalog material done farther in advance. In 1988, when I started with TSR, the company was already working with advance catalog copy and cover art. Editors and line heads had to provide summaries of content for each product, along with cover art orders, months ahead of time, frequently well before the books were written. (That's how you end up with the occasional cover-product mismatches, like Tantras, both novel and module. The Avatar covers were finished long before the novels and the modules.)

RPG Geek has entries for many of the TSR company catalogs from the late 80s and 90s here: https://rpggeek.com/rpgseries/19204/tsr-product-catalogues

Between 1988 and early 1994, when I stopped working with TSR, the overall movement had been to complete products earlier, for a variety of reasons (to provide near-finished books to fiction reviewers who wanted galleys six months before publication, to have more time to schedule for the best print costs, to increase overall schedule flexibility, and so on). By the mid-1990s, the company was completing RPG and fiction material farther ahead of ship date than they had in the late 1980s. And that meant an increase in the time gap between when the freelancers were being paid for a product and when the company brought in any money from that same product. (Random House typically paid TSR on ship.)

TSR's cash flow problems made themselves known outside the company by 1995 or early 1996, when the company started to pay bills late. By 1996, they had stopped paying me and many of the fiction authors the royalties that were due several times a year. They owed a long list of individual writers tens of thousands or hundreds of thousands of dollars. And that's just the debt for late/unpaid fiction royalties. Freelancer payments of other sorts had become routinely late, too. As we know now, TSR was in a financial tailspin.

If a dictate on the production schedule--shortening up the time between project completion and ship--came down from upper management, that would have been why. The completion–ship gap would have been one of the few areas where TSR could control the pace of the cash outlay for products. Shortening the gap to one month is ludicrous, of course, but it would not have been unusual for management to go completely overboard on such a dictate. That's just speculation, though. I was outside the company at that point and did not see that dictate play out firsthand.

--James Lowder

You wrote Ring of Winter? I really enjoyed that on my flight from Portland to Seoul for my first deployment as a young private in the army back in the day. Thanks for the good memory!

 

[JLowder]

You wrote Ring of Winter? I really enjoyed that on my flight from Portland to Seoul for my first deployment as a young private in the army back in the day. Thanks for the good memory!

I did indeed. Thanks for the kind words!

--Jim Lowder

 

[EthanSental]

Does audible count for Ring of Winter? Great novel!

 

[Lanefan]

As an accountant, Just-In-Time (JIT) is popular and can result in reduced storage costs.

Having worked in companies that ran their key operations on JIT I twitch every time I see the phrase, because far too often in reality Just-In-Time ended up as Just-A-Bit-Late; which is a [female dog] when you're expected to make sales targets on product you don't have...