The Art of Wearing Multiple Hats

Stack of hats

Stack of hats

A small business frequently requires its employees to become adept at tasks and skills outside of their initial comfort zone. Perhaps a sports analogy is warranted: Big college football programs can afford to recruit specialized players. The Ohio States, University of Texas, and Alabamas of the world have the luxury of recruiting players whose job is to come on to the field of play at very specific times, perform their task well, and then return to the sideline to await their next opportunity.

And then there are the other schools; the smaller ones. I will use TCU as an example since they are in my “backyard”. If they were to approach the game with the same strategy as University of Texas, they, most likely, would not be successful. How do they differ then, in order to compete with such giants?

 

The answer is this: They don’t recruit specialized players. They recruit athletes.

 

As a result of recruiting players who may have grown up playing one position, but who have shown a willingness to learn something altogether new, and to put aside what is best for themselves in favor of what is best for the team, TCU’s program has experienced sustained success over the past couple of decades.

 

To drive the analogy home: On a daily basis, the employees of Pentecom assume different roles depending on the project, and, in fact, interact with each other differently based upon those roles. As an example, the President and Vice President of our company, Kathy Rainbolt and Kim Willmott, frequently are tasked with software programming and development duties. In such instances, they are getting their proverbial marching orders from our Director of Programming, Ryan Augsburger. Ryan, in turn, as a person with years of experience with the aviation world, might be pulled off of a development task in order to help with a business development opportunity (fancy term for getting new business). Yet, when we convene for weekly status meetings, Kathy is the President, Kim is the VP, and Ryan is the Director of Programming.

 

So, how does this work, not in theory, but in practice? And why should you, dear reader, see this as a plus and a benefit when choosing to work with Pentecom? Allow me to address the last issue first; that is, why Pentecom?

 

From top to bottom you get employees who are adept at solving problems. The person who is talking to you about your large scale conversion project is, most likely, going to play a key role in building the routines that make that conversion process work. In short: They know what they are doing and they have significant experience in multiple layers of a given project. Most of us have taken turns as analysts, developers, project managers, and QA testers.

 

As to answering the question regarding “how does this work”, the more esoteric answer is “hire people who like this type of environment.” Let me be clear at this point: I am not favoring one type of employee over another. Many talented, driven people like to have, essentially, one task, and do that to perfection. In fact, that type of employee exists within our own company. We don’t hire people who like multi-tasking to run and complete the day-to-day tasks that are required on our conversion projects. Those projects require someone who is focused on completing the job at hand.

 

Our consulting side of the house, conversely, needs and thrives on the “multi-taskers”. And, so far, that is what we have assembled: A team of folks who plug into a project where they are needed and work to get it done.

 

So, if you’re a small shop, like ours, our initial advice has been to hire people who are adept, and who like being nimble. There is one other component: Ego. Or, in this case, lack thereof. Our company would not work as efficiently as it does if our two founders refused to complete any software development tasks. Similarly, if I were to only write blog posts and not manage projects or develop XSLTs, I would not be contributing where I was needed. Within a small company, hierarchy needs to be fairly flat, and there needs to be an implicit, well stated understanding that, during a project, the roles of a project trump our official corporate roles.

No Comment

Post A Comment