I used to present a session called Managing a Technical Team: Lessons Learned (Alexa: Remind me to update and submit this session again); the point of it was to reflect on some of the lessons I learned early in my career transitioning from a database developer into a management position. I was trying to give a view from the trenches, mostly to help other folks get a perspective on what it’s like to fumble through a career change. Management, like development, is a process of learning and continuous improvement; the difference is that other people have some expectation that you know what you’re doing (and often, you don’t). Inevitably, I’d get asked some version of this question:

“Can I still be technical and manage a team effectively?”

I used to have a quasi-canned answer, something along the lines of “at some point you must choose your path; management is about people, not technology”. I still kind of believe that, but recent experiences in my own career path have caused me to reconsider giving an answer. Instead, I’ve started asking the questions:

“Why does it matter? What’s your goal for your career? What do you think you should do?”

The truth is, I don’t know what’s best for you, but I trust that you do (that satisfies my libertarian soul). Everybody’s got different experiences, different beliefs, different goals, and different circumstances. When you bundle those things together, it makes for a very complex decision tree; even a simple question about how you want to conduct your day-to-day affairs becomes overwhelming for someone sitting on the outside to answer. That being said, I still want to help, so I thought that I would share some of my decision factors using the four buckets above.

Experiences

Here’s some of experiences that have gotten me to this point:

1. I don’t have a technology-related degree; I have a BA in RadioTVFilm Production, a MA in Communication, and a MEd in Instructional Technology. I got into database work when I flunked out of a PhD program in Health Communication (and salvaged some of those hours into the MEd). I had failed my comprehensive exams twice, and had a meeting set up with my advisor to discuss a third attempt. She never showed; I drove off campus that night, bought some books on SQL and relational design (having done stats work as a grad student), and started looking for a job.
2. In my first IT job, I worked for a good manager (a developer running a support organization). When he left, I worked for an awful manager (a project manager who had no clue about anything related to computers). I try to emulate the former and check my actions to make sure I’m not acting like the latter.
3. I’ve been with the same company for almost 15 years since then. Different roles, different responsibilities, different owners.

Beliefs

These are some of the core beliefs I have about management and technology; these will be tough to change.

1. Management is more about people than tools.
2. Management should be more strategic than tactical. While a team may be responsible for specific operations, the manager of that team should understand the unit’s role in the bigger picture.
3. Technology is used to solve business problems; a good manager will focus more on solving the problem than on the tools used at any point in time. SQL Server is the tool I’m accustomed to using, but the problems I’ve been focused on lately aren’t database problems (they’re IT infrastructure and networking issues).

Goals

Goals are tough for me, because I believe they should be a mixture of both long-term and immediate. As such, they change more often than you would think (at least for me).

1. I want to be forward-thinking; I want to keep being exposed to new tools and technologies.
2. I want to be compensated well, and I want to continue gaining new responsibilities.
3. I want to feel like I’m making a difference; I’m not interested in continually addressing the same problems over and over again. I want to make a change and move on.

Circumstances

Everybody’s got different external factors that influence their decisions; managers are no different. For me, the following things are true:

1. I’ve been a remote worker for the last 8 years; it would be tough for me to go back to having a daily commute.
2. I’m project focused, not time-focused. I like having flexibility to get things done without a set schedule.
3. I’m a dad, and time with my kids is critically important. That means that I’ve had to pass up on opportunities because I’d rather take time for them.

What does this all mean?

For me, it means that I don’t want to be a single-technology manager; I want to figure out how to make technology work for business, even if it’s a technology that I’m unfamiliar with. The logistics of scale means that I can’t be the single source of authority when it comes to implementing technical solutions. I scale out by relying on my team to be the experts, and I want to keep building teams that can handle lots of different problems.

More to come later.

Tags: DevOpsmanagementProfessional Development