Tips for Programmers New to Management
Start Talking to People Instead of Typing
by D1J1T — in Management — Updated: Mar 4, 2014 at 9:39 am
Let's assume that you are the director of web development or overseeing programming for a large corporation. Let's also assume that you have some experience and knowledge with the technologies used for the product in development. Finally, let's assume that you understand most of what the programmers are telling you. It is crucial that you have already have established a method of communication that is quick in order to resolve current issues, concerns or question(s). If you are bombarding your lead developer every 30 minutes though to answer questions, there is a problem, if not several. See how distractions diminish developer effectiveness.
If you are the "lead" of development or in charge of programming and know specifics
of the the programming languages and technologies used already, then chances are,
you're already (or have been) a programmer/developer yourself. If you are new to management however,
here are a few tips I can offer given my management experience that may be of interest
to some of the tech gurus/programmers/developers out there that have been recently promoted to management.
1. You'll probably do this anyway, and may already have, but if not, be sure to recognize both the stronger and the weaker programmers/developers that you are managing. Then learn the specific strengths of the "weaker" as well as the weaknesses of the "stronger." In sum, know your development assets well and who to go to for rapid, quality completion of task "x" which requires skills in "y", "z" and "a."
2. After making evaluations, re-evaluate, in particular those that you initially thought as being "weak" developers. Determine if they are strong in other skills that are relevant and beneficial to the company. Adjust based on this, perhaps moving them away from db specific code to front-end UI/UX.
Though it may eventually be necessary, don't immediately let them go. I've fired 1 person in my 20 years of experience, after long thought, delay, and obvious necessity only. In retrospect however, I should have done so sooner in that case. It's important to remember that people are more valuable than any machine or software and that both are useless without them. This sounds obvious, but can be easily overlooked by skilled programmers. "My software is fully autonomous..." For how long? And what if you want to change that one ugly graphic that you didn't notice until now or fix that bug resulting from running the app on that newest mobile OS? Even the most skilled (if not especially them) will admit that no piece of software is perfect and can more than likely be improved now or in the future.
Some employees may have skills they have yet to be able to demonstrate. Just because you are a UNIX guru, are as familiar in a shell as you are in a browser or any other application, have programmed your own operating systems, port sniffers, or software types most aren't even familiar with and know the software and hardware used on the project inside and out, don't discount the fact that an employee may know something valuable that you don't. Perhaps you can get him or her to do some of the grunt work code which they can hammer out quickly and are more than happy doing in the interim while you evaluate their skills further. Consider their potential first, and shift their responsibility accordingly. The employee may surprise you. Sure, if you're using pcs and he or she can't find the control panel, you may have to regretfully let him or her go. Here is an example of why it is important to understand an employee's full skill set and value. Let's assume that an employee is a brilliant graphics artist, knows every tool and function in all Adobe products, but has worked only on OSX mainly, yet can pull up an ai file that he or she created of the most beautiful 2d vector art you've seen? Once while training a new developer, after days of answering what I thought to be remedial if not ridiculous questions, correcting her time and time again, fixing her code even, she presented on screen one day the inclusion along with the proper implementation of a library that I was unfamiliar with. She explained that the reason she chose it was for its ease of use, time efficiency, and functionality, and then showed me a functional result of the implementation. I probably would've programmed the function myself, and spent a good bit more time doing so.
3. Avoid acting arrogant or superior even if your skills are more advanced. Be willing to celebrate their skills. Give them kudos for what they do correct. Also clear, specific recommendations and corrections when needed. Communicate with them on a programmer/developer level most of the time, playing the "I'm your manager, do what I say" card only when it's really important. Ensure they know that their efforts and opinions are respected, at the same time urge the employee to be more efficient in areas that you note he or she may be lacking. School him or her when needed because he or she will listen and will more than likely be eager to learn something new. Most importantly, acknowledge the employee's experimentation and creativity. Yes! You read that correctly! Programmers are very creative. They also constantly experiment. Anyone that sees a programmer as a simple number cruncher simply doesn't understand the power of programming nor the drive which motivates many of them. As an experienced programmer, now manager, you can relate to the value and power of experimentation. As long as they aren't spending the whole day on a particular snippet, let them.
4. Given that you are a manager now, you'll have to actually speak the common tongue to people: your bosses, clients, vendors, everyone. You can't just sit in that dark corner anymore. Yes, this means that you should also shower, shave, look and speak professionally. It may sound silly, but appearance, demeanor, and communication can make or break your success. It doesn't matter if you're face to face in a board room or using Skype, FaceTime, Google Hangouts, or other conference/video software. This doesn't mean you have to wear a tie, but don't go to a meeting/conference in your pajamas either. Many simply don't realize/recognize that you're a genius, and many wouldn't care regardless. Get over yourself and just try to fit it. Your knowledge and value will shine without effort in most cases. Just put up with the nonsense often delivered from superiors within the company that pretend, but don't actually know a register from a byte, a class from a library, a jpg from a png, a network user from a group, logical && from bitwise &, or DOS from OSX for that matter. Most details that you must explain may be frustrating in communications. Be respectful and accepting of the fact that these people haven't spent the majority of their lives on a computer. Just correct them when they are wrong (in a nice way), ensure they have a basic (condensed summary) of the main vital points that are relevant to time/costs/topic at hand, ensure that the team you're overseeing is producing efficiently, and most importantly, that the final product code will meet the specifications and deadlines without any unexpected/unforeseen issues.
If you find these articles to be helpful, I could always use another cup of coffee! Social media likes/+1s are also much appreciated. Thanks for reading!