Scripps has become very puzzling. It is difficult to discern the governing priciples of software development ( DevelopmentPrinciples ) THe situation is best understood in its historical context. In the beginning, Scripps had two web initiatives. The first was owned by the Newspaper Division. They needed to get their content online and fast. But also cheaply. Newspapers operate on very tight budgets, and as the content is advertiser supported, they weren't making a lot of money. THis has not stopped them from trying though, and their approach of building simple, inexpensive systems has served them pretty well. At little later, it was decided that the category stations needed a web presence as well. Specifically HGTV. They viewed their site merely as an extension of reinforcement of their brand. HGTV was successful and money was no object. However, they ran into various problems with ISP's, vendors, carriers, etc, and decided that the whole effort needed to be brought in house and controlled. After a couple of years, the newspaper group was centrally managed by a staff of 5, but the category group had at least twice this, and as the internet became more critical to business, it became clear that the newspapers would have to start thinking about their sites along similar terms as the category division. With the new focus came bigger projects and bigger bills. And so this is the crux of the conundrum. On the one hand, I'm excited becasue now we can focus on doing a good job technically, but on the other hand, the bottom line trumps all. How do we balance cost, strategy, technology and ROI? Consider the SHNS (ShnsContentFlow ). We isolated the performance issues, the technology issues, the architectural issues, and even bits of strategy that need to be addressed, but did we end up doing anything about it? No. I applied the best band-aids I could to keep them going, because we are too married to the sweetheart hosting deal they have in DC. But I ask you, just because it's cheap doesn't mean its the way to go. Doesn't the site have value? Should we be willing to invest in its value? Should we expand its value? And doesn't the current set up leave the brand at risk? Isn't the lesson from HGTV that it's all about the brand? So there you have it. To pieces of the puzzle that don't quite fit together. So how to we fix it? Split them back up? Not smart. Clearly there is overlap. Just use separate account reps? I don't think that will ever work. Clearly, the coordination of the two agendas will end up favoring one of the two halves, leaving the other feeling cheated, if not suspicious. One thing is certain, Bob is happy when teh NT group are helping him, and it has nothing to do with NT. I don't work close enought with Ron any more to know what makes him happy, but I hear it isn't the current situation. The current investment in FF leaves the newspaper div with too much skin in the game to back out, and it does work for those that could afford to implement it. Th ecurrent FF is too expensive to roll out and possibly even to keep up with, especially with vignette dropping tcl in favor of J2EE. Let me make these observations - Vignette is dropping TCL for java as a marketing move because that is what the market wants. The market may not be very rational, but it is what it is. For that reason, customers will always get orphaned and forced into unneeded upgrades that are driven by shareholders and release cycles. In my mind it is just another reason to leverage open source technologies - the upgrades are for what is needed. Tomcat doesn't change because they need to trigger another buying season. They fix bugs and add features in generally the most prudent fashion - on the basis of need. FF is too expensive because they never bothered to build the tools they would need to manage and roll out sites, and the schema is overly complex. This was a result of planing for the unknown at every turn. If only they knew more about what to expect. Also of trying to put EVERYTHING in the db. Lastly, they still do not ''get'' XML. The internal use of NITF is worthless. I still contend, binary formats should be translated into xml representations of the their actual structure, XSL should be used to transform that into a format compatible with the db, and the those documents should be ingested. Support becomes simple, and flexibilty is preserved. WHen it comes to trouble shooting, the first XML doc will tell you if you are dealing with the original format properly, or if there is some deviation. When it comes time to ingest to the db, that code is very simple and less bug prone, and the xml doc clearly shows what will end up in the db and where. In between you have xslt which is simply concerned with the translation. issues of parsing and generation become consistant and generic, now only the exceptional stuff has to be worried about. Plu sstatements like 'We support NITF' are worthless. I helped write our spec. We had to bastardize it to accommodate our needs, so our NITF is not the NITF from other sources, and what will we do when the industry upgrades its definitions of NITF? Our whole feed chain end up at the mercy of an NAA commitee. BUt I digres... I ''grew up'' with the newspapers, so I know a little more about what they want and need than the category side ( does the broadcast division even exist anymore ;-) ). I hear phrases like accountability, responsibility,etc. I think these are all just code words for a lack of trust. And nothings instills less trust than phrases like 'trust me' and "you wouldn't understand". Also, it is becoming clear to me that there now little future in this space, as we show preference to vendors over our in house folk. Our goal is to provide the same or better service/functionality at a lower price than the vendors because we work for cost with no profit overhead and have more familiarity with the customer. IN short our goals are more aligned. THat's all well and good, but we have also been structuring ourselves to include all of the overhead that outsiders would include. IN some cases, we have more overhead than the vendors. And we've actively brought in leadership for from other industries whose vision is not aligned to the divisions ( essentially seasoned neophytes ). It almost seems a battle we are intent on loosing. Today I received an email from PowerOne touting their new DisplayAds taking "display ad publishing farther than anyone else by building the Display Ad Viewer, (screen shots to the left and below) an easy-to-use, browsable display ad directory that increases advertiser visibility through smart indexing, a page-through utility, and call-to-action functions such as web site and email links as well as maps and directions to the advertiser's business." Bullshit. I've had that for three years now. Anyway, back to the task at hand, solving the puzzle. I'm thinking the concept of technical product managers makes some sense. It seems to fall to the KeyMan argument, but that's not the case. Success generally depends upon a combination of vision and leadership. Technical as much as business. Such groups already exist on the business side. We already have this in a de facto sort of way. Craig owns search, back by me and Sharon. Jeremy owns stats, backed up by Sharon. I own Classifieds, back up by Phil and Sharon and Brett(?) and Dale. Ownership brings the "-ilities" desired from the two halves as mentioned earlier. And if someone is going to be somehow responsible for something, they pretty much have to own/control it. This sounds like the dreaded Silo Syndrom that some fear. But the converse is the stratification strategy we have now, where person x writes X type code, no matter what the application, and person Y does Y code, but because persons X and Y have no concept of the application as a whole, they each have to rely on Person Z. Person Z is charged with a complete and deep understanding of all applications, and can only split his time 50/50 across the two. The time diminishes as applications are added and new Z's are added, slowly the the number of Z's grow, but the Z's, while perhaps understanding the application , don't understand the implementation. Also, the Z's end up competing for X and Y's time, and someone is needed to referee who has priority for X's and Y's time. The alternative is to not share X's and Y's, but instead add more of them. So lets examine the silo. Generalists are hired as X's and Y's. The individual silos can be shares between the puzzle halves, or not. Because X's and Y's are now so similar, they can trade back and forth between projects much easier, but most importantly, those involved in a project have a deeper, more thourough understanding of the implications of changes, and can better anticipate future needs. Further, the less specialized skill sets make for projects that other generalists can understand and pick up on. In the strata model, its much harder to get help for the java layer from the tcl layer. Also, under the silo model, communications between layers of functionality tend to be quicker, because the communications path may be much smaller. Strata: movement between projects easy, but technology hard. Silo: movement between projects less easy, but technology also easy. It used to be that moving between languages was easy. They were all based on a common ancestry ( ansi c ). But today, the languages used are a less significant part of the overall picture. Today, the focus is on platform and architecture. Common protocols, standards, etc make the language much less important. Language is just a tool, and your better off having more tools so you can use the most appropriate. My new theory on why ff rolls along and classifieds is mired - http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING Perhaps I should JoinTheNewspaperDivision.