Maker’s Schedule (For Managers Too)

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

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?

 

Some Pathways for Career Development in a Product Engineering Organization

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

 

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

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

Project Management: Time to Market, People & Teamwork

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:

  1. People & teamwork
  2. Priorities
  3. Planning
  4. Process & operations
  5. Products & technologies
  6. Pace & acceleration