“I love deadlines. I love the whooshing noise they make as they go by.” So said Douglas Adams, the famed author of such hits as Hitchhiker’s Guide to the Galaxy.
Unfortunately for the rest of us, we are not famous authors and most of us don’t have the luxury of letting our deadlines lapse. Our deadlines are implementation deadlines, by which our whole company could become stagnate until implementation succeeds. Our deadlines are product release dates that are essential to our business’ bottom line. We have to complete projects for our bosses to keep them from firing us, and to keep their bosses from firing them, and so on. In general, we’re a deadline driven world.
Having deadlines is both a good thing and a bad thing. On the positive side, they drive productivity. They give projects a certain start and end date so they do not simply stagnate and drone to a halt. Deadlines have a psychological effect on people that often causes them to produce some of their best work while under pressure.
On the other hand, they can also cause stress and worry, particularly when you’re working under a deadline and some members of your team are not particularly reliable.
In the IT world, one or two unreliable team members can often make a huge difference in how quickly a project gets done and how well it’s completed. Given the field’s propensity for specializing, there are often few, if any, individuals who can step in and take over if one person isn’t performing.
This propensity can result in some rather unfair outcomes, though. What if you’re suddenly held accountable for the work your teammate failed to perform? It doesn’t matter if you aren’t the accounting specialist in charge of implementing the accounting processes on your new SAP system – your boss wants to know why it isn’t done on-time, and you’re the one in his line of sight. You asked your team member to do it, but he appears to be AWOL for the day. What do you do?
My Recommendation: Learn Accounting
This response may come as a surprise. After all, shouldn’t you be able to delegate to certain people so you don’t have to worry about everything yourself? And the answer to that is yes – you should. But, if you’re an SAP system consultant, you should also be able to step in when needed to areas that are not your specialty in order to ensure it all gets done. If you’re just the “ABAP guy,” and someone is having a problem tied to the FI module that is supposed to be running without any issues, the excuse rings pretty hollow that you’re unable to help out if no one else is available. You’re a consultant in IT, and you work for a medium- or large-sized company. You’re now a “SAP guy.”
It may sound like I’m advocating you taking the weight of the SAP world on your shoulders. In some ways, I am. The fact is, in order to survive and thrive, you must be self-sufficient in many ways in order to avoid layoffs and out-sourcing. That means knowing not only your area, but also the systems that impact your area, so that you can troubleshoot in more ways than just one. Your vision, then, is not through the lens of a microscope. Rather, you must be the one at the top of the ladder looking down at all of the components laid out before you and how they must fit together to function smoothly.
“But I’m just the one responsible for developing ABAP programs,” you might protest. “That’s all I want to do.” Chances are, most of the time, that is what you will do. But if you have a deadline looming and the functional area your ABAP programs are working on is malfunctioning, do you really want to have to wait for outside help to get up and going?
New Opportunities
Many employees aren’t working with the thought that they’ll be at the same job for the rest of their lives anymore. It’s understood that you’ll seek other opportunities with other companies, or seek to advance within your existing company. If you’re in IT, chances are, you want the opportunity to grow your career rather than be at a stalemate once you hit some plateau at the peak of your current skill set. Who is in a better position to achieve growth, transitions, and advancement: the one who took the extra time to learn other functions that directly impact his or her particular “specialty,” or the one who operates in a vacuum and relies on others to rescue them when things to go wrong?
This need to develop a broad skill set extends to more than just technology; it also extends to the underlying business for which you work. Just to use an example: there is an accountant who is responsible for preparing tax returns each year for his clients. Rather than being an all-purpose accountant who files taxes for a broad range of people each year, he focuses his practice on preparing returns for law firms. This may seem like a very narrow niche; however, specializing like this has proven exceptionally lucrative for his accounting practice.
In order to grow his practice, what steps do you think he took? He knows more about how to run a law practice than most lawyers. Rather than simply concerning himself with learning general business deductions applicable in virtually any industry, he knows those that are specific to lawyers. He understands how lawyers bill for their time, what kinds of expenses are attributable to clients, and how to handle anticipated income from contingency agreements. Is he planning to open a law firm? No. But he has taken the time to learn the ins and outs of the legal industry so he can better serve his clients.
If you were serving this particular accountant with IT solutions, what would you do in order to serve his practice better? Would you content yourself with a crash course in FI-CO? Or would you take the time to develop some knowledge in the area of taxes and law practices to come up with a deeper understanding of his business and how to serve it best?