Technologists have an incredible advantage in problem solving because they can actually “do” much of the work to solve a problem whereas many higher level problem solvers have become distanced from the technology. At least that’s what I thought at times. But really, no matter what your “level” you must learn to use the resources you have effectively.

Resources means much more than your own skill set or the constraints of budget and your time. It’s also about who you know and how you can effectively relate to them.

In considering a large-scale scale out problem recently, I thought about how my approach has changed over the past few years. My old approach was to jump in, learn as much as possible as quickly as possible, and start working on a solution. Leadership is still a big component of that approach, but it is very self-directed. I became more sophisticated in my approach as I developed skills in tools like virtualization to become more efficient and remove the barriers of time and space…but it remained a very individualist approach.

Contrast that to how I approached a more recent problem…I started thinking of who I could call. I emailed some people I know who I know have considered similar challenges recently. I searched the blogosphere–not just for product material and white papers, but for great sites like HighScalability and this blog by Nati Shalom and this article on scaling out mysql.

Anyone can google “scaling out mysql for performance” and find a ton of articles, but that is only a starting point. The next step is to consider how to use ALL your resources to solve the problem. My colleagues who have been there before can help me vet the product recommendations and tell me their implementation war stories. The awesome-sounding white-paper solution may be great…if you can re-engineer your application first. High-level howtos can turn into a million unanticipated detours that waste everyone’s time. If we were to start looking at solutions like GigaSpaces or Amazon E2, then I need to quickly be talking to the development team to understand what I might be signing them up for. And, of course, we have to assess our current state of affairs anyway and do the basic performance tuning, documentation, and process standardization things we can to “get control” over the day-to-day environment before embarking on an ambitious project.

Monitoring is absolutely essential. Do we even know whether our current systems are about to break or not? How do we measure the improvements we plan? Use virtualization to prototype an architecture, develop meaningful monitoring, and find out what tools are going to provide the best feedback to developers. Do we need to do system profiling? What about hardware, memory caching? Don’t get lost in the details and don’t develop “analysis paralysis!”

The way to avoid that is to realize that no one person can do all this. No one is enough of a master to dream up and plan the perfect system and deploy it. So from the very beginning, each decision must be based not on what the latest reviews from CIO magazine say, but what you can do with all the resources you have. Those “resources,” in terms of people, are NOT folks you can schedule, manage, and dictate to…they are your peers, the people you helped in the past or the people you must convince that a little of their time will help you make their life easier in the future.

Build a solution team by doing the detail work that makes it easy for others to help you. It’s your job to find the analysis tools and verify they work before asking developers to use them. It’s your job to document the database schema in a wiki if you believe that will help get everyone on the same page. If developers are currently spending half their time administering databases or dealing with tech support calls–figure out a way to free them up to focus on what they are most passionate about, not your ideas about how they should be coding. Ask for suggestions, don’t dictate solutions. Be skeptical of “silver bullets:” If only we had a cluster set up…we should put this “in the cloud,” “Hibernate is the problem, but now there is something better.” My favorite: “Those disks are just too slow; we would be fine if we had 10,000 RPM disks.” Much progress can simply be made by separating inoperable opinion from testable action…