Management Coding Breaks
management, software development
Despite the enjoyment I get from doing development or even working through a configuration or installation issue I often find that I have weeks like the last one. Last week I was unable to code at all either at work or at home. Work was just a series of firefighting exercises largely to get to new projects deployed and at home I spent my few free hours coding and catching up on some old household todo items.
I’ve accepted that my job as a manager is largely to develop my people. Still, I realize that most technical folks will quickly lose respect for you if your technical skills wither substantially. My compromise has always been to devote myself at home to doing a lot of learning and coding. This week was just one of those where I didn’t get time to fire up an IDE and work through some more unit tests while learning Ruby.
Balancing technical skills versus management skills is something I expect I will probably always struggle with and is just part of the territory. I’m just glad I really enjoy both or the balance would get out of whack in a hurry.
Technorati Tags:
management, software development
Ed Gibbs @ January 16, 2006


Ed,
I am interested in fleshing out a bit more the premise you posit in this post, namely that developers will lose respect for a manager who allows his/her own technical skills to wither. It’s probably already obvious, but I’ll go ahead and state that I’m not a technical leader. (I was a liberal arts major at university and picked up some web dev skills on the side, which led to a temp job, which led to my learning of asp, vbscript, sql server, ado, com+, etc…, which eventually led to a management promotion.) I’m now a BI manager in charge of a team of .Net developers. I’m conversant in programmer-speak, understand the general concepts, and can read code well enough to get by, but I’m not a developer myself, nor do I care to be.
I’ve found that my team doesn’t give two craps about my programming skills as long as 1) I attempt to understand what they’re doing, 2) provide learning and professional development opportunities for them, 3) shield them from the “business” and let them concentrate solely on development, and 4) take their technical suggestions seriously.
I know I was not promoted because I’m a technical guru. In fact, I generally consider myself to be a “jack of all trades, master of none.” However, I’m a great people person, my team trusts me (and I them), and I provide an excellent buffer between the business side and the IT world. I’ve found that in many companies, it’s difficult to find technical experts who are also good leaders and qualified business analysts; a company that can find one is truly lucky, and in a lot of cases, settling for two out of three is not settling at all.
I’m curious to know how your experience has differed from mine?
p.s. I work for a CEM with ~50,000 employees, about 1,000 of which are IT.
Ed -
I agree with Elliot. I have been a manager/director for about 10 years now and have not lost respect from my engineering teams. The respect for your programming skills must change into respect for your management AND business skills. Your ability to program is less important - your ability to understand how to develop your team, the business and your customers is critical now.
Yes, you must still understand the implementation technology - but a cursory understanding is acceptable as you should rely on your senior developers/architects for that expertise. You are now a sounding board and direction setter, but you must bridge the gap between implementation and business.
Instead of learning the latest programming language or architecture, you must focus on learning how to develop people, negotiating skills, project management (like agile), etc.
If that’s not what you want to do, then I suggest that you move back into a pure technical role. Otherwise you are doing your team a disservice.
Thanks for both of the comments. I obviously need to follow-up this rather short post with a bit more thinking about the topic.
I actually didn’t come out of a pure CS background and instead picked up my undergrad in Physics. I also got a masters in Political Science while pitching in at a friend’s early web startup back in 94-95. I’ve learned almost everything I know about software development from self-learning.
Sometimes you need to reexamine your ideas around a particular topic and I’ve had a general belief that a large part of my role as a line technical manager is to help mentor my people. That’s meant keeping up with a lot of technology. I worked for a professional services outfit as a Web Dev Manager where I was more advanced technically then any of my 8 employees. Currently out of my team of nine I’m still probably deeper on the programming side then most of them, some because they’ve come over from mainframe backgrounds, and some because they’ve stayed in a narrower niche. For example, currently on my team perhaps my two leads have been doing Java or OO as long as I have.
I feel like I tend more towards a jack of all trades as I’ve done a lot in a PM role, requirements gathering, management, and even some QA/UA testing roles. As I attempt to grow my management skills I’m trying to spend more time thinking strategically about nurturing the team. And now that I’ve got my current team up to speed on the sort of Java web development side I’m feeling more and more comfortable letting them take over a lot more of the technical leadership. The one realm I’m still pushing on is TDD which has been a real bear for adoption so far and I’m the only one currently on the team that really had done it in practice.
I tend to split my time between learning technical skills and management skills, but I’m probably moving towards spending more time on management and moving the technical stuff to after work on my own time for fun. I completely agree that care and feeding of my team is pretty much my highest priority. The better I can make my team by developing them and protecting them as much as possible from organizational distractions the better. I’m also trying to spend more time with our sort of weird niche business so I can understand our customers better.
The thing I have experienced though and that came out in this post is that high level technical developers will often dismiss a manager who isn’t at least near their level. There’s a lot of danger when a developer comes to you with the idea that say we should scrap UDDI because using some new technology from another vendor is the way to go? If you don’t know the area that deeply and would have trouble researching it this becomes difficult.
I’ve had developers who I trust a lot, but I know they love to work with new technologies and it can cloud their vision. So when they come to me and explain that they’ve implemented the newest version of .NET or Java 1.5 there’s a real danger if I don’t know what risks they might be exposing us to.
And then I’ve seen examples where the developers just stop running things by their manager because they don’t expect them to understand. That tends to be when the organization gets blind sided because the developers went ahead and made a design change that should be invisible to the users say moving to EJB 3.0 from Hibernate. Unfortunately when QA gets a hold of it a ton of defects show up. These are the sort of things that are harder to handle without the up to date technical background. At least with Scrum and daily standups you’re more likely to hear about these sorts of design decisions.
Thanks again, though for the feedback, and I’ll probably return to this subject with a bit more thought next time.
Thanks for expounding a bit more, Ed — I appreciate it, and I agree with your premise. My lead developers also tend toward leaping at new tech with boundless enthusiasm rather than cautious optimism, and it can cause difficulties, not the least of which is defining the scope of any given project.
As an example, when we finally got our hands on VS2005 and .Net 2.0, we realized that a lot of what we had done previously really should have been done using master pages, and that our custom controls really should be XHTML compliant. Well, because we’re waiting on another team before we can roll out our product to production, we could afford to spend 3 weeks on the conversion, but it’s been my experience that developers aren’t always keen on being told to ignore new tech and do things “the old way.” This is one area where PM knowledge and soft skills are key.
Best of luck to you in continuing to refine your management technique!
I see your point about the pressures and risks of moving to the new stuff without much hands on experience. The best advice I can give is that you, as the manager and ultimate decision maker, should be able to ask probing questions about the software, tools, risks, etc. that can force the developers to think through the decision. Not all tools are the same, but I think all the same questions apply: backward compatibility? what’s your upgrade strategy? downgrade? how new is this technology/product? explain the architecture to me (draw, whiteboard, etc)? why is this better? what are the disadvantages? etc.
I do wish that I could spend more time keeping up with the latest technologies. I am a better manager than software developer so it takes me a lot longer to learn the new stuff!
I agree that asking a lot of good questions is a good strategy and one I’ll have to rely on more in the future as most of my team is getting up to speed enough that they’ll tend to know more than me about particular technology niches.
Thanks for all the feedback.