Aaronontheweb

I alluded to a change in my employment circumstances in my previous blog entry, and now that I'm an official Microsoft employee as of Monday I feel extremely comfortable making this information public.

My role is Developer Evangelist for the BizSpark program; Microsoft recruited me for this position after they read .NET Culture Shock: Why .NET Adoption Lags Among Startups and the rest, as they say, is history. I've relocated to the Santa Monica area and my immediate task is to work on increasing goodwill towards Microsoft and the .NET platform among the startups in southern California; it's a prospect that is exciting, daunting, challenging, and mind-blowingly awesome all at once.

If you're involved with startups in SoCal then I will make it my mission to meet you and find a way to help you should you require it. If there's anything I can do to help you, please feel free to contact me.

As for the blog - it's not going to change much :p . If anything, I'm going to have more content as a result and it'll be from a much higher altitude than it was before.

Wohoo!

If you enjoyed this post, remember to subscribe to my RSS feed!

General, Startup, Microsoft Microsoft, startups, Los Angeles

Today was my last official day at SmartDraw – I’ve worked for this great company for two years and saying all of my goodbyes was bittersweet.

Were it not for the fact that my new employer graciously dropped an irresistible opportunity at my feet¹ I would have been happy putting in another couple of years there and I would have loved to watch it continue to grow into the large company that it will be some day.

You don’t expect to get trophies for leaving a company and moving onto a different job, but oddly enough that’s what literally happened today. My boss took it upon himself to host a happy hour at a local chain restaurant to wish me farewell along with my co-workers. Thirty minutes into the celebration he stood up next to myself and the CEO, gave a quick speech where he rolled off a list of things I had accomplished during my time, and handed me a glass trophy. Good times ensued.

A Culture of Achievement

My next job will plunge me neck-deep into the startup community, although I will not actually be working directly for one. My co-workers know this, so naturally they spent the next hour or so sharing stories with me about the startups they’ve worked for in the past: ProFlowers, Level 3, ADN, and the list goes on.

Not once during the course of these conversations did anybody brag about the money they brought home from the bank as a result of an IPO or an acquisition – what everyone talked about was the thrill of sharing success, of feeling like they’d helped leave some organization in a better shape than they found it.

Everybody who goes to work for a small, young company is an entrepreneur to some extent (the range is debatable, but not in the slightest bit relevant) – you have to be in order to tolerate the risks and lack of security that come with a firm of that size. And why do people do it?

The trophy is just an object and certainly not an ends in and of itself. What it represents, however, is that my peers and co-workers recognize that I left SmartDraw a better place than when I found it. The external validation and praise from my peers is more than welcome too, but it’s not something you can or should expect – SmartDraw just happens to be a truly exceptional place to work with exceptional people.

The reason why people with talent and ambition work for anybody else is this – because we want to be needed as much as we need the job, and we want to have the opportunity to make something better than we found it even if that something wasn’t an idea born of our own imaginations. Creative control doesn’t matter half as much as the knowledge that we can and will make a difference.

For every blog post I read like this one,² where the author basically states that if you recognize your own talent then it’s time for you to become your own boss, I would like to answer it with this:

Being involved with a startup isn’t about a glorious exit, getting rich quick, or being your own boss. It’s about accomplishment, and doing it with a group of people who are really fun to work with. If you start something yourself, then more power to you.

I’m going to work for a great employer, and I couldn’t be happier about it. And one day I’m going to decide to start my own company and I’ll venture off to do that. But ultimately I want the same thing from both opportunities: I want to accomplish things of significance.

If you’re running a company and ever want to attract ambitious people like me, make a case for why you need us, not the other way around.

If you enjoyed this post, remember to subscribe to my RSS feed!

Startup startups

I showed up at BarCamp7 this morning and saw that absolutely no presentations were up on the board whatsoever, so me being me I spent most of the day putting together a presentation at the last minute.

I spoke for an hour about How to Design Applications People Love. I’ll add more to this post later after I decompress with some TV, but here’s my PowerPoint:

All in all, it turned out really well – I’ll try to update this post with some more detail tomorrow.

Update 7/13/2010

Ok, here’s the run-down of my talk:

1. We all begin with ideas for new applications or products, but in order to determine if it’s worth actually pursuing any given idea we have to determine who the product’s core user group actually is and whether or not they’d actually use it enough to merit its production.
2. We begin this determination using “the onion process,” a name I invented on Sunday morning, which elegantly formalizes the process I’ve been using for my latest group of projects.
3. During our execution of the onion process, we inevitably make a number of assumptions about our application / product’s users – therefore we have to map out those assumptions explicitly so we can systematically test them when we start our customer / user engagement process. I find that it’s best to use a mind map for this, but a simple outline can work too.
4. Once we have our assumptions outlined, we have to test them by interviewing potential users and determine if and where we are on/off-target.
5. Let the process of churning begin.

If you enjoyed this post, remember to subscribe to my RSS feed!

General BarCamp, application design, apps, startups

One of the other things I took away from Code Camp was a bit of .NET culture shock. As you can tell by glimpsing around on this blog, I am somewhat enamored with the idea of starting my own business. I’m a natural entrepreneur and it is my wont to think about startups constantly.

That being said, I’ve always wondered why a platform as widely adopted and supported as .NET isn’t more visible in startup culture. Many major open source  platforms and languages have very visible and vocal presences in the startup community, everything from mainstays like Python and PHP to even the more obscure and specialized ones like Clojure and Hadoop.

.NET on the other hand is conspicuously absent from the startup conversation despite the fact that it is a singularly larger platform than any of the others.

It’s like there’s a silent majority among the development community that just tinkers away on its own projects without even occasionally raising its hands and saying “here’s something clever and unique we did with this platform that no one else has done before.”

It’s somewhat tragic for the .NET community too – because the perceived lack of sex-appeal on the surface doesn’t match the reality of what the platform is capable of.

Just take a brief moment to peruse through CodePlex for more than a couple minutes and you’ll find thousands upon thousands of examples creative open source projects all built in .NET.

And in the startup space there actually are a number of .NET-based startups making it big, including this week’s Hacker News / Social Media darling Woot. But why oh why isn’t there a louder .NET voice in the startup community? Why aren’t there developers from Woot working with developers from StackOverFlow (also implemented in .NET) to encourage more startups to use the extensive .NET stack to create new and exciting products and services?

And most importantly, why aren’t there more startups adopting .NET?

It’s All about the Enterprise

I’ve heard all sorts of lame answers to this question before: “platform lock-in,” “no open standards,” “licensing costs,” and none of them pass the test of objective reality – yes, those are issues that might prevent some developers from adopting .NET in the startup space, but not enough to bar virtually all of them from using .NET, arguably the most comprehensive and versatile platform with the best tools and the best support.¹

At Code Camp I think I finally figured out why this is: it’s the culture of the .NET community itself, not anything specific to the platform or the architecture which supports it.

.NET culture is centered around the concerns of  the enterprise – the large already-established businesses in the economy, not plucky up-and-coming startups. And when I say “culture,” I’m not talking about the development tools – I’m talking about where the hearts and minds of the developers who use the .NET platform are. I’m talking about the blogs and media sources .NET developers read. I’m talking about the networks where .NET developers contribute and the substance of their conversations.

Most of the developers I met developed portals for giant healthcare providers with thousands of employees, worked on legacy code whose lifespan could be measured in decades, worked in teams with hundreds and even thousands of programmers, and lived in ecosystems ruled by large bureaucracies. These are problems to which few if any developers for startups can relate.

That’s why so many of the talks at Code Camp were staked around RAD methodologies for developing internal projects, coding standards, enterprise architecture, and other things that matter to developers who work in giant ecosystems.

And who can blame Microsoft for catering to the enterprise market – that’s where the money is! No one ever became rich selling high-end development tools to a handful of capital-starved, small companies.

However, the consequences of the .NET community’s enterprise-centric culture is that the startup community and the .NET community don’t overlap as much as they do for other technologies.

As a result, developers working for startups and even the startup founders themselves don’t get much exposure to .NET and don’t think of it as an applicable tool for their purposes.

The flipside is that many .NET developers who want to work for hot startups don’t have as many opportunities to do so unless they abandon the platform for a more “startup-friendly” one or start a company themselves.

So what do the members of the .NET community fuss over? They worry about supporting legacy systems, building enterprise architectures which can service multiple departments, they worry about large systems for supporting in-house business processes, and they worry about satisfying the needs of stakeholders throughout their companies.

.NET developers in general, worry about architecture in order to support systems.

Members of the startup community fuss over a very different set of issues – they’re their own stakeholders, they worry about concurrency, they worry about scalability, they worry about user experience design, they worry about supporting multiple clients and browsers, and they worry about how their designs will impact their bottom line.

Startup developers in general, worry about architecture in order to support products.

See the difference? .NET is perfectly capable of fulfilling the needs of product designers and startups, but comparatively little² of the .NET culture, literature, and conversation is product-centric – instead the majority of it is structured around using .NET to support the needs of the business, not building the business’ products itself!

But It Doesn’t Have to Be

One thing that should be clear here is that any platform, not just .NET, can be used as a platform for building enterprise technology and for building new products. The platforms don’t often dictate their use – that’s the work of the people who develop on them.

If Microsoft wants to make a splash in the startup scene with .NET, and I have every reason to believe they do, then they need to do a better job evangelizing .NET’s capacity from a holistic new service / new product / new business perspective and not just for the enterprise.

Enterprise and startups aren’t mutually exclusive – they’re just different stages in the evolution of software, and there’s no reason why the startup community shouldn’t look at .NET as an attractive starting point for a new business.

The next article I’m going to write on this subject will cover why it’s a good idea for Microsoft to have .NET adopted more readily by the startup community.

If you enjoyed this post, remember to subscribe to my RSS feed!

.NET, Startup .NET, startups, Code Camp

I wanted to take the time to follow up on some of the additional lessons I learned from my May startup project, some of which I already shared in The Myth of the Single-Person Startup.

This week I decided to indefinitely postpone my startup project, the same project I spent a month of unpaid leave working on sixteen hours a day. The decision wasn't at all painful, and I came away from it feeling oddly successful and much wiser for it. The project taught me a lot of hard-earned lessons, the kind you only learn experientially, and all it cost me was a couple of paychecks - not bad considering that I don't have any obligations outside of paying my rent on the first of the month at this stage in my life.

But back to the point of this article: learning when it's time to walk away from a project. I have no idea how hard it is for other people to dump something into which they've invested a lot of emotional energy, time, and even money, but for me all it took was recognizing the following things:

1. The effort needed to actually implement the project's MVP (minimum viable product) grows explosively even though you're not adding any new features or functionality.

   I suspect that anyone who reads this is going to think "well, why don't you reduce the complexity of your MVP then?" to which I reply "the point of an MVP is that that's as simple as it gets - you can't reduce it." Reducing my initial feature set wasn't an option given the competition in my space as it would forgo requiring my product's differentiation - although I had plans for something much more grandiose down the road, my vision of an MVP was assuredly realistic and modest on paper.

   However, when it came time for implementation I came to appreciate just how complicated some of the mundane details of the project truly were. It wasn't over-engineering, it wasn't poor design, and it wasn't any of the usual suspects - it was that I was unable to realize the full scope of the project's complexity without getting into the guts of it.

2. The competitive space and surrounding ecosystem is changing more rapidly than you can keep pace with.

   My idea (a social media analytics tool for marketers) is in a domain with lots of fast-moving competitors. Although none of the present competitors have built anything that truly captures the value or essence of my idea, they're rolling out innovations and new products at a pace I cannot maintain, and they're better suited than I am to adapt to rapid changes in the surrounding environment, such as Facebook's rapid changes to its APIs.

   I'm a one-man startup trying to compete with well-funded companies in an explosively innovative space - without quitting my day job, finding funding, and building a team, things I'm not suited to do presently, it's a battle that would have been difficult for me to fight.

3. The technical depth of the product goes beyond your technical expertise.

   This is also called "getting in over your head." As you can probably tell by looking around this website, my real world experience in software development is wanting not for lack of intellectual effort mind you. It's largely because I've been out of a computer science program for two years working full-time as a marketer.

   Nevertheless, I'm enthusiastic about getting back into it and I was excited to take on a big project like this. Unfortunately, I learned quickly that an MVP for a startup is a terrible place to catch up on programming techniques and technologies.

It's was really the combination of all three of these that drove me to ultimately shelve the project, rather than any single one. I'm sure with enough ingenuity and effort one could find the resources and methods to overcome at least one of these problems, but all three at once was too daunting for a young solo entrepreneur who was still working full time.

If you enjoyed this post, remember to subscribe to my RSS feed!

Startup startups

During the month of May, 2010 I took an unpaid leave of absence from work for the entire month and set off to launch my own web-based startup company.

My objective was to take a month off work, shut myself away in my apartment, spend a month coding up all of the basic plumbing I needed to get the first core part of my service in working order, and profit. Needless to say, I failed to reach my goals,  but not for any of the typical reasons like poor project planning, lack-of-focus, and so forth. No, I failed because I took the experiences of other entrepreneurs too literally and tried to “be my own boss,” without appreciating what that really means.

Success doesn't occur in a vaccuum

I grew up with a father who successfully launched his own self-funded business and made it look easy. Naturally, being the 24 year-old who doesn’t know any better, I figured it was as easy as having the technical knowledge to engineer my own product, having a good eye for end-user requirements, having a decent business plan, and enough time / resources to actually put something to market.

Naturally, when I finally secured the time I needed to begin engineering my product in earnest, I shut myself away, locked out virtually all human contact, and dove head first into my code. After all, that’s all what successful single-person startups do, right? “Sure,” I thought.

Twelve days into my project I had to scrap virtually every piece of code I had written – everything. It was a disaster. I wiped the slate clean and started redesigning and refactoring the entire thing, and I still hadn’t said more than a few sentences about it to anybody. Bear in mind that I was living off of my savings, so the time = money factor loomed large over my head. I went back to work on my project, still determined to get something done.

With one week to go before I was due back at work, I bought lunch for the Chief Architect from my regular job and had him take a look at some of my UML diagrams. I explained the domain I was working in, what I was trying to do, and what trouble I had run into thus far. In that one hour of speaking with him, I learned things that could have saved me the previous three weeks of 16-hour days, sleepless nights, endless debugging, and lessons-learned-the-hard-way.

This is going to seem like a total “no shit” observation for people who’ve been around the block before, but bear with me: though there are many entrepreneurs who successfully start businesses where they are the sole founder and first employee, they never truly do it alone.

They use other colleagues as sounding boards for ideas; they run design ideas by people who are familiar with the business or engineering domain; they stay in touch with potential customers and clients all the way through the process; they operate in professional networks; and they do a much better job keeping friends and family in the loop than I did.

I never looked at any of these contacts as must-have items before I set off on my own, and I got burned big time for it. I spent a substantial amount of time barking up the wrong trees and architecting solutions for the wrong problems, and all it would have taken to avoid that was some more collaboration and idea-sharing with people who were never going to be partners, employees, investors, et al.

Stay in the loop with your people

Lesson learned: the appeal of locking yourself in a confined space with nothing more than an Internet connection, a stack of programming books, and a mountain of pop tarts is significant if you’re young and tired of people telling you what to do.

However, isolating yourself from the world while you undertake a startup project is disastrous – you don’t necessarily need partners working with you day-in and day-out on the project, but you absolutely need sounding boards and supportive people you can share ideas and experiences with, because ultimately if you don’t get some outside perspective on what you’re doing, you’ll make myopic decisions and stumble along the way.

Get feedback where you can; talk database schema with the DBA in the break room at your day job while he’s refilling his coffee; share your ongoing startup problems with family and friends who’ve launched businesses before; join online news groups and connect with other people familiar with your problem domain; just stay in contact.

Remember this: being independent isn't the same thing as being alone - always keep a network to support you even if their contributions never amount to something more than friendly advice and encouragement.

If you enjoyed this post, remember to subscribe to my RSS feed!

Startup startups