For the most part, information architects are communicators and strategists. While others merely tolerated the mishmash of responsibilities, they relished it. Designers often put up with having to write HTML but jumped at the chance to 'just do design.' Programmers were forced to meet with clients and work on strategy, but all along probably wanted to just write code. When these two ends of the spectrum split off, the empty middle was a perfect place to be. At the same time, there was an increased (but still hidden) need for information architecture. As the average web project process matured, more problems arose. Formal documentation was needed, business objectives were taking on increased importance, and, as the size increased exponentially, information organization became a much more important role. (The fact that this evolution took place during the 'dot.com fallout' is not insignificant, as this led to the placement of web projects under the same microscope as other business endeavors.) Some of these positions could be filled by existing disciplines; project managers, business analysts, and usability specialists transitioned from 'traditional' work and were added to web teams. Still, there was something missing. The connection between 'the big picture' (business strategy, high-level user tasks, basic structural architecture) and the nitty-gritty (categorization, labeling, bottom-up information hierarchies) often wasn't being made. This is where information architects fit in.