Hackathon: Impact Journalism in New York

On April 8-9 2016, the Global Editors Network (GEN), The Huffington Post and Change.org will gather the best media innovators in New York for a two-day Editors Lab focused on developing innovative news prototypes.

Theme

Impact Journalism: How can news organizations develop innovative and interactive ways to create impact by connecting audiences with issues they care about?

Jury

Further information at the source: http://www.globaleditorsnetwork.org/programmes/editors-lab/the-huffington-post-and-changeorg-editors-lab/

Information for Technologists Interested in Learning about Artificial Intelligence

These days, artificial intelligence is gaining a lot of attention in mainstream media. This is a topic that I’ve been passionate about for many years, and a number of fellow technologists have asked me where they can learn about AI.

I have posted a shared Google Document for people with a background in technology and software engineering wanting to learn about AI. Topics include artificial intelligence, machine learning, deep learning, artificial neural networks, reinforcement learning and other concepts. I plan to keep this document updated as I come across interesting AI related articles, new developments, and sources of information.

The document is for technologists who are interested in learning about the basics of AI and related technologies. You need some background in technology and software engineering to delve into AI. However, some of the information I’ve linked to is of general interest.

3 Dimensions of a Technology Team

Organizing Software Engineering Teams to Balance Products, Partners & Professions

This organizational design for a technology department aims to optimally blend the need for the technology team to be an engine of innovation, a customer-service organization and technically excellent.

It views the staff, roles and responsibilities in three dimensions: products, partnerships, and professions.

img

  1. Products and projects the technology teams work on
  2. Partners, customers, and stakeholders of the technology department
  3. Professions of the various technology staff members

Organization by products focuses on providing great user experiences via small, agile and nimble teams that have ownership of their work.

Organization by partners focuses on being an effective client-service organization to other parts of the company.

Organization by professions provides for learning, best practices and career development of the tech employees.

This article first describes the three models and then suggests ways to bring them together into one integrated organization design.

Organizing by small product focused teams

Product

A product is defined as something that customers use and experience. A product consists of features and functionality.

It refers to a digital entity, a physical good or a combination of the physical and virtual. For example, it could be a communication app that people use via their smartphones and computers. It could be a health device that people wear and access via their smartphones and computers.

The goal of a product is to meet customer’s needs & desires, to solve problems for customers including ones they didn’t know of, and to delight them. Many products aim to help make the world a better place, be it in small or big ways.

Product Team

One way to think of a product team is as a mini-company within the larger organization. A product team has customers, which could be external, internal or both.

A product team develops the product, makes it available to customers (“ships” it), and maintains the product. Maintenance of the product includes new features, major upgrades and innovations.

Roles in a product team

A product team has several roles which are filled by professionals with certain skills, knowledge and interest.

The roles can be narrow in scope, like front-end JavaScript developer or broad, like software engineer. The roles include the professions of engineers, designers, subject matter experts, marketers, and managers. For a longer list of roles in a product team with examples, see the section titled “list of professions/roles” under organization by professions below.

People and Roles

These roles are not necessarily each held by different people. There is no prescribed restriction on who can hold which role or how many roles. Depending on the team’s needs, people’s skills & interests, and budget & resource situation, any permutation of the roles can be held by the people in the team.

A team should make the best decisions in allocation of the roles. The roles held by people are expected to change as the team scales up or down. The team should give importance to checks and balances via separation of duties where required for compliance of regulations.

Team Size

As a minimum requirement, at least three people are required for it to be a product team that encompasses a sufficient set of the roles required. In a few rare cases, the team might be able to start with just two people.

Proximity

For a product team to be successfully implemented, it needs to consider and address evidence-based management science related to human collaboration.

An important recommendation is that the team “resides” together, i.e. works together on a weekly if not daily basis. If the team works out of the same office, then they should work in close proximity. If the team is geographically separated, like the teams at Auttomatic/WordPress, then they should have “virtual proximity”, i.e. be in close contact using video conferencing and other online collaboration tools.

Organizing by Partners, Customers, and Stakeholders

Aligning the technology department with business departments

In this model, each line of business, department and product/service at the company is assigned a technology partner in the technology organization.

Examples of stakeholders in a media company include the heads of advertising, marketing, finance, customer service and editorial.

The technology partner is a senior, widely-respected and influential member of the technology management team who serves as the primary technology leader for that business, department or product/service. Excellent client-relationship skills are a requirement.

The technology partner may also serve as the solutions architect for the client, or may have solutions architects assigned to them.

Technology Partner Role Description

The technology partner is the go-to person for all technology matters for the client department, including for engineering, project, and technology, areas that the technology partner does not directly manage. For example, a large department like Advertising will have projects that could span multiple tech departments.

The responsibilities of the partner include:

  • Assess Current Capability: Evaluate the current technical capabilities of all the technology systems.
  • Define Future Capability: Understand strategic industry trends to plan future technology roadmaps.
  • Technical Lead for product development: Responsible for technology execution, bringing new products to market and optimization of existing offerings.
  • Plan Capacity: Translate roadmaps into future year capacity plans.
  • Collaborate with other tech teams: Work with other product teams to service the needs of the business needs / departments / products where other teams in the technology organization are the owners of systems.
  • Subject Matter Expert: As the primary contact for a business / department / product act as the SME for all technology.

Organizing by Professions

In this model, the technical people are organized by the professions they choose to belong to.

Professions and Roles

This is a sample list of professions and roles gleaned from companies that have products in the digital media space. This list can be easily adapted to other industries, for example, by including the relevant subject matter expert roles. This was compiled between the years of 2007 to 2014 and reflects some prominent roles from then.

Each profession/role is grouped under one of five major categories:

  • Technologist/Maker
  • Designer/Artist
  • Subject Matter Expert/Analyst
  • Marketer/Seller
  • Manager/Admin

List of professions/roles

Technologist/Maker
Software Development Engineer, Server-side “backend” Software Engineer, Client-side “frontend” Software Engineer, Mobile iPhone and Tablet Software Engineer, iOS Software Engineer, Android Software Engineer, Content Management (CMS) Engineer, Testing Engineer, App Release Engineer, App Operations Engineer, DevOps Engineer, Systems Administrator, Database Administrator, Security/Privacy & Compliance Analyst

Designer/Artist
User Experience Designer, Visual Designer

Subject Matter Expert/Analyst
Product Manager, Business Analyst, Journalist, Reporter/Content Author, Editor

Marketer/Seller
Salesperson, Marketer, Customer Service Representative, Internal Advocate, Documentation Writer

Manager/Admin
Project Manager, Finances & Budget Manager, Team & People Manager

Integrating the three dimensions

Now that we have described the three dimensions, let us discuss ways to make it all work together.

Reporting Relationships

Some people believe that “reporting relationships are irrelevant in today’s world”, but social science research has repeatedly proven this to be false.1  Reporting structures and hierarchies are an essential and integral part of any organization of humans.

So rather than pretend that reporting relationships in a team don’t matter, it is important to address them in setting up these teams.

Let us start by acknowledging that human relationships are complex, nuanced and changing, so there is no one formula to organize your teams. Every approach to organizing reporting relationships has its advantages and drawbacks. Here, we present a reasonable but imperfect model.

This model applies to medium to large size organizations, but not to small companies or very-large companies. In a small company of less than 10 people, there are unlikely to be departments by profession where people report into. In very large companies’ each business unit may operate as an independent company with its own departments by profession (e.g. their own finance, HR and engineering).

We also make some assumptions. For example, that it is preferable that each team member has exactly one primary boss who they formally report to.2

Departments by Profession

It is important to define what is expected of a primary boss in your organization so you can best determine how to structure reporting relationships. For example:

  • Does a boss’ role include the long-term development of the employee’s career, existing skills and new skills?
  • Does a boss need to be a subject matter expert in the chosen profession of the employee? Or, is the employee best served by being part of a team of others with the same or similar professions?
  • Does a boss need to objectively and independently look at the employee’s work as serve as a checks and balances relative to the product/project team the employee is presently doing day to day work in?

If your answer to the above questions is yes, then it is likely that setting up the primary reporting relationships by profession is a good solution for you.

What does reporting relationships by profession mean? It means that primary (and formal) reporting relationships are organized by departments of people in similar professions. For example, HR professionals report into the HR department, finance professionals report into the finance department and software engineering professionals report into the software engineering department.

In medium to large sized companies, having the primary reporting relationship by professional departments often has advantages over having direct reporting into the product/project team. In fact, most consulting firms use this model. Some of the benefits include:

  • As new products are created, old products decommissioned and projects start and end, employees don’t need to switch from boss to boss. By having a boss who has seen an employee’s work over multiple products, services and projects, the employee can receive better coaching and development support.
  • A boss who manages a team of employees of the same profession helps share best practices, standards and development opportunities across the organization.
  • Such a boss can also serve as a check and balance for a product/project team’s short-term needs vs. the best long-term interests of the company. The employee has a primary person higher up to consult with outside their current product/project team.

Most medium to large size companies have departments by profession. For example, they have departments for finance, HR, sales, marketing, software engineering, design, etc. This makes good sense for reasons like the above.

Such departments often assign (or even embed) their professionals within other departments and product/project teams. For example, finance (or HR) may assign a finance person or team (or HR person or team) to work with the technology department. This person would likely be assigned full time to the technology department and work in close proximity to a part of it.

The organizational model recommended here views technology as a collection of departments by technical professions. For example, software development, quality assurance and testing, infrastructure engineering, and project management. Each of these technology departments embeds their staff into product/project teams.

The overall technology department also assigns a technology partner to every other department by profession. That’s how these three dimensions come together.

Balancing Professional Departments with Product/Project Teams

In setting up direct reporting relationships by professional departments, it is critically important to not let the departments become siloed. Each employee should be focused on, deeply care about and feel accountable to the product/project they are working on.

When the person’s primary boss is a functional head outside the team they are currently doing day to day work in, both the employee and the boss must ensure the employee is highly committed to their product/project team whether it is in their department or outside it. One way to accomplish this: Each employee can also be accountable to a lead within the product/project team via a dotted line if needed. In some cases, the employee’s boss and their lead within the team can be the same person.

The goal of the functional department is to both support product/project teams and serve as checks and balances, but never to work against them.

Non-Technology Departments

While this article was written for organizing technology departments at companies where a substantial amount of work involves software engineering, the thinking here might be adaptable to other types of departments. If you have thoughts on how to do that or have other approaches to organizing teams in organizations, please do share them.


This article is mirrored at LinkedIn and Medium.

  1. Hierarchy is Good. Hierarchy is Essential. And Less Isn’t Always Better by Professor Bob Sutton at Stanford University https://www.linkedin.com/today/post/article/20140112221140-15893932-hierarchy-is-good-hierarchy-is-essential-and-less-isn-t-always-better  []
  2. If someone has scientific evidence supporting this, please let me know.  []

SHA-3 Hash Generator


SHA-3, originally known as Keccak is a cryptographic hash function. Learn more on WikiPedia…

Enter text below to generate the SHA-3 Hash Code for

Output length in bits:

The SHA-3 Hash Code is below

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

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

This article presents an organization system and policy for job titles of makermanager 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 Titles Examples 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 XY & Z
  • Distinguished Software Engineer8
  • Program Director
  • Director of Project Management
  • Director of Products XY & 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. []

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

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 doing Often 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 impact The 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

 

A Memo on Leadership by a Colleague

I regularly ask other people for their advice, insights and knowledge about leadership and management. The following is a memo a colleague recently wrote for me on the subject.

[memo begins]

Loose your ego

Leadership isn’t about you or what you can do and rarely are people motivated to make you look good. Itâ s all about what you can do for your team. The team needs direction and something to achieve for you. You could almost think of yourself as the helpless grandparent who has work to do and lavishes accolades whenever one of those items gets completed. It may strike some as odd, but most people are eager to please and get a great deal of satisfaction knowing they completed something of meaning. Often the work you have to offer can lack significant meaning in and off itself. So, as the leader, you can provide meaning or significance where none exists. It can also be your responsibility to paint a picture or create the mission.

In the past, when faced with an impossible task of creating meaning in completely insignificant work, I found I could inspire the team by getting them to focus on creating very elegant code. Since the result of the work was clearly not fulfilling, I reasoned with the team that producing the most elegant code would be fulfilling. The tactic got the team past the barrier and gave them the motivation to finish the required work. I really doubt I could have had the same success by appealing to get the work done just so I would look good.

Get to know your team, learn about them

Itâ s really important to take the time to know the people who work for you. Even if you have a hard time opening up to people, you need still to make the effort. Generally, people really appreciate that you actually take time to get to know them. For each person that reports to you, do you know if they are single/married? Do they have children, grandchildren? What do they like to do outside of work? What is the person passionate about? All of these are really good, safe questions to get answers to. The more you get to know the person, the more of a connection you will have. Essentially, you are building a bond of trust and mutual respect and maybe even friendship.

Listen and listen well

Listening is one of the most important skills you can learn. Yes you can learn to be a good listener with practice, patience and perseverance. Never, ever listen to formulate an answer for someone. I’m sure you can remember more than one time when you raised an issue or made a statement and there was that genius in the room who retorted a quick “You should just do ….”  Personally, people like that are never ever helpful and worse yet, they get me upset and I instantly loose a percentage of respect for the person.

When someone else is speaking to you, make every effort to understand what that person is saying to you. Try not to interrupt and let that person complete their thought. When the person has completed their thought, try and repeat back to that person what they said e.g. “So, what you’re trying to say is…” or “If I heard you correctly, youâ re saying…” The general idea is to repeat back to the person what they said thus making a reasonable effort to demonstrate that you have heard and understood. By asking, you give the person you’re speaking with the opportunity to clarify their point to their satisfaction.

The next step in listening is to make that split decision to offer a suggestion or sympathy. What is often missed, is that many times someone is raising an issue in an effort to find someone who can sympathize with him or her or offer a little empathy. They may feel they are the only person with the current concern. Most people aren’t usually looking for you to give an answer either, so it can help to ask additional questions for clarity after you have communicated that you understand how they feel. e.g. That’s got to be really frustrating.  Yeah, that would upset me too. Those types of statements can really help communicate a level of understanding or empathy, and that may be all the person is after.

Always take the blame; never take the credit. Take the heat for the team and give the team all the credit.

Nothing makes a group despise their leader/boss/manager more than watching them take all the credit and blame anyone else for the failures. Maybe that’s a little harsh, but itâ s really important to create a safety zone for your team where they know that you have their back. I like to think of this as the “obsessive parent” sometimes. My kids can do no wrong when their exposed to the world, but when we get back to the house we talk. In much the same way, taking the blame for your staff does not mean letting things slide. It means that you take the blame in the eyes of your boss but take the team or the team member aside to coach and mentor. When addressing issues, it is often better to address the issue instead of assigning blame e.g. “Our last release had too many bugs that could have been caught that is causing too many distractions. What can we do to improve?”

If you have a team that is struggling to succeed, is it really the teamâ s fault or is it your fault as the team leader? If you’re honest with yourself, the problem always lies in the leader. Itâ s your responsibility to identify the problems, come up with remedies and implement. Until identified problems are resolved, you are better served by taking the blame. It will give you credibility with your team and those you report to because it shows a level of maturity, competence and sacrifice.

Treat everyone with respect

This isn’t limited to your team in any way. Its important to treat your team with respect and dignity all of the time. Do not belittle them. Do not disregard them. Do not take them for granted. When you treat others with respect and dignity you are then seen in a positive light as someone who is respectful.

When looked from another angle or from the negative, you want to avoid being known as someone who has no respect for others, you will be avoided like the plague. Disrespecting or disregarding people is a recipe for failure.

Find someone and something to praise every day

People have a natural desire for recognition. They want to know that the work they perform has meaning and is valued. Most will not come out and ask for praise, but everyone, no matter how much they profess to the contrary, actually appreciate recognition and genuine praise.

Sure, there may be people who are so upset or jaded that you begin to doubt if it matters much if you give thanks or congratulate them. However, I would argue there is simply more work to accomplish before praising offers any significant value to them. That jaded person is simply the result of previous leadership failures and requires a lot of effort on your part before this tactic works.

Use constructive criticism. Never shoot down ideas

Really, don’t ever just tell someone they’re wrong or what they’re thinking won’t work out of hand. That kind of behavior will just kill a person’s desire to think outside of the box or to even come up with anything creative. They will quickly start to think, “Why bother?”

I once worked with a boss who was masterful at getting me to see the flaws in my plans without ever telling me something wouldn’t work. Whenever I came up with an answer that had a flaw, he would ask me questions about my direction that illuminated a problem I was unaware of e.g. “How will your solution stay within constraint…?” It was a really powerful technique that provided many additional benefits. I usually learned something I wasn’t aware of, maybe in the business or the platform, I was able to “save face” and wasn’t put off or discouraged from trying to solve a problem or be creative.

Offer up challenges and don’t do the work

Software developers like to solve problems and I will bet that most of them actually love solving problems. Itâ s your job to give them something to solve and follow the advice on constructive criticism. Whenever you have something that needs to be done, try really, really hard NOT to come up with a solution. No one likes to be given something to implement – there’s no fun at all and it does very little to stimulate the team. It may take a little more effort on your part, but instead of giving them something to build, give them a challenge with measures of success. They may or may not come up with the solution you thought or be done in the way you would do it, but if it solves the problem with all of the constraints you listed, then let it go (see first point on ego)

Help everyone

I have found nothing better to gain influence like helping others. A good leader is always looking to help, to be a person of service. Nothing is more indispensable like a helpful person. Help usually does not mean doing someone’s work for him or her, but it can be, especially if the team is on a tight deadline. When leading a team of software developers that has too much work to do, I recommend taking on all of the worst tasks. Aspiring developers want the cherry work, the stuff that will get them noticed. If you take that work away and leave them the drudgery, it won’t make you any friends. Remember that it’s not about you, it’s about creating a team that loves to work for you. So, if you take away the garbage and leave them the fun stuff, you’re definitely helping.

[memo ends]

(Posted with permission.)

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

 

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

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 & Responsibilities Guardian Tasks & Responsibilities Recycler Tasks & Responsibilities
Develop new products, functionality, services, systems & processes Operations, execution, delivering predictable results, maintenance & support Examine existing systems, products, processes and resource assignments seeking areas for recycling
Add a major new feature to an existing Web application Track expenses to budget, monthly Decommissioning a system no longer in use
Develop a new mobile application Compile status reports, weekly Elimination of unnecessary steps and waste in a process or workflow
Mentor and coach employees on a regular basis Identification of areas for cost reductions
Review and approve requests like vacations, expenses and When 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.