Proposal for Linking To Users Across Social Networks @[email protected]

We present here a convention for linking to users across social networks.

Social networks have evolved into a category of their own. They are not like most Web sites in the traditional sense and even when considered modern Web apps, they are a special type of application. They have become our new digital personas. Email used to be our online persona. Blog URLs (especially when coupled with OpenID) have also served that purpose. Instant messenger IDs and online forum handles have been also serving as our partial online identities. Social network personas combine elements of all  of these: Personal blog/comment URLs, email, discussions and real-time chat.

We often see people including their Twitter usernames ( e.g. @rajivpant ) as contact info on presentations, business cards and email signatures. This has helped make Twitter even more popular. There is a need for a simple, short and consistent way to refer to a user on any social network.

We propose three alternative options.1 A. @[email protected] , B. socialnetwork:@username and a third option as conventions to link to users across social networks. Why? Because Twitter has already made the @username widely popular. These conventions are backwards compatible and extend the existing convention to include other social networks.

Option A.  @[email protected]

On Twitter posts (tweets), you would continue refer to a Twitter user as @rajivpant (implying a Twitter user as the default). On posts on other sites, you would refer to the user as @[email protected] and still have it link to the user’s page on Twitter (and potentially also notify them on Twitter). That way, we’d have a consistent person naming and linking convention across social networks and perhaps even blogs. E.g. @[email protected] , @[email protected] , @[email protected] and @[email protected]

social-network-link-convention

Option B.  service:@username (URL format)

On Twitter posts (tweets), you would continue refer to a Twitter user as @rajivpant (implying a Twitter user as the default). On posts on other sites, you would refer to the user as twitter:@rajivpant and still have it link to the user’s page on Twitter (and potentially also notify them on Twitter). That way, we’d have a consistent person naming and linking convention across social networks and perhaps even blogs. E.g. facebook:@rajiv.pant , linkedin:@rajiv.pant , google:@rajiv.pant and tumblr:@rajivpant

Option C.  sn:[email protected] (Unified URL format)

A third option, and one that we originally proposed is to have social network URLs like sn:[email protected] where sn:would be a universal social network protocol handler that would be distinct from the email URL syntax of mailto:[email protected] . It would avoid the need of per-site handlers like twitter:@rajivpant on iOS that are becoming common.

One benefit of having the @ (or + in Google+) at the beginning is that the text editor can start to autocomplete the name for you. It would still continue to do that. However, when you type @@, it would first give you a list of other social networks and then could even show you names from your connections on other social networks if you have authorized it!

In your contacts (e.g. MacOS Address Book), you could then enter someone’s social network addresses using the @[email protected] or the sn: URL format. When someone clicks on an @@ or sn: link, the URL handler would first look to see if there is registered custom app for that domain name (e.g. Twitter client on MacOS or iOS) and then launch that app. If no app is registered for that social network’s domain, it would map it to an http: URL like https://twitter.com/rajivpant , https://www.facebook.com/rajiv.pant or https://profiles.google.com/rajiv.pant
This would avoid social network specific URL formats like twitter:@rajivpant proposed by option B.

For brevity, the URLs could simply be in the format @[email protected] , @[email protected] , @[email protected] and @[email protected] If such shorter forms are adopted, then each social network’s brand name could be registered via a system of registries or it could default to .com if the full domain name isn’t specified. We could also have shortcuts like @[email protected] or fb:@rajiv.pant since Facebook owns the fb.com domain at the fb: URL schema on iOS.

Either way, a number of people have agreed that this problem needs to be solved. Which option do you prefer, A, B, or C?

  1. Thanks to Adnan Alam and Vinod Unny for suggesting option B. []

Organizing a Digital Technology Department in a Media Company By Functional Areas

This article presents a system to organize your digital technology department in a media company. It is written for a CTO, CIO or EVP Technology 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 all aspects of technology for a major digital brand or for a large company with 3 or more Web sites.
  • You lead a technology department of between 50 to 250 staff.
  • Internal corporate IT functions such as desktop support, telecommunications services and internal business systems are beyond the scope of this article.
Click on the diagram above to view it as a zooming presentation

The following are seven areas that the CTO heading up such a technology department in a media company is typically responsible for.

Digital Technology Department in a Media Company – By Functional Areas

Each of the seven areas contains the following functions.

In a company, the above may map to the following organizational structure.

CTO / EVP Technology’s Organization

  • Director of Technology Administration & Management (Chief of Staff to CTO)
    • Administrative Staff
  • VP of PMO
    • Director of Program & Project Management
      • Project Managers
    • Director of Technology Budgets (has dotted line of reporting into Finance department)
  • VP of Technology, Client Satisfaction & Advocacy
    • 24×7 Support Staff
    • Technology/Developer Advocate(s)
  • Director of Technology & Business Analysis
    • Technology Analysts team
    • Business Intelligence, Research & Analysis Team
  • VP of Quality
    • Teams of Testers
    • Team of Test Automation Engineers
    • Software Release & Shipping Team
  • VP of Product Engineering
    • Teams for each technology product
  • VP of Software Engineering
    • Director of DevOps (has dotted line of reporting into VP of Systems & Infrastructure)
    • R&D Team
    • SEO Team
    • Web Client Technologies Team
    • Mobile Technologies Team
    • Builds & Configuration Management Team
  • VP of Systems & Infrastructure
    • Security & Privacy Protection Team
    • Systems & Applications Administration Teams
    • DBA Team
    • Infrastructure Management Team

In the above organization, each person directly reports into their functional area. In a smaller organization, the VP roles above may be director roles.

Program/Project Teams: Dotted-Line Reporting By Programs & Projects

At any given time, a company has a number of programs and projects in progress that are best suited by a dedicated team. In this system, staff is assigned to the program or project. The assignment of a person to a project  is a dotted line valid for the duration of the project, not a direct line of reporting to the head of the project.

An example of this is a Scrum team.1

The benefits of this approach include: By directly reporting to a manager, director or VP in their discipline, the employee benefits from the learning, coaching and exchange of knowledge with others in the same discipline. That gives the employee a good feeling of belonging with others that share a passion for that area of work.  By being part of a program or project team, the employee enjoys the sense of co-ownership of a project or product.

During and on completion of the project, the project head gives feedback to the direct supervisor of the employee, which the supervisor uses to coach, help and provide support to the employee both in the current project and for future projects.

Below is an alternate illustration showing teams as “vertical” and “horizontal”.

vertical-and-horizontal-teams

  1.  More articles related to Scrum teams. []

Some Pathways for Career Development in a Product Engineering Organization

The diagram below illustrates some pathways for career development in an engineering-focussed product development organization. It shows an organization where software engineering is a major discipline. The pathways shown here map out career paths that we have seen work well in a number of organizations. (There are also other pathways that work well that are not shown here, for example from VP Engineering to VP Product.)

 

Shorter paths (fewer arrows along the way) do not indicate a quicker career growth path. To the contrary, often gaining experience in multiple areas helps develop as a well-rounded executive prepared for senior leadership roles.

Certain roles are not listed explicitly but are combined into other roles in this illustration. For example, the roles of Security are merged into Systems in this view. Also, roles like Senior Engineer and Lead Engineer are not shown separately, but covered by Engineer and Engineering Manager. Similarly, Senior Manager and Senior Director are also not shown separately. Incorporating that level of detail would have significantly increased the complexity and decreased the readability of the diagram.

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? []