Is your team qualified, or merely capable? There is a big difference between the two. Simply possessing the ability to complete a task doesn't necessarily mean you have the knowledge to do it well. And though your team may be familiar with the technology you seek to employ, it doesn't necessarily mean they are qualified to design, deploy, or support that technology. It's important to distinguish between capability and qualification before embarking on any major tech project.
Becoming Proactive, rather than Reactive
Your team isn’t going to be effective if they’re engaging in activities with only basic competence rather than skill. In fact, they may actually cause problems as opposed to reducing the number of them. This will impact the way your organization is seen and diminish its perceived value. Your organization will become a source of quick (but not necessarily lasting) solutions; solutions that will be ticking time bombs waiting to detonate. A qualified team will be able to proactively resolve issues before they become disruptive; a merely capable team will be purely reactive to events as they occur. Waiting for an event to happen first to then resolve it means you are already too late. You need to be proactive and resolve issues before they happen to keep you from going on a downwards spiral.
Capable (But Not Qualified) Support Services
A capable support team can offer support– and this can lead to a false sense of security. Though they may be able to arrive at solutions, their solutions will take longer than a more qualified team. The reliability of their solutions may be an issue, and some problems may be too big or too complex to truly fix. Ultimately, a capable (but not qualified) team will find itself having to call for backup, tying up the support process, and slowing productivity down. Capable team members may understand the technology, but they simply aren't well-versed enough in it to be able to intuitively fix problems as they arise or anticipate problems before they surface.
The Difference in Support and Design
Not only is it difficult to support a product without being qualified in it, but it's difficult (if not impossible) to actually design services. To be an architect, an operator will need to have enough knowledge in the service to be able to set it up in the most effective, stable fashion. This requires advanced knowledge of how systems work and how they relate to others– otherwise achieving integration will be difficult. The capability is there to potentially support the service, but the qualifications are not there to design and develop the service.
Why would anyone ever use a team that is capable but not qualified? Well, it can happen for a variety of reasons. One can overestimate the skill levels of their team members, or simply believe a solution is "good enough" for the situation. But employing a team that is just capable rather than fully qualified will ultimately cause more issues for an organization than it will resolve. On every level, support and architecture will be completed "just good enough," and this will lead to a decrease in productivity–an increase in disruption.
Qualified teams have the experience to ensure smooth operations and tailor solutions to the business (rather than the other way around). Capable teams, on the other hand, are simply a cheap, quick-hit strategy that will lead to a loss in both reliability and credibility. So, the moral of the story... qualified over capable. A qualified team over a capable one will take your business a long way and send you in the right direction for success.
