Executives have assistants, why don't development teams?

It's well known that a good Executive Assistant is indispensable for making an executive more productive and organized. Executives typically have far more on their plates than they can handle - well 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 his assistant in his place to important meetings and then asks for a summary so he can make decisions. The role of a great EA is to enhance the connection the executive has to his 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 coding/design 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 or elect a "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 hurt agile development teams). Instead of hiring a product owner to handle product and customer understanding for them what they really need is an assistant to give them time back from all the other demands so they can focus on their core mission.

What development teams really need is a Product Catalyst not a Product Owner. 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 can 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 her own right. Here is where the role can diverge 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 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.