Anonymous Hex

PhizzPop ‘08

jdsmith — Tue, 18 Nov 2008 17:19:08 GMT

Technorati Tags: Microsoft,Clarity Consulting,PhizzPop,Surface,Silverlight,touch

The ‘08 PhizzPop Design Challenge takes place this Thursday night (11/20) around 7:00 PM at the Chicago Cultural Center (@ Washington and Michigan Ave). More info here.

Clarity won the Chicago event in ‘07. All new teams this year, so we can’t defend out title, but we’ll be back as judges belittling the efforts of this years contestants! We’re also planning to show some top-secret Clarity stuff that you won’t want to miss. You can register for the event at phizzpop.com.

Got a great idea? A VC that will probably listen to your pitch (and it’s one that you probably never thought of).

jdsmith — Mon, 25 Aug 2008 17:40:09 GMT

Technorati Tags: Clarity Consulting,venture capital,entrepreneur

I’ve attended a slew of tech conferences/unconferences, speaking events, happy hours, etc. over the last few months and noticed a theme. A lot of people view corporations as a sort of developmental league for technology start-ups. When an employee comes up with a good idea, the first thing they should do is hire an attorney so their employer doesn’t try to “steal” it. The next steps: pitch your idea to a VC, get funding, and grow rich.

Here’s what I don’t get: why are people afraid of sharing their ideas with their employer and dead set on starting from scratch?

Don’t get me wrong. There are lots of upsides to striking out on your own. It’s a challenge to build a company, there’s potential for a huge reward – both financial and a sense of accomplishment, there’s a lot of freedom in being your own boss, you might get Scobleized or Kawasakied or Arringtoned. But it’s also hard as hell. You probably have a better shot of getting into the NBA than launching the next Google (NOTE: for you current/retired pro b-ball players that read this blog, pretend I just wrote “FIFA”; Sergei and Larry… see you guys at the thing).

But there are some significant upsides to “pitching” your employer. First and foremost, it’s probably the easiest meeting you’ll ever get with a potential investor. I don’t know the exact number, but I’d guess VCs meet with less than 1% of the individuals that approach them. Who do you think is more willing to take a chance on you? Your current employer or a bunch of guys/women managing $500M in investors’ coin who have never heard of you? A small or medium business might not have the deep pockets of a Silicon Valley VC firm, but they probably aren’t looking for a 10x return on investment, either.

I’m not suggesting that you give away your idea to your employer. If it’s a great idea, one that can make money for your employer, you deserve a share of those profits. Just like a VC, though, if your employer agrees to take on the risk, they deserve a piece of those profits, too. Nor am I suggesting that your current employer will say “yes” to every idea. Lots of Clarity employees – both current employees and alums – have “pitched” interesting (and sometimes fantastic) ideas to Clarity’s management team that didn’t align well with our business or required a bigger investment than we’re capable of making. So we passed. And some of them went elsewhere. But I appreciated the fact that they brought it to us first, and hats off to them for believing so strongly in their ideas. Nor do I believe that every employer has a heart of gold. If you’re working for a jerk (or a gaggle of jerks), don’t waste your time.

So, the next time you come up with a $1M (or $1B) idea, consider talking to your employer. “innerVenture Capital” or iVC (thanks, kmarshall) is often the easiest money to get.

PS – Clarity made the Inc. 5000!

The end of entrepreneurism (if you’re talking to me)

jdsmith — Thu, 14 Aug 2008 21:05:40 GMT

Technorati Tags: Clarity Consulting,entrepreneur,accomplipreneur

I just read an article that used the word “entrepreneur” at least 20 times in two pages (before I stopped counting). “Entrepreneur” and its sinister step-child “serial entrepreneur” are so overused they are almost meaningless. Seems like anyone who quits their job refers to him/herself as an entrepreneur. It’s the business world equivalent of an Ed Hardy shirt: their rarity made them cool, but now they’re everywhere…and not so cool.

Entrepreneur comes from the French word “entreprendre” which means “to undertake.” I think that sells “real” entrepreneurs short. The best ones don’t just undertake a task; they finish it. They might make mistakes, but they finish. There’s already a demeaning term for the pretenders (“wantrapreneur”), so I'm giving the finishers a new title: accomplipreneur. Now to come up with a way to make sure only those deserving of the title get it…

How Long is the Long Tail?

jdsmith — Fri, 25 Jul 2008 14:27:44 GMT

Fed up with the (un)reliability of Chicago’s rail transit system (the “El”), we’ve kicked around the idea of a crowd-sourced train tracking system for a while. Well, one of our fearless Consultants took on the task and created Where The El. The app is a neat combination of Google Maps and twitter. The time frames, which increased exponentially with each step, were amazing. Some real data:

Time spent talking about how great an El-tracking system would be: about 2 years
Time required to develop said El-tracking system: about 2 days(!)
Number of people marketing the system: 2 (who each sent one e-mail to about 10 people)
Time To First “Real” User (TTFRU; does Google Analytics track that?): about 2 minutes
Time To First Media Inquiry(TTFMI): about 2 hours

Technorati Tags: CTA,Google Maps,twitter,crowdsourcing,Clarity Consulting

The ideal project manager, um, software developer, make that employee

jdsmith — Fri, 06 Jun 2008 17:30:55 GMT

Technorati Tags: recruiting,software development

Being a services firm, recruiting is one of our most important (and challenging) functions. Rather than hiring specialists, we tend to hire Jacks-and-Jills-of-all-trades. We look for people that know a lot of different software technologies, people who always want to learn more, and people with strong non-technical skills.

As we grow, it becomes harder and harder to "teach" the newest employees what we look for in candidates. To help describe what we're looking for in the interview process, we came up with the concept of an "Ideal Employee Law":

Programming Experience * Problem Solving Skills * Ability/Interest to Learn Technical Things = Energy/Attitude * Consulting Skills * Professional Skills * Communication Skills * Leadership Skills * The “Everything Else” Constant

The name might ring a bell with anyone who took high school chemistry.It's sort of a “PV=nRT” for recruiting. What's it mean?

The "product" of the attributes on the left (technical skills) has to "equal" the product of the attributes on the right (non-technical skills). In short, the best candidates have strong technical skills AND strong "soft" skills like communication skills, organization skills, and leadership skills.
A strength in one skill can offset a deficit in another. For example, we'd overlook a candidate's relatively "light" programming experience if they provide proof of an exceptional ability to learn new technical skills (because, hey, if they can learn new technical things, they can learn a new programming language). However, skills on the left side of the equation can't replace those on the right or vice-versa. In other words, even the best communication skills can’t offset a lack of programming skills.
There's a sort of “Plank's Constant” involved (the "Everything Else Constant") which means we have a min. bar that every candidate must exceed. It's a high bar. It also provides us a way to “tune” the formula based on a candidate’s overall work experience. We don’t expect a senior in college to have the same skills as someone with ten years of industry experience.
We don't actually use a “formula” when evaluating candidates, but we absolutely use the concepts it embodies.

The attributes above are pretty specific to our line of work, but I think the principle applies to any job hence the title of this post. The emphasis is on a broad range of skills rather than specific attributes, so it really can work with almost any job. Feel free to plug in your own. It’s also my belief that somebody who fits the above equation will do well in almost any activity in which they participate. More than one of our employees came with a reference from a former supervisor along the lines of “I don’t know what this person’s job will entail, but you’d be an idiot not to hire him.”

These people are out there but certainly not en masse. We extend offers to less than 10% of the candidates we interview. The upside is that we end up with strong software developers that can also communicate with our clients, understand a client’s business, with whom the client enjoys working, eventually lead a team, and are highly interchangeable among projects. The “downside” is that once our clients work with these people, they never want them to leave <g>. The developers also free up our Engagement Managers’ time to concentrate on other issues. Likewise, because our Engagement Managers have strong technology backgrounds, they can accurately estimate development effort (so they rarely over-promise), help the more junior people on the project solve difficult programming problems, teach “programmers” how to become “team leads”, etc. It also enables us to staff smaller teams which saves our clients $$.

In my experience, IT firms tend to look for people that only fill out one side of the Ideal Employee equation, and they end up with top-notch programmers that can’t see the big picture or project managers that have no idea what the team is working on (nor can they help with difficult issues).

What happens when the shoe doesn't fit?

jdsmith — Fri, 30 May 2008 17:59:00 GMT

Our firm does a significant amount of user experience and graphic design work. I don't have a background in either (although I can draw a pretty kick ass circle), but it's neat to see how the folks with training in creative design go about their work.

We've always described our employees and our approach as "pragmatic", and the graphic artists we employ are among the most pragmatic of the bunch. They don't necessarily work faster than the ladies and gents who focus on application development, but they follow a process and rarely waste cycles. What's more, the rigor they employ doesn't crimp their creativity. And even though they work on a wide variety of projects, they're always efficient. Their process amounts to what I'd consider a methodology, and the first step in their methodology is "figure out what's going to work for this project."

That's different from the typical line-of-business application project that adopts one of two approaches: the Screw Process! (or "Two Dudes") approach or the Process Rules! approach. I think most people will agree that the "Two Dudes" approach rarely ends in success. But what about projects where the team conforms rigidly to a methodology? Isn't that supposed to ensure success?

In my experience, the Process Rules! projects succeed much less often than you'd expect. It's not because the team is following a process. It's because they're following the wrong process.

Re-read the second paragraph. Process is important, but the same steps won't solve every problem. Seems obvious, right? But that's what people often try to do with software development. They don't consider which methodologies are well-suited for their project (mistake #1); they use the methodology "as is" (mistake #2); they punish people who veer from the prescribed steps even when it yields better results (mistake #3). In short, they get hung up on the methodology.

Successful software development teams:

Involve smart people. This is so important. More on that in another post.
Consider the project's characteristics and determine which methodologies are geared toward their project's success factors and limitations.
Use a methodology as a starting point but customize it for their project.
Adapt midstream if something isn't working.
Mix methodologies. Specifically, they combine concepts from several methodologies. 80% XP and 20% Scrum? That can work.
Repeat these steps on all projects.

I understand why teams take a liking to pre-packaged methodologies. People assume strict adherence to a process lowers risk, and that's often true when you're dealing with repetitive tasks like disarming bombs or shutting down a nuclear reactor. If you modify or stray from the process, you increase risk (ironically, concepts common to many methodologies and the ones with which I agree the most - notably, that it's tough to predict the cost/duration of a project up front; that it's possible to gather all requirements up front - are often seen by "management" as the worst parts of a methodology and, as such, are ignored). But software development isn't a repeatable process.

When a potential client asks us to describe our methodology, we generally tell them we need more information before we can determine the right approach. Does XP make sense in this case? Will Scrum help us? We didn't invent this. I've talked to dozens of successful people and heard countless successful business leaders speak, and they all say the same thing: when faced with a problem, they figured out what was going to work for them even if it broke some rules. I'm not suggesting teams need to reinvent the wheel. Methodologies like XP, Scrum, RUP, Iterative, Spiral and "Agile" are based around solid ideals. They just don't work "as is" in every case.