It is all about Balance

Posted on October 25, 2008 by Rajiv Pant

To be effective at anything in life, balance is required Be it personal life, leadership, management, technical work: balance is essential. You need to be aware of balance at all times.

I plan to write a series of articles about this subject.

Some topics I discuss with friends and colleagues:

standardization vs. innovation & creativity (technology, management)
dedicated resources vs. shared services (management, leadership, technology)
security & privacy vs. convenience (technology, product design)
centralization vs. decentralization & empowerment (leadership, management)

I’d love to hear your topic suggestions and read your viewpoints and experiences. Please do so via the comments section here and in future articles.

Ars Technica Interview: IT consumerization in the enterprise

Posted on July 23, 2008 by Rajiv Pant

My colleague Jon Stokes who is Senior Editor and co-founder at Ars Technica interviewed me on the topic of IT consumerization, and about the shifting boundary between professional and the personal profiles.

Jon writes:

For this third installment of my series on IT consumerization, I interviewed Rajiv Pant, vice president of technology at CondeNet (the digital arm of Conde Nast Publications). Rajiv is mainly responsible for the company’s online presence, but he’s watching many of the same trends and themes that I’ve outlined in the previous two installments play out across CondeNet.

The full article is at:
http://arstechnica.com/articles/paedia/it-consumerization-enterprise.ars

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

Posted on February 16, 2008 by Rajiv Pant

My journalist colleagues at Wired.com published some of my comments related to Amazon S3.¹ 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:

Update 2010-Jan-24: This checklist is now maintained on the Checklists Wiki Web site at:

www.checklistnow.org/wiki/IT_Incident_Reporting

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 blame² third-parties or say things like “beyond our control”. A technology leader takes responsibility equally for both insourced and outsourced products and services.³
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.

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.

Disclaimers:

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 Amazon.com. 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.

Silicon Alley Insider and ValleyWag have amusing spins on it. :-) [↩]
There may be extreme instances, especially when criminal activity or malicious wrongdoing was the cause where it would be appropriate to blame someone. [↩]
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

Posted on January 31, 2008 by Rajiv Pant

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.

People Management Track	Technical (Engineering) Track	Technical (Project Management) Track	Band	Salary
				From (Typical)	To (Max)
Manages team of people and/or manages work assigned to others	May lead people, but usually does not manage people from HR perspective	May lead people, but usually does not manage people from HR perspective		Please refer to the notes at the bottom of this table.

CTO, Executive Vice Present	Chief Scientist & EVP	EVP [Program]	5.2	300	600
Senior Vice President	Distinguished Fellow & SVP	SVP [Program]	5.1	250	500
Vice President	Fellow & VP	VP [Program]	5.0	200	400

Executive Director	Architect & Executive Director	Executive Program Director	4.2	180	220
Senior Director	Architect & Senior Director	Senior Program Director	4.1	160	200
Director	Architect & Director	Program Director	4.0	140	180

Deputy Director	Architect & Deputy Director	Deputy Program Director	3.2	140	180
Senior Manager	Senior Architect	Senior Program Manager	3.1	120	160
Manager	Architect	Program Manager	3.0	100	140

Lead Technical Business Analyst	Lead Engineer	Lead Project Manager	2.2	100	140
Senior Technical Business Analyst	Senior Engineer	Senior Project Manager	2.1	80	120
Technical Business Analyst	Engineer	Project Manager	2.0	60	100

Apprentice Technical Analyst	Apprentice Engineer	Project Coordinator	1.0	30	60

Notes: In this table, a number like 100 may correspond to a salary of US $100,000/year. However, please note that salaries vary greatly based on industry, the particular company, market conditions and location. Comparing your salary to the To (read: Often The Maximum) end of the range is unrealistic. The From (read: Typical) is not the Minimum. In many markets and companies, the minimum of the range is lower than that. The example salary ranges shown here are based on data from online research (Salary.com, RobertHalf.com, GlassDoor.com, etc.), experience and discussions with people in the industry. The salary range within any particular rank is wide since salary is based not just on rank, but also on factors like performance and specific job roles and requirements. There is significant overlap in salary ranges in nearby ranks to reflect the realities of salary differences among employees based on factors like areas of expertise of the employee, the person’s prior salary history and market/company conditions at the time of hiring. Salaries for VP and above jobs vary widely across industries, organizations and even within the same company, especially since performance based bonuses vary greatly.

This system isn’t meant to be rigid. It is designed to find a good balance with most organizations. That balance, i.e. how may “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 military¹ 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:²

Large corporations in research and development-intensive industries³ 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.

Interviewing By Putting To Work

Posted on April 17, 2007 by Rajiv Pant

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.

Owning vs. Renting Software

Posted on March 24, 2007 by Rajiv Pant

At interviews, technology executives are often asked about build vs. buy. The question would be better articulated as own vs. rent. See, building and buying in the true sense are often part of the same ideology: owning. For example, Google bought Blogger and YouTube. As a result, Blogger and YouTube programmers (builders) became Google employees. When people ask about companies buying software, they are almost always referring to leasing or renting software.

I consider using open source to be in the own camp, because you can withing reason do as you please with your copy of the open source software and no one can take it away from you. Open source makes owning even better. It enables owning and sharing at the same time, which benefits the community.

Often technology executives answer this question ambiguously. They claim they have no preference towards either owning or renting software. To me, when a person provides such a noncommittal answer, it means they might lack leadership, vision, a clear philosophy, or the courage to give an honest answer to a prospective employer.

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. Circumstances by themselves don’t make the own vs. rent decision. That’s where people come in. A leader does not manage their company or department at the whim of circumstances. A leader has a style, has preferences and applies them to the situation. Leaders who prefer either one of owning or renting can be equally successful in the same organization and circumstances.

Here I present my viewpoint on why sometimes a philosophy of renting software as much as possible runs companies into trouble. 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 at a high cost. Later, the company will find it wasn’t worth the investment, even though they may not admit it or even like to talk about it.

When a company owns a software product core to its business, it can use it towards a competetive advantage. When you own the software product, you also have control over your data. When a vendor hosts and manages your data, in most cases you have practically relinquished control of your data even though your contract may say on paper it is yours.

When you own the products you use, it is generally easier to integrate with other systems. Your timelines are less at the mercy of vendors.

However the future of software may be changing. With web applications becoming popular, even home users may be renting software on a pay-per-use basis. I’ll have more to write on that subject. Stay tuned.

7 Tips for Effective Email

Posted on March 24, 2007 by Rajiv Pant

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

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.

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

Sometimes extra steps in workflows are good

Posted on August 31, 2006 by Rajiv Pant

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:

unlock the car door
pull the door handle
open the door
get inside the car
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.

Project Management: Time to Market, People & Teamwork

Posted on April 1, 2006 by Rajiv Pant

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:

People & teamwork
Priorities
Planning
Process & operations
Products & technologies
Pace & acceleration

Technology, Innovation and Business Decisions

Posted on April 25, 2005 by Rajiv Pant

Nowadays, it is becoming fashionable to belittle technology. I hear people say things like “technologies should not drive business decisions“, “define your requirements without worrying about technology and ask technology [people] to deliver them“. May sound logical at first, but is it? Consider this imaginary conversation between Bill, a technologist and Plato, a Platonist businessperson.

Bill: How do you commute to work?
Plato: I drive.
Bill: Why don’t you fly or teleport?
Plato: What do you mean?
Bill: Why do you use a car that drives on the road, why not a personal flying machine or a teleporter?
Plato: Because they aren’t invented yet.

Defining business needs without consideration of technology is impractical. It is being quixotic and ignoring the current reality. Leave the dreaming for the innovators since they and businesspeople are usually different people.

Think about ten important inventions that changed the world. How many of them were created with a business plan? How do you think the wheel was invented? How was fire discovered? Did someone create this World Wide Web with a business plan? Many important things were created with a business plan. The point here is not that business is unimportant, but that technology is important on its own merit.

Sound business practices have an important place in this world. Technology and innovation have a place in this world. One is not master to the other.

Web Site of Rajiv Pant

Victory is winning people, not defeating others.

Tag Archives: Management