Executives have assistants, why don’t software development teams?

It’s well known that a good Executive Assistant is indispensable, making an executive far more productive and organized. Executives typically have more on their plates than they can handle, and it’s the same with product development teams. Want to make your agile development team far more effective — get an assistant.

An executive needs to be engaged in the work at hand. He needs to be connected to his peers, stakeholders, and customers. A good executive assistant does not abstract away these connections. No executive sends her assistant in her place to important meetings and then asks for a summery so she can make decisions. The role of a great EA is enhance the connection the executive has to her work. The following three things are key roles of an EA:

  1. Removing distractions
  2. Helping to optimize time and schedule
  3. Routing incoming requests

Development teams work best when they do two things well, keep constant and close direct contact with customers and stakeholders and get a lot of time to code and design. Outside of heads down building and customer connection development teams have so many other things to attend to. Research, distractions in the office, incoming support requests, meetings scattered throughout the week, scrum or agile rituals, and having to chase down resources and information needed to do the job. Because of the tremendous demands on teams many optimize for spending a lot of time coding and designing not by reducing the aforementioned demands but instead by taking less time with customers and stakeholders. Teams frequently hire a full time “product owner” who takes on the work of connecting with customers and stakeholders giving the team more time to build but less understanding of what they are building (See my previous article on how product owners can hurt agile development teams). A good assistant can give development teams time back from all the other demands so they can focus on their core mission.

I want to introduce here then the role of Product Catalyst. The role of this Catalyst is to give the team 30% of their time back so they can focus on improving customer understanding and building products. A good Catalyst will have an outsized impact on the productivity of a development team. A catalyst should focus on exactly the same things that a good EA should focus on. The exact nature of the work however takes on a different form. Let’s talk a little bit about it.

A Product Catalyst should remove distractions. Development teams are constantly plagued by distractions, needing to figure out how to get an expense report submitted, trying to figure out a time for the team outing, figuring out how to pay for that photoshop extension, and on and on. A catalyst can avail himself of the team and help reduce these distractions thereby giving back a lot of time to the team.

A Product Catalyst should optimize time and schedule. In order to form close customer and stakeholder relationships meetings, phone conversations and other face to face and virtual communication must be arranged. A catalyst can foster these relationships by handling much of the scheduling and timing of these communications.

A Product Catalyst should route incoming requests. Requests for time, requests for features, requests for fixes, requests for information, requests for estimation. All of these requests take time. A Catalyst can help route these requests effectively thus saving the rest of the team a lot of time.

A Product Catalyst is an expert in his own right. Here is where the role can diverges from that of an EA.

A Product Catalyst should aid in decision making by becoming an SME. Often times work goes undone because of research that needs to be done, questions that need to be answered. A Product Catalyst can answer these questions and bring information generally useful in helping the team understand and design their product more effectively.

When moving beyond the role of assisting and into the role of being an subject matter expert its important to remember the role of the catalyst is not to take over team product functions but instead to give the team 30% of their time back so they can focus on improving customer understanding and building products.

In a coming post I will share the training we do at Guaranteed Rate to make the Product Catalyst role a successful one.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.