Project Idealism
I've noticed quite a bit of conversation lately around non-technical co-founders trying to recruit developers to work with them on their projects - and what kinds of things they can do to bring them into the fold of their product/company. Likewise, there seems to be endless demand right now for quality programmers/hackers/developers, and if you have the words "Ruby on Rails" anywhere on a public resume you've likely received a call from at least a few clueless recruiters - and probably more.
I've been fortunate in that I've worked on a number of projects with some great developers, and I know a number of people from iOS developers, to PHP programmers, to RoR hackers, to Android folks that I can work with to make an idea real for either myself or a client. And I'm working with two awesome developers on SignalKit.
I'm realizing that the fundamental difference between myself and other people that are considered "non-technical" is in my stance and posture towards developers, my clients, who I ultimately look at as "the customer", and that I have a different definition of "technical". I'd like to explore these differences in this post.
Defining the customer
In my mind, the customer is not just the person that pays you - it's the person that enables you to get paid. This slight tweak in defining who the customer is changes a lot in my posture, and quite frankly, who I'm going to work to make happy.
Traditionally, the person writing you a check is the customer. Period.
But we're living in a world where everything is being upended - from media, to publishing, to business models - and so it only makes sense that our definition of customer should be upended as well.
Simply put, if I don't have good relationships with good developers, then I can't make my clients happy. If I can't make my clients happy, I don't get paid. If I have good relationships with good developers then I can make my clients happy and I get paid.
The customer is not the person paying you; it's the person enabling you to get paid.
You need to bring value to your customers
Now that we understand who the customer is, the next step is to bring value to your customer. Yes, money is valuable, but if all you're offering developers is money then you haven't really separated yourself from anyone else that's trying to land that customer.
Something fun to work on, autonomy, a workplace of their choosing, freedom from dealing with middle management BS, exposure(!), and the freedom to work on and explore their own ideas independent of yours are all things that most people find valuable.
This of course is a short list - there are many other ways you can provide value to a developer.
Other than money, why should a talented developer work with you? What can you offer them? If you can't answer this question you'll have a hard time making the sale.
What you think is technical isn't technical
There was a time when not everyone knew how to use Excel, and Word, and Outlook. And then people had to learn how to use these tools because management said so. But no one ever says "whoa - wait a minute - I'm not a technical person so I can't send email."
I believe we have entered an age where "business" people need to learn how to use a new toolset.
Should a product manager really require a programmer to change text, or insert a different image, just because they haven't learned how to use .git and textmate? I think those days are disappearing quickly.
The reason people had to learn how to use tools like Outlook is because that's the way people started communicating. Developers have a way of communicating - and it's often done with checking code in and out.
I don't think you have to be a programmer to understand the file system of an application; I think that's merely learning how to use new tools in the modern workplace.
You don't own your customers
You would never expect a customer to have only one vendor, and business people shouldn't be trying to own their developers. Far too many people think they need all or nothing from a developer. "Either you're working only on my stuff, or not with me at all!"
I think that approach is a mistake.
Instead, I've had the most success working with people that have their own companies, are working on their own ideas, and then they also work with me on some of my apps or my client projects. Good developers are able to manage their workloads and get work done for you - even if they have other project they're on.
There's good customers and bad customers
Just because the developer is the customer doesn't mean they have ALL the leverage. In the same way a service company might fire a high maintenance client, so too might I not want to work with a high maintenance developer.
This isn't to say that developers don't need good product people, good business people, good marketing people, or anything else. They do. Just like a traditional customer might need a vendor to run their business, so too do good developers need great business people to work with.
Understanding who the customer is though, is a very important part of the equation.
I've been fortunate in that I've worked on a number of projects with some great developers, and I know a number of people from iOS developers, to PHP programmers, to RoR hackers, to Android folks that I can work with to make an idea real for either myself or a client. And I'm working with two awesome developers on SignalKit.
I'm realizing that the fundamental difference between myself and other people that are considered "non-technical" is in my stance and posture towards developers, my clients, who I ultimately look at as "the customer", and that I have a different definition of "technical". I'd like to explore these differences in this post.
Defining the customer
In my mind, the customer is not just the person that pays you - it's the person that enables you to get paid. This slight tweak in defining who the customer is changes a lot in my posture, and quite frankly, who I'm going to work to make happy.
Traditionally, the person writing you a check is the customer. Period.
But we're living in a world where everything is being upended - from media, to publishing, to business models - and so it only makes sense that our definition of customer should be upended as well.
Simply put, if I don't have good relationships with good developers, then I can't make my clients happy. If I can't make my clients happy, I don't get paid. If I have good relationships with good developers then I can make my clients happy and I get paid.
The customer is not the person paying you; it's the person enabling you to get paid.
You need to bring value to your customers
Now that we understand who the customer is, the next step is to bring value to your customer. Yes, money is valuable, but if all you're offering developers is money then you haven't really separated yourself from anyone else that's trying to land that customer.
Something fun to work on, autonomy, a workplace of their choosing, freedom from dealing with middle management BS, exposure(!), and the freedom to work on and explore their own ideas independent of yours are all things that most people find valuable.
This of course is a short list - there are many other ways you can provide value to a developer.
Other than money, why should a talented developer work with you? What can you offer them? If you can't answer this question you'll have a hard time making the sale.
What you think is technical isn't technical
There was a time when not everyone knew how to use Excel, and Word, and Outlook. And then people had to learn how to use these tools because management said so. But no one ever says "whoa - wait a minute - I'm not a technical person so I can't send email."
I believe we have entered an age where "business" people need to learn how to use a new toolset.
Should a product manager really require a programmer to change text, or insert a different image, just because they haven't learned how to use .git and textmate? I think those days are disappearing quickly.
The reason people had to learn how to use tools like Outlook is because that's the way people started communicating. Developers have a way of communicating - and it's often done with checking code in and out.
I don't think you have to be a programmer to understand the file system of an application; I think that's merely learning how to use new tools in the modern workplace.
You don't own your customers
You would never expect a customer to have only one vendor, and business people shouldn't be trying to own their developers. Far too many people think they need all or nothing from a developer. "Either you're working only on my stuff, or not with me at all!"
I think that approach is a mistake.
Instead, I've had the most success working with people that have their own companies, are working on their own ideas, and then they also work with me on some of my apps or my client projects. Good developers are able to manage their workloads and get work done for you - even if they have other project they're on.
There's good customers and bad customers
Just because the developer is the customer doesn't mean they have ALL the leverage. In the same way a service company might fire a high maintenance client, so too might I not want to work with a high maintenance developer.
This isn't to say that developers don't need good product people, good business people, good marketing people, or anything else. They do. Just like a traditional customer might need a vendor to run their business, so too do good developers need great business people to work with.
Understanding who the customer is though, is a very important part of the equation.