Software Jobs to Be Done

Depending on the role of the person outside of product and engineering you are talking to I find they often don’t understand the value proposition of the software development part of the organization. This breaks down in many ways of not understanding how the tools they use on a day to day basis work. Software as a service business is on one end of the spectrum, service assisted by software kinda in the middle and internal software on the other end of the spectrum. Often a company that is considered SAAS will also have service assisted software and internal software for the makeup of the business. What are the roles and general jobs that need to be done?

Managing a team isn’t just about the individuals. It is also about the other roles and external teams. In the successful engineering department understanding and supporting the collaboration is a critical manager responsibility. No organization or department is the same however I think it is important to discuss some of the key roles based on how the work is done.

Project/Program Manager Omission

The introduction of agile's (20+ years ago) focus on "customer collaboration" has seen a reduction in necessity for project managers. There is a Venn diagram of senior (lead/staff/architect) engineers, engineering managers and product managers that cover the main job of the project manager. There are a couple of reasons that I find a project manager is helpful:

  • lack of experience or capacity in the senior engineers and or managers

  • poor organizational communication and lack if visibility of work

  • trust issues

  • lack of commitment to "customer collaboration" or agile

Jobs needing to be done

I am trying to take the view of "jobs needing to be done". There are a lot of ways to break up the work. Usually we have a role and define the responsibilities as in a job description. Taking a different view I think might help to understand the different jobs. In software the costs are not physical plant or equipment but servers and services. In the same way that there are not plant managers and machine operators there are engineering managers and system administers (devops we call these days).

Job: Delivering Product to Customer

In almost every case the software engineering is going to be deploying software that the customer is going to use. In a sales driven process it could be sales that does the initial setup or signup for the customer if it is not self-serve. Product managers may control beta features via a feature flag or experimental feature however even this has to often be coordinated with software engineers. As the software is iterated on 99% will be delivered to the customer in the forms of updates, bug fixes ect directly from software engineers.

Job: Communicating with Customer

In a health agile organization customer support (customer success), product managers and software engineers will spent lots of time with customers. The ratios will depend on a couple variables. Depending on the maturity of the company and or software, the type of business or problems being solved by the software and finally the quality of the software.

SAAS business are replacing the factory with computer servers and factory workers with software engineers (and system administrators / devops). SAAS will most likely have a high ratio of customer success when the product and business are in the early growth stages. Customer success can be a great way to improve customer experience, prioritize customer feedback and take product risks.

Product managers should be in constant contact with customers. Product managers in a SAAS should be able to receive feedback from customers but also transfer enthusiasm to customers.

Software engineers need to make thousands of decisions. Being able to relate to customers is a hedge benefit for software engineers. Being able to directly listen to customers and ask questions is extremely helpful. Even if this is only a small portion of the time for software developers is should be a constant daily activity.

Job: Breaking outcomes up into deliverable

Assuming there are a clear set of measurable outcomes from upper management (one of the hardest tasks is to build software to effect the outcomes). The process of experimentation, analysis and iterating towards measurable outcomes is what justifies senior engineers. Critical part of developing the goals/outcomes/OKR for any software should involve senior engineering staff.

The process of taking those high level organizational metrics and turning them into software that is automated can be very tricky. Experienced engineers, product managers can maximize efficiency and minimize cost.

Job: Performance Management

Every business that scales requires some amount of human assets. Product and engineering management should be optimizing the humans to increase them as assets. It is unfortunate that I often observer managing for liability instead of managing to increase human potential. Problematic staff should be address quickly. IMO the goal of human management is to create a system that increases the contribution of individuals over time and has a reinforcing feedback loop by compensating those individuals for the increase contributions. Indifferent of a staff of 2 or 2,000 successful management increases the contribution of individuals continuously and over time.

There is a proportional amount of work that engineering managers, senior engineers and product managers will be required to enable optimizing the performance of humans. Engineering managers will need to capture get and provide feedback to individual contributors, do 1-1 to address "the feels", coaching and career. Senior engineering will need to provide day to day mentoring, training and technical opportunities working with the engineering manager and product manager for individual contributors. Product managers will need to support both engineering managers and senior engineers with a small amount of flexibility.

Job: Operations

In SAAS business the operations is 90% software engineering (as the software matures it transitions to devops or system administration). Even with internal tools and or software assisted services there is always some amount of effort to keep the software working. The trade off made in releasing software is often technical debt. The cost can be manifested in many ways:

  • Overhead in just keeping the system running

  • User experience is poor and or frustrating

  • Bugs and errors

  • Service disruptions

Software systems need to change based on the businesses change. In very static problems there are low or no operational overhead software solutions. Or in best case the operational overhead can be handed of the end user or customer.