programming and human factors
by Jeff Atwood
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:
Marketers, sales staff, and upper management all tend to be better negotiators than technical staff, so when marketing (or whoever) says "get it done," technical staff ends up losing that negotiation. But it isn't really the technical staff that loses. The business loses, because it sets up a situation in which it pretends for months or years that it can do something that it can't.
We present our best estimates, but we aren't assertive enough to stand up for them.
Because we don't fight for our estimates, we get negotiated down to an untenable position:
Executives and managers tend by nature to be more assertive than rank-and-file technical staff, which is not a problem. The problem is that they assume, incorrectly, that technical staff will be assertive with them if they need to be, and that isn't the case. Technical staff often feel that they're being very assertive, but an objective observer would probably say the technical people cave in far too easily.Business executives with non-technical backgrounds don't have any objective ability to judge the analytical validity of an estimate, so they probe the person they're talking with to see where they hit that person's point of discomfort, and they make an assessment based on that. Technical people who don't push back hard enough, soon enough, are implicitly sending a message that they can do more than they really can. When I talk with executives, I emphasize that they need to account for the fact that technical people are intimidated by them. Most executives assume the people around them are as assertive as they are, but that isn't true-- there's a reason that they're executives!
Assertiveness doesn't have to mean loudmouthed and obnoxious. Nor is assertiveness "getting all up in someone's face". Assertiveness is, quite simply, the ability to convey your position to others as an equal participant in the conversation. Dr. John Welford explains:
To be assertive is not, as some people imagine, to be overbearing and aggressive, but to be straightforward, open and honest. It means that you relate well to people, able to express your needs freely, take responsibility for your feelings and stand up for yourself when necessary. In conflict situations you seek, where possible, to reach a 'win-win' outcome, in which the needs of all parties are fully acknowledged.
I'm reasonably assertive, to the point that I've found myself interceding on behalf of my teammates. But I really shouldn't do that. I should encourage them to stick up for themselves, instead.
If you'd like to be more assertive, I recommend starting with Dale Carnegie's classic book How to Win Friends and Influence People. Dale's central thesis is truly timeless: show a genuine interest in the people you meet, and you'll find it reciprocated tenfold. It's the kind of book you should re-read every year, and it's short enough to make that possible.
Beyond the Carnegie book, it's clear that being technologically savvy isn't enough. It's important to cultivate your negotiation skills and assertiveness, too, if for no other reason than to avoid being easy meat at your next salary review. One of my friends took the initiative to sign up for a public speaking class. Improv classes would also work.
What are you doing to improve your assertiveness?
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.
Jae on December 23, 2006 5:46 AMPart 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.
David Sokol on December 23, 2006 6:42 AMListen 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.
Eam on December 23, 2006 7:19 AMEveryone 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!
AL on December 23, 2006 10:15 AMI 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 :)
ik on December 23, 2006 11:24 AMI 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. :)
Toufeeq Hussain on December 24, 2006 2:10 AMSupose 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.
Doug Ferguson on December 24, 2006 2:15 AMI 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
km on December 24, 2006 4:34 AMI 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.
ar on December 24, 2006 6:41 AMIf you can't walk away from a deal then you are not negotiating.
Doug on December 24, 2006 7:48 AMI 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.
Henry Miller on December 24, 2006 8:05 AM+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:
1. Make your estimate with the constraints in mind.
2. State how you can shorten the schedule, e.g. more people, less scope, etc.
3. Stand by your team's estimate.
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.
anonymous on December 24, 2006 10:13 AMIn 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.
Carl Manaster on December 24, 2006 11:09 AMOn 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.
isabelle on December 24, 2006 11:58 AMI 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 :)
Moz on December 24, 2006 12:03 PMAn excellent topic with some excellent suggestions, but you kind of assume that developers are geeks and therefore are push overs. I am not a geek nor a push over. If a fence builder can stand by his estimate surely so will I.
Besides reading several of Carnegie's books I was fortunate enough to attend public speaking classes by Carnegie certified instructors. Without a doubt, public speaking is an invaluable confidence builder, regardless of one's vocation.
Just because you are a developer does not mean that you have to be a geek or a whimp.
"Listen to gangster rap. Those guys are assertive to the point of ridiculousness."
That's what Michael Bolton (Office Space character, not singer) did. It didn't seem to help, except in his own mind.
bitwize on December 24, 2006 12:21 PMIn general, I do believe that developers don't exploit the right rewards and in fact is due to their poor communication skills. Management takes most of the benefit.
listin on December 24, 2006 12:43 PMThe whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts.
Bertrand Russell
Moz on December 25, 2006 1:45 AMHow can I "show a genuine interest in the people I meet" when sometimes, I really don't care at all about them? Especially when the meeting was not my choice? Is the answer in the book? ;-)
Joe on December 25, 2006 3:57 AMIf you can't walk away from a deal then you are not negotiating.
And, of course, that's the point. The PHBs are giving orders (that's what they've assigned themselves to be: The Decider). The Tech Staff is merely there to Carry Them Out. If you sense that I'm making a metaphor from a larger socio-political arena; wellll yes. The same failing is exhibited. The Deciders, natch, know that the failing is in The Tech Staff to Carry Out any Lawful Order. And all Orders are Lawful.
If it were the case that The Deciders had any interest in reaching a mutually beneficial decision (i.e. a Negotiation), then argument (in the sense the word is used in debate/negotiation) would be possible. But the decision isn't intend for mutual benefit.
etc.
Doug Ferguson said "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."
Ask management some questions:
--Why do you think the project can be successfully completed with x resources? What is your basis for that determination?
--Are you willing for the project to take twice as long if we only use x resources?
--Are you sure my resources estimates are wrong?
--Do you remember projects a, b and c at our company that went way over budget because initial resources estimates were too low? Why do you think this project is different?
--Based on your cost analysis, I think it's possible this project won't be profitable. Are you sure you want go ahead with it anyway?
--Are there other options that we haven't considered for getting the project successfully completed?
Bottom line: get them to convince you that they're making a good decision.
Btw, I agree with buggyfunbunny. They don't care about mutual decision making. They do, however, usually care about looking foolish. If you ask provocative questions, sometimes they can see the lack of logic in their thinking before it's too late.
As a former CTO/architect who believed he WAS being assertive enough, I've come to believe that assertiveness is really only half of the equation here. Programming is, in all too many cases, the process of innovation by schedule - you will create a completely novel solution by the 1st of December, regardless of whether or not such a solution has ever been completed before, whether you have the technical skills in-house or available by contract to produce it, or whether or not not you even have all of the (non-programming) resources (such as critical data contracts) that are necessary by then.
Such requirements are frequently driven by factors that have nothing to do with the technical issues involved: the client has only so much money involved, and in order to get sale, the sales team have promised far more than the programming team can deliver on, as one example, or the managers need to have a functional application by a given date because only if they have it will they be able to meet a funding deadline by the investors. One client of mine in particular refused to even look at wireframes of a web-based application until a week before the product was supposed to be finished, then panicked when they realized that what they had loosely set out in their requirements were in fact being implemented according to what was written, not what was desired.
What many programmers don't realize is that what, to them, is a straightforward process is to most of those A-type personalities little short of magic. The typical marketing or sales VP can't understand what's going on at the technical level beyond what they are told, and to add insult to injury, many senior marketing or sales executives also believe that they do understand this, meaning that what gets sold to clients is typically not only not feasible within a given timeframe but not feasible within ANY given timeframe. Again a prime example of this in a company I worked for was a senior sales VP who nearly sold a number of clients on the fact that we could create generalized publishing solutions for any of their work that would scan existing content from hard copy sources and then generate, automagically, the properly formatted output in XML with full contextual support. Given that this remains one of the single hardest nuts to crack in publishing, this venture would have basically ended up committing every single programmer at the company to a life of perdition before they put in their resumes.
This also plays into another facet of the programmer personality. Young programmers (the ones most likely to end up bearing the brunt of these decisions) are eager to prove that they are capable of doing pretty much anything as much for the personal prestige as anything, so in general they will likely be the last to admit that what is being presented cannot be done BY them. Programmers can be as assertive as anyone when it comes to that alpha-geek competitiveness, but admitting that something can't be done involves an embarassing loss of face (and quite possibly a loss of job) if some other programmer cuts them off and says that it can be done within the constraints provided, even if it's just posturing.
A similar situation can arise through simple miscommunication - programmers tend to be far more exact in their definitions than non-programmers because they have to be ... they are often the ones writing the definitions in the first place. Thus, when a non-techie manager (one who controls your paycheck) asks whether its possible to do something, what they are asking is whether its possible to do that something within the budget, time, and amorphous requirements that are floating around at the time, often with themselves having only a vague idea about what these are. The programmer, on the other hand, will parse this as - does the technology exist (or can it be created) to perform a given task, and then will generally answer in the affirmative because they know that most problems are ultimately soluble, given the right resources.
Finally (and related to this), when a manager is asking for an evaluation of a technology (up to and including a timeline) typically that manager is wanting a definitive answer - yes or no by this date- so that he can go back and report this back to his boss/investors/board.
The programmer on the other hand will most likely end up seeing most software projects as being distribution curves with varying degrees of deviancy from the norm, with a given date being that point which, given normal fault tolerances in estimates, can provide a probability of say 80% that the project will be completed by, with variances that may be as much as 100% of that estimate.
When the programmer goes back to the manager, the manager perceives this as equivocation, and typically reacts angrily to it (in my experience), often to the point of trying to get the programmer to nail down on a specific date. If the programmer is being honest, the date will not be acceptable to the manager, who is of course being pressured to get this project done under budget and in the time frame so outlined, who will in turn pressure the programmer to give earlier estimates.
Since those estimates are fuzzy at best anyway, the programmer is often then forced to compromise on an earlier date with a lower degree of confidence, and later becomes the one to bear the brunt of the fallout near the end of the project when it in fact DOES come in closer to the initial estimates (the manager typically escapes, of course - they can point to their programmers and say that the estimates they gave were off, and that's what I based my estimates on).
The best tool that a programmer has to prevent this is personal email notes to themselves documenting every transaction, every request for estimates, and every change request. It takes some work from the actual day to day programming to document this, but typically in the long run it not only serves to keep the programmer on track but also provides material for an audit trail to show why such estimates were made in the first place. This is not to say that managers are malicious and determined to ruin the lives of programmers - most are just trying to get the job done themselves - but it can serve as a way of insuring that incompetent, grandstanding or malicious managers aren't promoted up into higher levels of authority and can also make wrongful termination suits and breach of contract far easier to prove or disprove.
Kurt Cagle on December 26, 2006 1:39 AMI feel I am assertive, but 6 years in the US Marines will do that to a person.
As far as negotiations go, how often are programmers interacting with upper management? For my company with 10K employees world wide. Normally our small staff gets projects handed to them by supervisors, who got them from managers who go tthem from directors, .... All those levels going from suits down to promoted technical people (my director and manager are both hardware engineers that were promoted).
My point is most of us take orders from technical people that may not have an assertive nature, and we have no control over the entire negotiation process. My assertiveness is taken out the picture.
I was going to quote from Mr. Cagle, but kept finding more, so just mentally drop it in here: show of hands for those who've experienced having to create a system to duplicate a PowerPoint deck created by the salesmen. Who never talked to you while they were PPT-ing.
buggyfunbunny on December 26, 2006 7:21 AMSometimes your blog is right on, and sometimes it's so far off the mark I can't believe it.
It's almost never the case that marketing and development are sitting in a room arguing about how long it will take to make it and the wimpy devs are unable to hold to their guns in the face of the marketers' superior negotiation skills.
No, the way it works is that the business analysts say "the right time to launch is N months from now" and the marketers say "our studies show it has to do X, Y, and Z to succeed" and some of the technical staff say "X can't be done and it'll take us 2*N months to do Y and Z" while another faction of the technical staff say "it'll take us N/2 months to do X, Y, and Z and while we're at it P and Q too" and so on and so on. The decision-makers have to try to make sense of all these contradictory statements, most of it wrong in some aspects and backed up by the barest of facts, and try to make the right choices for the market that won't exist for another N months.
In my experience, developers are often too loudmouthed and aggressive. So sure, being "straightforward, open and honest" is a good first step. But just because you're sure you're right and can present your case well doesn't mean you really are right. For developers, focusing on broadening your understanding of the big picture and obtaining just a shred of humility would be a better use of your time than focusing on assertivess.
[a young girl with impossibly long pigtails bursts in]
Dale Carnegie is good, but many people need stronger medicine.
They don't get it from today's psychiatric profession. You get diagnosed with "anxiety" or "depression", maybe get some meds or cognitive therapy. You might feel better, but you don't face your real issues.
Psychoanalysis, on the other hand, is all about the relationship that people have to other people, in particular, to people in authority, and to people you have authority over. As a child, you had to deal with the authority that your parents had over you, and learned coping strategies (effective or not) that you still use today.
HMOs don't pay for psychoanalysis. It takes too long and digs too deep. Skills-based training (see the book "When I say no, I feel guilty") can help, but a prolonged effort of self-analysis and inner growth is required for people who have particular difficulties in assertiveness.
A friend of mine had problems with (a lack of) self-assertion that got him kicked out of school in the sixth grade. More recently he lost a job because he was bullied by his boss: after months of abuse, he delivered a software upgrade that he knew wouldn't be ready. The consequences on his organization were severe: six people left the organization after the project failure, including his boss, his boss's boss, and the director of the organization.
He realized two things as a result of the failure: he couldn't take management for granted, and he'd have to do something about his problems with self-assertiveness.
He's found that the work of Ken Keyes ("Handbook to Higher Conciousness" and "Your Roadmap to Lifelong Happiness") were useful for him in reprogramming his brain's software, and reducing the impact that anxiety has on his life. Yes, Ken can be saccarine at times, but his work is based on sound psychology.
Karen Horney is probably the best writer on practical psychoanalysis: "Our Inner Conflicts", "The Neurotic Personality of Our Time" and "Self-Analysis" are worthwhile.
Steven Covey's "7 Habits of Effective People" is a roadmap to getting your act together -- how to be a real winner. "The Eighth Habit" is a philosophy of the politics of everyday life; "Find your voice and help other people find theirs" -- the world would be quite different if people thought this way in their work and family lives.
I wonder if some techies who have trouble being assertive have some form of Social Anxiety - a real illness that can be helped with medication. Don't get me wrong here. I'm not the type of person who says we need to pop a pill for every little problem, but there are people who are completely unable to cope with their being intimidated by people. They can't use will power to "snap out of it" in the same way that a person with the flu can't "snap out of" being sick.
DaveH on December 26, 2006 9:08 AMIt's one thing to be assertive when you know that you are right; it's another thing to be assertive when you know how much uncertainty is included in your estimate, and that the person challenging you might in fact turn out to be right after all.
Interestingly, when we're hiring for techies, I often find what could be the reverse: Techies are far too willing to bignote their experience and abilities, past what they can reasonably achieve.
Probably the best example is database experience ("yes I understand SQL", "So, you're familiar with left joins, stored procedures, normalisation...?", "uh, well, yeah, sure" - only to find that "understand SQL" means they worked on a single-table database once via PHP). The same applies to languages known, networking experience - most often the places where techies are weakest in actual understanding they'll claim familiarity because they think it'll make them look better, or because they truly don't understand the complexity and think they can bluff it.
This carries over into alpha geeking - that fun little game that techies play between themselves to try and look more knowledgeable than the next person.
My partner believes this is one of the reasons there's more guys in IT than women - she's much less willing to blow her own trumpet, or get involved in the "I know more about that than you do" wars, thus often gets overlooked, but is actually far more competent in her field than many others I know. That may be an aside, I'm not sure ;)
Fundamentally, though, I'm not sure it's a lack of assertiveness that's at the heart of the problem. I think techies are too willing to try and come across as clever/capable, and for them that means being able to say "yes, I can do that", whether they really know or not. They're also too likely to make exactly the same mistake we point our fingers at sales over - giving estimates or promises without really understanding the complexity of the problem. I've seen enough people burn themselves out trying to complete a task they said they'd do, because they simply didn't understand the problem sufficiently, that I don't believe it's assertiveness at the heart of the issue. Not always, anyway.
We do estimates with cards, similar to the XP approach but just within our group - so the projman and all the dev team agree on how much effort's involved in each piece. The number of times I've seen devs estimate low because they don't really grok what's involved in a particular piece of work is astounding - it's why the old "estimate then double" rules of thumb float around, in part. The typical conversation is something like "how long will it take", "about 2 days", "including the web pages, docco, and unit tests", "ummmm.... maybe a bit longer?". This isn't lack of assertiveness. Incidentally, that's still a common failing of mine, it's why we do all our estimates in at least pairs, so people can cross-check each other's thoughts ;).
KevinL on December 27, 2006 6:45 AMI think the conflict between dev and business units will always exist due to the way they get paid. Upper managemnt feels the benefits and loses much more that labours (dev staff), since performance is tightly coupled to their pay. And everyone, even buddist monks, want more money. Managment always wants more, they are like greedy, spoilt children, and they know they can get more by pressing dev to produce. I think its a rare company that has decent upper management.
To me assertiveness is courage to speak what I believe knowing that I will face competition and challenge coupled with courage to be humilated in a group of peers (weather I'm wrong or right). And really if you've been as wrong as many times as I have its not that big a deal to be assertive, but now know I at least know when to speak and when not to speak.
Observer.2 on December 27, 2006 6:52 AMKevinL -- you've got good insight, but it's not contradictory with what I'm saying. People who have problems with self-assertion also have problems with self-image. For instance, somebody who is worried about losing their job might try to cover up their anxiety by puffing up their technical skills. Deep inside they feel worthless and unlikable, so they make a big effort to impress people with their skills.
Observer.2 -- Top management is right to want to make a profit. On the other hand, they can wreck their companies and their careers by overpromising and underdelivering. Yes, they might benefit by intimidating some technical people into not taking their vacation time, but they aren't going to get what they want by creating a culture of fear that leads to project failures.
Dylan -- Assertiveness isn't an extreme behavior, so it doesn't need to be "moderated". If the first thing you do is point at people and say that "I will punish you", you're being aggressive, not assertive.
Assertive people balance their needs against those of other people -- they realize that they may have to give something here to get something that's really important to them there. Assertiveness is about effectively getting your needs met, and it overlaps with other communication skills.
I guess "jump around on the conference room table and squeal like a marketeer" is good advice if you plan to stay in a sick organization much longer, but in my universe, when management can't grasp a calm "you can't have that product this quarter unless you'd like it to be crap" it's time to look for another job.
kokorozashi on December 27, 2006 7:29 AMI can only say one thing. At any point of time, try to do what is right. Some times it is right to keep quite without stressing too much on your own opinions. On the other hand there might as well be instances when you need to stick to your point no matter what. Being assertive, being confident in ones decisions, being strong in ones own point of view whatever it is called has to do with ones regular habits of choosing the right things to do no matter what may come to disturb us. I have seen some instances where my colleagues are called for being more assertive in similar situations what I have gone through, while I have never even faced with that question (of being assertive). I my case it completely bypassed me and got taken care automatically. My point is when we have that regular habits of right living and doing what we ought to do, it makes it easy to be assertive. Otherwise it would be difficult, no matter you are an executive or anyone else. I am making sense to someone out there?
Venkatesh on December 27, 2006 9:31 AMThis is, by far, my favorite:
Executive: We need this done by Q2 for $X.
Developer: That's not humanly possible, even for $X * 4 and by Q4.
Executive: Well, we had a [covert] meeting with the CEO [tech was not invited] and he said we had to do it.
Always a classic.
JimmyC on December 27, 2006 10:14 AMAssertiveness and negotiation have to be moderated. The problem is not wholly with programmers; it's also a problem with the management in question. In a pragmatic sense, programmers are generally given heavy pressure to produce the impossible ahead of schedule and under-budget. Being assertive and being educational are two completely different things; often you need to tell people what exactly is involved in a general sense.
The thing many programmers tend to forget is that effective communication is as important a skill as effective problem solving; applying the same method to a problem with talking to someone as you would (generally) to a programming problem will sometimes result in a worthwhile result. This means effort, time, and reworking your own thought pretty extensively. Traditionally, many people have thought that ability to create, extend, and apply metaphors is a good measure of intelligence. I do not believe this is completely true, but I certainly believe that if you are capable of creating effective metaphors for what you are doing and where the effort comes from, you will be more successful in describing and explaining your own viewpoint. And if you are successful enough in how you describe a particular problem, that description will make its way up the chain. Unfortunately, as the 'plant' of your explanation goes up the chain more and more people will try to trim it. Which is unfortunate, because often they start trimming at the trunk. But with enough explanation in enough visual words, communication can be achieved.
That so few people are capable of really understanding how to do this is a big part of why software is so hard, organizationally, for people to achieve.
Dylan Brams on December 27, 2006 12:46 PMMany executives came up from the rank and file in 'Sales'.
Sales people share the following traits:
Aggressivness
Buy low
Sell high
Driven to succeed.
Aggressiveness: They have to be that way in order to survice the 'sales game'.
Buy Low: Sales people always want to supplier or product to cost them less.
Sell High: Sales people want to get the most for the product because it increases their commission.
Driven to succeed: Your either a successful sales person or your out.
Of these the Buy Low mentality is the biggest problem. Sales people can't seem to get it through their heads that it takes a certain amount of cost (i.e. time, money, tools, etc.) to achieve the end result. They are constantly looking for ways to lower the front-end costs and if bullying some poor developer into an un-realistic estimate is what it takes then oh-well, as long as it looks good on the supply side of the numbers they don't care...
I think some of the problem with gaining assertiveness at work is the power structure that the lowbies must clear through before even getting heard. Programmers report to senior programmers or team leads, who report to analysts, who finally talk to the boss, who may/may not bring ideas to the management meeting. (insert additional levels of abstraction where applicable.)
Trying to circumvent the chain of command will get you chastised for not going through the channels; or if you are actually heard, you are extra nervous because of the hierarchy itself.
I read some of that book awhile back. Though most of it I assumed would never work because the book was really old.
I just do what I am told and if I can't do something or it's not part of my job I'll give them a flat out no. And then I'll explain to them calmly why I can't do it and what's part of my job. If it's someone who has no place to say it'll be a flat out no with no explaination.
I think I might read that book now that I saw it helped someone... When I read some of it I thought it was one of those books that was some funky fad and I just treated it like a joke.
clueless_furball on December 28, 2006 11:26 AMThis is one of the favorite of many books I have read on software development. It discusses things you can do to motivate teams, meet deadlines, and determine when you aren't meeting your deadlines. It is sprinkled with interesting antecdotes from the authors career at microsoft. It is called 'debugging the development process'
http://www.amazon.com/Debugging-Development-Process-Practical-Strategies/dp/1556156502
steve souza on December 29, 2006 2:40 AMOne thing your article doesn't take into account is that marketing, finance, and upper management are internal IT's customers. So no matter how strongly we believe our position is on a given subject, at the end of the day, all we can do is advise our customers the best way to do something and then do exactly what they tell us to do. Any other course of action will result in you needing to look for another job.
At the end of the day, all I can do is be honest and straight forward with my customers and then allow them to make the decision that they have to live with. It's just like being a parent.
Sean---
Cheap, Fast, Good - Pick any 2
Sean Burgess on December 29, 2006 6:07 AMbr
waleed on December 24, 2007 6:08 AMAt my old job, we had a plaque with the saying (which you've probably heard), "We do three types of projects here: Good Projects, Fast Projects, and Cheap Projects. When making your Application request, pick 2."
This obvious, yet profound, truth has helped us in the "assertiveness" factor with our projects. We used to be a "yes man" type house because the IT director blindly forced us into them until a few backfired. Now we can show them that "Sure we can do that project in a month for you, but the UI will be minimal and you run the chance at data issues. Oh, we won't be able to convert that data for you either. If you want it in a month, then we suggest purchasing product X for Y bucks and we'll maintain it from there since it meets all our standards for software we have the staff to support."
The thing I try to remember is that without asserting my skills and knowledge to a new project, I risk bringing the whole house down should the project fail. This became extremely important and increasingly painful during our identity management project when I pointed out that the initial 6 month deadline wouldn't fly because the data between the three disparate systems was so mangled and the solution we were tasked to provide was going to be a robust and stable solution instead of the plethora of LDAP hack jobs already out in the environment.
Great article, I hope others will learn as I have through "the trials" that being assertive doesn't mean that you "geek down" the managers, but you help them realize the technical angles that will make the solution a success.
Sorry, I'll get off my soapbox now 8^D
Sean Patterson on February 6, 2010 9:51 PMJeff,
I have a question for you concerning being assertive with clients on estimates, requirements and such. 9 times out of 10 every estimate I make requirement I state gets trimmed down to something that is so minimal that it is no longer near what the client stated that they wanted or in regards to estimates that it ends up being overshot due to the little things that usually happen, which was calculated in the original estimate. The question that I have is how can you be assertive and push for what you know/feel is correct when you run into situations where everything is micromanaged and comes down to trying to make the client happy by keeping the cost down? Also I apologize if it is a bit confusing my mind is going all over today.
Brandon
Brandon on February 6, 2010 9:51 PMThe comments to this entry are closed.
Subscribe in a reader
Subscribe via email
|
|
Traffic Stats |