Chances Are,your biggest problem Isn ' t Technical

?

Chances Are,your biggest problem Isn ' t Technical

Mark Ramm

Right now SoMEonE's Running a failing project to build a payroll system. Probably more than one someone.
Why? Was it because they chose Ruby + Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should has chosen Linux? We ' ve all seen technology take the fall for failed projects. But what is the chances that the problem is really so difficult to solve that Java wasn ' t up the the task?
Most projects is built by people, and those people is the foundation for suc-cess and failure. So, it pays to think on what the it takes to help make those people successful.
Equally, there's a good chance that there's someone who's think is "just isn't doing it right" and is undermining the Proj Ect. In these cases, the technology are need to solve your problem are very old and well established indeed; In fact, it's possibly the most important technical innovation in the history of humanity. What's need is a conversation.
Mere familiarity with the conversation as a technology isn ' t enough. Learning to treat people with respect, and learning give them the benefit of the doubt, are one of the core skills that Tur N A smart architect into an effective one.
There ' s lots more to it than this, but a couple of small tips can significantly increase your conversational effectiveness :
????
Approach these events as conversations-not as confrontations.
If you assume the best about people and treat this situation as a opportu-nity to ask questions, you definitely learn mo Re, and is less likely to put people on the defensive.
?
??? Approach these conversations only after your ' ve got your attitude right.
If you ' re angry, frustrated, annoyed, or otherwise flustered, it's very likely that the other person would interpret your n Onverbals as an indication so you ' re on the attack.
? Use these as opportunities to set mutually agreed-upon goals.
Instead of telling a developer that they need to being quiet in meetings because they never let anybody speak, ask if they CA n Help your increase other peo-ple ' s participation. Explain that some people is more introverted and need longer silences before they enter into a conversation, and ask the Developer to help you out by waiting five seconds before jumping in.
If you start with a gkfx purpose, treat people "problems" as an opportunity to learn, and manage your own-emotions, you ' ll not be become more effec-tive, and you'll also discover that you learn something every time.
Mark Ramm is BDFL for TurboGears 2, a Python enthusiast, and a generally crazy dude. He ' s done nearly every job imaginable from software architect to network administrator to lobster-trap Thrower and Biker-b AR cleaner. He is pas-sionate about making tools, the help professional, and amateur programmers more productive.

Chances Are,your biggest problem Isn ' t Technical