Are you going to the APIStrat Conference in Nashville, or the API City Conference in Seattle?

API Transit Basics: Training

This is a series of stories I’m doing as part of my API Transit work, trying to map out a simple journey that some of my clients can take to rethink some of the basics of their API strategy. I’m using a subway map visual, and experience to help map out the journey, which I’m calling API transit–leveraging the verb form of transit, to describe what every API should go through.

Think of support as a reactive area, while training will be the proactive area of the API life cycle. Ensuring there is a wealth of up to date material for API developers and consumers across all stops along the API life cycle. Investing in internal, and partner capacity when it comes to the fundamentals of APIs, as well as the finer details of each stop along the API life cycle, and CI/CD pipelines will pay off big time down the road.

Every API should be included in training materials, workshops, and potentially part of conference talks given my product owners. If your API delivers value within your organization, to partners, and 3r party developers you should be training folks on putting this value to use. Here are some of the training areas I’m seeing emerge within successful API operations:

  • Workshops - Conduct more of the workshops that I conducted with external consultants like me, as well as make sure they are conducted internally by each group. The first day of the our workshop was a great example of this in action.
  • Curriculum - Establish common approaches to designing, developing, and evolving curriculum for teaching about the API lifecycle, as well as using each individual API. Provide forkable templates that developers can easily put to work as part of their work, and make support materials a pipeline asset that gets deployed along with documentation, and other assets.
  • Conferences - Make sure you are sending team members to the latest conferences. In my conversations during the workshop, this didn’t seem like a problem, but something I think should be included anyways.

Like every other stop along this journey, API training can be a pipeline artifact and be developed, deployed, and evolved alongside all other code, documentation, and available solutions. Pushing everyone to not just attend trainings, but also work to develop and deliver curriculum as part of trainings helps make sure everyone is able to communicate what they do across the company. Everyone should be contributing to, executing, and participating in API training, no matter what their skill level, or ability to get up in front of people and speak.

API training will increase adoption, and save resources down the road. It will compliment platform communications, and strengthen support, while providing valuable feedback that can be included as part of the road map. My favorite part about doing API training is that it forces me as a developer to think through my ideas, consider how I can articulate and share them with others, which if you think about it, is an essential part of the API journey, and something we should bake into operations by default.