Why subscribe to the SDW newsletter?

  • Insight on business technology trends and news.
  • Case studies on ground-breaking innovation.
  • Invitations to SDW events and webinars.
  • Other worthy dispatches from our expert team.
  • No spam. Just cool stuff.

Please leave this field empty.

Go back to skookum.com


Where we talk about business tech,
hardcore development & craft beer

Leave a comment

One-size Fits None: The Hidden Costs of Off-The-Shelf Software

Ever notice how the same “size” of a pair of jeans can differ radically from pair to pair. Might be shrinkage, might be stretchage — whatever — but they don’t all fit the same. And, when you get a pair of jeans, even if they are the right size, you have to wear them for a while before they are yours.

If this happens with something as simple as a pair of jeans, how much more complicated must it be with a piece of software? Horrendously more complicated. But the people who sell you software in a box don’t want to talk about that. Who can blame them? For them, it’s one-size fits all. Or, “This one is juuuuuuust right for you.”

Unfortunately, Big Tech lies.

EVEN IF off-the-rack or out out-of-the-box technology works for you, the cost is never the sticker price. No no, the cost for supposedly “ready to go” software is always the sticker price plus the time, energy and lost productivity during the integration period for that “easy” to “plug-in” new “module.”

Further still, pre-packaged software lacks the a majorsurprise upside; custom software requires a re-evaluation of the business models and process that had you originally hunting for a new technology investment in the first place. By assuming you can just purchase your way to more profits, scalability, efficiencies or robust automation, no one actually takes the time to examine the new opportunities to make or save money.

When purchasing off-the-shelf software, there’s no possibility of creating something that works so well it becomes a competitive advantage. Or, even, a product you can license.

The hidden cost of off-the-rack aren’t just your integration costs. The real cost of off-the-rack is leaving the possibility of transformative change off the table. Unrealized innovation.

Hidden Costs of Off-the-Shelf Software

- seat licensees, use-it-or-lose-it maintenance, all the stuff you already hate
- surprise integration costs
- missed productivity hacks because new business process automation was never addressed
- lost opportunities for sellable/licensable IP

Transformative change and innovation are scary, we get it. And if you’re not willing to explore those possibilities, we won’t blame you. We’re just not going to work with you.

[Call IBM. They're always happy to over-bill on a mediocre project.]

Leave a comment

Profitable Innovation & 5 Reasons Why BigCompanies Burn Big Dollars When “Ideating”

Couldn’t be in Charlotte on 5/23? Here’s your chance to catch up.

This Tech Talk is 30min blitz on how big-money-making-and-big-product-shipping F1000 companies can avoid screwing up the innovation end-game.

(And I’ll start by defining what the heck “innovation” is… or, rather, what it should be…).

Hit me up with any applause, boos, questions, etc at pat@skookum.com or @pat_morrell


  • 2 metrics to measure “innovation”… the only 2 that really matter
  • 5 reasons / bad habits that explain why your favorite corporate logos burn through budgets when attempting to “disrupt” (HINT: it involves Pied Piper, Don Draper, & Nest thermostats)
  • 4 tips for how Innovation leaders can make actual progress and still see their kids every day.

And in the Skookum spirit of collaborative innovation, feel free to ping me if you want to learn more and/or review the deck live.

Links to reference articles:

Leave a comment

Stop Reading TechCrunch

Innovation seems hard. That’s why everybody likes to read about it and talk about it, rather than actually do it. It’s easier to look at someone else and think, “Wow, they really know what they are doing. They are so cool!”

For some reason, we are wired to believe if you read about people, or if you dress like them, or talk like them, or live where they live, that you will become like them.

Myth: Silicon Valley is the Epicenter of Tech Innovation

Reality: Silicon Valley is the epicenter of tech speculation.

Since it doesn’t help your business to keep tabs on the Silicon Valley casino, you need to stop reading TechCruch or any of the other Valley techfotainment.

Thankfully, business is not high school. You don’t become cool by hanging out with the cool kids. You become cool by lowering costs, increasing revenues and making people’s lives better. And doing these worthwhile things aren’t hard, they are just uncomfortable because they require change.

You wanted the Chief Innovation Officer title.
You got the CEO to buy into your dream.
And the faster you refresh TechCrunch, the sooner you’re going to be fired.

It’s easier to refresh TechCrunch than to speak truth to power.
It’s easier to refresh than to look at the parts of your enterprise that aren’t working so well.
It’s easier to refresh TechCrunch than to listen.

So the next time you find yourself tempted to skim a few quick posts on your phone, stop. Do nothing for a moment. Give yourself a quiet minute in which to examine your business processes. How are people, places, and data moving around your company?

Instead of reading TechCrunch, focus on that unpleasant pain-point inside your organization that you are actively avoiding.

By giving your attention to the stream of relentless, irrelevant, money-sloshing cheerleading that is most of SV press, you’re failing to innovate.

Leave a comment

Software Development as a Creative Process

“How big is this feature? We need an estimate.” The project manager waits for the developer to play his predictable card. “It depends. It could be 2 hours, but I might have to refactor, which could take 2 months.” Not a very useful exchange.

In software, it’s no secret that meetings between project managers and developers can get painful for both sides. With all the tools and processes we have at our disposal, projects still consistently blow budgets and trample deadlines.

Why does this happen? Why can’t developers ever give a straight answer? Why do project managers always seem to be asking the wrong questions? The root cause is a mismatch between the type of problems development presents and the metaphors we use to model them.

Our industry has always managed software development using metaphors from manufacturing and construction. We use language like “groundwork”, “build”, and “defects”, but the metaphors run much deeper. They shape the way project managers, product owners, and the general public think about development and consequently the processes and expectations developers work under.

Sure, there are some stages of some projects that resemble construction, but more often than not, especially for new applications, the metaphor is completely misapplied.

Take the Healthcare.gov meltdown for example. The failure and the subsequent “Tech Surge” that followed is a classic example of construction metaphor applied to software. The implicit assumption is that the work is linearly cumulative, and that more workers equal more units of output. We all know this isn’t true, but is it because developers can’t work together or is there something wrong with the concept of “output” as it relates to development work?

Another example is the relentless requests project managers make for estimates. The assumption is that the work follows a known path that can be measured and estimated. We all know developers are notoriously terrible at estimates. Why is that? Are they all just stupid and lazy, or is there something wrong with the framing of question?

There’s even been writing directly equating developers with factory workers, destined to be automated out of a job. The assumption is that the work is well defined and repetitious. If developers are the factory workers, then whose job is it to create the software that automates them and why has demand for them only grown?

The examples go on, and as the questions pile up, we start to get a nagging sense that there’s a mismatch between who we are and who we’re supposed to be.

Software isn’t Built, it’s Invented

Let’s untether ourselves for a minute from the world of physical goods and try to see software development as a creative problem. Creative problems like designing an interface, writing a novel, inventing a machine, or composing a symphony have much more in common with the challenges of software development than does building a house or manufacturing a car.

Creative problems have an undiscovered solution. Edison’s creative problem was to create a practical electric light. His solution was the light bulb. Leonardo da Vinci’s problem was to create a portrait of Lisa del Giocondo. His solution was the Mona Lisa. These problems have infinite solutions. They’re worked on and refined until a satisfactory one is discovered.

Some might argue that software has specifications: design documents, business requirements, visual mockups and so on, which specify a single solution, but they don’t.

From a development perspective, those documents are the problem definition, not the solution. Software can only be specified in code, in the same way that a book can only be specified through its writing. Code itself is nothing more than an unambiguous and complete specification. If business requirements were complete specifications, you’d be able to compile and run them, but you can’t.

Coding is a creative problem. Every time a developer writes code, he is taking a non-deterministic path towards an unknown solution — a unique solution that has never been created before. If the work weren’t unique, he wouldn’t need to write it, he’d simply copy and paste it.

Looking at development through this lens, it’s clear that there’s a mismatch between the type of problems we’re facing and the processes we use to solve them today. Even Agile methodologies are still rooted in the flawed construction metaphor. The mismatch between the type of problems we face and the way we choose to model them is responsible for much of the pain, frustration, and absurdity we’ve come to accept as the norm in our industry today.

The Creative Process

If software development is truly a creative problem, maybe we should look for inspiration from other fields solving creative problems.

We can start with our closest neighbors, the friendly UX and design folks we work alongside. There is a lot written about design thinking and the creative process, and design shops like Zurb have been kind enough to publish the exact processes they use to design products. The steps are basically:

  1. Understand — Explore the problem and identify the risks.
  2. Ideate — Experiment with divergent solutions and distill them.
  3. Prototype — Build a prototype based on the consensus ideas.
  4. Test & Learn — Use the prototype to test, learn and improve.

How can we apply these ideas to a development process?

Developers already do some of these creative tasks, but they’re never officially part of the process and almost always under the radar. No project manager wants to hear her tech team is “ideating.” It’s seen as an emergency measure — like “down time” for a factory line, to use our manufacturing metaphor. If software is a creative problem, then we should build exploration into the process.

Imagine what a time-boxed development sprint modeled after the design process might look like.

It could start with bringing the development team together to identify and document key problems. Developers could then individually break out and research/test diverse solutions to those problems. Without the pressure of shipping features, they could validate new methods and patterns for solving the given problems.

In a convergence meeting, the team could share and distill the diverse ideas into consensus recommendations. Developers receive feedback from other team members who may have envisioned solutions in completely different ways. Armed with a consensus direction, the team then builds out the set of features using the patterns they’ve agreed on.

As a final step, the team should instrument and measure the work product in an objective way against success criteria like performance, organization, and complexity to inform the challenges of the next sprint.

Would this exact process actually work? It’s hard to say. The example just serves to illustrate that we don’t have to look at development purely through the rigid lens of linear, incremental construction. Even if the process we described doesn’t work as a whole, nobody can deny that it includes obviously valuable development activities that are completely overlooked today.

Now What?

Acceptance is the first step. Writing software is a creative problem and today’s development processes are still in denial about that. We need to move beyond 19th century assembly line thinking and change the way we fundamentally think about the art of software development.

We should take a close look at creative processes from adjacent industries for inspiration. How do inventors design revolutionary new devices? How do engineers design a unique skyscraper? How are factories designed rather than operated? What can we learn from these processes? Let’s start drawing new metaphors and tweaking our processes a little bit at a time and see where it goes.

We’ve been peddling the Agile process for nearly 15 years now. That’s a long time for an industry that moves as fast as ours. If we can replace the broken metaphors in our heads and be honest with ourselves about the challenges we face, we can move our industry forward and open doors to entirely new ways of working.

Leave a comment

Outsourcing Innovation Is Not Only OK, It’s Preferred

A company can be a lot of things, but mostly it is a group of people who have similar idea about a profitable business offering. On the matter of commerce, colleagues are (more or less) philosophically-aligned. This isn’t group-think, this is efficiency. If you had to spend all of your time defining terms with your co-workers, you’d never get anything done.

You are efficient and effective because there are whole bunch of assumptions that you don’t question in your day-to-day work. Questions you don’t have to ponder. You are running an enterprise, not a philosophy class.

But for innovation, givens are a problem. People need to ask stupid questions. A few key stakeholders (with budgets and backing) need to take chances and be willing to lose face. Therefore, the things that makes your organization run well day-to-day and quarter-to-quarter are exactly what makes it hard to innovate.

You’re just too damn close to it. And you should be.

If you are happy with the results your business is getting, you don’t have to worry about innovation. (Probably.) But while you’ve been doing the same thing, the world has been changing and evolving. And somewhere, deep in the back of your routined brain, you know anything that isn’t growing is dying.

To get unstuck. To get it done. To make it better, you need someone from the outside. Someone who can look at the trees and see the forest. Then look at the forest and say, “Yeah, but have you ever thought about grassland here? Maybe a river?”

“Oh and BTW, this process over here that’s just ‘How things are done?’ That’s costing you 1M per month. Here’s how we’ve seen other industries turn that liability into an opportunity.”

The opportunities you don’t seize are the ones you can’t see. You’re too close.

Leave a comment

Your Request for Proposal is a Request for Mediocrity

It is impossible to write a good RFP for custom software development.

Instead of looking for people who can check off your carefully spec’d boxes, you want to look for people who can help you figure out what boxes to spec.

The easiest things to filter for in an RFP response are expertise in a given tech stack or industry experience. But what if there’s a better tech stack? What if the answer isn’t a tech stack at all? And what if the way it has always been done in your industry just isn’t very good.

For example, department stores thought they had distribution figured out pretty well. Then came Wal-Mart. Then came Amazon. Are you sure you want the current “industry” expert?

The point of hiring a collaborative partner is to get insight unfettered by conventional “wisdom.” And results beyond what you thought was possible. Not every project can get there, but one thing is for sure — the RFP process makes it harder for everyone to do their best work.

Continue reading

Leave a comment

SDW Hosts Charlotte Code for America Kickoff Event

For years, we have championed the influx of developers, entrepreneurs and technology startups in the Charlotte area. After discovering Code for America chose Charlotte as one of 10 cities to work with for 2014, we were honored to host their kickoff event. It’s no secret we love Charlotte. That’s why we leapt at the opportunity to utilize our Space Volcano for their press event, fund raiser and supporting brigade meet up.

Josh Oakhurst Interview

Continue reading

Leave a comment

RFIs, RFQs, & RFPs Can Hurt Your Business

rfp strategy

Sending your big technology project to RFI, RFQ, or RFP forces you to play both patient and doctor. Does that ever sound like a good idea?

With myriad and overlapping business and technology problems, doing the ole’ get-a-bunch-of-bids-thing requires self-diagnosis — and self-awareness. Mostly, your request for submissions will require honesty about your business.

Nothing about your RFP will be remotely honest.

Continue reading

Page 1 of 1812345...10...Last »