Problem Statement

    I’m thinking about putting ‘Problem Preventer‘ on my resume. Many of the folks I’m talking with in interviews and phone screens don’t seem to get this at all.  I get a lot of questions about problems solved, etc.  I have some good stories and the calls usually go well, but when it comes down to compensation and such, things break down because a lot of companies are looking for warm bodies to sit in chairs and put their fingers on the keyboard and ‘software happens‘. They build software products, but what they built isn’t necessarily a product that will be maintainable and sustain its success. It’s usually short term, tactical success at the cost of long term, strategic success.

    Anyone who’s been in a shop like this (i.e. most of them), knows that this is an ultimately losing proposition. If you’re in problem solving mode, you’re not on top of the game. Hiring more developers — even better ones — is not sustainable. It’s a brute forcing through the problem rather than finding efficient alternatives that don’t require as much work.  Eventually the bailing wire, duct tape, and bubble gum will not be enough to sustain everything and the project will collapse.  Heroes will emerge to save the day, but in a pyrrhic sense.  Eventually even the heroes can’t stem the tide and the failure will be that much more catastrophic. I have seen this time, and time again.  Unfortunately, many folks at the highest level of the organization don’t realize that this is happening. They see that the product shipped, and they don’t have any idea that some on the team nearly killed themselves to make it happen.

Value Proposition

    The value that we provide (and if you’re reading this blog or others like it, you’re already heads above the vast majority of folks in the .NET space) goes beyond our ability to write code fast or solve problems quickly.  While important, these are solving skills that are needed to account for failure earlier up stream in the development process. If you’re in a senior dev or team lead role and you have developers looking up to you, you are in a position to deliver amazing value to your employer because you can help stop the bubble gum tactics and start pouring strategic concrete.  28.3495231 grams of prevention is worth 453.59237 grams of cure, as the saying goes (or something like that).

»    Rather than hiring 453 mediocre solvers (grams of cure) and giving them mediocre pay (or sending it all offshore), why not hire 28 really good preventers (grams of prevention) and pay them well.  It will be much less costly now, and the savings will grow exponentially as time progresses. 

    Now, I’m not suggesting you fire all your solvers. Obviously, you can’t have a team full of preventers because eventually problems do arise for which no prevention was possible and there will be need for heroic cure tactics. The rest of the time, the solvers are still useful and can be grown into preventers with the right leadership and guidance in place. This is especially important to prevent stratification. By blending a lot of problem preventers with a few problem solvers in order to address changing business needs, you can achieve a nice balance and the homogeny necessary to keep up with changing needs.

Conclusion

    I have talked with several companies and recruiters who are having a hard time finding “good, senior folks” in the .NET space. I’ve been pondering why this is and I believe it’s because the vast majority of .NET developers (myself included) grew up and were sustained in a solver mode and mentality.  The “senior” folks out there, for the most part, are just better and more efficient at solving problems. Their business value and, consequently, salary are capped because there’s only so many problems you can solve and only so fast.  The real speed, productivity, and monetary gains come by preventing problems in the first place.  Unfortunately, this is not as easily quantifiable, so people in our position who fancy themselves as preventers, don’t have an accurate way of justifying higher salary and the outrageous demands of changing the company’s development process to allow for “higher bandwidth and more meaningful communication”, “more trust and respect”, “quality first, last, and always”, and other such radical hippie/Communist nonsense.

    I’ll leave you with a question:  How would someone like me quantify the value of problem prevention?  For example, Sam Solver rewrote the inflexible data access strategy in the current application that saved the company $2 million last year (after the $4 million lost over the previous 2 years). This wasn’t a savings, but a recoup of a third of the money that would’ve been lost. Pablo Preventer, on the other hand, would’ve built the system such that it had a flexible data access strategy and a loosely coupled design that not only didn’t cost the company $4 million in the first place, but allowed 2x the features to be added in the next release and allowed the company to respond to a changing market condition that expanded the company’s revenue by $5 million.  Of course these are contrived numbers and it’s hard to calculate opportunity cost and opportunity gain, but I hope you get the point.