|
|
|
Displaying posts tagged "start-ups" (Clear Search) Wednesday, January 20th, 2010
By Tyler King
I recently had a conversation with someone about what type of people a start-up company should hire. I obviously weigh the importance of technology more heavily than most people, but I'm of the opinion that one of the first hires any company makes should be a CTO (or just a developer if we're being honest).
The purpose of this blog post is to discuss the merits of different types of developer hires. Here are some assumptions:
Considering these assumptions, I see two main hiring questions: (1) How much money can you really justify spending on a tech guy, and (2) what is the appropriate balance of experience vs. talent.
Let's start with the second question (weird, right?). One important thing to be aware of when deciding between experience and talent is your own ability to measure both qualities. Raw talent is pretty easy to judge when it comes to technology. Any strong developer should be able to show you something they've built. It could be a web app, a video game, or a school project. Whatever it is, you should be able to play around with it and decide if this person has the technical skill you're looking for.
Experience seems a little harder to gauge because it is almost entirely intangible. Working at a company doesn't necessarily provide "experience" unless a person is actually faced with challenging problems that they can learn from. A resume is helpful, but there's just no way to know how a candidate will perform in the real world. I've also never really believed that references are trustworthy.
Having said all that, I think experience is potentially much more valuable than raw talent, mostly because a candidate can only gain valuable experience if they are already talented. However, because I don't think anyone is any good at evaluating experience, I would probably try to hire someone that has ridiculous technical chops with the expectation that they will need to be managed by a non-technical person.
Presumably, the company already has a leadership team with lots of business experience. These people should be knowledgeable enough to guide a 22 year old programmer. The main mistakes a young developer might make are almost entirely business related (poor communication skills, lack of end-user focus, etc.) and a non-technical person can help with that. The opposite is not true. If you hire an experience developer that isn't a technical rock star, they will eventually run into a tricky tech problem that they won't be able to solve.
You might be wondering why I'm acting like experience and talent are mutually exclusive. That gets us to the first question we originally asked: how much should this developer cost? I think a company can hire great talent right out of college for about $80k per year. Great experience will cost more like $120k per year. Both will cost $250k or more. I just don't think it's worth paying that premium for experience that other members of the company already have (for the most part).
An added perk to hiring a young person is that there is a small chance they will end up being truly remarkable. You pretty much know the ceiling for a 35 year old. If they're looking for a $120k salary, that means they're only worth $120k. A 22 year old might be worth $500k, but nobody knows that yet so they have to prove themselves. When a talented 22 year old asks for $80k, that's their floor, not their ceiling.
So obviously every case is different, but if I had to give general advice it would be to hire the most talented young person you can find. Make sure a founder or manager will have time to carefully oversee this developer so that his or her inexperience won't be much of a problem, and hope that over the next few years, this person grows into the CTO your company really needs. If that doesn't happen, hire a real CTO when the company is more mature and can justify the cost.
What do you think? If you have to speak in generalities, what type of person makes for a good early technical hire?
Saturday, January 9th, 2010
By Tyler King
One of the things that I love most about working at Less Annoying Software is that we don't have any artificial barriers between us and our work. If we need a new feature, I'm free to design, implement and deploy it without anything getting in the way. When I'm done, I let Bracken know about it just so we're on the same page.
It's really tempting to try to add more structure to the process. We could have more sophisticated bug tracking software, we could be more careful about documenting internal practices on our wiki, we could have a more formal review process before deploying new code, and we could carefully track how our time is being spent. All those things seem like good ideas mostly because that's just how things are done. That's how big companies do things, and it seems like we should follow their lead since they must know what they're doing.
It seems like a good idea to do what the big guys do, but it isn't. Big companies have so much structure because they have to, not because they want to. When you have thousands of employees, you have to use complicated time tracking software because it's impossible for the executives to really know how productive the employees are. You have to schedule tons of meetings just to keep everyone on the same page. You have to invest time and money in annoying infrastructure just to keep the entire company from collapsing.
Big companies do those things because they have to. Small companies don't have to, and that's the only reason us little guys can compete. We can stay agile and quick. If a new technology or trend comes out, we can adjust without an endless approval process. If a customer has an idea or complaint, they can send it directly to a developer (me) and I have the freedom to work on it immediately if it's important. That's one of the main competitive advantages small companies have, so why ruin that by adding needless overhead?
In sports, you're taught to attack your opponent's weakness. If a football team has a strong rush defense, pass against them. If a baseball team has a great hitter, walk him and move on to the weaker players on the team. When a small company tries to mimic the practices of a bigger company just because "that's how things are done", that's basically the same as deciding to match up your greatest weakness with your opponent's greatest strength.
That's not to say that there shouldn't be any structure at start-up companies. The key is to identify the things that you need to do versus the things that you're only doing to maintain the status quo. Over time you may need to adopt new processes as the company grows, but the company might not be able to grow in the first place if you get ahead of yourself.
Saturday, September 19th, 2009
By Tyler King
I got in an interesting conversation tonight with a friend of mine that works as a sales rep. We were talking about his job, and we somehow got on the topic of how important the product is to a salesperson. His claim was that the product is completely irrelevant to a salesperson because you can either sell or you can't and it's not actually about what you're selling.
Obviously this is ridiculous, but I want to discuss it anyway because it leads to some other thoughts. First, saying "a salesperson can sell" seems eerily similar to baseball fans saying that a good pitcher knows how to win games. If a pitcher's team doesn't score any runs, the pitcher may very well lose despite throwing an amazing game. There's some sort of weird jock logic that makes people think "winners win" and I believe it's the same attitude that leads someone to believe they can sell regardless of the product.
If we look at this from a developer's point of view, it would be possible to take a similarly naive position. I can create great software regardless of what the marketing and sales people do. I can make a product great so there's no reason to care about sales or marketing. It's true that the product can be great, but what's the point of making a great product if you can't sell it?
So I think we can all agree that a salesperson can't sell a product that doesn't exist and there's no point in a developer create a product that has no way of being distributed. Similarly, HR, operations, and IT are all important. However, most start-up companies (particularly those that bootstrap like we do) are short on resources and have to pick one or two core competencies. When deciding between development and sales, what should a company focus on?
Well, while there's no question both are needed equally (for most companies), that doesn't mean that you can't easily decide which comes first. This is not a "chicken or the egg" situation. Obviously, you develop a product first, and then you sell it. When a company is getting started, it's worth thinking about marketing and sales, but it would be ridiculous to prioritize either of those areas above development until you actually have a product to sell.
|
New posts will be emailed to you each night
About this blog
This is a blog for small businesses interested in how they can better use technology. Most tech
is targetted at either individual consumers or huge corporations. We'll help you find the tools
that are powerful enough to help run your business, but simple enough that you won't need an I.T.
team to use them.
There are two main writers on the Less Annoying Blog: Tyler has worked on the tech side of several small businesses and knows first hand what the little guys need, and don't need. Bracken is finishing up a PhD at MIT and he's always experimenting with any new software he can get his hands on. We also run an online customer manager tool called Less Annoying Software which was created specifically for small businesses to track all their customer activity.
Search the blog
Tips and Feedback
We obviously want to write about things that you want to read, so help us out! If you are
interested in reading about a particular topic, let us know. We're also always on the lookout for
new software and tools to try out (and review), so feel free to forward information on any new
tech you'd like us to write about.
You can reach us at blog@LessAnnoyingSoftware.com
Archives
|
