Organizing a Digital Technology Department of Medium Size in a Media Company

There are many good ways to organize your technology department. This article presents some of them. It is written for a CTO or VP Technology leading a medium size department looking for suggestions on organizing or reorganizing your Digital (Web, Mobile) technology department. It is best suited for you if your organization has the following characteristics:

  • You manage software engineering, implementation and technology operations for 3 or more digital brands.
  • Yours is a medium size technology department with somewhere between 20 to 100 technology staff.
  • Internal corporate IT functions such as desktop support, telecommunications services and internal business systems are beyond the scope of this article.

The Venn diagram below presents one model of organizing your department into 3 sub-departments.

Web Technology Department Organization
Web Technology Department Organization Venn Diagram Illustrating Purposeful Overlap Among Sub-Departments

Some CTOs in smaller companies organize their technology departments as 2 sub-departments: Software Engineering and Technology Operations. Software engineering is the function that is responsible for developing and implementing Web & Mobile application software. Technology Operations is responsible for running, maintaining and supporting the Web applications.

If you operate 1 or 2 digital brands (Web sites), having these 2 sub-departments is a good approach. For 3 or more Web sites, organizing Software Engineering into Site Engineering and Platform Engineering has some benefits.

Site Engineering is focused on working on the Web sites’ direct projects. Its work includes

  • Small and large projects for adding or changing functionality on the Web sites
  • Bug fixes on the Web site applications

Platform Engineering is typically smaller than the other two organizations and typically includes functions like:

  • Architecture across sites
  • Shared applications across sites
  • Common libraries across sites
  • Research & Development (R&D)

Technology Operations includes functions such as:

  • Systems & Applications Administration
  • Infrastructure Management
  • 24×7 Tech Support
  • Builds & Configuration
  • Release Management
  • Testing & Quality Assurance (QA)1
  • Technical Analysis
  • Technical Project Management
  • Budget Management

These three departments have purposeful overlap of responsibilities as illustrated in the Venn diagram above. That helps minimize the chances of the departments becoming silos with walls between them. For success, it is important that your entire department functions as one integrated unit. Some shared goals & responsibilities are required for mutual success.

DevOps2 is a set of processes, methods and systems for communication, collaboration and integration between departments for Development (Applications/Software Engineering) and Technology Operations. Its purpose is to facilitate meeting business goals by producing good quality software products and services in a timely fashion. It is where development methodologies (such as agile software development) occur in an organization with separate departments for Development, Technology Operations and Quality Assurance. Development and deployment activities that need deep cross-departmental integration with Technology Support or QA require intimate multi-departmental collaboration.3

DevOps
llustration showing DevOps as the intersection of Development (Software Engineering), Technology Operations and Quality Assurance (QA)

To make this work, you need 3 directors who head up these departments who work well together, collaborate often and are not sensitive about their turf. They should know that a successful technology manager is not an individual-only contributor, but a great team player with peers. They should have strong goodwill among each other and welcome each other to work directly with their teams. Such a collaborative team is essential.

Article Updated: September 25, 2010

  1. QA can also be set up as an independent department. []
  2. WikiPedia entry on DevOps []
  3. Article: What is DevOps? []

Project Management: Time to Market, People & Teamwork

Starting early, not driving recklessly fast

People who have worked with me are familiar with my trait of challenging the team to bring products and solutions to market as soon as possible. I’m a strong proponent for quickness to market and love to deliver sooner than the initially projected timeline. In this article, however, I present a different viewpoint for balance.

In product development, the question often comes up: How can we be quicker and faster to market with our products? We should ask instead: How can we be earlier to market with our products than our competitors? We should also ask: Is it more important to be early, or to deliver good quality and innovation?

For the medium and long term good of your organization and in the best interest of your customers, it is more important to deliver a high quality and innovative product than to deliver it quicker.

In most cases, successful companies are not the ones who are fast or early to deliver products, but those that deliver better products.

Take Google for example. They were a couple of years late to the Web search engine market and were reinventing a product that had already been established by others. Many thought the search engine market was already saturated. Remember some of the early ones like Infoseek, Lycos? Where are they now? Consider Microsoft and Apple: most of their products are not early, but they often succeed. The iPod came years after the early portable digital audio players. MySpace.com came up to dominate online social networking a couple of years after Friendster, Tribe and Orkut were already established.

Even when analyzing products whose success was due their being early to market, we find that early does not imply fast. These projects often started early and were executed at a comfortable, smooth pace.

As the saying goes, when you ask for quick and dirty, you get both. The benefits of speed to market are for the short term. In some cases, it does make sense to go for quick, short-term solutions. In all cases, however, one must give serious thought to whether that’s the correct path to choose considering the medium and long term goals.

People & Teamwork

In projects, working fast is often a recipe for failure, especially after starting late. The overwhelming majority of projects are not like 100 meter races, where speed results in victory. They are like football games, where factors like teamwork have much greater influence on winning.

The greatest factor affecting the success of projects is not speed, not technology, not even process or planning. It is people. Invest your time, energy and resources on your people and they will make your projects succeed more than anything else.

Whether you are a leader, manager or information worker, I recommend learning more about the people factor and practicing better people related activities at work. Here is a quote I like from a book: “People under time pressure don’t work better; they just work faster. In order to work faster, they may have to sacrifice the quality of the product and their own job satisfaction.” — Peopleware: Productive Projects and Teams, 2nd Edition, Tom DeMarco and Timothy Lister

Keep in mind this order of descending significance of factors in projects’ success:

  1. People & teamwork
  2. Priorities
  3. Planning
  4. Process & operations
  5. Products & technologies
  6. Pace & acceleration