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…
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
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).
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.