Assertiveness 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.
Many 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.
This 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’
One 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.
At 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.
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.