Click here to monitor SSC

Tony Davis is an Editor with Redgate Software, based in Cambridge (UK), specializing in databases, and especially SQL Server. He edits articles and writes editorials for both the and websites and newsletters, with a combined audience of over 1.5 million subscribers. You can sample his short-form writing at either his blog or his author page. As the editor behind most of the SQL Server books published by Red Gate, he spends much of his time helping others express what they know about SQL Server. He is also the lead author of the book, SQL Server Transaction Log Management. In his spare time, he enjoys running, football, contemporary fiction and real ale.

Should IT Managers Code?

Published 17 January 2014 11:40 am

In one of his first ever Simple-talk articles, Phil Factor tells the story of a freelance Sybase programmer who created a reporting system using exquisitely complex dynamically compiled stored procedures, and then promptly departed when he failed to secure a doubling of his contract rate. As Phil struggled to make sense of the code, with the business baying for bug fixes and impossible improvements, he learned a valuable lesson for any IT Manager:

“Never let a programmer do anything that you yourself cannot understand”  – Sir Tony Hoare (Computer Language expert, inventor of Algol and the Quicksort algorithm)

At first glance, it would seem an odd sentiment, but Tony Hoare was referring to code that couldn’t be understood even after being explained to a technically-savvy manager. He was warning of the dangers of complexity.

Certainly, there needs to a restraining force that prevents the typical development team’s tendency towards complexity. There is generally a yawning gap between the technologies that an ambitious programmer wants to use and the technologies that best suit a project. A manager needs enough programming nous to help keep the technology as simple and reliable as possible. In the face of their countless managerial, strategic and company political duties, the struggle is to maintain their programming skills to the point where they can spot if a programmer is adopting an unnecessarily complex or unwieldy approach, or championing “unproven” technology, when something duller but more reliable would suffice.

According to Eliot Horowitz, the CTO of MongoDB, the way to do it is for IT managers to spend at minimum 30% of their time programming. If they don’t, he argues, they “encounter a significant degradation in their ability to execute their responsibilities”, and their “connections to the concerns of developers atrophy…decision-making, planning, and leadership suffer”.

Is Horowitz really correct that a failure to do this simply means one becomes an ineffective manager, as well as programmer, over time?

It is only recently that professional people, Doctors, Lawyers, Engineers or Scientists have felt it to be an option to slide into a generic managerial role, to neglect or abandon the professional skills that first enabled them to rise in the profession. A part of their job was to keep up with changes in their profession. Until the 1980s, management skills were acquired as part of career development and it was unthinkable that a generic manager without professional skills could direct professional work.

Maybe technical leadership is undervalued. Recently, some of the most catastrophic IT failures have been precipitated by startling technical shortcomings, rather than general lax management. Would a more technically-savvy management have been able to spot the imminent disaster and prevent it?

23 Responses to “Should IT Managers Code?”

  1. Laren Hagen says:

    If you don’t have the technical savvy to understand what your employees are doing: are you really the right person to be managing them?

  2. callcopse says:

    I’d like to present a flip side to this argument. Perhaps managers should have the skills to assess what their employees are up to without necessarily understanding the technical details. Perhaps they should be able to trust their employees to not overreach on technical scope.

    As I say I’d like to present a flip side – however I don’t think I can. Yes, they should know enough to understand, at least broad brush, what is going on. Programming 30% of the time I think unrealistic from my experience but my favourite managers have been hands-on to a decent extent.

  3. DrTechnical says:

    My take on technical managers being able to work in the same environment as their direct reports has a different spin to it.
    I’ve found that when my manager is not technically savvy about what I do and how I do it, they are much more likely to place me in projects with unrealistic expectations and wholly unreasonable timelines, because they don’t understand the time and effort required to produce a quality product. Only when they have continuing experience in development do they reign in a user’s expections (where necessary) and set deadlines that allow me to craft a high quality solution that works well and meets the user’s requirements.

  4. Robert Young says:

    On this side of The Pond it was the B School (aka, The Harvard School of Business Administration) that, mostly, created the myth that management was a separable skill. And that a good manager could manage any task.

    From this all came PERT, GANTT, and a host of mainframe project management software. Which found its way to the PC, in the form of Primavera (for the serious ones) and MS Project (for those not so serious). Managers became timekeepers and interrogators. Such folks, who also functioned as micro-managers, are especially dear.

    OTOH, one hears: “just hire smart folks and stay out of their way.”

    The most effective managers I’ve had knew the tech. One of the, possibly most important, value-add of managers is steering the ship. For that, the captain needs to know more about the ship and where it’s going than the crew. I guess that explains why far fewer ships crash than software developments.

    • WilliamII says:

      I think it goes further back than Harvard. Gantt was a disciple of Frederick Winslow Taylor.

      Taylor is regarded by many as the father of management consulting, but he was definitely a hands-on guy who also achieved some significant technical advances in steel production.

      I think one of the long term problems in IT management is the attempt to force-fit it into the manufacturing model that worked brilliantly for Taylor and for Henry Ford.

      Agile proponents equate Taylor roughly speaking with Satan, but ironically methods like Kanban look like pure Taylorism, at least from where I am sitting.

      I find Taylor a fascinating, if controversial, figure and not enough people are aware of his enormous influence on how almost everyone works today.

      • Robert Young says:

        I didn’t intend to say that the B School invented any of those (PERT came from Booz for the US Navy and CPM from industry, for example), but that the idea of “scientific” management using such “tools” made management a separable skill, and so forth. Nor was the B School the only place that went that way. But, being the B School and having entree’ into the Fortune X00, its influence was substantial.

  5. Dimitrios Kalemis says:

    Your question: “Would a more technically-savvy management have been able to spot the imminent disaster and prevent it?”
    My answer: “Of course.”

  6. Keith Rowley says:

    It seems to me the rise or non-technical managers corresponds to some degree with the fall of apprenticeship as a training model.

    We used to have masters in a craft who would be expected to train apprentices up in the craft, and thus managing went directly with doing AND teaching.

  7. WilliamII says:

    It depends what you mean by understand.

    As an example, let’s say a programmer follows fashion and caches some data in the middle layer. Subsequently a bug occurs because the data was updated in the database but the application still saw the cached version of the data.

    The manager needs to know enough that the programmer made a mistake that violated the basic principles of data management.

    What he or she probably doesn’t need to know is whether the programmer wrote it in C# or Java and how in detail the folly was perpetrated.

  8. Sergio E. says:


    From my perspective, in this modern world where IT Managers has too many responsabilities I think it’s very very difficult to they can spare even 10% of ther time coding.

    I agree with the statement that it’s very very important to don’t let the team do all in their owin way and coding is one great approach to do so.

    However, usually IT Managers are always in the middle of a storm of meetings and administrative tasks that don’t allow this coding time.

    Even worse, at least in my country, in many enterprises the IT Managers are not IT people at all, so coding is not even an option to them.

    Greetings from MX, as always is a pleasur read your blog.

  9. jkeefe says:

    At what point does the 30% rule become moot? When the technical manager becomes a director, and has mostly technical managers as their direct reports, it seems absurd to expect them to continue coding 30% of the time. Perhaps 10% is more reasonable since the director-level manager is still “technical” but now more involved with the business than with the technology.

  10. DGPerson says:

    Contrast Phil’s experience with this: Years ago I was called in to discover and prove why an IVR system based upon stored procedures failed to run. Once I proved that the 3000 lines of code did nothing but return to the starting point a big meeting with the managers and the VP of development lead to the VP asking the question, “Why can’t we get someone in here that is smarter than this guy and prove him wrong?” He was referring to me. They tried 3 consulting companies and each agreed with my conclusion. The consequences are that they fired 2 managers responsible for the development project and never wanted to see me again. Apparently they don’t like discovering how badly they are managing development and the truth I provided generated too much job risk.
    So what do IT managers need? It certainly isn’t coding ability. That is our job. An IT manager needs a way to measure accountability for the code and a mechanism for proving the claims of the programmer. A good IT manager asks the programmer what he has and looks for a demonstration of its results. The answers might be “45%” and a bunch of tables with staging data. But now the manager is empowered to answer for the project and has something to judge against in the next review.
    The fired managers failed to establish and measure accountability. If they had done so the company would have needed me to redesign and rewrite the core of the IVR system. this is all IT managers should do: measure and prove accountability; this and nothing more.

  11. paschott says:

    Mixed feelings on this. I think a manager should know enough about the technical side to make good decisions, but doesn’t necessarily have to be a coder in order to do that. I’ve had some managers who didn’t know much and could easily think that a Flux Capacitor needed to be part of their network hardware. I’ve had others who were down in the details and doing the work along side us. Admittedly, the latter was one of the better managers I’ve had. However, I’ve had some in-between who didn’t do much code-wise, but knew the technology and the team. He trusted the team to make good decisions, but would step in if we were going in the wrong direction.

    I can see the benefit for managers to keep their hands in the technology so they can continue to make good decisions, but I can also see the other side of managers who understand the higher level details and can be effective that way. Perhaps the suggestion that they spend maybe 10% of their time keeping up with technology is the best I’ve seen. Their main responsibility is not to code, work on servers, and so on. It’s to manage the people, help them do their jobs, and provide them with the things they need to do the job well.

  12. Andy Doran says:

    I agree with others here, that a good Technical Manager needs to spend time, perhaps 30%, keeping up with technology and “steering the ship”. The manager doesn’t need to be an expert coder/programmer, that’s what the employees should be doing. What the manager definitely should do, is describe and document the higher-level architecture, programming standards, naming conventions, security practices, etc. And, more importantly, ensure these practices are followed.

    Even excellent programmers can get stuck in their ways, and sometimes need direction, or perhaps a poke in the right direction.

  13. Phil Factor says:

    I’ve tended, over the years, to oscillate between Technical Architect, Management and developer roles, rather than try to mix them. I think that maybe that is the best for the industry. By switching roles, I retain a sympathy and respect for the other roles whilst, at the same time, being familiar with the tricks and deceits that each can sometimes employ. To make this happen, we must stop treating the developer as a second-class citizen in the hierarchy, and reorganise development teams in a way that makes the most of the skills of each role. The thought of managers micromanaging the developers’ coding is rather scary, almost as horrific as developers trying to manage aspects of the direction of a project.

  14. Nelson Petersen says:

    I’m so glad the responses are pointing out some of the pitfalls of managers who split their focus between management and coding. Yes, IT managers need to be technically savvy, but they don’t need to be coding 30% of the time to maintain their edge. Maintaining an edge is much more than coding.
    As to the final question, “Would a more technically-savvy management have been able to spot the imminent disaster and prevent it?”, they might be able, but that is no guarantee.

    Truly technical-savvy management would insist both on complete testing [documented results] ***before implementation into production*** and review by the code-review process, and making sure that testing and code-review is working.
    Have a developer regularly put in different types of bad code to make sure it is found by the testers/reviewers.

    A manager who is finding flawed code would be better served by training their staff to find flawed code instead of doing it themselves.

  15. Robert Young says:

    The rebellion against the RM and SQL databases, touted IMS/hierarchical datastores (xml/NoSql/etc.) and was driven by coders who couldn’t grok SQL, much less the RM. IT management cowed before the mob. In due time, the coder mob realized that hierarchy proved too rigid (single parent) for real development, and so the mob then segued to “graph” (multi-parent) datastores, again a reiteration of age old (pre-Codd) databases (which pre-date IMS, even) of IDS/IDMS, then known as network databases. The lunatics are running the asylum, while IT management struggles with Angry Birds and Candy Crush.

    Discuss amongst yourselves.

  16. JonRobertson says:

    I agree with so many responses here.

    DrTechnical: I have had three managers that had zero understanding of my job. Two of those, each at a different firm, had written software 30 years ago on mainframe computers and could not relate to the challenges and difficulties we were having. (When our MS-DOS app was running out of memory, no matter how well memory was configured, one manager asked “Can’t we just write our own linker that utilizes virtual memory?” Granted, we were already using an excellent product for this (RTLink), but we were still running out of memory.) I unfortunately shared DrTechnical’s experience, where those managers had “unrealistic expectations and wholly unreasonable timelines”.

    Andy Doran: I completely agree with your comment of “What the manager definitely should do, is describe and document the higher-level architecture, programming standards, naming conventions, security practices, etc. And, more importantly, ensure these practices are followed.” I’ve failed to meet a manager that even attempted these tasks/responsibilities. Most of the time, these tasks were completely ignored. Several times, I or another team member would try to implement them ourselves, but that ultimately fails. They need the authority of coming from management and a manger to enforce them and ensure accountability.

    I’ve never been able to convince management of the value of routine peer code reviews. I successfully convinced one company to try, but ultimately it was decided it took too much time (since it involved every team member) with insignificant results. :(

    Nelson Petersen: I love your idea of having developers intentionally put in bad code to test how well the quality processes are working. Unfortunately, I think that’s an Utopia. All teams I’ve had any experience with are under constant pressure from management to complete the project yesterday, and often QA is under pressure to approve a product yesterday. I’m not saying these teams do anything to compromise quality. Most take pride in doing quality work and delivering a quality product to the customer. But I’ve never had a management team that would approve intentionally slowing down the process.

    My best jobs as a developer have been where my manager had coding experience, enforced good (versus bad) software development practices, and had realistic expectations of software development. Those guys could keep management’s unrealistic expectations at bay, providing necessary grounding between the development teams and other teams. Any team (even a team of one) needs a senior developer who can understand, translate, debug, even port or rewrite any code written by anyone else on the team. And there needs to be significant trust between that senior developer and the manager.

    For me, the biggest disappointment in software development today is inconsistency. The first commercial project I worked on 20+ years ago initially failed, largely due to a lack of consistent software development practices on the team. Luckily, we learned from our mistakes and was given a second chance, where we delivered twice the product in 1/3 of the time we spent on the initial failed product. I’ve only had two other jobs since that one, but I’ve been unable to convince management of the merit. Both companies/teams do “well enough”. It seems major change is only motivated by major failure. :(

    • JonRobertson says:

      After re-reading this, my emphasis on good practices (where I emphasized versus bad) sounds silly and redundant. But I still stand behind it. I think it comes from having managers who thought they knew good practices but really didn’t. :(

  17. Timothy A Wiseman says:

    No, a manager does not need to code and certainly does not need to spend 30% of their time coding. They do need to have some basic understanding of what is reasonable and possible though, but as long as they have good people they can trust initially they can learn the basics from those people without coding.

    I served for a while as a Military Intelligence Officer in the Army and when I was a platoon leader I had a platoon composed of different types of intelligence soldiers with different specialties. I was only actually qualified to perform one of those specialties and even there my soldiers could do it better than I could and without some of the distractions that came from my position as platoon leader.

    It was of course vital that I learn some about each of the specialties in my platoon so I would know what they needed and what they could do. But for the most part, I couldn’t get in there and do their job. I could not do the equivalent of coding. Instead, I handled the other things so they could focus on their actual jobs. I handled paperwork, scheduling, interfacing with other units, and handling personnel decision. I could do all of this without being able to do their jobs, much less without spending 30% of my time doing it.

    Since leaving the Army, I have been a Programmer, a DBA, and a Technical Manager. Although I continued programming as a technical manager, and I do think that helped me, I do not think it would have been essential to perform my duties as a manager. Some basic knowledge of what programmers need, what is realistic, and matters along those lines are vital of course, but a manager who has a good team can learn that from his team and by researching without spending close to 30% of his time coding.

  18. jerryhung says:

    I’m a DBA and all managers I had didn’t code, and that’s not why they were manager anyway

    I think managers should manage PEOPLE, and leave the technical to technical guys. You don’t need to code to succeed, you just need to pretend you do understand :)

  19. DeafProgrammer says:

    Very simple.

    we now have a “Plan”, what has to happen next is that we start SERIOUSLY IMPLEMENTING the Plan!!

    While the first step clearly must be the establishment of the Committees and Sub-Committees including what meeting schedules they may have etc. so that people know what their commitment needs to be, the next challenge on that score will be getting the right people for the Committees and ensuring that people are aware that we are sincerely seeking their contribution and hard work to make the Plan a reality.

    You will be ready to lead and participate in much of that work!!

  20. Andrew Watson says:

    I think that while it is helpful that managers could program (and perhaps did at one stage), it is also better that they don’t.
    - Managers that program will be too frequently interrupted with other tasks to do the job efficiently.
    - Managers that still program are more likely to rewrite their underlings code the way they would have written them which is de-motivating (perhaps a code review opportunity missed?)
    - Managers cannot possibly be an expert in every language and technology used in the modern workplace
    - Code should not be part of a manager’s expected personal output…. they should be doing the things that you don’t want the programmers to do.

    If you limit your employees to having a lesser intelligence than your own, then you are asking for mediocrity. I personally think you should never be scared to hire someone more intelligent than yourself. Part of being a good leader is knowing how to delegate, and if there is no-one better than yourself to perform the task….?

    For me the main tasks of an IT manager are to:
    - Keep the developers happy and productive.
    - Ensure standards are observed by everybody.
    - Protect their team from management responsibilities.
    - Know how to listen to their team’s input and choose between alternate strategies.
    - Manage risk (like the one person knowledge store described).
    - Have realistic expectations of output (no false metrics like lines per day). Eg:
    - Keep people learning and engaged

    Having a programming background can help with all of these, but there are certain people skills and mind-sets that in my view are just as important, and are definitely not taught by programming experience alone.

    If I ever manage to run a large software company, the manager’s salary will be pegged to that of their team. That is, a manager is only as valuable as the people they attract, train and keep. (Eg sum(coder_salary * 10%) of a team of 12… and yes it would be possible for a top programmer to earn more than their manager.)

    If anything, perhaps a manager could spend some (? 30% ?) of their time reviewing code (not writing it).. that way they understand what their underlings are doing, can recognise training needs, lack of standards, help QA, learn new techniques (and help to enforce the good ones, remove the bad ones before they become entrenched), keep obscure code to a minimum, etc.

Leave a Reply

Blog archive