Tips for Managers of Developers
I Already Feel Sorry For You
by D1J1T — in Management — Updated: Mar 4, 2014 at 9:37 am
You've been tasked with overseeing the development division
of your expanding company. How do you even begin if you aren't
a developer? (Please pardon the stereotypes, but) many programmers
and developers are often... well... different.
They may be extremely introverted to the point of being anti-social sometimes.
They speak odd languages full of acronyms, and they make jokes amongst themselves
that only they "get" or that are somehow encrypted in their most current, favorite
form of piglatin nonsense that only a select few of them comprehend. They even
enjoy taunting you with random programming or tech specific jibberish that they already know
you don't understand. This is done just to be able to have the spotlight for a second, brag about their skills,
rub in your face these details that you don't know, frustrate you, and waste your time.
(The whole time, you patiently listen, holding back the urge
to scream "I DON'T CARE ABOUT ANY OF THIS UNIX SHELL SSH SOFTWARE $H1t !?!?!")
Worst of all, you simply can't relate to them at all on a personal or social level.
When asked socially what their favorite football team is, they awkwardly
state to everyone "I don't watch football." Then they quickly walk away,
to their dork club in the corner whom are all currently either discussing their
odd obsessions with things like comic book superheroes, Dungeons & Dragons,
and Buffy the Vampire Slayer. OR they are just bragging about and comparing their geekdom:
"I can write that function in 5 lines, and not even use that library" or "I saw John using design (instead of code)
view and even referencing simple String library functions the other day!" or "Microsoft
is the most evil." "No, Google is." "What? How can you say that? MS....... Google......." ...
but Apple .... "So what, Flash...." ... Doesn't matter, with X you can .... "You're not
considering the limitation of ..." Well with the new Y spec, you can ... "Right, but that
doesn't support Z, not to mention, Xa doesn't work with Tg and to include Hw, you have to use DZ. Jp version R is the worst!"
Why are developers often difficult to work with?
Being one of these crazy programmers, while also having experienced working in multiple environment types, and being placed in management and training roles, I can certainly relate to frustration on both sides.As a manager, you are concerned with quality, costs, and time factors involved for development. You have to report time lines, statistics and costs to owners/upper management, not to mention please and coordinate with clients regularly. You could probably care less about specific hex values, the fact that "this function returns a string," that "this audio file is stereo, 32bit, 44.1kHz" or that "that graphic is a transparent, flattened, png file" or that "the text embedded in the app stretches below the available space for browser version X." This is understandable; your job is not to program and to have to worry about all of these specifics, rather to ensure that the job is done well and within budget.
Understand however that these details ARE the developer's job. If they are wise, they have in the back of their mind, and must constantly factor in budgets, deadlines, estimates, quality, speed, efficiency, all while focusing on ironing out many details, fixing bugs, development and other issues (perhaps previously unknown to them), that arise while working on producing the best quality software product. They should know that they must please not only management, but also clients, and must produce the final product within a time/cost budget and to specification. Details are sometimes, many times actually, major or vital factors in making vital time/cost decisions. The developer will let you know when these arise. It is a manager's job to know when the developer is informing them of a serious issue and not just bragging about their most recent awesome function. It is also the developer's job. They must communicate this clearly.
Finding this middle ground where only necessary specifics are communicated can be extremely difficult for both management and developers. It can also cause serious time delays, unnecessary replication/creation of work, missed deadlines, extra company costs incurred, and added stress/frustration for all parties involved in the project.
The Importance of Communication Between Management & Development
While you're thinking, "Why is this guy telling me about proper database structure and the use of AJAX in our app?" The programmer may be thinking, "Why won't she listen to what I'm telling her?" or "How else can I better explain this fact?" or "Doesn't she realize I'm trying to save time and money?" or "I'm giving her options, why won't she tell me what she wants specifically?" or worse yet, "This person should not be managing me and knows nothing about this technology."And of course, you may not! Why would you hire him or her if you could do what he or she is doing? How do you translate developer "jibberish" in order to make the most effective management decisions? How do you establish a working relationship with an introverted, perhaps even arrogant, programming geek that just happens to have a specific skill set that you don't?
To be blunt, while also acknowledging that I'm probably a tad biased on the programmer side, you can't do so efficiently without having at least a basic understanding of the technologies involved. If this is the case, the best advice I can give is twofold:
1. Redirect the developer when she starts giving unnecessary specifics, unless your sense is that they are conveying something vital/major that may effect the scope, time, or cost of the project.
2. Admit directly and without pause that you don't understand, if you don't. (Remember, it's his or her job to know these specifics, not yours. Direct the developer to get to the major point/factor as quickly as he or she can. Keep in mind that this may be difficult, depending on the technology, and also your knowledge level of it.) Still, force a quick explanation that makes sense to you. Being honest, you'll more than likely gain more respect. This will also give them a stronger sense of value within the company and save time/money for the company. Finally, your honesty will allow the developer to enhance her technical communication skills, and maybe even gain a better technical understanding of the programming language(s) or technolog(ies) involved in the project. Pretending to know information that you don't or the lack of proper communication on the programmer's behalf, can be detrimental in countless ways.
3. Learn at least the basics of the software/project the programmers are working on. Don't just use buzzwords. These work well in sales, but a skilled developer will see through that ruse instantly and will shun you for attempting it. You are the manager. They know it. You don't have to try to prove your value as it's implied already with your job title/position. At the same time, you don't have to be a web developer to know that HTML5 is the latest version of the language for example, and that it has a groundbreaking new tag: <canvas>. Get an overview of the technolog(ies) to be able to communicate on the most basic level, then ask them for any necessary specifics that you may need at the given time. Again, admit that you aren't an expert in the language, but also redirect them when necessary or when they are getting in depth to the point where you begin to get "lost." Most developers that are passionate about their skills will jump at the chance to let you know all the details. It is important to be able to filter out the "jibberish" from the important factors they are attempting to convey. You may only need <0.3% of what they are telling you, though keep in mind, both: a) that much of what they are working can be complex, and b) they may be offering certain specifics not to brag, but rather to give you a better understanding of the system(s) and maybe even in fear of repercussions from not informing you well enough in order for you to make the best decision for the company. (Of course, they could just be bragging. Ask them directly to explain how the details they are currently providing are related to the current question/issue. They'll tell you if it's not. But if they begin to answer and provide an explanation, it is probably in your best interest to listen for a while, despite how boring... Yes, take notes even.) I have personally experienced situations where managers have been told certain details, ignored/forgot them, and then came back to bite the company. Ignore any boasting, filter what you don't need, but also listen and learn what is necessary.
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!