The CEO's job
jessicamah.com
The CEO's job
1–10 of 39 posts
Re: The CEO's job
#2I agree that a startup should hire multi-talented people. But it's a bit extreme to say that startups should hire people who can do UI design, backend programming, and do business deals. Certainly such people are useful, but they're incredibly rare and are probably more interested in founding their own startup.
Also, I don't agree with the "just contract it out" philosophy. The problem you run into with contractors is that even if they're good, they don't have anything invested in what they produce. They don't have to live with it long-term.
I'm not saying that it's bad to hire contractors, only that you have to be careful with them. And I certainly don't think that it's a good idea to hire contractors because they're easier to find and fire than full-timers. In fact, many times it can be harder.
Re: The CEO's job
#3I come from a retail management background, so I'm a newbie to the tech industry.
The guys who taught me retail management put extreme emphasis on training. Training and knowledge dissemination was a top priority for the management teams I worked with. Once I was managing my own stores, I adopted this world view and had great success.
Coming from this background I'm sometimes surprised there aren't more articles about improving the flow of knowledge and communication within organizations.
So what gives? I learn a lot of stuff on my own (as do most of my tech savvy friends), is that the way things work in tech? Or are training and communication just not discussed very often because they're seen as so elementary?
Re: The CEO's job
#4I come from a retail management background, so I'm a newbie to the tech industry. The guys who taught me retail management put extreme emphasis on training. Training and knowledge dissemination was a top priority for the management teams I worked with. Once I was managing my own stores, I adopted this world view and had great success. Coming from this background I'm sometimes surprised there aren't more articles abou…
It really depends on the organization. But in general, it's expected that you take some level of ownership over your own training. On the other hand, it's impractical to expect that people will know every element of your technology stack. Most of the time, it's expected that you know the core of the technology stack (like the programming language), but it's ok not to know every technology. And even then, you're expected to be able to get up to speed on what you don't know quickly and without sucking up too much of your peers' time.
Re: The CEO's job
#5> It's typically difficult, if not impossible, to scale up and down your engineering team in the way you can spawn up new cloud servers. We're trying to change that by having a reliable source of contract engineers who can help us grow non-essential components of our codebase.
Sounds like an awful place to work. Treating your most valuable asset as a commodity? Let me know how that works out for you.
Re: The CEO's job
#6> It's typically difficult, if not impossible, to scale up and down your engineering team in the way you can spawn up new cloud servers. We're trying to change that by having a reliable source of contract engineers who can help us grow non-essential components of our codebase. Sounds like an awful place to work. Treating your most valuable asset as a commodity? Let me know how that works out for you.
Agreed - but this is what happens when a 20 yr old is the CEO. Could MSFT have been started by contractors? I don't think so. Also, quickbooks online is 10X better, get those contractors working!
Re: The CEO's job
#7I agree that a startup should hire multi-talented people. But it's a bit extreme to say that startups should hire people who can do UI design, backend programming, and do business deals. Certainly such people are useful, but they're incredibly rare and are probably more interested in founding their own startup. Also, I don't agree with the "just contract it out" philosophy. The problem you run into with contractors i…
The important thing that I think Jess forgot to mention is that inDinero doesn't contract out critical parts of the sites. It's usually smaller things that we want to get done that aren't important enough for the full time engineers. Example is a small ad that we run to get user feedback on the dashboard page, something easy to build but not super critical part of the site.
We also make sure all contrator code goes through code reviews, which takes up my time but ensures that no code enters our site that isn't up to our caliber of quality.
P.S. I'm an engineer (Rohan) who works at inDinero in case that wasn't obvious.
Re: The CEO's job
#8> It's typically difficult, if not impossible, to scale up and down your engineering team in the way you can spawn up new cloud servers. We're trying to change that by having a reliable source of contract engineers who can help us grow non-essential components of our codebase. Sounds like an awful place to work. Treating your most valuable asset as a commodity? Let me know how that works out for you.
Agree with Ted. I've heard so many horror stories from people who thought this way in the beginning. Yishan Wong, would give you good stories about, how zuck tried the contracting route when Accel funded them and very soon pressed the hard revert button.
Jessica - I'm a YC founder too, and most people have strong opinions on this. (http://bit.ly/9uDFfe); Maybe, you should ask pg, what he thinks.
Re: The CEO's job
#9> It's typically difficult, if not impossible, to scale up and down your engineering team in the way you can spawn up new cloud servers. We're trying to change that by having a reliable source of contract engineers who can help us grow non-essential components of our codebase. Sounds like an awful place to work. Treating your most valuable asset as a commodity? Let me know how that works out for you.
> ... non-essential components of our codebase ... to build lower priority features that our core team doesn't have time to get to." [emphasis added]
Sounds like they've already got their most valuable assets, the employees, where they need them the most (presumably on core product). Using contractors to fill the lower priority gaps doesn't seem so bad in that context.
However, I could see it becoming an issue if something that was previously considered non-core suddenly turned out to be critical (e.g after changing direction based on customer/market feedback)
Re: The CEO's job
#10> It's typically difficult, if not impossible, to scale up and down your engineering team in the way you can spawn up new cloud servers. We're trying to change that by having a reliable source of contract engineers who can help us grow non-essential components of our codebase. Sounds like an awful place to work. Treating your most valuable asset as a commodity? Let me know how that works out for you.
Is the assumption that any company that wants to increase head count rapidly will treat their employees poorly?