Tag Archives: Management

Ray Dalio, Randall Munroe and I Think Alike – Culture of Courage & Candor

Leave a reply

On the matter of bad behavior of complaining against others behind their backs, Ray Dalio, Randall Munroe and I share the same viewpoint. This article starts with Randall’s cartoon, Ray’s and my quotes on the subject and then discusses the causes of and solutions for this problem. Please note that this article is not about ethical whistleblowers, people who have no choice but to complain secretly about someone in a position of great power and formal authority above them engaged in wrongdoing. Backstabbing (the subject of this article) and whistle-blowing are two completely different things.1 This post is about someone complaining against his peers, those he sees as  competition or those who may be in his way.

Cartoon from XKCD by Randall Munroe

Ray’s quote:

I learned that I want the people I deal with to say what they really believe and to listen to what others say in reply, in order to find out what is true. I learned that one of the greatest sources of problems in our society arises from people having loads of wrong theories in their heads—often theories that are critical of others—that they won’t test by speaking to the relevant people about them. Instead, they talk behind people’s backs, which leads to pervasive misinformation. I learned to hate this because I could see that making judgments about people so that they are tried and sentenced in your head, without asking them for their perspective, is both unethical and unproductive.2 So I learned to love real integrity (saying the same things as one believes)3 and to despise the lack of it.4

– Ray Dalio, an American businessman and founder of the investment firm Bridgewater Associates. Bridgewater is the world’s largest hedge fund company with US$122 billion in assets under management (as of 2011). In 2012, Dalio appeared on the annual Time 100 list of the 100 most influential people in the world. In 2011 and 2012 he was listed by Bloomberg Markets as one of the 50 Most Influential people. Institutional Investor’s Alpha ranked him No. 2 on their 2012 Rich List.
Quote sourced from Principles by Ray Dalio. Emphasis mine. Brief bio of Ray Dalio from Wikipedia. Thanks to my colleague Leon Shklar for introducing me to Ray’s philosophy.

My quote:

When someone complains negatively about a problem, person or situation it often indicates a lack of courage, skill, desire & collaboration required to solve it. Worse, it may be for nefarious reasons.

Senior executives should listen to and reward employees who focus on solutions and support their coworkers. People in leadership should be wary of people who habitually complain about others. Since complainers misleadingly pretend to be smart or helpful, you should always question their motives, challenge their statements and let them know you will ask for others’ viewpoints.

Once you know about such behavior, you should strongly discourage it. The first step is to make sure you don’t reward it. When a senior executive simply listens to a complainer and does not challenge their statements and does not tell they will solicit others opinions as well, the complainer may feel rewarded with the executive’s attention and implicit approval. Things an executive hearing the complaints can say:

  • What did [the target person] say in response when you told them this?
  • Have you spoken to [the target person] about this clearly, honestly and comprehensively? I will reach out to them to understand their viewpoint. (This makes it clear to the complainer that they can’t get away misrepresenting things behind another’s back.)
  • Do you have a collaborative solution to offer that makes it a win/win for both you and [the target person]?

– Rajiv Pant
Quote originally published on Rajiv’s Google+ Page

Why badmouthing others behind their backs is bad for business…

Its toxicity kills productivity. Robert I. Sutton, Professor of Management science at the Stanford Engineering School and a researcher in the field of Evidence-based management writes: [emphasis mine]

… if you want people to think you are smart, apparently you can feed their stereotypes by demeaning others…  I should also warn you that although unleashing your inner asshole may help persuade people of your intellectual superiority, we also show in The Knowing-Doing Gap and Hard Facts that the climate of fear created by such nastiness undermines team and organizational effectiveness.  Potential victims become afraid to try (or even mention) new ideas and hesitate to report mistakes or problems out of fear that the resulting anger and humiliation will be aimed at them.

It creates distrust among coworkers which hurts collaboration and productivity. It distracts focus away from productive work to “watching your back”. It lowers morale at work, which is also bad for business.

On the perpetrator’s side, it diverts creative energy away from business innovation, solving problems and achieving greatness. Instead the perpetrator’s talents, time and tricks are applied towards crafty, cunning and cruel behavior that only hurts the organization.

At its worst, when it becomes a rampant problem, it can lead to costly lawsuits against the organization. When you develop a habit of badmouthing someone behind their back thinking your accusations will remain secret, and you keep getting away with it for a while, you are likely to start saying things that cross the line.

 

Why it happens…

So why do people engage in smear campaigns? Simply because they have found them to be useful for their benefit in the past. There is ample evidence in multiple fields ranging from election campaigns to organizational behavior that despite being immoral, unethical and unfair, smear campaigns can sometimes be highly effective for the perpetrators. At least for the short term. In an organization with a bad culture it benefits the perpetrator every time they do it and there are minimal harmful consequences to the perpetrator.

I asked my friend Professor Jeffery Pfeffer, a well-respected guru of organizational behavior at Stanford University’s Graduate School of Business why such behavior exists. He explained that “It persists because it often works, and it often works because negativity and criticism seem more profound than positive statements.” He pointed me to his5 article The Smart-Talk Trap published in Harvard Business Review and the article Brilliant but Cruel by Teresa Amabile, now a professor at Harvard Business School. (The word “brilliant” here alludes to a pretense of brilliance, not the real thing.) Those two articles explain that people who disparage others or the work of others falsely appear to look smart and competent, even when they are not so in reality. Basically, it is a cheap trick that works until it is exposed.

The false feeling of being honest (when in reality they are being dishonest) in supposedly exposing  the flaws in others and/or other’s work provides misguided gratification to the perpetrators. When the important person to whom the clandestine complaint is being made to (and it is usually an important person) listens to the complainer in private and engages in that conversation, the complainer sees that as a reward. This encourages more of such bad behavior.

An even bigger mistake a person in a position of power can make after hearing a one-sided complaint is to substantially reward the complainer. By a substantial reward, I mean giving a promotion, power or pleasure of winning. That is not only unjust, unfair and unwise, but a display of poor judgement.

A root cause of this problem is lack of courage. Another is insecurity. It takes courage to walk up to someone you have a problem with, to tell them that on their face with candor especially when you are insecure inside that your accusations will be able to sustain to a fair trial. It is much easier to be a coward and do it hoping the accused will never find out, at least not until it is too late.

Insecurity and an inner lack of confidence in the merits of their accusations are behind complaints that are supposedly backed by unverifiable sources. When someone complains about another and says “others have also complained about [the target person], but they confided in me privately and wish to remain anonymous,” the listeners’ alarm bells should go off. This method of trying to sully someone’s reputation by adding the supposed support of unidentified others is weak at best and disingenuous at worst. There is no way for the leader to know what the unknown people actually said, and if they did complain in what context and what state of mind it happened. Worse, this perpetrator could have baited them unwittingly into speaking negatively about someone they otherwise wouldn’t have. Remember that the complainer is not an unbiased journalist with integrity writing an article citing anonymous sources (and even they have to verify their sources to an Editor), but is most likely an opinionated person with an agenda. If you are a leader, think like a judge or a journalist. Don’t just believe what you hear, especially this type of BS.

On the leader’s side, the one to whom the one-sided complaint is brought, the problem is also a lack of courage. It takes courage to tell someone who is seemingly confiding in you and appears to be trusting you that you do not entertain such bad behavior and that you will put this person and yourself in a deeply uncomfortable position by bringing the accused in to the discussion.

Especially in this day and age of political correctness, being sneaky, disingenuous and cowardly is much easier than being open, honest and courageous.

Unless your organization has a great culture.

…and how to discourage it

So how should executives in an organization discourage such bad behavior? With a culture of continuous and consistent fairness.

In many cases, complaining behind others’ backs also badly backfires. I mentioned earlier that it is cheap trick that works until it is exposed. An effective way to hinder such behavior is to spread awareness about it, for example, by sharing this article. By making it a well-known fact in your organization that such behavior is bad for the business and backfires for the perpetrator, you eliminate its effectiveness.

People for whom such behavior has backfired, causing them harm instead of benefitting them, learn to not do it anymore, provided they quickly realized that it was their bad behavior that hurt them. The human mind learns best when the feedback is immediate or comes soon after.

Therein lies the key to solving this problem in your organization.

Senior executives should build and maintain a culture holds open courts. What does that mean? This:

  • There are no trials held in private. Both parties must be present when any arguments are made in front of the judges (deciders, people with power). In other words, senior executives never entertain clandestine complaints made secretly behind the accused’s backs.
  • The accused always gets a fair hearing. If the accused does not have the debating skills to defend their case, the senior executives should assign someone strong to support them in a public-defender-like role. Winners should not be decided on the basis or their ability to win debates, but on the merits of their case.
  • Senior executives should be careful to never reward this bad behavior, and not even give the complainer the pleasure of indulging them in such a conversation.
  • Most importantly, senior executives must model good, desirable and fair behavior themselves.

The last point is especially important. People look up to successful, effective senior executives. People copy the behaviors they see emanating from the successful person. If senior executives badmouth other people behind their backs, people who look up to them are likely to emulate that behavior. If they see senior executives as respectful, supportive and caring of others, they will learn that. Mirror neurons in action. Which reminds me:

Look in the mirror.

Further Reading

Some neuroscience research related to this

(Shared by Cameron Brown)

 In person learning

badmouthing-behind-back-bad-for-business-cover-slide

  1. For whistle-blowing, there are formal established means. For example, speaking with legal authorities, human resources, or journalists, depending on the situation. [↩]
  2. It is unethical because a basic principle of justice is that everyone has the right to face his accuser. And it is unproductive because it does not lead to the exploration of “Is it true?” which can lead to understanding and improvement. — Ray Dalio [↩]
  3. I do not mean that you should say everything you think, just that what you do say matches your thoughts. – Ray Dalio [↩]
  4. The word “integrity” is from the Latin root “integer,” which means “one” i.e., that you are the same inside and out. Most people would be insulted if you told them that they don’t have integrity—but how many people do you know who tell people what they really think? – Ray Dalio [↩]
  5. co-authored with Bob Sutton  [↩]

Maker’s Schedule (For Managers Too)

Leave a reply

The following memo from a department head to staff is an example of how to implement a productive maker’s schedule at your workplace. This approach recommends starting with baby steps, evaluating results and making changes accordingly.

Comic strip from XKCD

Dear Colleagues in the Technology, Project Management and Product Teams,

Executive Summary:1

We are implementing a maker’s schedule starting this Friday May 31st which means developers will have from 12 noon onwards on Fridays to focus exclusively on writing code, with no meetings or other interruptions. (This also applies to other contributors besides developers. For more information, see details below.) The goal of this is to increase productivity, creativity and job satisfaction. This practice is based on science and employed by other successful organizations. We request your understanding, your support, and your help in making Friday afternoons meeting-free.

The Details:

We are implementing a maker’s schedule system starting Friday May 31, 2013. What is it? A maker’s schedule is calendar scheduling system that gives a group of people a continuous multi-hour block of time to focus on their work with minimal productivity diminishing things like distractions, context switching or frequent interruptions.

The word maker in this context often refers to people like software engineers, designers, testers, systems engineers, infrastructure engineers, documentation authors, editors or anyone else making something. What they are making could be software code, documentation or a configured server. It need not even be technical work. Managers also do the work of making: writing a memo, editing a budget spreadsheet or creating a slide presentation, for example.2

The human brain has evolved in a way that creative work, innovation and productivity are maximized when a person is able to focus and work on one task at a time for multiple hours. It takes several minutes, often half an hour or longer to get in the flow state of mind that results in peak performance at work. Hourlong or half-hour long meetings peppered throughout the day with breaks in between supposedly to do productive work result in low quality work, cause stress, and lead to unhappiness.

One way to do better quality work, get more done and be happier in your job is to divide your day into two halves. Get all your meetings, emails and administrative tasks done in the first half and spend the entire second half of the day doing enjoyable creative work that puts you in the flow state of mind. You will leave the office less stressed, more satisfied and happier each day.

If you are interested in learning more about the maker’s schedule concept, the article titled Maker’s Schedule, Manager’s Schedule by Paul Graham is a good introduction.

Below are the answers to some frequently asked questions.

Q: Who does this policy apply to?
A: This applies to all makers as listed above, especially all engineers and quality assurance staff, people who spend the majority of their time writing, designing or implementing software code, systems or designs. This also extends to those in management roles who’d like to use this time to do maker’s work.  At this time, we are not applying this policy to employees with special employment contracts like guild or unionized employees.

Q: When will we have maker’s hours?
A: Fridays after 12 noon, i.e. the latter half of all Fridays going forward until further notice.

Q: Does this mean I can go home early on Fridays?
A: No. This is not a summer hours policy. This is meant to be uninterrupted software engineering and development time. It does not change anything about when you are expected to be in the office. The prior agreed upon schedules you have with the company will continue.

Q: Why Fridays and why only Friday afternoons?
A: We analyzed our organization’s current meetings schedule and found that Friday afternoon is the period where there are least meetings and those meetings can be rescheduled with least impact. We are starting the pilot program with Friday afternoons. After some months of evaluating the results, we may extend it, keep it the same or cancel it. Until Further notice, this policy applies only to Friday afternoons.

Q: Does this mean I only get Friday afternoons to write code?
A: No :-) What this means is that we must all do our best to not organize, nor attend meetings on Friday afternoons so that time is exclusively reserved for writing code, building systems and doing other maker’s work. You are expected to do maker’s work every business day and to manage your own schedule to block off enough time to do that on others day the same way you already do.

Q: What about production emergencies? Can I get called into an emergency meeting to deal with a critical production emergency?
A: Yes. Production emergencies qualify among the rare exceptions.

Q: What about meetings between makers? For example, between two software engineers.
A: That is a slippery slope. We are strongly discouraging meetings on Friday afternoons in this policy, but we are not the meeting police and are not going to ban all meetings, especially if all the attendees have a strong desire to meet. We trust you to use your best judgement and lean towards not holding meetings on Friday afternoons unless you determine you have a good reason to make an exception to this policy. Our suggestion is this: Pair programming is encouraged. Working sessions are ok, assuming that in the entire working session multiple makers are making something together. However having staff meetings at this time is not a good idea. Nor is it a good time to have your weekly 1-on-1 with your manager. Remember your manager is likely to be using this time to do their own maker’s work. So on the question of can developers hold a meeting with just developers at this time, ask yourself why. What is the meeting for? Is it a working session where each of you will make something together? If yes, that’s likely fine. If not, schedule it for another time.

Q: What should I do when someone invites me to a meeting on Friday afternoon and I plan to observe the maker’s schedule and write code at that time?
A: Please always be respectful, courteous and friendly while declining meetings. Use your discretion and common sense. If the meeting request comes from someone it may not be wise to decline, consult with your boss. In many cases, you can politely, respectfully and nicely point the meeting requester to this policy at http://www.rajiv.com/blog/2013/05/24/makers-schedule-for-managers-too/ and suggest or request another time. Letting your collaborators know about this policy in advance will also help.

  1. Thanks to David Perpich for suggesting this executive summary. [↩]
  2. Since processing email has become such an information overload problem, distraction and waste of time these days, we hesitate to classify doing email as productive maker’s work. If you don’t have the unproductive bad habit of checking your email every 15 minutes and instead you process your email during a few blocks of time a day, you may consider email productive work too. [↩]

Three Pillars of a Media/Publishing Company

Leave a reply
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?

 

HR Classification and Discretionary/Business Job Titles for Makers, Managers and Leaders in Technology

Leave a reply

This article presents an organization system and policy for job titles of maker, manager and leader roles in technology staffs.

Separate job titles for HR classification and discretionary/business use are used at many technology organizations, ranging from medium-sized, innovative and fast-moving companies to large, established and enterprise technology companies.1 This is a well-established practice that balances HR requirements with the rapid pace of innovation and change in job functions. They each serve a different purpose: HR classification titles are designed for use by information systems and discretionary/business titles are designed for use by humans.

HR Classification Job Titles are meant to be comparable in the entire organization (across different departments) and sometimes even comparable with other organizations. The purpose of these is to maintain standardization across the organization for HR purposes such as payroll, benefits and eligibility for things. The number of HR classification titles at each role level should be finite and small. They do not change unless there is a major change in the person’s job like a promotion or new functional role. They map to the employee’s internal level, status and eligibility for things in the company. They follow a standardized naming convention for logical classification.

Discretionary/Business Job Titles, on the other hand, are used to describe the job (or a key part of the job) in easy to understand language. A person’s discretionary/business title can change, if desired, with smaller changes in the role compared to what warrants a HR classification title change. These titles are named in human-friendly language (and do not need to be worded for logical classification like HR classification titles). Discretionary/business titles are usually the ones employees put on their email signatures, business cards, online forums and social media sites. The number of discretionary job titles at a job level is limited only by the requesters’ imagination.

Below are some examples of HR classification titles along with examples of some corresponding discretionary/business titles. Employees may propose their discretionary/business titles to their supervisors. Most of the titles below are for technology staff, but some non-technology titles are included for comparison.

HR Classification Job TitlesExamples of Corresponding Discretionary/BUSINESS Job Titles
  • Engineer
  • Senior Engineer
(Software)
  • iOS Software Developer
  • Software Engineer, Mobile Applications, Android
  • User Experience Engineer
  • Release Engineer
  • Product Engineer
  • Software Development Engineer in Test
  • Test Automation Engineer
  • Web Developer
  • Mobile Apps Developer
  • JavaScript Programmer
  • Code Ninja2
  • Software Artisan
  • Developer Advocate3
  • Video Software Developer

These are software engineers, also known as computer programmers and software developers. The key job requirement is that they write software code.

When appropriate, the prefix “Senior” may be applied to these titles except where noted.

  • Engineer
  • Senior Engineer
(Systems)
  • Systems Engineer
  • Systems Administrator
  • Unix Systems Engineer
  • Infrastructure Engineer
  • Network Engineer
  • Security Engineer
  • Windows Systems Administrator
  • Unix Guru4
  • Video Systems Engineer
  • Robotics Engineer
  • Hardware Engineer
  • Web & App Servers Administrator
  • Database Engineer
  • Database Administrator
  • Sysadmin
  • Email Administrator
These are systems, networks and other engineers. They implement, maintain and upgrade systems. While they are not required to write as much code as software engineers, they are likely to do some scripting to assist in their jobs.
When appropriate, the prefix “Senior” may be applied to these titles except where noted.
  • Analyst
  • Senior Analyst
  • Technical Analyst
  • Quality Assurance Analyst
  • Quality Assurance Tester5
  • Business Analyst
  • Product Analyst
  • Functional Analyst
  • Financial Analyst
  • Business Intelligence Analyst
  • Technology Support Analyst

Analysts are generally not required to write code, but some may.

When appropriate, the prefix “Senior” may be applied to these titles except where noted.

  • Designer
  • Senior Designer
  • Graphics Designer
  • Photo Designer
  • Art Illustrator
  • Graphics Artist
  • Visual Designer

When appropriate, the prefix “Senior” may be applied to these titles except where noted.

  • Manager
  • Senior Manager
  • Technology Manager
  • Engineering Manager
  • Software Development Manager
  • Manager of Quality Assurance for Mobile Apps
  • Manager of Engineering for Product X
  • Staff Software Engineer6
  • Lead Software Engineer7
  • Software Architect
  • Applications Architect
  • Systems Architect
  • Program Manager
When appropriate, the prefix “Senior” may be applied to these titles except where noted.
  • Director
  • Senior Director
  • Technology Director
  • Video Technology Director
  • Director of Engineering for Food & Dining Products
  • Director of Content Management Systems
  • Director of Quality for Products X, Y & Z
  • Distinguished Software Engineer8
  • Program Director
  • Director of Project Management
  • Director of Products X, Y & Z
When appropriate, the prefix “Senior” may be applied to these titles except where noted.
  • Vice President
  • Senior Vice President
  • Executive Vice President
  • President
  • CEO
  • Chairperson
  • Board Member
  • Chief Technology Officer
  • Chief Information Officer
  • Chief Scientist
  • Fellow
  • Chief Operating Officer
  • Chief Financial Officer
(any title)
  • Founder
  • Co-Founder
  • Emeritus

Often used in combination with other words, these can be used in a discretionary/business title, but obviously, only if they are true.

Discretionary Titles are official, significant and used inside and outside the organization. Therefore, like HR Classification Titles, they also need to be approved in advance.

Policy and Guidelines for Discretionary/Business Titles

  1. Assignment of discretionary/business titles (and changes to them) must be approved in advance by the same people who approve assignment of HR classification titles. Once assigned, it must be documented in the HR information system.
    • Typically this requires two people: 1. the immediate supervisor of the employee, and 2. an HR representative to comply with these guidelines. In case of doubt, dispute or disagreement it should go to a department head, staffing committee or similar body for confirmation.
    • The benefit of this process is the employee will feel good in knowing that the discretionary title is official, recognized and endorsed by the company.
  2. Please refer to the examples above see what types of discretionary/business titles are likely to be acceptable.
  3. Inappropriate, offensive or harmful language is disallowed. (E.g. “Code Nazi” and “Architect of Terror” are not ok.)
  4. It must not reflect poorly on the organization. (E.g. “Underutilized Engineer” and “Dissatisfied Manager” are not ok.)
  5. It must not make unauthorized use of trademarks, copyrighted material or anything else that is likely to run afoul of the law, policies or best practices. (E.g. “Facebook API Engineer” is not ok unless you work at Facebook.)
  6. It must reasonably relate to or represent the job, at least partly. It can’t be completely meaningless to the job. (“E.g. “Ninja” is likely not ok, but “Code Ninja” is likely to be ok, provided it is not someone else’s trademark.)
  7. The title must not exaggerate the scope, authority (decision making or staff), or level of influence of the role. (E.g. you must not call yourself just “Head of Software Development” unless you are the one and only head of all software development.)
  8. When the employee and their supervisor do not see the need for separate HR classification and discretionary/business titles, they can be the same. (E.g. Software Engineer).
  9. When required, sensible and appropriate, the discretionary and HR classification titles may be written together in combined form. (For example, on a resume or biography, the employee can write “Director & Distinguished Software Engineer”, “Staff Software Engineer (Manager-level position)”, “Vice President & Fellow”, etc.)
  10. When in doubt, consult with your department head or HR representative.
  1. For example, discretionary/business titles are used at Oracle. [↩]
  2. Fun titles may be acceptable as long as they match the role [↩]
  3. Assuming that the developer advocate needs to also be a software engineer [↩]
  4. Another example of a fun title that matches the role [↩]
  5. For testers who are not software development engineers. Those who are would have an HR classification title of software engineer [↩]
  6. Staff Software Engineer is a people-manager level maker role. It is equivalent to an architect level, but unlike an architect who often reviews others’ code, a staff software engineer is generally an individual contributor. [↩]
  7. Equivalent to Staff Software Engineer [↩]
  8. The word distinguished is reserved for software engineers who are contributing value at the people-director level. At the VP level, the distinguished engineer becomes a Fellow. The bar for earning this title is exceptionally high and requires extraordinary achievements. E.g. inventing a programming language or software framework used by hundreds of people in multiple companies. Distinguished Engineers are typically well respected outside the organization. Prefixes such as Senior cannot be applied to the title Distinguished Engineer. [↩]

5 Productivity Tips for Executives in Leadership & Management Roles

Leave a reply

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

Your Brain At Work (Book Review)

3 Replies

Let me tell you a story about my friends Emily and Paul.

Emily and Paul were struggling in their demanding jobs and in managing their busy family life raising young children at home.

Emily, a marketing manager at a company, had recently earned a promotion to VP and was finding it challenging to supervise the team comprised of people who were her peers until recently. Paul, an independent software engineer and project manager, was running into problems completing the proposal for a software development project for his client, managing his subcontractors, and determining the best way to architect and implement the software product.

Their workdays were burdened with email overload, filled with meetings, and interrupted by phone calls at the most inopportune moments. They multitasked during meetings, responding to emails on their smartphones1 while missing important discussions and failing to pick on subtle (and some not so subtle) human interactions.

Life at home was no child’s play either. Their son, Josh, and daughter, Michelle, didn’t feel their parents understood them. The parents and children didn’t communicate on the same wavelength. This led to the parents and children talking over each other and having angry arguments.

So Emily and Paul turned to a consultant called D’Rock for help. By following his evidence-based, proven, scientific advice, Emily and Paul began to get increasingly better in their jobs, with family and in social settings.  They didn’t become perfect: They still made occasional mistakes, but fewer and smaller ones, and when they did, they recovered well.2

The improvements in their lives were measurable, major and memorable. Emily and Paul became highly successful in their jobs, solved the problems with their children at home and even developed a more enjoyable sex life!

How?

All this was possible because D’Rock was no ordinary consultant, but a neuromagician (stay with me here) — a superhero with who had the ability to give other people the power to change themselves for the better.

Here is the surprising twist to this story: D’Rock, the neurosuperhero character in this story is a real person called David Rock. He has even written a book that can help you overcome major challenges like Emily and Paul did.

Following David Rock’s advice will make you more successful in your professional, personal and social life. It is highly likely to make you a better computer programmer, a better project manager, a better people leader — better at pretty much every aspect of your job. It will make you smarter, more effective and happier. It will even enable you to fly. Ok. I’m joking about the flying part. Unless you are a pilot.

Before you ask me what drugs am I taking that have caused this flooding of dopamine into the synapses in my brain and is causing me these delusions, read the book Your Brain At Work and see if it changes your mind.

The book is enjoyable, educational and easy to learn from since it is written in the form of stories. That’s one of the best ways the human brain learns.

I highly recommend reading this book. Once every six months.

Rating: ★★★★★

  1. Doing emails on smartphone during a meeting, by the way, is a not-so-smart habit. [↩]
  2. The path of steady progress is preferable to the pursuit of unattainable perfection. I call this the P5 principle. [↩]

Case for a Consistent, Comprehensible & Cost-Effective Vacation Policy

1 Reply

This article makes a case for having a vacation policy that is simple, sane and standard across the organization.

Some organizations have unnecessarily complicated vacation policies that require a lot of labor and time to implement, manage and support exceptions for. That is substandard because such vacation policies are costly for the organization, they distract from the organization’s other work and they make some employees feel unfairly treated.

Most companies would be better off with a simple vacation policy for all full-time employees.1 Here is a such a vacation policy. It can be described in one sentence as:

Every full-time employee gets 25 days (5 weeks) of paid time off per calendar year.

Detailed explanation and justification

To some managers in the United States, it may initially seem that 5 weeks is too much for entry level employees or workers at the early stages of their careers. However, 25 days is not too much, especially considering that these also include paid personal days off. Many organizations already give employees about 5 personal paid days off (in addition to their vacation days) to use for personal/family/religious/social events, the day before/after major holiday etc. So you could think of this policy as: Every FTE in the organization gets 20 days (4 weeks) of paid vacation, plus 5 more paid personal days off per each calendar year.

Here is one way the 5 weeks could be scheduled: The 4 four weeks of regular vacation would be meant to be used for regular vacations. As long as it is ok with the employee’s supervisor, it could be one 4-week long trip to another country, two 2-week long vacations, or even 20 separate Fridays taken off during a calendar year.

The 5 personal days would be meant to be used for other purposes like birthdays, anniversaries, personal/family/religious/social events, needing a day off at the last moment to run errands, take off the day before/after a company holiday.

Fair, consistent and simple

Every FTE from the CEO to a entry-level engineer gets the same number of paid days off.

Vacation time is a necessary downtime for employees to relax, recharge and refresh. It should not be viewed as a perk. By giving senior-level executives more vacation days and making vacation seem like compensation sends the wrong message at multiple levels: Is the organization implying that senior-level people put in less time and effort? Is it implying that being away from work more is a valuable and desirable thing that employees should strive for?

Senior executives and entry-level employees alike get a two-day weekend. They get the same number of company holidays. They have the same sick-day policies. They should also have the same number of vacation days per year.

All prospective employees are informed of this consistent policy: 5 weeks vacation for all full-time employees, regardless of role, level and compensation. This eliminates distracting negotiations during the hiring process about vacation days. After which, existing employees can feel demoralized learning that some of their peers have more vacation days for no fair reason. Unlike compensation, vacation time is not private information. In a team that works closely together, people can often observe how much vacation their colleagues are taking if they choose to.

Speaking of sick-days, a detailed discussion of that is currently beyond the scope of this article and likely the subject of an article about employee health policy. Sick days should be separate from vacation.

Accrual, Carry Over & Trading

Vacation days are not collectors items. Also, they do not have any cash value as per this policy. Employees should be encouraged to use all of their vacation days each calendar year. Taking vacation is good for the employees. It increases morale, productivity and innovation.2 So it is good for the company. Vacation days may not be carried over from one calendar year to the next, nor can they be transferred to other employees. They can definitely not be redeemed for cash.

In this system, vacation days do not accrue incrementally over the year, so employees can’t redeem any unused ones for money even if they leave the organization. You could think of it this way: They accrue all together at the end of the year. When an employee leaves the company, they are not expected to pay the company back for their vacation days used either.

As for when a new employee (or any employee) can take vacation, that should be discussed between the employee and their supervisor and needs to be signed off by the supervisor. Use trust and common sense. In almost all cases, it would not make sense to take a month-long vacation after just one day at the job.

As for the first calendar year of new employee’s joining, we can apply the following simple formula: The number of vacation days you get in your first calendar year is adjusted based on the number of weeks remaining in that year, using whole numbers rounded up. For example, if you join in the middle of the year with 26 weeks remaining (half the total number of weeks in the year), you get 13 days of vacation that first calendar year (half of 25 days, rounded up).

Alternative Policies

These days, a few companies offer open-ended vacation policies, where there is pre-set limit to the number of vacation days an employee can take, within reason.3 Realistically, these are not unlimited vacation policies, the same way credit cards with no pre-set spending limit don’t allow unlimited spending.

The data on these open-ended vacation policies is not yet conclusive, but initial data indicates that they have two potential drawbacks: 1. They result in employees taking less vacation time, and 2. They cause employees to keep working during their “vacations”, which defeats the purpose and benefits of vacations.

For these reasons, I recommend this 25 vacations days per calendar year policy over open-ended policies that may backfire.

Benefits

A clear, consistent and complete vacation policy like this is likely to lower administrative costs, make employees happier and increase productivity. It is also likely to make the company more attractive to potential hires and improve retention.

  1. By full-time employee (FTE), I am referring to a person directly employed by the organization who is expected to work ~40 hour/week, typically on a Mon-Fri schedule. [↩]
  2. The Case for Vacation: Why Science Says Breaks Are Good for Productivity: The Atlantic  [↩]
  3. IBM’s un-vacation policy: All you need, all the time: article in The New York Times  [↩]

Product Maintenance vs. New Development on Web Sites, Mobile Apps and Other Digital Products

1 Reply

maintenance

Maintenance of a digital business product (e.g. a Web site, mobile app, or software) refers to the work that includes modifications made after delivery to production to fix bugs, address compliance/security issues, or improve scalability/performance These modifications can be to the product’s software code, configuration, documentation, hardware, or surrounding network.

Maintenance is often contrasted with the development of new features and functionality to enhance or increase the capabilities of the product.

The distinction between maintenance vs. new feature development comes up in both internal and external contexts. In the external context, it pertains to a maintenance contract with an outside vendor. A vendor is likely to define maintenance in strict and narrow terms to minimize costs the vendor has to incur. In the internal context it is helpful in analyzing staffing and resourcing capacity of an organization which is needed to understand the bandwidth available to work on new initiatives.

The purpose of this article is to help answer questions such as: What do you mean by maintenance work? What should we consider maintenance vs. new feature development? Is there an industry standard definition? What’s our selection criteria? Can you give some examples? Other questions that often accompany these are: What ratio of maintenance vs. new features development work is considered best practice for our industry? How does our organization’s situation compare with that? These latter two questions require analysis specific to your organization and a set of reference organizations to answer.

The following illustrates some typical attributes of maintenance vs. new features.

Maintenance

New Features

Consequences of not doingOften maintenance work is not optional, i.e. the consequences of not doing maintenance range from the gradual decline of the product to complete breakdown of the product. Not doing maintenance often causes legal, security and other compliance issues.Implementation of new features, functionality and services is often optional. The negative consequences of not implementing new features typically include loss of competitive advantages, loss of market share, and decrease of relevance.
Financial impactThe financial value of an asset decreases in the absence of maintenance. Maintenance work helps maintain the value of the product, but typically does not substantially increase it.New features and functionality increase the financial value of an asset.

Types of Maintenance Done on Web Sites and Mobile Apps

Learning from the The International Standards Organization and International Electrotechnical Commission’s ISO/IEC 14764 specification, we define maintenance of a digital business product such as a Web site or mobile application into the following four categories:

  • Corrective maintenance: Reactive modification of the software, configuration or infrastructure powering a Web site or mobile app performed after delivery to correct discovered problems. E.g.
    • Bug fixes
    • Fixing design compatibility (HTML/JavaScript/CSS) issues with Web browsers that have been around for a while.
    • Install security patches to address existing security/privacy holes.
  • Adaptive maintenance: Modification of a software product performed after delivery to keep a software product usable in a changed or changing environment. E.g.:
    • Modifying a Web site to work with an newly emerging Web browser like a recently released version of Google Chrome.
    • Modifying a mobile app to comply with changes made by third parties, e.g. new terms of service from Facebook or Twitter, a new API released by Google+.
    • Increase capacity to handle increasing traffic on a Web site.
  • Perfective maintenance: Modification of a software product after delivery to improve performance or maintainability. E.g.:
    • Changes to servers or network to make the Web site serve quicker.
    • Refactoring the software code to make it less expensive to maintain and modify.
  • Preventive maintenance: Modification of a software product after delivery to detect and correct latent faults in the software product before they become effective faults. E.g.:
    • Y2K :-) fixes made on or before December 1999. Remember that? When we had to install patches and test software on the Web sites in the 90s.

The following are some examples of maintenance work contrasted with new features development.

Maintenance

New Features

Fixing bugs in existing software.Developing new Web applications or mobile apps. Adding major new features and functionality to existing apps.
Modifying software code on a Web application to comply with changes to Facebook’s application programming interface (API).Adding new software code to add support in a Web application for a new social network, e.g. Google+.
Rewriting parts of a Web application to handle increased usage (E.g. more users, users storing more data, growing traffic.)Developing a complete new Web application to replace an existing application to address the shortcomings the previous one has.
Routine work like generating, analyzing and publishing periodic reports.Designing, developing and automating a new report that has not existed before in the organization. Adding significant and major new features to an existing report.

In certain cases, the distinction between maintenance and new development can be blurry. For example, when rewriting (rebuilding) major parts of an application to overcome its shortcomings, at what point do we consider it a replacement (new development)? In such cases, it may be subjective based on how the output of the work is classified, branded and marketed. If it is being announced, launched and sold as a great new product to replace the old, it would be new development. This can cause issues when a customer has a maintenance contract with a vendor and doesn’t want to pay for the new version that doesn’t add substantial new functionality. That, however like all contracts, becomes matter of trust, relationships and reputation.

In the cases where an external vendor has a maintenance contract with a customer, the vendor is likely to not classify certain maintenance activities as maintenance since doing so would incur significant and unexpected costs the vendor would become responsible for. For example, a vendor may not include many adaptive types of maintenance in the contract. A vendor may want to charge the client more to handle increased usage.

Ratio of Maintenance vs. New Development

There is no “magic number” answer to this question. Ratios like 80/20, 70/30, 60/40 or 50/50 are specific to an organization in a specific phase. In today’s dynamic and hyper-competitive environment, seeking a best practice ratio for an industry may be misleading. A company or project in the startup phase typically has a lot more new development than maintenance happening than a organization with a mature product. Even within a particular company, the ratio changes as new projects start, are worked on and are completed. Decommissioning obsolete products also lowers the maintenance.

Related observations

Going down to maintenance mode for specific products does make good sense in certain circumstances. For example, when you are working on a major new version of the Web site or product, you can put the current (soon to be replaced) version in maintenance mode.

Sometimes, in times of financial hardship, companies try to hunker down to maintenance mode where they shed the new development work and do only the work required to “keep the lights on” to ride out the storm. This type of horizontal cutting of all products may initially seem like a good approach but in most cases, it is not a wise practice. In most circumstances of financial hardship, it is often wiser to cut products vertically. In other words, focus on doing a fewer number of products well rather than keep doing the same number of products poorly. Stopping new development and product innovation enables existing competitors to gain a huge lead over you. It creates opportunities for new competitors to your business and leads to the decline of your brand.

My article titled Trinity Method of Technology Management makes a case for decommissioning products the way Google does seasonal cleaning by ending products that no longer suit the company’s revised strategy.

References

 

Management & Technical Career Growth Tracks (v2)

1 Reply

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

Productive Business Meetings

1 Reply

Here are some suggestions for making business meetings more productive, efficient and effective.

Template for replying to a meeting request

When I receive a meeting request, I often reply with the following text. In fact, I have it saved as a TextExpander macro as a shortcut to typing it.

[ meeting-reply-template begins ]

May I please request the following information in advance of this meeting? It will enable me to prepare, participate and be productive in the meeting.

  1. What decisions need to be made at this meeting (if any)?
  2. What problems need to be solved at this meeting (if any)?
  3. What knowledge is planned to be shared at this meeting? (topics or documents)

Thank you,

[ meeting-reply-template ends ]

Suggested Template For Meeting Requests

Every time someone calls a meeting, they should consider using this simple template.

[ meeting-invitation-template begins ]

The desired outcome of this meeting is:

  • e.g. Come to agreement on solution for issue X
  • e.g. Make a decision about Y.
  • e.g. Share announcements about topic Z.
  • e.g. Continue to grow a good working relationship with each other by socializing in person.

Note: Explain what this meeting is meant to accomplish, instead of providing a description of the meeting. Focus on the desired result of the meeting. A meeting should accomplish one or more of three things:

  1. Solve problem(s)
  2. Make decision(s)
  3. Share knowledgeand agree to act on it and/or make it a practice
    • Knowledge, as in: data –leads-to–> information –leads-to–> knowledge –leads-to–> practice

You should come to this meeting because:

  • e.g. You are likely to have input into potential solutions for issue X
  • e.g. You are one of the folks who has a viewpoint on what decision to make regarding Y.
  • e.g. It would benefit you from hearing the announcements in this meeting.
  • e.g. This is your opportunity to ask questions about topic Z.

Note: Give the attendees at least one good reason to attend. Sometimes attendees have no idea why they are invited to this meeting. Don’t be seen as a waster of others’ time.

The guidelines for participating in this meeting are:

  • e.g. Please come prepared having read the document about ChaosMonkey.
  • e.g. Laptops & mobile communication devices are considered contraband during this meeting. If it is critical for you to have a computer during this meeting, bring a desktop computer :-)

Note: Set the expectations of the participations.

[ meeting-invitation-template ends ]

Further Reading & Thoughts:

 50/25 Meeting Format

If you manage a team, value your team members time and want to improve productivity at your workplace with a simple change, consider implementing the 50/25 Meeting Recommendation that some companies are embracing. You can communicate something like the following to your team:

Dear Colleagues,

We deeply value your time, your productivity and your comfort at the workplace. As a part of our initiative to make your workday more productive, less hectic and better manageable, we recommend a 50/25 meeting format. It is simple concept: As much as possible, let us take all our meetings that are 1-hour long and shorten them to 50 minutes. For our meetings that are half-hour long, let us limit them to 25 minutes.

You will find that a 50 minute meeting will accomplish no less than a 60 minute meeting did and a 25 minute meeting will be as productive as a 30 minute one was. In fact, by having clear 50 minute and 25 minute deadlines, our meetings are likely to be better focused, on topic and more attentive. (For example: Since you will have time after the meeting to check email, there is likely to be less temptation to check emails during the meeting itself.)

The extra 10 and 5 minutes will give you valuable time back that could be used for many useful activities: Getting in the frame of mind for the next meeting or task; checking your messages to see if there is something urgent that needs your attention; or simply taking a bio break.

Please note that this not a mandate, but a recommendation. We realize that you may not be able to do this for every meeting. What we ask is that you consider doing this for meetings that you organize or can influence. As a result, we will make our great work culture even better, less stressful and even fun.

Further Reading & Thoughts:

  • NYTimes article about Larry Page, Google’s founder and new CEO instituting the same 50/25 meeting recommendation at Google:
  • http://www.nytimes.com/2011/11/10/technology/googles-chief-works-to-trim-a-bloated-ship.html?pagewanted=all
  • If a meeting accomplishes all its goals in even less than the 50 or 25 minutes, please, by all means end the meeting even sooner.
  • We suggest that you do book the full hour or half hour in the calendar even as you implement the above so that others don’t schedule over the “10 minutes left over” in your calendar.

Thank you for considering this,

[Signature]

A discussion about this 50/25 Meeting Format: https://plus.google.com/107443707510532643538/posts/AtYgnmbhtqc

When to have and when not to schedule meetings

Companies should, by default, avoid scheduling meetings that start before 10am or end after 5pm. If an employee comes to the office at 8am on some days, it is often to use the two hours of the morning before meetings to catch up and/or get a head start on the day. Meetings that start before 10am are often harmful overall since they put the attendees in reactive catch up mode for the rest of the day. Similarly, meetings that go on beyond 5pm (or worse, start after 5pm) take away valuable time from employees that they use to absorb information and events of the day, catch up with replying to email and get ready for the next work day.

i.e. Companies should consider any time outside the 10am to 5pm window to be not available for meetings and definitely not any weekly recurring meetings.

Preferably, employees who are ‘makers’ should have one 4-hour continuous block of time each day when they are free from meetings. (‘Makers’ differentiated from ‘Managers’)

What Meetings to Attend and a Polite Way to Decline Meetings

As much as possible, we should only attend meetings where we are active participants, not mere attendees with nothing to contribute to the defined outcome of the meeting. There are some exceptions to this like training sessions, educational presentations or others where the purpose for attendees is to learn something.
Time Management Tip: When you receive an invite for a meeting at work where you believe you may not add much value, reply to the invite with a polite message like:

Thank you for inviting me to this meeting. It seems from the subject, agenda and attendees list that I’m not a required participant for this meeting. If I’m mistaken and my presence is required in this meeting, please accept my apologies and let me know that I should attend.

This is preferable to ignoring the meeting invite or declining without comment that may come across as rude. I have this text also saved as a TextExpander macro.

Discussion about declining meetings: https://plus.google.com/107443707510532643538/posts/inUkYy1Ufg7

Laptops, Smartphones and Other Communications Devices in Meetings

It has been common for over a decade to find people reading and responding to emails on their smartphones in all sorts of situations, including during business meetings. This question, however, is not about smartphones: It is about use of laptop computers during meetings.

In what types of meetings and situations do you consider laptop usage to be acceptable?

There are some situations, where it seems to make good sense:

  • + Note taking during meetings: Saves time wasted transcribing later and better than having notes on paper which can’t be searched easily and piles up as clutter.
  • + More secure than taking notes on paper that can be forgotten and read by others who should not have access to the information.
  • + Quickly looking something up that is relevant to the discussion
  • + Entering action items that come up during the meeting into your to-do-list (especially useful for GTD system users, e.g. OmniFocus.)
  • + Meeting notes and action items can be automatically backed up in real time.
  • + Quickly and discreetly asking a question, or sharing an opinion or information over instant message without disturbing others in the meeting.
  • + Environmentally friendly, saves paper
  • + As for distractions, the user can be disciplined and focus on the meeting. Perhaps even using the laptop to participate more actively in the meeting. (Even a person using pen and paper can be distracted doodling or daydreaming.)
  • + This is the digital age.

There are also some reasons not in favor of using laptops during meetings:

  • - It comes across as disrespectful to some other meeting attendees, especially those with traditional styles of working.
  • - The laptop screen creates a “wall” between you and the people sitting across you.
  • - The laptop does make it easy to get distracted into reading your email or other online activities. (A tablet like the iPad that lies flat on the table like a writing pad does not have this problem.)

Are there certain situations where it should be ok? For example: Large group meetings, small team meetings? Meetings with certain types of people? …?

Here is what I personally do: When I bring a laptop to a group meeting or one-on-one meeting, each time I respectfully explain to the others beforehand that I’ll use the laptop for taking notes and recording action items in my to do list only. I inform them that I will be focusing attention on the discussion and that the laptop is simply my digital notepad.

A discussion about using laptops, smartphones and other communications devices in meetings: https://plus.google.com/107443707510532643538/posts/NZ9NqEA7PVu