Reacquainting Yourself with the Techie You Once Were

min read

Note: This blog post is directed toward those IT managers and leaders who have a technical background. However, the concepts below can be equally applicable to those who may not have extensive technical experience but are interested in picking up a new technical skill or two.

At my last job, IT staff would distinguish between the "administrative manager" and the "working manager." While the former would spend the day in meetings, on the phone, online, pushing paper, etc., the latter would do all that and provide technical leadership to the team. In addition to managing their units, the working managers would be in the trenches alongside their teams, slinging code, building servers, or troubleshooting user problems. These individuals would have often moved up through the ranks, spending years in technical roles before transitioning into management. Their technical skills would often rival those of their leads. Whether by choice or by necessity, being labeled a working manager was considered a badge of honor. I was a working manager and proud of it.

When I changed jobs and became a director, those glory days came to a screeching halt. Although my new team performed a role almost identical to my old team, my own role had changed. I moved into a position where I was supposed to function at a 30,000-foot operational level, regularly crossing over into strategyville. In keeping with this "higher level" functioning, I found myself almost exclusively—you guessed it—in meetings, on the phone, online, pushing paper, etc. Whereas success in my old job was measured in the personal currency of clever solutions and successful products, I suddenly had no clue as to what even constituted success. Often I would arrive at the end of the day, questioning what, if anything, I had accomplished. I began to feel more like a liability than an asset.

I remember having more than a few discussions with my supervisor about this sense of inadequacy. To his credit, he kept encouraging me, insisting that I was doing everything right. Even then, I tried pleading with my team lead to assign me something, anything, to no avail. His reply was, "If you have time for development, then you aren't doing your job." Eventually, the realization sank in that my paradigm had shifted increasingly from managing to leading.

A recent Professional Development Commons blog post described leadership roles as being "essentially a juggling act between three fundamental activities." The author discusses the need to achieve a balance between leading, managing, and doing. In hindsight, I understand that during my transition into a leadership role, that balance had been upset. I still had management responsibilities, but I was spending more time leading—substantially more because I was learning how to do it and not that comfortable with it. Something had to give, and that was the "doing" part.

I have been a director now for three years and have a much greater understanding and appreciation of what it means to lead. I have taken numerous trainings in leadership development, most notably the EDUCAUSE Leadership Institute Program. I emphasize the Institute because that training singularly boosted my confidence and convinced me that I actually knew what I was doing as a leader; I just cannot speak highly enough about it. I can now articulate what my daily accomplishments are. Until recently, I also had not written a line of code in over two years. However, because I am now more comfortable in my role, I find that I can partially reset the balance. About eight months ago, I assigned myself a small technical task. I felt justified because we have been down one staff member for some time. But then I gave myself another, and then another. So in this blog post I will make the case that, based on my experience, getting reacquainted with technical activities can have benefits.

Six Reasons to Revisit Your Technical Skills

  1. Create opportunities to exercise your hard skills. If your day is anything like mine, it is abundant with activities requiring you to communicate, facilitate, present, negotiate, sell, etc. As you move up the career ladder, you are increasingly expected to use these soft skills. The higher you get, the less you seem to need hard skills. At some point you may find yourself exercising only your soft skills. There's nothing wrong with a job that emphasizes one skill set over the other (e.g., engineer versus counselor). I believe that leaders are more effective when they can practice both hard and soft skills, especially in our discipline. Whatever the data on the topic may say, my own sense is that it's akin to weight training and cardio—each positively impacts the other. In my own (unscientific) experience, I find that my soft skills actually improve when I set them aside for a while and focus on hard skills.
  2. Understand your team's work, challenges, and obstacles; make your daily work more relevant to what they do. We often use the analogy of "not seeing the forest for the trees." As a leader, you are required to understand the forest (the big picture). Over time, it becomes all too easy to forget the nature of the forest: the collective presence of individual trees and their synergy. By periodically sampling a few trees (people), you better understand the total health of the forest (your organization). Similarly, by occasionally experiencing what your staff actually does on a daily basis, you become more in tune with the rhythm of your operations. You can claim to know what your staff does, but nothing beats firsthand experience, especially if you share in both their frustrations and their triumphs. Putting yourself in their position cultivates empathy, helps you ask the right questions, leads to more effective program management, and ultimately better informs your higher-level decisions.
  3. Remind your team that you really are one of them. This is the flip side of #2. It is quite common in IT to make the distinction between us (the technical) and them (the nontechnical). Supervisors come in both flavors: those who put in their time among the techies, and those who found their way in through "less technical" qualifications (e.g., project management, business analysis, other administrative experience). One is not necessarily superior to the other; great supervisors also come in both flavors. However, I have noticed a different level of bonding when techies realize that their supervisors can walk the walk. Interpersonal communication seems to become richer and more forthcoming, because presumably, they perceive that you get it. Picking up a task here and there quickly gets you to us. The converse can also be true; if you've done nothing but administer for several years, you might find yourself drifting toward them.
  4. Communicate projects more effectively. As an IT leader, the ability to effectively build bridges between the technical and nontechnical worlds is a key measure of your success. At various times you find yourself being the great communicator, the chief evangelist, and the captain of the cheerleading squad. Often this involves presenting technical information to a nontechnical audience in a way that makes a cogent argument. I find that the more granular my understanding is about the technical details, the more compelling my presentation becomes. I know that I will not get into the gory details with most stakeholders, but having them in reserve lends a sense of confidence. Should the discussion digress, I know that I will have at least a chance at responding intelligently without resorting to the default, "I'll have to check with my staff." Technical work helps get you to that granular level.
  5. Evaluate new technology more effectively. Establishing vision is high up on the list of leadership functions; shaping the future organization is your responsibility. To be effective you must recognize and understand evolving technical requirements and new technologies. This knowledge guides your planning, determines your purchasing, and informs your hiring and training strategies. But determining the value of tomorrow's technology only makes sense relative to what you have today. Gaining familiarity with your current technology provides a basis for that comparison. The more you know about the tools you use today, the better you will be able to judge the value of the tools you adopt tomorrow.
  6. Remind yourself as to why you entered this field. Last but certainly not least, returning to your technical roots renews the passion that got you into technology in the first place. After a hiatus of two years, it was amazing how even a few hours of coding brought me so much pleasure. I had forgotten the deep satisfaction that I used to feel with each object I created, no matter how simple. Even more gratifying is the realization that a well-executed technical task enhances some aspect of someone's day. That reminds me of one reason why I accepted a leadership role. No, I am no longer creating applications on a daily basis. But, if I lead well, I am enabling an entire team to do the same. And suddenly, my next two-hour meeting doesn't seem quite so long.

How to Find the Time

The big question is, How do you find the time to do this? I have a few strategies, and none involves taking the lead on a major project. The idea is to take on small, manageable tasks. You are not trying to become an expert, and you are certainly not challenging your staff to see who's the best techie. It's about becoming familiar with your team's technology through frequent, limited exposure. You will find that a little goes a long way. Also, you may have surmised by now that I come from a software development background. So, in the following suggestions, I will use examples from that area, but these can be applied equally to other areas in IT.

  1. Pick something small. It should be something that you can finish in a few hours. In my case, I will occasionally build a custom database object such as a new table or view per user request, or I might create a simple report with our tool of choice (i.e., Crystal Reports).
  2. Ask to be assigned a small part or module of a larger project. One of my staff might be developing a database application for a user. I might create the validation tables used in that application or even build the table maintenance forms that go with them.
  3. Volunteer for a well-defined routine task. We have developed an automated workflow that routes account requests through a series of approvers. Occasionally, requests are held up by various approval steps. I take responsibility for troubleshooting these on a regular basis (it's not too technical, but it gets me into the application).

In Summary

If you are new to leadership and recently came from the technical ranks, this story may resonate with you. If you resemble me, you will feel like a fish out of water for the first six months, year, or maybe even two years. You will have to give up your day-to-day technical frolicking, but you knew that when you accepted the promotion. When you do get to that place where you feel comfortable and can spare (or make) the time, go for it: write that SQL script, install that router, or unlock that user. Indulge. It's like wine or dark chocolate—in moderation, there are potential benefits.


Steven J. Chang is Director of IT Development Services at Pima Community College.

© 2016 Steven J. Chang. The text of this article is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License.