Painters, Portraits, Software Architects

I’ve been tuning an analogy about painters for the last few months, which has become my litmus test for which companies see software strategically – and the kind of talent they attract.  First the analogy, in three parts:

1. If you want someone to paint your house, you get a few quotes from house painters. Bids focus on size of house, cost of paint, prep time and ladder time. Good references help, but your decision is mostly about price and availability.
2. If you want someone to paint a portrait of your loving spouse, however, you might prefer a modern-day Renoir to a Cassius Coolidge, even at substantially higher cost and less convenient scheduling. The quality of the work product really matters, and you hope to be living with it for a long time.
3. Likewise, if you want to build market-leading software, you’ll want a seasoned software architect whose previous work demonstrates thoughtful structure and anticipates technical evolution.

Why tell this story? Because I continue to meet executives who buy software development “by the pound,” hiring primarily on price rather than on expertise… who think of engineers as digital assembly line workers, instead of intellectual artisans… who implicitly undervalue high-quality work… who don’t know what “good software” looks like. And who ultimately overpay for crappy, inflexible, uninspired, optimistically scheduled, minimally viable systems that lack any strategic advantage. Who later admit that paintings of card-playing dogs seemed like a bargain at the time.

So far, listeners to my little story sort themselves into three heaps:

Fetishistic architect worshipers

Here in Silicon Valley, the technical talent wars rage. Highway 101 is cluttered with recruiting billboards, headhunters relentlessly troll every hot startup, and semi-experienced developers get signing bonuses.

Experienced software architects are our movie stars (LA), our fashion designers (Milan), our celebrity chefs (Paris), our rappers (Philadelphia), our soccer stars (Manchester), our hedge fund managers (Greenwich). Our painters (Florence). They get unlimited free snacks at the office, fiber optic at home, 4G on the train. They can bring their dogs to work. In the land of viral growth and lean startups, there’s a mystical belief that developers can repeat previous market successes.

This roughly aligns with companies who understand that their only business is software… whose differentiation is (at least in part) technology-based, who race against the competitive clock, who taste the digital future. Think B2B SaaS, robotic cars, network security, stock market analytics, big data, marketing automation, genome parsing, cloud storage, fraud detection, social networking platforms, satellite-navigated harvesters. Watson. (Leonardo was famous in his day for designing military tech.)

I’m 70% in this camp. Having worked with brilliant architects over the years, I know that the right design can save dozens of developer-years in work-arounds and re-plumbing. That ignoring Conway’s Law leads to chaos.  And that clear architectural insights from previous projects can shape a great solution. As a product guy, though, I know that success still requires a business model, astute marketing, shameless selling, and a hefty slice of luck. Architecture is necessary, but not sufficient. Past performance is no guarantee of future software awesomeness.

Cost-Focused IT.

These are shops where the real business is something else entirely, and software isn’t viewed as a differentiator. Technology is a cost center, a necessary evil, an attention sink for execs who would rather be working on the real business. Finance drives the IT budget, and even moderately priced software tools need a solid cost justification. The business side declares both delivery schedules and requirements with depressingly little input from developers. Think retail banks and insurance companies, government, low-tech consumer goods, chain restaurants, large not-for-profits. Car rental companies.

Not surprisingly, they rush toward offshoring for its promise of near-term cost savings – ignoring the inevitable burdens of poor communications, transient teams and naively implemented requirements. They believe in the mythical developer-month and the accuracy of project plans. Listen carefully, and you’ll hear a business unit executive telling his IT staff that “fixing this can’t take more than 20 lines of code.”

Over time, these shops increasingly trade off longer-time technical realities for shorter-term business objectives. Workarounds heaped onto partial fixes slathered across wrongly architected subsystems. Heaps of technical debt and postponed refactoring. Poop. Software architects and talented developers find these situations very frustrating: they leave for more satisfying gigs or embrace the technical lethargy.

IMHO, these shops get exactly what they manage toward: uncompetitive, over-budget systems that frustrate users and are always a year from completion. Project managers with legalistic, contract-driven attitudes and by-the-book deliverables. (“If the internal customers want us to paint dogs, then we’ll paint dogs. Would you like Westie or Weimaraner puppies?”)

Technology-Enabled

Between the two are companies that need excellent software, but primarily differentiate themselves along some other dimension. Their core proposition (or business model) isn’t primarily about technology, but good great systems can improve customer satisfaction or profitability.

Think logistics companies (with proprietary package tracking), B2C daily deal discounters or location-based couponers (with self-service advertising), dating services (with custom matching algorithms), free-to-play social gaming (with behavioral tracking and occasional crashes that don’t really hurt anyone) and tech-enabled recruiters (with keyword searches or video interviewing tools). Or any of the cost-focused IT companies above that try to use technology for strategic customer service.

These companies are just as likely to be in Minneapolis or Memphis or Plano as Palo Alto or Austin, more ROI-driven than “big tech idea.” They know that software is important to success, but can’t compete with Google or Square for raw technical talent. Their executives are typically line-of-business experts, not software folks, and don’t have (or want) deep experience building successful systems. Yet (IMHO) the success of software initiatives hinge on getting a few strong technical leaders in place.

So how do executives at these technology-enabled companies avoid cheap-but-underwhelming systems and the people who design them? In other words, how do you spot the technical Renoir among the Coolidges when hiring a software architect?

A few suggestions if you’re light on software experience:

• Find an unbiased technologist that you can trust for honest opinions. By definition, this excludes headhunters (who get paid to fill positions) and internal engineering managers who wanted the open position. Pick someone who “knows what good looks like” and also can appreciate your corporate goals.
• Ask your candidates the hard questions. “Tell me about software you’ve built that delivered strategic business value.” “How would you explain that to a non-technical executive?” “How can we turn our business objectives into project goals?” “What would your last CEO say about you?”
• Listen for realism, especially around hiring the rest of a technical team, since that will be a big challenge. Where would your candidate recruit for junior engineers? Capable development managers? UX designers? Perk up when you hear “mentoring” or “cross-training for a mix of skills.”
• Avoid religious appeals about agile or lean. These are great methodologies where they’ve been successfully applied. Applaud “…this is how I got measurable business results with agile techniques…”

Sound Byte

Software architecture is a mix of art and science, and shapes the success of your software solutions. Don’t be afraid to get some help when choosing the right architect so that you can avoid the dogs.