The Technical Manager
-
The Technical ManagerCan you manage and be technical? In Andy Warren's presentation at PASS he said that you have to manage first and fit technical stuff after hours or during downtime from managing. This article looks at whether a manager needs to be technical. It's an interesting discussion and I'm not sure how I feel. I do think that a manager needs to have some idea of technology, understanding the basics of how things work, but I'm not sure they need to be able to do any of the technical work.
I've been a technical guy most of my life. At least most of my career, though I think I learned to be a decent manager. As a technical guy, I have a good understanding of how things fit together and while I don't completely understand how some things work, like the details of an AD forest, I can get the expert to explain it to me and then judge their solution against the explanation. It also helps that from my years as a bartended I have a pretty good manure meter.
A few years ago I was put to the test by having to manage a team of DBAs running Oracle and DB2 databases in addition to SQL Server. Of the ten people I managed, most knew two databases well, though they were expert in one. I had very limited knowledge of Oracle, having just done some development against it more then 10 years previously. I knew how to spell DB2 and that was about it.
Maybe some of my former employees will chime in, but I think I did a pretty good job. When we had issues, and we had lots of issues, they were almost all on the DB2/Oracle side and I had to get explanations and possible solutions from my people in both a platform (*nix) and a technology (Oracle/DB2) where I had weak or non-existant technical skills and then present these positions to other managers, executives, and techies, arguing for my people and their ideas.
When I left, my replacement wasn't a database person at all. My boss asked me if he could do the job and I thought he could because he was a decent manager and I didn't think that deep technical knowledge was required. Again, a good manure meter is important, but the ins and outs of Oracle system processes isn't needed.
Some of the best managers I have had the opportunity to work with weren't people I'd consider very technical. They had to like and understand some of the technology, but none of these individuals would be able to do actual technical work. And you know something.
They didn't need to.
One of the hardest things I had to do as a manager was nothing. I had to sit back and let others do the work, even make mistakes, to help them grow. But more importantly to show them I trusted them. I think this is where many first time technical managers, often uber-geeks themselves, fail because they don't manage people. They correct them, try to be mentors, and even do better work at times. It's hard to put yourself "below" someone else without them showing up your skills.
I think some people can be very technical and be great managers, but they'd likely be great managers in any industry. I think that's a skill unto itself.
-
The priorities of a good manageer should be: 1) Managing their own staff; 2) Managing their peers and superiors; 3) Managing relationships with customers and vendors; 4) Managing their own budget; 5) Understanding what the technology can do.
Although a good technical person could do with all these skills, the priorites of techies are just about opposite to those of managers. When a techie gets promoted, it can be very hard for them to change their work priorities, especially if they are still expected to do their share of the technical workload. However, being a manager is a career change from being a techie and the skills and priorities of the new career must be adopted if the job is to be done effectively.
Most of the people I respect the most as managers, and who then moved up the management tree, tended to work to these priorties.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
-
To effectively manage technical problems requires an understanding of the underlying principles. I agree you need not know everything to effectively manage, but you do need to know if policies and procedures are being followed and if they are relevant. As times change, you have to change with them. Introducing change is difficult, but necessary. Effective communication, professional attitude, and a willingness to learn are aspects of leadership. The more technically savvy the manager is, the better they will be at determining what is required, and what is to be expected from their staff and their resources. When you stop learning, its called retirement.
What I fear in any technical job is the ass-kissing backstabbing manager. They need good people to make themselves look good, however, they arrest growth, stunt morale and generally get less productivity from their staff.
Of course, these people never worked with Steve at Utopia Inc.
-
Having come from the defence force before I inhertied looking after a SQL server installation and the hardware it sits on, I can say with absolute clarity that you don't need absolute techincal expertise to be a great or even good manager.
It seems that I have almost gone backwards - having been a manager or over a dozen direct reports and in charge of a maintenance budget that exceeded 30 Million p.a. to be the lone techie for a small group inside a university.
I would be doubtful though if you could do the job (manager) without any consolidated knowledge that is the purpose of being for your team.
How can you possibly have a good BS meter - if you don't know what your staff are talking about?
I certainly believe that you don't necessarily need to understand the ins and outs of what they're telling you - but you should at least know, best industry practices for the group you manage, the capabilities of the tools they have to use and the capabilties of the underlying systems they're in place to maintain/develop.
My number one piece of advice for any manager and any staff I have ever had authority over is:
"value the process - not the results."
By having a framework / methodology that is at least based on open, industry derived, best practices you can ALMOST guarantee the results you're after.
Gavin Baumanis
Smith and Wesson. The original point and click device.
-
Some of the best managers I've ever had were completely non-technical. And some of the worst ones I've had were very technical. Typically, with technical managers, I have found they cannot help being hands-on and when that happens they stop being managers.
As far as I'm concerned a manager does not need to be technical to be a good manager. They need to know how to manage people and let them get on with things and let them make mistakes (as you pointed out). Obviously there is a lot more that goes into making a good manager but technical ability isn't one of them in my opinion. A good technical team is usually helpful.
-
My situation is an unusual one - I had a boss who wasn't technical, but suffered under the delusion that he was...
Now, I don't want that to come off sounding like a knee-jerk rant from yet another geek railing against "Teh Us3rs", so let me clarify - he's a CPA who occasionally dabbled in technical things. But when we had a project, he insisted on making arbitrary code-level decisions, typically based on some article he just read on the 'net. Not a good improver of efficency, and definitely more hindrance to the design process than anything else...
-----------------
C8H10N4O2
-
Thanks to all... This was a great thread.
My experience has been that my best managers had some knowledge, but backed off after assigning a task and evaluated the results of my efforts or the teams efforts at the correct time. Timing is everything in IT work. You can be one day away from finding the best way to solve a sticky problem and if a manager evaluates your work on that day, he or she may be disappointed in the current results. Check a week later when much of the correct idea has been implemented, and that same person may appear to have super hero skills
-
I guess that since I (a) can manage a team, and (b) know the rules of Baseball that I should go apply for a job with the Kansas City Royals.
Yes non-technical (or light weights) can and do manage tecnical teams. If there is too much light at the top then the team spends a lot of time defending themselves or justifying actions. If there is too much weight at the top then there is a tendency for the leadrer to dive into the trenches. For it is written "moderation in all things". That applies here as well.
Ed has a good list of priorities "The priorities of a good manageer should be: 1) Managing their own staff; 2) Managing their peers and superiors; 3) Managing relationships with customers and vendors; 4) Managing their own budget; 5) Understanding what the technology can do." I woul add: 0) Manage yourself. Dirty Harry said, "A man's got to know his own limitations."
ATBCharles Kincaid
-
Maybe I should expand a little. You can't be ignorant of technology, but you don't have to be able to write SQL queries to manage SQL Server DBAs.
You get explanations from from your staff and have them explain it to you along with alternatives and risks. And they're explaining it to themselves. Sometimes they'll come up with a new solution as they're explaining it.
While the Royals might not hire you (or might, not doing so good on their own), if you approached the players in each situation and asked them to explain what they wanted to do and why, you could weigh things and likely make a good decision. Often you might go wiht who has the most confidence in their abilities (like starter or reliever) and might do great.
My point is that I could manage DB2 and Oracle DBAs while in the short term, I'd struggle to get much of anything done on those platforms. You make the decisions after forcing other to think things through and give you their positions, risks, and benefits.
-
My best manager wasn't very technical. He was an accountant who had drifted into IT. He knew TSQL to some extent and basic Lotus Notes programming. He delegated, had weekly check ins and required weekly status reports. He conducted weekly meetings with the the user group managers and had bi-weekly team meetings. I was very happy working for him.
-
I had been assigned a small project to manage with one tech person to do the work. (at the time, I was managing 8 projects ranging in staffing needs on 1 to 6 techies.) At the time, I was given a warning about the techie who was assigned to work on this project, that he was a trouble maker, not cooperative, and not able to communicate well with others or the clients.
The first thing I did was go to his desk, sit down, and address these issues. started by saying, "You have a clean slate" and then procedded to address these issues in a one on one conversation. I determined that he had probably upset some managers feelings, but that professionally, the issue were unfounded, based on his answers and a look at previous work efforts. I then arranged the initial meeting with the primary client to whom he would deliver the finished product and glean what aspects he needed. After I performed the brief introductions, I told him to keep me updated and call if he needeed me.
The end result was, the customer gave him good reviews, the product worked great, was delivered early and under budget.
The techie actually thanked me for believing in him.
So, my thoughts are always manage to your people first. You still owe your clients or upper managers (those folks paying the bills) a qualilty approach to managing their investment. But it a lot easier with folks who you can trust and who trust you.
On the technical know how of managing techies, the more you know, the better off you are. The key lies in knowing that you are managing these folks first, and should probably think of doing techie work as a lower priority. How low a priority depends on what level of management you are performing.
-
Ouch, Michael!
Doctor Who -
My manager started out life as a techie, drifted through various things in the company (he's a Six-Sigma black-belt) and then we invited back to IT. Best damned manager I have EVER worked for.
He knows enough of the technical side to know that he should keep from fiddling, but he also trusts and entrusts to those of us who report to him. Consequently we work together well, we get things accomplished and we all know where we stand, both in his eyes and in what he represents to the CIO as well as all the other management and non-management customers.
So his techie background has served him well enough to know when to ask questions and when to let us opine on approaching some new technology or software, but his management skills make him the IT manager in our location that everyone wants to work for.
------------
Buy the ticket, take the ride. -- Hunter S. Thompson -
I read the book 'One minute manager' and many other books about how to influence people and how to be a good manager. For all my years working in different companies, the 'one minute manager' is only existed in book not real life !!!
-
For all the +1ing that are in the replies saying '...managers need not be technical...', I think that may be true but makes a few big assumptions.
a. that the team being managed is well qualified and/or is capable of finding technical answers on their own. (and before someone jumps in and says, '... well, if they are not they should be gotten rid of...', I would ask how would you know who to get rid of if you didn't know the technology yourself)
b. that the team is being upfront/honest and lazy when presenting problems/solutions. The sentence being repeated here, '... I would ask them to explain their solution...'. Well, once again, if you didn't know the technology yourself, what makes you think you'll be able to spot BS? I was a DBA in a previous life, and as an example if I told my manager, it would take 300 lines of code to restore a Full backup and Transaction log backups and therefore we should purchase 'XYZ' third-party software, and the only thing you know is how to spell 'SQL', I don't see how you'd spot my BS.
The best managers I've had (including but not limited to 'Technical Leads' in a Dev team), had all 3 of the below
1. good knowledge of the product / technology, and in a pinch would know OR could figure out fairly quickly, how to do the detail work that his/her direct reports did AND
2. had people skills, to not barge their authority all the time and support direct reports when speaking with superiors etc. AND
3. were willing and interested in keeping up with the technology, learn from the direct reports even
Of course, people can be (and are) managers with a subset of the above, but I disagree that it is sufficient condition for being a good manager in a team working with fast changing technology.
For me, anything less that all 3 of the above is a compromise.
The Technical ManagerViewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply