As software developers, we're great at communicating with computers. But we're typically not so great at communicating with other people. Esther Schindler's recent interview with Steve McConnell illustrates how this aspect of our personality tends to work against us:
You know, I am a lot more assertive than most technical staff, but even I could stand to be more assertive. I think a lot of it comes from the fact that people who are technically inclined tend not to be the type that are boisterous about our achievements. The ones that really know what they’re doing feel the work should speak for itself. Unfortunately, most people don’t understand what it is we’ve accomplished, so they can’t appreciate it. A lot of it is about having the stones to stand up and say “You really don’t know what I’m talking about, and I’m going to have to insist you take me at face value here.”
One of my first jobs was as the web master for a record label. When I was first starting out, I got a lot of crap dumped in my lap because they knew I could do something, they just didn’t know what. It took me about a year, but I finally realized that they were never going to respect me at my own level. It took the chief of networking to show me how it should be done.
“Figure out the most it would cost you to get your project accomplished,” he advised. “Then double that figure. When they slash it in half, you’re still working within your comfort zone.”
That we’ve had to learn to be sneaky and manipulative of office politics is a shame and it’s a loss for the companies. That company I was mentioning did not last, and it’s only been lately that I’ve even thought of taking on a supervisory capacity (not that it’s being offered).
Well, I agree, techs need to assert themselves… but there also has to be a lot less one-upsmanship in the field as well. It does you no good if you say something and someone with equal respect and authority completely contradicts you. It casts doubt on both parties and works against everyone.
Part of the curriculum of my University’s Computer Science program requires a course on public speaking. It’s the only technical major that requires the course and every CS major hates it. Almost every programmer agrees (after the course is over) that it was incredibly helpful and should be taken by every CS major. Though I’m not sure for the academic benefit or because of the “hey you should suffer too” mentality.
Listen to gangster rap. Those guys are assertive to the point of ridiculousness.
Go ahead, envy me. I’m IT’s MVP and I ain’t goin’ nowhere.
Everyone developer needs this kind of skill badly at their first job! Trying so hard to prove yourself makes you end up putting up with anything that gets thrown in your face!
I had a job that also let me work with the customers. And many times, I found out that the sells department, did not really understand the client needs, because they took care on anything but the installation itself (that I did). So as the same developer that create and installed the software, often the instructions from the sells department was wrong. And many times they keep “forgetting” my instructions on how to give me the right and needed information from the clients.
So I think it’s better off to say that developers communicate in different “language” then sells department, and the point of view of the two groups are very different.
For example I look how something can be done, while sells department look at how they can sell the product. So the sell is about features that usually I require to supply, and many times, there is no real technology to give some of the features that sells often tell the client that we have in the product.
Just another way on how to look at the subject 
I guess you are partly correct when you say that technical people (and programmers mainly) are not assertive enough. I realized that I too suffered from the same problem i.e not standing up in a one-on-one conversation. It’s when I decided that I’ll try to have all my communications with managers and marketing folk through e-mail. With e-mail I can think twice one what I have to say and measure up my “opponents”. E-mail also gives you the power of the Internet so if you are in a discussion, pulling links from the Web or other resources (attachments) really help in the argument.
Nowadays, whenever I’m faced with a “challenge” from an assertive guy I try and take that conversation to e-mail. When it does move to e-mail I usually have it my way.
Supose that a company has a cost-benefit analysis that a project will be profitable if it can be done with X resources, but your calculations show that it will require 2*X resources to complete.
You could recommend that the project be cancelled. If you work on a project that is not profitable it will not do you or the comany any good.
I think that one missing point in these discussions is the dysfunctional nature of many businesses these days. Dysfunctional in a managerial sense.
In many large organizations, playing the career advancement game is far more important than actually producing anything of value. Yes, something does get produced, but its a by-product of the actual activity, almost happening by accident.
You must have experienced such organizations. Regular status meetings (scheduled for a short duration, but degrading into multi-hour affairs); processes where the schedule is more important than the product, and where success is measured by how closely the schedule is followed.
So, what is being negotiated here? Is it the software product, or is it the careers of the managers involved in the product? If its the latter, and you’re trying to negotiate issues related to the former, then, sorry to say, you’re going to loose, no matter how assertive you are.
I hate to be cynical about such matters, but the truth is that things like assertiveness and negotiation are second order effects, and ignoring the first order effects (i.e. the career game) will only lead to frustration and disappointment.
There are only two solutions: play the career game and forgo software development, or leave the dysfunctional organization (voluntarily or otherwise…) and get into an organization where the process is not the product. Sadly, the frequency of occurrence of such organizations is rapidly decreasing
I don’t think you should put too much emphasis on assertiveness. You need to choose your battles very carefully. Two assertive people with opposing views is a confrontation. Influence is more important. Better to listen first then use their arguement against your opponent if need be (while finding something in what they say to agree about). More important I think is to build and maintain good relationships with ‘decision-makers’ and even with those folk you don’t like (difficult I know). The old ploy of making the manager think it was his idea all along works well for me cos I get my opinion heard, his ego is protected and we get the best solution.
Loosing the arguement after you’ve been assertive can be quite demoralizing. And often theres no point in being assertive if the decision’s already been made. You can make your opinion known and after things go t*ts up maybe they’ll listen next time .
If you’re ignored, well, its only a job after all.
If you can’t walk away from a deal then you are not negotiating.
I refuse to estimate any task that will take longer than 3 days. (One of my first interviews was with a company that claimed they got acurate schedules by breaking everything down into 3 day tasks. I didn’t get the job, so I don’t know how it worked, but I stick to that number) For any task, either I can be done in 3 days, or I honestly have no clue. It is the project manager’s job to figure out dates longer than this.
I do however get a priority for all my tasks (and if they don’t give me one I can normally make educated guesses). When they come up to me and say why isn’t it done now, I may be less than half done, but I try to keep things in a state where they can ship as is with just a little polishing, which lets me push back on them: is what we have now enough to sell, or do you want to wait longer for more features.
Of course I’m just a contractor. I’m not asked to play the games full time people are.
+1 for Doug
Although there is plenty of CYA in management, everyone understands they are risking their job in every negotiation.
Too many programmers aren’t prepared to do this:
Prog: This will take 6 months.
Mgr: We need it in 3 months.
Prog: I’ve reviewed the spec carefully and it is a 6 month task.
Mgr: If you can’t do it in 3 months we will find someone who can.
Prog: I can get it done in 3 months!
(Secretly planning to work 80 hours a week)
A year later it’s still not done and the manager is complaining and of course the programmer really is working 80 hour weeks.
A few weeks ago I prepared an estimate for a planned modification of our existing site. Resources were fixed, the scope was fixed. The schedule was assumed to be “short.” When we estimated about a month, my manager asked why. I listed the reasons and that the estimate was based on historical data (the most accurate). He still didn’t understand why it couldn’t be done more quickly, so he told our boss. He had a one-on-one with me. Not fun. I defended the estimate tooth and nail. He finally asked what I needed to get this done quicker, so I asked for more resources.
To my surprise, he said OK. I took on an additional resource and we made it on time. Lessons Learned:
When a developer or team of devs tries to be assertive in an organization where the yes-man mentality is the norm, things can often backfire. For instance, my team was recently asked at the last minute to develop a slew of new products and features in a ridiculously short time frame. Rather than just say “no”, we carefully explained how long each piece of the proposed project would take. We included a time estimate for all the work that was much longer than the short deadline requested, with the idea that they’d either make a more realistic schedule or cut features.
Their response was basically “Oh don’t worry about these features for now. You’re right, you can implement them later.” In the meantime they gave the project to another team, comprised primarily of yes-men, and proceeded to publicly bad mouth my team for having the gall to be assertive and push back against unreasonable requests.
So my point is that while developer assertiveness can be useful in a reasonable organization, being assertive in an organization in which that trait is not valued will only get you into trouble.
In the case presented by observer it would appear that Prog came out ahead in the deal. He is still working on the program a year later.
So, how do you measure the success of a negotiation?
Just as we wouldn’t optimize code without measurement, how can we pick a negotiation strategy without being able to objectively measure the outcome of a negotiation?
My favorite book on negotiating is Getting to Yes; I find its advice helpful in all kinds of situations.
http://www.amazon.com/Getting-Yes-Negotiate-Agreement-Without/dp/0743526937
On being assertive, it may have to do with being introverted vs. extroverted. Software developers are often introverted. That’s how they can stand to sit at their computers for hours on end. Most extroverts could not do that. Managers, especially senior managers, are usually extroverts.
Introverts need time to think and prepare before an important conversation. They often do better writing (as mentioned by ik above) since it gives them time to think.
And Doug nailed it with “If you can’t walk away from a deal then you are not negotiating.”, but sometimes you have to give in initially just to prove them wrong with evidence. Lesson: document everything and don’t commit unless you agree with the terms.
And, my god, don’t overestimate what you can realistically accomplish. Explaining why the schedule slipped again is much worse than fighting for a realistic schedule up front.
Doug Ferguson said “how do you measure the success of a negotiation?” It depends on what you’re negotiating for. Schedule, cost, quality, pay increase, workload, etc. can be quantified and measured. Managerial support, leadership, sensitivity, communication, playing fair, good relationships, etc. are harder. Sometimes successful negotiation is only realized in hindsight - long after completion.
I see two issues. Firstly is the “can do” approach valued (and practiced) by many managers. Overselling in the geek world leads to pointing and laughing, bu8t in manglement it seems to lead to promotion.
Secondly is the way language is used. Geeks, as with most technical people, deal with a lot of binary value - stuff either compiles or not. So they are usually conservative and cautious about what they promise. It’s hard to convince the compiler to complete a build despite syntax errors.
On the flip side, hearing a geek try to persuade management that they should allow its favourite project to proceed gives the lie to everything I’ve written