Tag Archives: organization

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

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

Some Pathways for Career Development in a Product Engineering Organization

Leave a reply

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

 

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.

Trinity Method of Technology Management

5 Replies

In the Trinity Method of Technology Management, tasks and responsibilities are categorized under three types of roles: Creator, Guardian and Recycler.

If you are the CTO or VP of Technology at an organization, your team needs to do three things effectively and regularly:

  1. Innovate; improve; create new products, features, services & processes
  2. Operate; maintain; execute existing processes & systems with predictable results
  3. Seek & identify products, features, services and processes that are no longer necessary; Decommission systems; Free up resources for reassignment

The above are the roles of creator, guardian and recycler, respectively.

An example of a creator-type manager is someone whose primary background is software engineering and that their strength is in delivering client satisfaction & happiness via innovative products & services.

A example of a guardian-type manager is someone who does a good job heading up technology operations.

The dedicated recycler-type role rarely exists in many organizations, resulting in unnecessary systems (whole or in part), features and processes consuming money, causing unnecessary complexity and slowing down productivity and innovation. Recycling should be a part of everyday work in a technology organization. Reduce waste by recycling.

There are many benefits of having a dedicated recycler role in your management team:

  • Higher productivity due to reduction of complexity, removal of obstacles and availability of freed-up resources
  • Helps eliminate or minimize ‘process creep’
  • A happier workplace resulting from the above
  • Cost savings

I recommend that you have these three distinct roles, with a manager focussed on only one of creator, guardian, or recycler type tasks & responsibilities at a given time.

The table below gives some examples of tasks and responsibilities under the three areas.

Creator Tasks & ResponsibilitiesGuardian Tasks & ResponsibilitiesRecycler Tasks & Responsibilities
Develop new products, functionality, services, systems & processesOperations, execution, delivering predictable results, maintenance & supportExamine existing systems, products, processes and resource assignments seeking areas for recycling
Add a major new feature to an existing Web applicationTrack expenses to budget, monthlyDecommissioning a system no longer in use
Develop a new mobile applicationCompile status reports, weeklyElimination of unnecessary steps and waste in a process or workflow
Mentor and coach employees on a regular basisIdentification of areas for cost reductions
Review and approve requests like vacations, expenses andWhen an employee leaves, don’t immediately assume that you need to fill the position. The recycler manager should urge the team to determine if this work can be absorbed elsewhere. This will help eliminate waste and avoid or minimize layoffs in the future when business requires reducing staff.

This article was inspired by the Indian concept of Trimurti in which in which the cosmic functions of creation, maintenance, and destruction are personified. It was also inspired by the Harvard Business Review article titled “What 17th-Century Pirates Can Teach Us About Job Design“ by Hayagreeva Rao, Professor of at Stanford University’s Graduate School of Business.

This post about the Trinity Method of Technology Management is part of a series on technology leadership & management.

Mail.app Logo

How to Avoid Duplicate Search Results when using Apple Mail.app with Gmail

8 Replies

I use Gmail’s IMAP feature with my Apple Mac OS’s built in Mail.app program. Mail.app keeps local copies (on all my personal Macs) of all my email messages that I’ve kept (since 1994). It enables me to:

  • Effectively work offline with all my emails (searching, reading and composing), when my computer is not online. That’s sometimes the case when I’m traveling, especially in places where Internet access is unavailable, unreliable, slow, insecure or too expensive.
  • Regularly back up all my saved emails using Apple’s Time Machine. It is also a precaution in case I someday no longer have my Gmail account and/or move to another email service. With email account theft rampant these days, it is important to have up to date backups of all your emails.
  • Send digitally signed and encrypted emails when needed.
  • Compose greeting cards and other visually rich emails with pictures on Mail.app’s stationary.

The Problem:

When you initially set up Mail.app to use Gmail via IMAP, you will observe that when you search your mail using Apple’s built in Spotlight feature, the search results will show duplicate (or more) copies of your email. This is because Gmail’s labels and special views (like “All Mail” or “Starred”) appear as separate IMAP folders in Mail.app. Messages in these seemingly “separate IMAP folders” appear to be duplicates to Mail.app and Spotlight search.

The Solution:

To solve this problem, I suggest showing only essential Gmail special views and labels as IMAP folders to Gmail and then telling Spotlight search to only index the master copies of the messages in Gmail’s “All Mail” folder. To accomplish this, I did the following.

Note: I do the labeling of my messages via the Gmail Web interface and do not need to see the labels applied to messages when I’m using Mail.app. My solution below hides all my custom Gmail labels from Mail.app and that’s fine with me.

In Gmail (via the Web interface)

Go to “Settings > Labs” and activate “Advanced IMAP Controls“. After enabling it, go to “Settings > Labels” and uncheck “Show in IMAP” for each custom Gmail label you have created. Also uncheck it for “Starred” since Mail.app shows to do flags in messages in other folders.

Leave “Show in IMAP” checked yes for “Inbox“, “Sent Mail“, “Drafts“, “All Mail” and “Trash” since these are system folders and Apple Mail.app should be configured to use them. Also leave it checked yes for a label folder called “Apple Mail To Do” which is an Apple Mail system folder.

On your Macs

Go to “System Preferences > Spotlight > Privacy“, exclude the following folders from appearing in search results. Where it says [email protected] below, use your Gmail account name.

~/Library/Mail/IMAP-[email protected]/INBOX.imapmbox

~/Library/Mail/IMAP-[email protected]/[Gmail]/Sent Mail.imapmbox

Also, if you are displaying your starred folder via IMAP, exclude:

~/Library/Mail/IMAP-[email protected]/[Gmail]/Starred.imapmbox

Now when you search messages in your Mac’s Mail.app, only results from your Gmail All Mail folder will appear.