Assertiveness for Software Developers

An 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.

In 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.

The 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

How 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? :wink:

If 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.


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.

I 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.

Sometimes 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.

It’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 :wink:

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 ;).

I 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.

@kevinl 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_21 – 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_Brams – 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.

I 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?

This 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.