Dear [Under-Capitalized Business-Guy who wants me to work on your site for 'equity'],

Thanks for taking time to meet today. It was interesting to learn about what you’re doing.

I’ve put some thought to what you’re trying to do and I have to be honest, I have some reservations about it. The business model itself may work, though I don’t know that much about the kinds of businesses you’re hoping to get as customers. But the very rough proforma you’ve put together gave me a bit of pause.

I appreciated that you’ve had the foresight to put together some financial modeling — that was reassuring. But it concerns me that you felt you could somehow spend only $50,000 on developer salaries over a 5 year period. And while I understand that at this point the numbers are all pretty rough, it just seems way low for what you’re trying to do.

A single developer (one with the skills to handle all aspects of the site, build it and keep it running, backed up and responsive as your customer base grows) would cost a very minimum of $75-80K/year (plus benefits, etc.) For $10,000/year you might be able to hire a single person at far less than half-time. That’s to me just so unrealistic as to be almost impossible. I can’t imagine it. You can’t build a software-based company without software developers. To realistically handle what you’re trying to do would likely require an ongoing staff of 2 or more people once you got to 2-300 or more customers using the application.

And if you can’t find someone willing to work for free I’d recommend a budget of closer to $50K to have enough to get things live with a decent design and cushion for when things go wrong — which they will.

But given your current funding level you probably can’t afford that. So what I’d recommend is finding a ‘technical co-founder’ that you can partner with. The only appropriate thing to do, though, would be to be up front that you don’t have money and are looking for a co-founder — and provide co-founder-level equity participation for their efforts (meaning probably no less than 30% ownership). Otherwise you won’t likely find someone with the level of skill and experience to make this thing work. You have sales experience and the idea, and that’s worth a lot.

But either way, given your current unrealistic expectations regarding cost I don’t think I can in good conscience refer you to contacts of mine as a potential partner. I wouldn’t feel right about it.

Maybe we can get together in a couple weeks and talk about where you are. I’m happy to meet and provide what guidance I can over coffee periodically.

Best of luck,
Kevin

One of the answers, though, I think got it all wrong:

“Selling the engineer on the vision is key, but it doesn’t need to be the same part of the vision that you think is exciting. You may have to frame it differently in terms the engineer will understand as valuable to their learning and reputation as an engineer.

Want to eliminate third world debt through micro-finance? Ok…that’s great but might not excite an engineer. It involves implementing a machine learning algorithm to arbitrage risks based on someone’s social graph? That might be a wee bit more exciting for an engineer to implement.

Finally, just get them to help you with a very small part of the problem. If you can get them to write a few lines of code, odds are a good engineer will not be personally satisfied until it is a 1000 line elegant solution. At that point, they have sold themselves on the project.”

I have to be honest, I’m not sure I agree with this approach. It may work to sell some engineers, but not the engineer that can bring your vision to reality.

‘frame it differently in terms the engineer will understand as valuable to their learning and reputation as an engineer.’ – this is just not accurate. An engineer capable of bringing your vision to reality needs to clearly see *your* vision and buy into it. If you get them excited about a technical solution that they think will make them more valuable, what happens when the technical solution needs to change? Are they still bought in?

You and the technical founder need to be aligned on what the vision and the value are. And a good engineer for that stage in a business’ life is one that can see your vision and also see the way to make it real.

And this sentence to be honest is a bit insulting and niave – ” If you can get them to write a few lines of code, odds are a good engineer will not be personally satisfied until it is a 1000 line, elegant solution.”

A good engineer is satisfied when the solution fits the problem, not when they have a 1000 line elegant solution. Engineers that ‘over engineer’ in the name of finding elegant solutions will kill your startup.

It’s better to enlist them as a full partner with the whole team focusing appropriate levels of resources to achieve a clear business end. Great engineers are those who can do that. And they exist.

1. Raises were based more on how the company was doing rather than individual contribution. I remember one year my entire department was given a 4% raise. Everyone got the same regardless of how hard they worked.

2. Risk taking was only rewarded if things worked out for the best. Trying a new technology that ended up not working (even the failure didn’t impact delivery schedules or business goals) would result in a negative at review time. It encouraged people to not suggest new approaches or technologies in case they didn’t work. It was great for people who played it safe and didn’t try new things.

3. Management was always working to reduce development cost — meaning they worked to outsource our work if they could. I was in a meeting once where the CIO told my team he could probably outsource our work to a 3rd world country for 10-20% of what he paid us. What an ass.

On the flip side, many of the people I worked with are still there and have had stable salaries and good benefits in a job where they didn’t have to work that hard for years at a stretch.

I guess what’s best depends on what you want from your career and how driven you are to create new things and work on the edge of technology. Personally, I work now with startups and love that I’m always on the edge of what’s new.

The challenge is that thinking 3 steps ahead too often will get you into trouble as you can lose site of the things you need to execute on today.

I’ve always said the hardest thing in business (especially in a startup) is to ‘execute effectively today while also building tomorrow’. Most people have it in their nature to do one or the other.

To be really successful, you need to do both. At the same time.

If you’re going to be a co-founder and receive equity on par with the other co-founders, it seems appropriate that you should receive income on par with them as well.

In other words, it depends on how much cash is available. ‘Co-founders’ that get significant ownership should receive similar ‘salaries’ initially.

So rather than think of things in terms of how much of a discount against salary you should ask for, I think it would be more appropriate to think in terms of what you bring to the table — and what the others are bringing. Then, see what cash is available for you all to share.

If you want more cash than others, then you should be prepared to get less equity. Some technical co-founders take no salary at all in return for more equity.

Co-founders that bring money to the table in addition to time would be right to ask for a greater equity stake.

As a UX developer, you get deeply involved in how users will use the application — which lends itself well to a Product Management role. Product Managers set direction for the product and sequence which features will be done when. They need to have a deep feeling for how the user gets value from the application.

Of course, Interface Developer is one of the key roles for a startup as well, if you have interests in that area. It’s very difficult to get investment in a startup without a working ‘beta’ or prototype — and building out prototypes of sites is one of the things a User Interface developer should be good at. You could find yourself in a situation where you could own a good deal of equity on a small startup if that were what you wanted to do.

Longer term, the things that will carry your career forward are your people skills and business skills — even if you choose not to go into management and stay technical. You’ll need to develop relationships and help people solve business problems.

But user interface developer is a great place to start a career.

From a fundamental perspective, the role of Architect has to do with overall application design – or at minimum review of designs. Some responsibilities would include:

* API Design
* Application Architecture (split the app into multiple apps? One big app?)
* Standards support (RESTful api’s -v- SOAP api’s, etc)
* Overall design pattern review and recommendation
* Design review *across multiple projects* to ensure consistency and reuse.

Notice that none of these responsibilities has any coding specifically associated with them.

A Lead Software Engineer, by contrast, is a coder. They build things and implement designs.

In many companies these roles are combined. It’s only in large companies (or on large projects) that these roles would be separate — for only then is there really enough architecture work that the lead software developer can’t do it as part of their job.

If you see a company advertising one position or the other, it’s most likely because they have one role that has elements of both — but that they’ve chosen to ‘label’ it one or the other for some reason. If they advertise ‘Architect’, they probably want that role to oversee design decisions made by others.

In a ‘feature-boxed’ approach, a set of features, defects and chores are defined to ‘scope’ the work to be done during the Sprint. Once those features are complete, the Sprint is complete. There are several advantages to this approach.

The first advantage is that you know exactly what features will be completed during the Sprint. There’s no question which features will be completed, because by definition a specific collection of features define the Sprint’s scope.

A second advantage is that you don’t have to worry as much about which order you work on the features (or defects/chores) in the Sprint. Since you’ll get to them all anyway, you can order the work in whichever way you want.

But in that second advantage lies a significant disadvantage: Because you don’t have to worry about which order the features are completed, you’re not forced to prioritize as aggressively. If time runs out near the end of the Sprint you may end up abandoning features in order to bring the Sprint to a close. Moreover, it’s possible that some of the features completed early in the Sprint may not have been the most critical pieces of work.

Contrast this with a ‘time-boxed’ Sprint approach. In the ‘time-box’ approach, the end calendar date for the Sprint is determined at the outset. The Sprint is complete once that day is met and all work that’s going to be launched needs to be done, through QA and ready for launch.

Time-boxing the Sprint requires a much sharper focus on prioritizing work, since you can’t push the end date if work isn’t done. Features that aren’t complete get pushed to the next Sprint.

This forces decisions much earlier on what will and what won’t make it into the Sprint. In fact, hard decisions on prioritizing work should really be done right at the outset. Decisions on what features get pushed to the next Sprint have to happen very early — otherwise testing can’t be completed before the end of the Sprint.

One technique I’ve used to prioritize features is to use what’s referred to as the MSCW (or ‘Moscow’) rating. MSCW is an acronym for:

• ‘M’ – Must – The feature MUST get done during the Sprint
• ‘S’ – Should – The feature SHOULD get done during the Sprint
• ‘C’ – Could – The feature COULD get done during the Sprint
• ‘W’ – Won’t – The feature WON’T get done during the Sprint

By tagging each feature with a MSCW rating at the outset, decisions on which features will and won’t make it into the Sprint is built into the process from the beginning. This approach enforces a discipline that ensures features are prioritized correctly.