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

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

Management Tip: Thank Your Employees For Jobs Well Done

If you supervise employees or are in a senior position relative to some others, make it a habit to thank employees when they do a good job.

Here are some tips for effective appreciation of employees’ work:

Appreciation is good even when it is an expected part of their duties. If the work is good quality, thank the person.

Don’t trivialize your thanks, however. Don’t thank an employee for just sending a meeting agenda or sending a recap of a meeting unless the agenda or recap they sent is so good that it impresses you. (An exception to this rule would be if in the company most people forget to send meeting recaps and this person did and you are working to encourage this good habit.)

Don’t send an email just saying “thank you” and nothing else. Add at least a sentence or two explaining why you appreciate what the person did.

Don’t always send an email. Mix it up. Sometimes walk up to the employee and thank them in person. If they are in a remote office location, call them by phone to tell them.

When thanking someone by replying to an email they have sent, send a thank you note directly to the person. Don’t reply-all unless it is a major above & beyond accomplishment that deserves public congratulations. When you do send a public thank you to an employee with other people cc’d, take the time to write at least a paragraph or a few bullet points mentioning the benefits of the accomplishment.

Mention by name the person(s) when you thank people. Don’t just thank “the team”, or “all who worked on this project” out of laziness instead of calling by name the people you are thanking, unless you have a good reason for not naming names.

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.


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.

Opinion on the Amazon S3 Outage; Checklist for Dealing with Outages

My journalist colleagues at published some of my comments related to Amazon S3.1 Wired also posted another article titled Customers Shrug Off S3 Service Failure. I agree with the views of many of the customers expressed in the article. Don MacAskill, CEO of the popular photo hosting site Smugmug, wrote an understanding post about it.

My entire career working for media companies, I’ve held firm the belief that the uptime, reliability, performance, scalability, performance and security of commercial Web sites is of paramount importance. When sites that I’ve been responsible for have had issues, my colleagues and I have given our personal time and energy to resolution. With my teams, I spend considerable time on proactive measures. I’ve had the honor of working closely with and learning from some who do an excellent job running technology operations.

Experience has taught that things can and sometimes do go wrong. Sometimes calculated risks don’t pan out. Sometimes mistakes cause problems. We are human. We should strive for perfection; we can get close to it, but not fully attain it. We should be prepared for such scenarios. When they happen, we should work diligently and expeditiously on resolution and have frequent and honest communications with stakeholders and customers. Such communications during the incident should include:

During-Incident Communication Checklist

  • Current status
  • What is the full impact?
  • Estimated time to resolution
  • Any recommended workarounds until resolution, if practical
  • Assurance that it is being worked on
    • It often helps to mention who all are working on it and what they are doing

The post-incident communications to stakeholders and customers should include:

Post-Incident Communication Checklist

  • Summary
  • What happened, how and why it happened?
    • Including full description of all impact
    • Do not blame2 third-parties or say things like “beyond our control”. A technology leader takes responsibility equally for both insourced and outsourced products and services.3
  • How it was resolved
    • If the resolution is temporary or long-term
  • Next steps
  • Plan for eliminating or minimizing this and similar incidents from happening again
  • Thank all those who helped resolve and the customers for their understanding
  • Mention the monetary credits you plan to give as per the Service Level Agreement (SLA)
    • Specify any additional ‘make goods’ or returns you plan to make to the customers above and beyond the credits as per SLA, if appropriate.
  • Double check each recipient’s email address to make sure you are sending this memo which may contain confidential information to the correct person and not someone else with a similar name in your address book. You don’t want your memo published on Gawker.
  • Speaking of Gawker, in the event someone does leak your memo outside the beyond the intended recipients, take care to not say anything in it that would be an embarrassment. That’s another reason to be honest, own the problem and solution, and not pass the blame.

Stakeholders and customers here refer to internal customers of the technology operations team (e.g. the concerned folks in editorial, marketing, sales, finance, legal and other departments). External communications to the public Internet should be handled in consultation with legal and public relations.

S3’s outage (or any outage) isn’t to be taken lightly, but I have faith Amazon and their customers will learn from it.


  • As explained in the terms of use of this site, any opinions expressed on my personal Web site do not reflect those of any employer, past or present. My Web site and I in my personal life neither represent nor speak for any corporation.
  • I have no affiliation, financial or otherwise with I happen to be a user of their products and services, some of which I like and some that I don’t.
  • Personal Web sites like this are exempt from the performance requirements of corporate Web sites :-) My personal Web site is for expressing, learning and R&D. It also happens to be hosted on Amazon EC2 and S3.
  1. Silicon Alley Insider and ValleyWag have amusing spins on it. :-) []
  2. There may be extreme instances, especially when criminal activity or malicious wrongdoing was the cause where it would be appropriate to blame someone. []
  3. It is ok to mention service providers, or describing external events for explaining what happened, but don’t do it in a “it was their fault, not ours” tone. The technology leader should factually describe what happened and take responsibility. []

Management & Technical Career Growth Tracks

Described here is one way to enable technologists to grow their careers in your organization while still allowing them to focus on the type of work they are best at and enjoy most.

The typical management career growth path does not suit some technical people. These information workers need to grow in their careers (gain greater compensation, responsibilities and influence) without having to become managers of other people. A good way to achieve that goal is to create a technical career growth track in your organization.

The following diagram and table illustrate management positions alongside technical positions of similar levels.

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

This system isn’t meant to be rigid. It is designed to find a good balance with most organizations. That balance, i.e. how many “levels of authority” there are will differ across organizations. The focus of this article is to provide a technical track as an alternative to management tracks, whether there are 3 levels or 13. There are pros and cons of having fewer “bands” or ranks. (As a side note, some organizations like the military1 require lots of ranks.) Ranks need not signify a strict hierarchy where one can only go from one rank to the one immediately above. The ranks could simply be used as “salary bands” and the levels of “hierarchy of authority” could be fewer.

In this model, for example, an architect role is at the same compensation and influence level as a manager role, assuming that the particular manager and architect being compared add similar value to the company. To accommodate more ranks, a senior architect would be at the same level as a senior manager.

If the organization prefers consistent titles for levels regardless of track, the system could name them like this: vice president & fellow, senior director & architect, etc. In the case of a fellow who is at an SVP level, they could be named SVP & distinguished fellow.

Here is a definition of the fellow role from WikiPedia:2

Large corporations in research and development-intensive industries3 appoint a small number of senior scientists and engineers as Fellows. Fellow is the most senior rank or title one can achieve on a technical career, though some fellows also hold business titles such as vice president or chief technology officer.

Such a technical career growth plan brings many benefits to your organization.

  • It helps retain good technologists who want to grow in their careers, but want to do keep doing the type of work they are best at and enjoy doing: technical work.
  • It avoids brilliant technical people from being “pushed” (by themselves or their supervisors trying to “reward” them) into people-management responsibilities.
  • It reduces situations of having too many people-managers but not enough people-management positions over time as people get promoted.

Care should be taken to recognize that some technical people do enjoy making the transition to people-management roles and the presence such a technical track should not discourage them. Having an alternate career growth track option is about presenting employees with more than one choice.

Similar system are also used to enable non-managerial career paths at editorial and design departments at newspapers, magazines and other newsrooms.

Related Articles on Other Sites

Some updates to this article are published at

(Thanks to Brian MurphyBobby Chowdhury, and Janet Kasdan for their contributions to this system.)

(Updated: 2012-Dec-17)

  1. US Military Ranks []
  2. Definition of Fellow at WikiPedia and Wikitionary []
  3. IBM or Sun Microsystems in information technology, and Boston Scientific in Medical Devices for example []

Interviewing By Putting To Work

I’ve found this to be an effective way of evaluating potential hires compared to just interviewing in a question/answer format: Put them to work for a few hours (or even days/weeks/months as contractors) and see how well they perform.

Having someone do the job as a short-term temporary contractor before hiring them is one of my favorite ways of testing them for the job. However, sometimes this isn’t practical. In those cases, having the candidate work on a short test assignment for a few hours can be very telling.

For example, when interviewing a software programmer, set them up on a computer and give them a programming assignment representative of the type of work they would do on the job. Give them reasonable freedom as you’d give an actual employee. If they need to research references / solutions on the Web, let them. If they want to call a friend for consulting help, that’s fine. If they ask for your or their “coworkers” for help within reason, that’s okay too.

Hiring a journalist? Give them a reporting, writing, and/or editing assignment. Hiring a web site producer? Have them build a mini-web site or edit a copy of an existing site. Hiring a designer, have them design a logo for a business or product. (This will help determine how well they can relate their design skills to the business aspects.)

While this is a simulation, the more realistic you can make it, the better.

For information worker type jobs, coming up with a realistic assignment is easier than one for a management or executive leadership position candidate. Another challenge with this is that a manager and leader’s job requires significantly more interaction with others. That means this simulation will consume a fair amount of your and your team’s time. However, remember that manager and executive leaders are very important hires, so the time spent in finding the best possible hire is totally worth it.

Some factors to consider in your evaluation. How resourceful is the person? Do they communicate with the customers? How do they interact with the customers? Do they get the job done? Do they seek help beyond their own resources? Do they become a drain on others’ productivity? How is the quality of their work? What’s their balance of being a team player and contributing individually? How is their planning? How is their presentation? Do they document their solution? How well do they explain their solution?

I admit this is too time consuming to do for everyone who applies for the job. You do need to filter the list down to between three to five candidates for this working interview. There are a couple of ways you can do this. For contract-to-potentially-hire positions, you can rely on a trusted vendor to do the filtering for you according to your guidelines. For others, you do need to review their resumes, see who has recommended them, do phone interviews and give them tests. Computerized tests are a good way to save you and your team some time during the initial screening, provided you present the test in a way that is not demeaning to the candidate. The time/money invested in setting up an automated online test is worth it. The test needs to be respectfully presented as a part of the standard process and should not feel like an entrance exam or impersonal screening.

So next time you have a position to fill, consider using a working-interview.

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,, 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.

Software Products: Own vs. Rent & Create vs. Get (Incorrectly Called Build vs. Buy)

Understanding the issue

Technology executives are often asked about their preferences on build vs. buy. This question would be better articulated as two separate questions: 1. own vs. rent and/or 2. create vs. get.

Why? The usual problems a company is trying to solve when they ask this are:

  1. How can we have the products, features and/or functionality we want sooner?
    • This is a create vs. get question, i.e. Will it take longer to build it or to get an existing product then install, integrate and configure it?
  2. How can we have a product that not only meets current requirements, but is also more likely to continue to develop to meet future requirements (foreseen and unforeseen)?
    • This is a own vs. rent question, i.e. Who do we think is more likely to innovate, continue to invest and do better future upgrades to the products: us, or a vendor?
  3. Which is the more economical and cost-effective option?
    • This is a create vs. get question, i.e. Which option has better ROI, in-house or a vendor?
  4. Which option will give us more business flexibility?
    • This is a own vs. rent question, i.e. Which option will give us a product that we can later decide to use for other purposes (e.g. sell or license to others)?

Building and buying are often part of the same concept of owning. For example, Google (the company) bought Android, Blogger and YouTube. Android, Blogger and YouTube programmers (builders) became Google employees. As a direct result of Google purchasing (buying) and thus owning YouTube, Google now builds and maintains it. In this example, buying and building are the same thing!

When people ask about companies buying software, they are almost always referring to licensingleasing or renting software.

So instead of calling the debate build vs. buy, which is inaccurate, ambiguous and confusing, we should consider it in two dimensions: own vs. rent and/or create vs. get. Even these distinctions aren’t complete, however, because there are different types of ownership (e.g. owning a product vs. owning a license to use it) and different types of rental or leasing agreements.

Owning a product is different from owning a license to use it. For example, you don’t own Microsoft Word (unless you are Microsoft). You own a license to use it on a certain number of computers. Another example: While you may own the physical DVD disk, you don’t own the movie on it: the rights holder1 does. You only own a license to play the movie for personal, non-commercial purposes. You are not allowed to play the DVD in a theater where you charge people to watch it. Nor are you allowed to distribute the film via a file sharing service. You are also not allowed to copy a long scene from the movie and use that video footage to create an advertisement for a product you are selling.2 These examples are relevant to the incorrectly named “build vs. buy” decisions, because the type of ownership governs what you can do and cannot do with the product. That has consequences for the future of your business.

Open Source Products

When asking the own vs. rent question, using open source products falls in the own side, because open source licenses permit you to do as you please3 with your copy of the open source software and no one can take it away from you. Open Source software licenses grant you rights similar to those you’d have if you owned it.4 Open source makes owning even better. It enables owning and sharing at the same time, which benefits the community at large.

When considering create vs. get, however, open source products fall in the get side because just like paid products, open source products are developed by someone else; are already made; and they can be implemented and supported by third-party vendors.

The popularity of open source products is another reason why build vs. buy is not the right question. Open source products are both “build” and “buy”, in the ‘own’ and ‘get’ senses respectively.

Having a preference is a good thing

Sometimes technology executives try to answer this question in a way to avoid seeming biased. They claim they have no preference towards either owning or renting software. However, a preference (a good thing) is not the same thing as a bias (a bad thing). When a person provides such a noncommittal answer, it might indicate they lack leadership, vision and a clear philosophy, or the courage to give an honest answer.

I generally prefer owning over renting. This applies not just to software, but to other things in my life like owning a home and owning a car. There are other people who prefer to rent apartments and lease cars. Neither philosophy may be better in general than the other, but one of them is always better depending on the circumstances. That’s where leadership comes in. A leader has learned from experience and from others and thus has preferences, principles and a philosophy. Good leadership is based on evidence, research and science. Leaders who prefer either one of owning or renting can be equally successful in the same organization and circumstances.

The nine main reasons I often prefer my organization to own the software it uses for its core business functions are:

  1. Competitive advantage via exclusivity, if desired.
    • You have an advantage over others who don’t have your software. They can’t just buy the products and services from the same vendor as you.
    • When an employee leaves your company to join your competitor, they can’t do the same thing they did for you there without your software.
  2. Business flexibility. When you own the software you use, you can:
    • White-label and license the products and/or services implemented using it to other companies, generating revenue.
    • License some of your software itself to other organizations, generating revenue.
    • Open source it, giving back to the community (a charitable thing to do)
  3. Economy and cost-savings when growing. When you own the software you use, you can use it without buying additional licenses for:
    • Companies that you acquire in the future
    • Implementing new products
  4. Control over your data.
    • When a vendor manages your core business data, in most cases you have practically relinquished control of your data even though your contract may say on paper it is yours.
  5. Superior integration and Time to market
    • When you own the products you use, it is often easier and cheaper to integrate with your other systems.
  6. Faster time to market
    • Your timelines are less at the mercy of outside vendors whose interests may or may not be aligned with yours at any given point in time.
  7. Superior integration
    • When you own the products you use, it is often easier and cheaper to integrate with your other systems.
  8. Choice. When you maintain a great software engineering team in-house:
    • You keep your vendors on their toes, knowing that they are not your only option.
    • You have the in-house expertise to evaluate the vendor products, solutions and claims. The in-house folks’ interests are best aligned with your company’s.
  9. The most successful companies have great software engineering teams that develop their core software.
    • Google, Facebook, Twitter, LinkedIn, Netflix, etc.: They all have great software engineering teams who build their core products.

The practice of renting too much of its software used for core business functions has run many companies into trouble.5 There are numerous examples of vendor solutions in search of problems. A vendor will often wow a team of executives with a product presentation and demo. The company will agree to rent the software not anticipating the cost increases over time. Later, the company will find it wasn’t worth the investment.

Vendor Evaluation Checklist (Starter)

When you do decide to use a vendor, consider using the following checklist.

When you meet a vendor trying to sell you a product or service, you must manage the meeting, instead of letting the vendor manage it. Ask the vendor the following questions.

  1. What business problem does your product solve?
  2. Who are your competitors?
    • If they claim they have no competitors, be cautious since it is unlikely to be an honest answer. Never assume that have no real competition like they claim. Do your own research on this regardless of how they answer the question. Compare their answer with your own findings.
  3. Please give us a live demo.
    • Do they use another customer’s data in their live demo? If yes, did they have permission from the customer to show it to you? If not, it implies they are callous about data privacy and how can you trust them not to show your data to others in a demo or even use your data for other purposes?
  4. We’d like to try before we buy but with no obligation to buy. Are you willing to do a test implementation (spike) with us at no or minimal cost to us?
  5. Explain your pricing in detail.
    • Ask for this at the first meeting.

This is a just a starter checklist. I plan to write a more thorough vendor evaluation checklist in a future article.


My preference to own applies only to software products for the company’s core business functions. For non-core back-office functions like corporate email, human resources, financial management, etc., I prefer to license software instead of owning it.

The future shape of software is changing.6 With Web-based applications and utility computing (“cloud” computing) becoming popular, even home users may increase the practice of renting software on a pay-per-use basis. I may write on that subject in the future.

[Authors Note: I expanded this post in July 2013 to provide more detail, but I purposely didn’t “update” it in the sense of making it current with respect to the times because I want to preserve this as a record of the philosophy I had back in 2007. To reflect the evolution of my thinking on this topic, I may write a separate article in the future.]

  1. usually a studio []
  2. …except as allowed as fair use under copyright laws. []
  3. within reason []
  4. except the right to restrict its use by others []
  5. E.g. Vendor Lock-In, Abandonware , etc.  []
  6. Konary, Graham & Seymour; 2004; The Future of Software Licensing: Software Licensing Under Siege  []

7 Tips for Effective Email

Some tips for making better use of email at work and in personal life

  1. Realize that busy people may skim your email instead of reading it thoroughly, especially if they notice that they are among one of multiple recipients of the email.
    • When speaking to a specific person or people in the email body, highlight their name using bold, italics or color so that they notice it.
  2. When you send an email to multiple people asking for a response or assigning a task, specify by name in the body text who you are asking for a response or action from. Otherwise people may read your email and assume one of the others will act on it.
  3. When sending a very short message via email, put it all in the subject line and put EOM at the end of the subject line. EOM is a special convention and abbreviation for End of Message signaling that the body text of the email is empty and can be skipped.1
  4. Avoid using the bcc feature in a sneaky way to tell someone else (e.g. the main recipient’s boss) only your side of the story without telling the known recipients.
  5. At a workplace, when you send announcements (i.e. when your goal is for you to disseminate information and not to start a discussion), send the message in a way that recipients do not reply-all.
    • You can do that by either using a mailing list that only authorized people can send mail to, or by putting the actual recipients in bcc: field and using a placeholder address in the to: field. That is a legitimate use of bcc:. You could also request in your message that recipients do not reply-all to this message and instead for example, report issues to an alternate address.
    • Managers sometimes cringe when after they send a positive message to a large number of people, one of the recipients replies-all with a negative message that either diminishes or distracts discussion away from the original positive message. An employee who does reply-all to a positive message with a negative one is being foolish or a jerk (usually both). You should avoid giving such people a pulpit and opportunity to lower others’ morale and/or start a flame war. (When you have such employees who don’t stop doing this after being told, fire them and hope they get employed by your competitor.)
    • If you are the recipient of an announcement, do not do a reply-all, unless you have a relevant, positive message to add that adds value to and strengthens the original message.
    • I am not suggesting that you don’t voice your disagreements, corrections, cautions, constructive criticism and other comments. You should express them, but not via reply-all. Communicate them to the appropriate person(s) only, typically that would be the sender of the announcement or your supervisor. If you find an error in someone’s announcement, give the sender the courtesy of an opportunity to send out a correction by letting them know first.
  6. Give people reasonable time to respond to your email, even if they have mobile devices (like BlackBerry or other email enabled phones).
    • Realize that some people are overwhelmed by email and you should occasionally reach out to them in person or via phone for certain important matters. Email is not a replacement for all personal communication.
  7. Avoid checking your email on a mobile device when interacting with other people in person except when absolutely necessary, for example in a meeting. It is rude and it implies you are not focusing on your job in the meeting.
    • If your job requires you to be on alert for certain messages, set up alerts via mail filters that will sound or vibrate the device to inform you of messages that require you to interrupt your current activity.

Further Reading

Please read, follow and share these tips about using email effectively:

  1. article on LifeHacker: How “EOM” Makes Your Email More Efficient  []

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.