Learn how to build a website

There's a new website/service that just launched in Chicago called Dabble.  The idea behind the site is that if you're interested in learning something, you can sign up for a class and "Dabble" a little bit to see if you want to learn more.

Likewise, if you know how to do something and are interested in teaching other folks how to do it, you can sign up to teach a class.

They have everything from photography, to welding, to drawing.  It's a great site, and a great idea.

Using Dabble, I'm happy to announce a class I'll be teaching on Saturday June eleventh titled "Build a Great Website on Your Own".  The class will start at 10am and go until about 1pm, and will be held in my office that I share with some other entrepreneurs in Wicker Park.

I'm limiting this first class to 5 people so I can ensure enough attention will be paid to everyone, and that you'll be able to walk out of the class with your first website built and launched.

I'll talk with everyone individually to understand what kind of site you want built - whether it's a marketing site, a personal site, or a blog - and then work with you to pick the best platform for your needs and get your first site launched.

If you've been wanting to build a website but weren't quite sure where to start, sign up for my class on Dabble.  It's a small fee of $20 - which is also the minimum price Dabble allows you to charge - and I'll donate any proceeds I earn to the Greater Chicago Food Depository.

I hope to see you there!

UPDATE: Received word today (Wed. 5/26) that this class has sold out.

The developer is the customer

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.

Fixing things that aren't broken

In the world of software development, we're always iterating.

Websites can look nicer. Web-Apps can have a better user experience. Designs can be more modern. Messaging can be clearer. And on and on we go.

But I've been thinking lately that this iterative attitude might not always be healthy. At least, not unless we're thinking about it the right way.  When we're working hard to make things better, I'm learning that we need to be paying careful attention that we're not breaking the things that are working perfectly.

Because part of the art of iterating I suppose, is to understand what you want to leave alone just as much as understanding what you want change. And if making the change you want is going to disturb that which you want to leave alone, then maybe the best thing you can do right now is nothing.

Doing nothing is really hard to do, because it means we have to accept where we're at, which can itself be challenging.

But maybe, sometimes, doing nothing is actually the right answer.

Fifteen Years

A few weeks ago my family went out to California to pay respects to one of Maile's uncles that had passed away.  He was in his mid/late 50s and died of a massive anurism.

It was pretty sudden when it happened, and his family was of course devastated.  While at the funeral though, I kept thinking about his daughter Angelina, who's 20 years old.

It got me thinking.

My daughter Leila is 5, which means that should she lose me at the age of 20, we have 15 years left with each other. (And my son Kai is 3.)

I've written about loss before, and I do so not to be morbid, or depressing, but merely to understand and accept the reality that life is short, fleeting, and unpredictable.

We've been taught that to live our lives without a little planning, or without saving money for retirement, or without working hard to build something, can be a careless way to go through ones life.  And this is true - to an extent.  If I reach 70 or 80 or 90, I'd like to still be able to support myself financially.

But I've come to believe that living our lives in a way that assumes we'll live until old age is equally careless.

Because if we were to know our children only had 15 years left with us, we might not be quite so willing to accept that 2 hour commute every day.  We might have a little less patience for a job that didn't give us the autonomy we need. And we certainly wouldn't give up a family vacation to work on a project unless it was meaningful and rewarding beyond the bills that it paid.

So while I still want to build a company that's great, and I still want to save money for when I'm old, I also try to let the idea of what would happen if I only had 15 years left with my kids influence me.

Because I think living my life that way is likely to make me happier today, and in the future, regardless of how long I actually end up living.
 

Podcast Episode #11: Ryan Singer of 37signals

For this episode of my podcast, I was joined by Ryan Singer, a designer at 37signals who kids that his "cocktail title" would be a product manager. Much of what I know about web design comes from listening to what Ryan has to say on the matter, and I really appreciate the time he spent with me.

We talked about how teams work together, design, how work gets prioritized, and the kinds of things that influence their decisions - about both design and the process of getting their work done.

Ryan shares some great insights, and I hope you find the talk as valuable as I did.  As always, you can listen right here in the post, or subscribe to the podcast in iTunes.

Ryan writes regularly on the 37signals blog Signal vs. Noise and occasionally posts articles on his site feltpresence.com, where he's also posted some great videos of talks he's given.  You can follow Ryan on twitter at http://twitter.com/rjs.

Thanks again Ryan, I really appreciate you joining me.

And lastly, as has been the case a number of times, the intro music comes by way of the Smashing Pumpkins and their Teargarden by Kaleidyscope project.

Links

The People and links Ryan mentioned:

• Kent Beck and Test Driven Development
• Ed Catmull - How to Keep your Crisis Small