Chapter 3. Chances Are, Your Biggest Problem Isn’t Technical
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-bar cleaner. He is passionate about making tools that help professional and amateur programmers more productive.
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 over Java, or Python over Smalltalk? Or because they decided to use Postgres rather than Oracle? Or did they choose Windows when they should have chosen Linux? We’ve all seen technology take the fall for failed projects. But what are the chances that the problem was really so difficult to solve that Java wasn’t up the the task?
Most projects are built by people, and those people are the foundation for success and failure. So, it pays to think about what it takes to help make those people successful.
Equally, there’s a good chance that there’s someone who you think is “just not doing it right” and is undermining the project. In these cases, the technology you need to solve your problem is very old and well established indeed; in fact, it’s possibly the most important technical innovation in the history of humanity. What you 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, is one of the core skills that turn 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 an opportunity to ask questions, you definitely learn more, and are less likely to put people on the defensive.
Approach these conversations only after you’ve got your attitude right.
If you’re angry, frustrated, annoyed, or otherwise flustered, it’s very likely that the other person will interpret your nonverbals as an indication that you’re on the attack.
Use these as opportunities to set mutually agreed-upon goals.
Instead of telling a developer that they need to be quiet in meetings because they never let anybody speak, ask if they can help you increase other people’s participation. Explain that some people are 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 shared purpose, treat people “problems” as an opportunity to learn, and manage your own emotions, you’ll not only become more effective, you’ll also discover that you learn something every time.