Profile: Patrick Curtain

Patrick Curtain is a software developer, architect, analyst and mentor based in Portland, Oregon. For decades, he's guided startups from concept to prototype, hiring and leading teams to their successful launch day.

Want to hire Patrick to help define your product? Or maybe you just need him to step in and coach your team toward a successful process? Contact Patrick on his website

Hi Patrick. Tell everyone a bit about yourself.

Well, I’m a bassist in every aspect of my life. You know, that role in music that holds the form and foundation so the rest of the band can shine, succeed and look good. Musicians know it’s the bassist in a band that lays that foundation. We may not get the chance to play solo very often, but without us the song and the feeling fall apart.

As a technologist, that’s led me to often jump into whatever is needed. Being surrounded by lots of brilliant programmers has led me toward leading, facilitating, and teaching them. I’ve spent a lot of time taking part in the burgeoning Agile community in Portland, trying to understand how software can succeed, be efficient, and reduce developer burden. As eXtreme Programming concepts became the standard methodology, I started turning more of my attention to other layers in taking products to market: Helping founders, product managers, and others.

On your website, you say your greatest enjoyment comes from the relationships built in your teams. What do you mean by that?

Oh man. I've had a career full of joy as a result of that care. In terms of delivery, I've found the most important elements in a team's success are its cohesion and communication. It's been critical to foster a good match of team members to each other, to arrange for activities that can deepen and aide in those relationships. And the nature of every endeavor is that as we engage deeply together in solving problems, overcoming obstacles, and even meeting unwanted challenges, we form deeper relationships. So that's one part.

Another is that very early I saw that any one company or project or effort was short lived, but the relationships would last far beyond those. So I chose to consciously prioritize the people over the task. The task will be there. The cows will still be there to be milked tomorrow. This particular Pivotal Tracker ticket will be there tomorrow. Put the human being first! How does this effort match their goals? Is the pressure of the project engaging and challenging them in a way that builds them up? Or is it going tilt their life balance in a destructive way? Is this or that characteristic something to encourage? Or does it diminish their effectiveness, even if it seems to help the project short term?

Teejay, do you remember the first project we worked on together? You maintained a desire to always deliver. That desire was helpful in making it seem like you and your team could deliver miracles. But it also took its toll on you and set unrealistic expectations that eventually harmed their own hopes. Things like that. And here we are still laughingly tolerating each other.

I sure do. And boy, what a naive dolt I was back then. I think the most critical way I've matured over the past decade isn't in my raw programming skills, but in my ability to say "no" without hesitation.

How do you make connections with prospective clients?

Truly, I'm not the right person to answer this question. In my work with development services teams, the sales team gets me involved in vetting and making first connections with organizations looking to have us build their software. In a market flooded with demand for development, the main task is finding worthwhile and high-value projects. Discovery helps ensure that.

Most of my inbound clients are from contacts I already know coming to me as friends asking about their startup idea. That leads to the same exploration that I do in every Discovery effort: Helping them determine if this idea has a path or potential toward profitability and determining phases and development cost ballparks.

What is the biggest hurdle you've found in selling Discovery services?

It's never been a problem once we’re talking about spending money to have their idea made real in software. At the point they’re already preparing to build it, some initial review and exploration of the idea by experienced technologists makes sense. The value is easily recovered in savings on the development work to be done as well as in help with vetting the viability of the concept.

A big key idea here is that there's no physics in software. Anything you can imagine, given sufficient time and budget, it can be done. The bigger questions involve narrowing that to smart, actionable and informative choices so that the organization learns from every iteration what customers desire most. If that work is done well (and this is more about product management and definitions) it will save developer hours in misdirection and rework.

You list "bassist" before "agilist" in your tagline. What does that have to do with how you work?

Well, mostly that points to what I said in the intro; I’m a bassist as a character trait. It’s who I am, in music of course, but also in life. So that’s one answer.

I’m also somewhat reluctant about the public image of Agile™ since it's become associated with dogma and formalism that was exactly what we meant to work against. The original Agile Manifesto was all about pragmatic improvements to how the whole work of software creation happened. It was eXtreme Programming and all these principles that are now captured in the Software Craftsmanship movement. But it was also about the wisdom of knowing the Folly of Human Prediction (see Freakonomics) and why not to trust Big Upfront Design projections and traditional Waterfall Project Management. Now we've gotten too devoted to Scrum and rolled "Agile" into that same enterprise level formalism.

I believe we can, if we choose, lighten up at every level. Set aside behaviors associated only with bureaucracy and hierarchy, and act more nimbly throughout the corporate hierarchy. Founders to Developers and everywhere between.

It's part of why I list myself as an "agilist" (lowercase 'a') and not a "Certified Agile Practitioner". This formalism defeats the very concept of "agile" as meaning "nimble; light on its feet."

I remember sending you Michael Church's article about why "Agile" and especially scrum are terrible and we had a bit of a back-and-forth about why he's "mistaking craft for branding" in your words. I agree; it's always frustrating when the buzzword buzzards take hold of a good thing.

If you could have your pick of any project for which to conduct a discovery, what would it be?

Seriously, every person’s new idea for a product is worth talking about. I'm trying to imagine projects where that isn't the case and… I can't.

Mostly that's because the discovery process itself is about finding the viability and value in that idea being investigated. Exploring lean principles and what they've learned so far, digging through and morphing the idea until we all reach a point of excitement that this can really take off! That's the fun!

That said, I'm certainly more excited about ideas that push world-affecting solutions in healthcare, mobile engagement and all forms of idealism. That's just part of my motivation.

Patrick wants to help you make your software team more cohesive. Contact Patrick on his website