info@wholestacksolutions.com   |   1601 Iron Street, Suite 101. North Kansas City, MO 64116    |    877-512-9269

  • Twitter Social Icon
  • LinkedIn Social Icon
  • Facebook Social Icon

December 4, 2017

November 20, 2017

November 6, 2017

October 2, 2017

Please reload

Recent Posts

Capable Doesn't Mean Qualified

November 9, 2015

Is your team qualified, or merely capable? 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.
 

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? 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.

 

 

 


 

Share on Facebook
Share on Twitter
Please reload

Follow Us
Please reload

Search By Tags
Please reload

Archive
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square