The Capability Development vs. Execution Paradox
Developing a skill takes time and practice. Complimentary or associated skills form a capability when combined: an effective way to execute on a non-trivial task. Skills and capabilities seldom develop in parallel fully. Innate talents might allow for the faster development of certain skills. Some environments might expose you to more learning opportunities, allowing you to improve faster.
Thinking in "capabilities" is a good way for managers to take inventory of a team and the requirements from the business imparted on it. When the capabilities of the team are not sufficient to realize its goals, new capabilities (and underlying skills) have to be acquired by hiring new or developing existing team members.
It is easy to platonify capabilities. A team member has either mastered a capability or not. Reality is not that clear cut, obviously. Organizations rarely define capabilities to a level of details to objectively determine mastery. This would certainly be beneficial, but it would also be incredibly burdensome to maintain. Having a clear understanding of what a team is capable of is instrumental to its current and future efficacy.
The Capability Development vs. Execution paradox is defined by the tensions that exist between the development of new capability vs. executing on existing capabilities, including:
Executing speed. Hiring a new team member with a known capability might be less risky than developing a new capability for an existing team member.
Investing time and money (developing/hiring a new capability), instead of generating revenue right now, as the team member are pulled away from their day-to-day tasks to spend time on development.
Safe-guarding institutional knowledge and fosterling long-term loyalty/employability towards the team by developing (and thus) investing in existing team members.
Quality control and its inherent (reputation) risk. Exposing existing team members to real-world learning opportunity requires keeping a close eye on the quality of the deliverables.
My personal experience is that "one the job" training is inherently messy, as you don’t have full control of the work that comes in. You’re out of luck if a team member wants to improve skills x, but new projects that require skill x do not materialize. Ideally these learning opportunities are sufficiently challenging to provide the right level of learning, but not overly challenging the team member is unable to deliver. Enrolling a team member in formal (external) training does not have these issues, but puts another type of strain on the business and team.
Continued development on human capital is hard to get right. It is one of those "important" aspects of running a business to ensure its long-term survival, but especially hard at a smaller scale in which volume and available infrastructure is limited.