9 Reasons Why News Media Web Sites Should Consider Moving to HTTPS in 2015

If you work in news media and are interested in technology, you may enjoy my article listing 9 Reasons Why News Media Web Sites Should Consider Moving to HTTPS in 2015. I co-authored it with Eitan Konigsburg and Elena Kvochko, two colleagues with expertise, deep knowledge and passion for cyber security, privacy and technology.

It is published on the Times Open Blog maintained by the Software Engineering Team at The New York Times.

My personal Web site, rajiv.com is served exclusively on HTTPS thanks to CloudFlare.

3 Dimensions of a Technology Team

Organizing Software Engineering Teams to Balance Products, Partners & Professions

This organizational design for a technology department aims to optimally blend the need for the technology team to be an engine of innovation, a customer-service organization and technically excellent.

It views the staff, roles and responsibilities in three dimensions: products, partnerships, and professions.

img

  1. Products and projects the technology teams work on
  2. Partners, customers, and stakeholders of the technology department
  3. Professions of the various technology staff members

Organization by products focuses on providing great user experiences via small, agile and nimble teams that have ownership of their work.

Organization by partners focuses on being an effective client-service organization to other parts of the company.

Organization by professions provides for learning, best practices and career development of the tech employees.

This article first describes the three models and then suggests ways to bring them together into one integrated organization design.

Organizing by small product focused teams

Product

A product is defined as something that customers use and experience. A product consists of content, features and functionality.

It refers to a digital entity, a physical good or a combination of the physical and virtual. For example, it could be a communication app that people use via their smartphones and computers. It could be a health device that people wear and access via their smartphones and computers.

The goal of a product is to meet customer’s needs & desires, to solve problems for customers including ones they didn’t know of, and to delight them. Many products aim to help make the world a better place, be it in small or big ways.

A Key Difference Between a Product and a Project

A project has preset start and end dates. A project, by definition, is supposed to be complete when it delivers its desired outcomes.

A product typically does not have a preset end-date. Most products are meant to exist and evolve for the foreseeable future. Products are (and should be) discontinued for good reasons (e.g. when they no longer have a viable future, or the organization needs to divert resources to other products).

Upgraded versions of the product are delivered via projects.

Projects are successful when they end.
Products are successful when they persevere.

Product Team

One way to think of a product team is as a mini-company within the larger organization. A product team has customers, which could be external, internal or both.

A product team develops the product, makes it available to customers (“ships” it), and maintains the product. Maintenance of the product includes new features, major upgrades and innovations.

Roles in a product team

A product team has several roles which are filled by professionals with certain skills, knowledge and interest.

The roles can be narrow in scope, like front-end JavaScript developer or broad, like software engineer. The roles include the professions of engineers, designers, subject matter experts, marketers, and managers. For a longer list of roles in a product team with examples, see the section titled “list of professions/roles” under organization by professions below.

People and Roles

These roles are not necessarily each held by different people. There is no prescribed restriction on who can hold which role or how many roles. Depending on the team’s needs, people’s skills & interests, and budget & resource situation, any permutation of the roles can be held by the people in the team.

A team should make the best decisions in allocation of the roles. The roles held by people are expected to change as the team scales up or down. The team should give importance to checks and balances via separation of duties where required for compliance of regulations.

Team Size

As a minimum requirement, at least three people are required for it to be a product team that encompasses a sufficient set of the roles required. In a few rare cases, the team might be able to start with just two people.

Proximity

For a product team to be successfully implemented, it needs to consider and address evidence-based management science related to human collaboration.

An important recommendation is that the team “resides” together, i.e. works together on a weekly if not daily basis. If the team works out of the same office, then they should work in close proximity. If the team is geographically separated, like the teams at Auttomatic/WordPress, then they should have “virtual proximity”, i.e. be in close contact using video conferencing and other online collaboration tools.

Organizing by Partners, Customers, and Stakeholders

Aligning the technology department with business departments

In this model, each line of business, department and product/service at the company is assigned a technology partner in the technology organization.

Examples of stakeholders in a media company include the heads of advertising, marketing, finance, customer service and editorial.

The technology partner is a senior, widely-respected and influential member of the technology management team who serves as the primary technology leader for that business, department or product/service. Excellent client-relationship skills are a requirement.

The technology partner may also serve as the solutions architect for the client, or may have solutions architects assigned to them.

Technology Partner Role Description

The technology partner is the go-to person for all technology matters for the client department, including for engineering, project, and technology, areas that the technology partner does not directly manage. For example, a large department like Advertising will have projects that could span multiple tech departments.

The responsibilities of the partner include:

  • Assess Current Capability: Evaluate the current technical capabilities of all the technology systems.
  • Define Future Capability: Understand strategic industry trends to plan future technology roadmaps.
  • Technical Lead for product development: Responsible for technology execution, bringing new products to market and optimization of existing offerings.
  • Plan Capacity: Translate roadmaps into future year capacity plans.
  • Collaborate with other tech teams: Work with other product teams to service the needs of the business needs / departments / products where other teams in the technology organization are the owners of systems.
  • Subject Matter Expert: As the primary contact for a business / department / product act as the SME for all technology.

Organizing by Professions

In this model, the technical people are organized by the professions they choose to belong to.

Professions and Roles

This is a sample list of professions and roles gleaned from companies that have products in the digital media space. This list can be easily adapted to other industries, for example, by including the relevant subject matter expert roles. This was compiled between the years of 2007 to 2014 and reflects some prominent roles from then.

Each profession/role is grouped under one of five major categories:

  • Technologist/Maker
  • Designer/Artist
  • Subject Matter Expert/Analyst
  • Marketer/Seller
  • Manager/Admin

List of professions/roles

Technologist/Maker
Software Development Engineer, Server-side “backend” Software Engineer, Client-side “frontend” Software Engineer, Mobile iPhone and Tablet Software Engineer, iOS Software Engineer, Android Software Engineer, Content Management (CMS) Engineer, Testing Engineer, App Release Engineer, App Operations Engineer, DevOps Engineer, Systems Administrator, Database Administrator, Security/Privacy & Compliance Analyst

Designer/Artist
User Experience Designer, Visual Designer

Subject Matter Expert/Analyst
Product Manager, Business Analyst, Journalist, Reporter/Content Author, Editor

Marketer/Seller
Salesperson, Marketer, Customer Service Representative, Internal Advocate, Documentation Writer

Manager/Admin
Project Manager, Finances & Budget Manager, Team & People Manager

Integrating the three dimensions

Now that we have described the three dimensions, let us discuss ways to make it all work together.

Reporting Relationships

Some people believe that “reporting relationships are irrelevant in today’s world”, but social science research has repeatedly proven this to be false.1  Reporting structures and hierarchies are an essential and integral part of any organization of humans.

So rather than pretend that reporting relationships in a team don’t matter, it is important to address them in setting up these teams.

Let us start by acknowledging that human relationships are complex, nuanced and changing, so there is no one formula to organize your teams. Every approach to organizing reporting relationships has its advantages and drawbacks. Here, we present a reasonable but imperfect model.

This model applies to medium to large size organizations, but not to small companies or very-large companies. In a small company of less than 10 people, there are unlikely to be departments by profession where people report into. In very large companies’ each business unit may operate as an independent company with its own departments by profession (e.g. their own finance, HR and engineering).

We also make some assumptions. For example, that it is preferable that each team member has exactly one primary boss who they formally report to.2

Departments by Profession

It is important to define what is expected of a primary boss in your organization so you can best determine how to structure reporting relationships. For example:

  • Does a boss’ role include the long-term development of the employee’s career, existing skills and new skills?
  • Does a boss need to be a subject matter expert in the chosen profession of the employee? Or, is the employee best served by being part of a team of others with the same or similar professions?
  • Does a boss need to objectively and independently look at the employee’s work as serve as a checks and balances relative to the product/project team the employee is presently doing day to day work in?

If your answer to the above questions is yes, then it is likely that setting up the primary reporting relationships by profession is a good solution for you.

What does reporting relationships by profession mean? It means that primary (and formal) reporting relationships are organized by departments of people in similar professions. For example, HR professionals report into the HR department, finance professionals report into the finance department and software engineering professionals report into the software engineering department.

In medium to large sized companies, having the primary reporting relationship by professional departments often has advantages over having direct reporting into the product/project team. In fact, most consulting firms use this model. Some of the benefits include:

  • As new products are created, old products decommissioned and projects start and end, employees don’t need to switch from boss to boss. By having a boss who has seen an employee’s work over multiple products, services and projects, the employee can receive better coaching and development support.
  • A boss who manages a team of employees of the same profession helps share best practices, standards and development opportunities across the organization.
  • Such a boss can also serve as a check and balance for a product/project team’s short-term needs vs. the best long-term interests of the company. The employee has a primary person higher up to consult with outside their current product/project team.

Most medium to large size companies have departments by profession. For example, they have departments for finance, HR, sales, marketing, software engineering, design, etc. This makes good sense for reasons like the above.

Such departments often assign (or even embed) their professionals within other departments and product/project teams. For example, finance (or HR) may assign a finance person or team (or HR person or team) to work with the technology department. This person would likely be assigned full time to the technology department and work in close proximity to a part of it.

The organizational model recommended here views technology as a collection of departments by technical professions. For example, software development, quality assurance and testing, infrastructure engineering, and project management. Each of these technology departments embeds their staff into product/project teams.

The overall technology department also assigns a technology partner to every other department by profession. That’s how these three dimensions come together.

Balancing Professional Departments with Product/Project Teams

In setting up direct reporting relationships by professional departments, it is critically important to not let the departments become siloed. Each employee should be focused on, deeply care about and feel accountable to the product/project they are working on.

When the person’s primary boss is a functional head outside the team they are currently doing day to day work in, both the employee and the boss must ensure the employee is highly committed to their product/project team whether it is in their department or outside it. One way to accomplish this: Each employee can also be accountable to a lead within the product/project team via a dotted line if needed. In some cases, the employee’s boss and their lead within the team can be the same person.

The goal of the functional department is to both support product/project teams and serve as checks and balances, but never to work against them.

Non-Technology Departments

While this article was written for organizing technology departments at companies where a substantial amount of work involves software engineering, the thinking here might be adaptable to other types of departments. If you have thoughts on how to do that or have other approaches to organizing teams in organizations, please do share them.


This article is mirrored at LinkedIn and Medium.

  1. Hierarchy is Good. Hierarchy is Essential. And Less Isn’t Always Better by Professor Bob Sutton at Stanford University https://www.linkedin.com/today/post/article/20140112221140-15893932-hierarchy-is-good-hierarchy-is-essential-and-less-isn-t-always-better  []
  2. If someone has scientific evidence supporting this, please let me know.  []

Three Pillars of a Media/Publishing Company

MediaCompanyPillars-for-blog
Diagram illustrating three pillars of a media/publishing company: Journalism, Technology and Business. Some areas of their intersections are also shown here.

Questions:

  • Where should product be depicted?
  • Is product an extension of the journalism (newsroom)? In this way of thinking, all products including Web, mobile and all other digital products are primarily newsroom products. Or:
  • Is product part of technology and development? In this way of thinking, product is primarily product development. Or:
  • Is product a business-side function that manages multiple stakeholders including the newsroom, technology, sales and marketing? Or:
  • Taking the business-side approach in the previous point to the next level, is product a general manager function, and should be depicted at the intersection of all three pillars along with the publisher, finance and HR?

 

5 Productivity Tips for Executives in Leadership & Management Roles

MP900309344Here are 5 productivity tips for executives in leadership & management roles. Each tip involves the number 5.

  1. Every morning (or the night before), make a prioritized list of the top 5 things you plan to accomplish that day. These are your must-do tasks for the day. At the day’s end (or when making the next day’s list), review how many of the 5 items you completed successfully. Learn from past data when planning your current top 5 things.
  2. Whenever practical, write emails and replies in 5 sentences or less. Link to five.sentenc.es in your email signature to explain this policy to your recepients.
  3. Time box your presentations, proposal pitches and plans/project descriptions at 5 minutes. Learn via  www.google.com/search?q=5+minute+presentations how to make effective presentations in 5 minutes. Limit certain conversations, phone calls and quick improptu meetings to 5 minutes or less.
  4. Wake up at 5 am or soon after and leave the office to go home soon after 5 pm.
  5. Do not check your email, social media and other messages every 5 minutes.

MB910227540MH900211482

Management & Technical Career Growth Tracks (v2)

Click on the diagram above to view it as a zooming presentation.

This second version of the diagram illustrating technical career tracks reflects the following updates since version one:

  • A product management track is now included. (Future updates may include other tracks like design, editorial and marketing.)
  • There is no longer a contributor-level position on the people-management track. This is because most organizations do not have an entry-level position whose main job is to manage people yet is below the manager level.
  • The number of levels is still 5, but the two contributor levels below manager have been merged into one. The C-level (as in CEO, CTO, CFO, …) band has been added above the VP levels.
  • The director-level position in the technology track is now called principal architect or simply principal.
  • In the people management track, it is suggested that a manager directly supervise at least 3 contributors and that a director supervise at least 3 managers. Exceptions can be made to this guideline when it is well-justified, but these are suggested as the default requirement to hold these titles.

(Thanks to Brian Murphy and Brad Kagawa for their contributions to this system.)

Future of Content Management for News Media for Web sites

Content on Web sites should be managed using systems that were designed from the ground up for the Web. Traditional content management systems with a legacy of features and workflows used for paper-based print products like newspapers and magazines are unsuitable for Web sites. The future of news media content management for Web sites is in:

  • simple & quick workflows
  • blogs & wikis as the main content types for text
  • social networking & community publishing

simple & quick workflows

Complex editorial workflows make sense for print products (on paper) , where once the edition is done, the content and presentation state is “locked” and sent to the presses. Working with Web content writers and editors over the past decade, I have learned that simple, quick workflows are preferable for Web sites. Many Web site producers who hail from print backgrounds now share the same conclusion that complex content management is a hindrance to successful Web site production.

The concept of an edition of the entire product is not necessary for a content Web site. The atomic unit that can be managed and published together can be a package of articles and multimedia or even just one article. A Web site is a living, dynamic, ever changing collection of content where individual items can be updated whenever required or desired or even automatically based on usage.

To be competitive, content needs to be updated and published quickly. Corrections can be made anytime. Thus for Web sites, the editing and approval process should be streamlined and quick all the way from authoring to posting on the site.

A new concept

The ability of online word processors like Google Docs or WriteWith to enable multiple people to edit a document simultaneously and collaboratively is different paradigm from traditional check-in/check-out access control.

blogs & wikis as the main content types for text

Content management system (CMS) which offers the simplicity of blogs and are extensible via plug-ins to add functionality like WordPress or MovableType, make good foundations of a CMS for a news media Web site.

For revisions, editing history and access control, wiki software works well. WikiPedia and WikiNews, which are powered by the MediaWiki software are two good examples.

The concept of content management systems that combine the agility of blogs and editorial control of wikis is interesting to follow. The term bliki seems to be the leading classification of such products.

In many newsrooms, writers are increasingly using blog posts to publish news articles instead of their enterprise-class content management systems. When asked why, they reply because it is simpler and quicker and they don’t need the overhead of things like complex approvals, advanced version tracking and access controls.

social networking & community publishing

Managing content using a blog or wiki is social networking and community publishing activity. On the readership side, successful social news sites like Digg and Reddit have accelerated the evolution of journalism and readership habits towards the social/community model. The distinction between authors and readers itself is blurring with wikis and comments on blogs.

Social networking features are being added to a variety of Web sites. Going forward, expect to see social networking and community features in content management systems.

Conclusion

Media companies should move to using CMS products that prefer simplicity over complex editorial workflows which were a legacy of writing and editing for print products. A news item, story or blog post should be the same content type. It is likely that blogging products that have proven so successful in empowering talented individuals in competing with large companies will evolve into content management systems with the addition of wiki functionality.

The Evolution of Web Sites

Over the past 15 years, as the Web has evolved, the web sites have gone through these generations. What’s likely to be next in the future of what the Web will be? This article describes the Web so far and what form it will likely assume.

  • 1993-1997: Generation 1.0
    • These web sites can essentially be considered digital versions of printed newspapers, magazines and books.
    • Like with the printed products, the consumer is primarily a reader and interactivity is generally limited to filling out and submitting forms.
    • Content and design are the most important part.
    • Product = Content + Design
    • Examples: Most news and other content sites in the 1990s.
  • 1997-2004: Generation 1.5
    • These web sites are similar to what interactive CD-ROM based software used to be in the 1990s.
    • The consumer is a user (as in user of software). There can be significant interactivity between the web site and the user. Interactivity between users is generally limited to discussion boards and marketplace activities.
    • Product = Technology + Content + Design
    • Examples: Online multimedia sites, online gaming sites.
  • 2004-present: Generation 2.0
    • The concept of user-submitted-content grows stronger. Users in the virtual community of the site publish, share and view photos, videos and text.
    • The consumer is a community participant.
    • Product = People (User Community) + Technology + Content + Design
    • Examples: YouTube, del.icio.us, Wikipedia
  • 2006-future: Generation 3.0 (prediction)
    • Concept of user-submitted-interactivity / user-submitted-programming arises. The users create, own, sell, share, alter and use interactive objects in the virtual environment.
    • Consumers are co-developers.
    • Product = Community Developed Interactivity + People (User Community) + Technology + Content + Design
    • Examples: Virtual environments and ecosystems like Second Life and Kaneva.

Sometimes extra steps in workflows are good

When implementing a content management system or other product, customers often ask for workflows that require the least number of steps required to any given complete task. At first, this seems to make perfect sense; however consider this example of a car:

Before you can get inside your car and start driving you have to perform the following steps:

  1. unlock the car door
  2. pull the door handle
  3. open the door
  4. get inside the car
  5. close the door

Steps 1, 2, 3, and 5 seem to add unnecessary actions to the workflow. The goal here is to be able to start driving to get to the destination. Over the course multiple car trips over a day, these steps seem to “waste” a lot time. An easier and “better” workflow may be for cars not to have a door at all. Then you’d save the steps of having to open and close the door.

However, with the current level of commonly available technologies, it makes sense for a car to have a door and require these steps before you can start driving.

Extra steps are often required to provide security, maintainability, reuse, reliability, scalability and performance.

Shortcuts aren’t always the best solution. You may save steps and thus cost now with shortcuts, but as a result you may pay much more later in other costs.

As technology advances, some necessary steps can be automated or eliminated. For example, some cars now have keyless entry that eliminates some of these steps. In the future, an advanced version of keyless entry may even open and close the door for you. However, expecting those in a car of today would be impractical.

Similarly in content management and other software extra steps aren’t always a bad thing. A good content management system isn’t one that allows web site producers to complete their tasks in the least number of steps. It is one that enables completion of the task in an optimal number of steps balanced with other factors like reuse, maintainability, flexibility and security.

Integrating Legacy Technologies With Web Systems at Newspapers

The topic of integrating print technology systems with web technology systems often comes up in the newspaper, magazine and book publishing industries.

There is a key difference between Content Companies (e.g. newspapers, magazines) and Other Companies (e.g. pharmaceuticals). With the World Wide Web and information technology (IT) becoming part of everyday life, every company is becoming a content company in certain ways.

In the case of other companies like pharmaceuticals, aeronautics, construction, etc. their pre-digital products are not going away nor changing as drastically as a result of the world wide web and IT as is happening in the case of content companies like newspapers and magazines.

For those other companies, it makes sense to integrate the web systems like content management with their core products because their other core products are not fading away as a result of the web and IT.

However, in print media companies like newspapers whose legacy has been printing systems, their product in its printed form is fading away as a direct result of the Web and IT. So for them it may make sense to not spend too much effort on integrating legacy print systems with Web systems. Instead, it may be a better strategy to spend more resources on enhancing and upgrading the Web systems and digital media products. So for newspapers today, the 1990s holy grail of having one seamless print+web content management system may be less relevant in 2007. It may actually make better business sense to to keep the print publishing system and Web CMS separate, focus more on Web and digital media and allow the printed on paper versions of their products to gradually retire over the next two decades.

Consistency in Labeling Ads as “advertisements” on Content Sites

Some newspaper and magazine web sites visibly label some ads on their web pages as “advertisements” but don’t mark other ads including their own in-house ads on the same pages. Their intentions are journalistic: They want to visibly differentiate their editorial content from ads. (Though that doesn’t explain why they don’t label their own in-house ads.)

Sites should be consistent in visually differentiating journalistic content from advertising and other types of content. Either they should label all ads consistently or not label any.

In specific cases where the Editors believe advertising content may be confused as editorial content, they should label it as an “advertising section” like they do in print.

However, some sites choose not to label ads as “advertisements“. Their reasons:

  • Readers can differentiate an ad from editorial content in over 99%1 cases of web pages.
  • Ads are not visibly labeled as ads in print publications, except in special cases when the Editors feel that ad may be confused as content.
  • Why stop at ads? Why not label everything on the web page that is not editorial content?

Presenting an entire advertising section as that does make sense. The same way the sports section is branded sports in both print and online, it is useful to brand an advertising section as such. It also does make sense to label ads that look like editorial content (in the Editor’s opinion), such as text ad links and ads in between content.

A related article on this subject at MediaPost.

  1. This 99% is not based on a survey, but I believe the actual percentage would be even higher. []