I 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…
The CEO's job
11–20 of 39 posts
Re: The CEO's job
#12> 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
#13> 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 som…
I think Jessica Mah is misunderstanding the purpose of contractors to her and her business' detriment. Hiring contractors because the team isn't able to accomplish its tasks in a timely fashion is disastrous in the long run. What happens is that the contractors will write code in the most expedient fashion possible, without care for the long term harm to the code base. The team then sees an inexorable decline in its ability to iterate, which causes the business side to think that even more contractors are required. This self-reinforcing cycle inevitably leads to a codebase that's almost impossible to change or improve in any way; it leads to a place where moving a logo is a three week project (don't laugh, I've been there).
There is another way of approaching contracting that is more valuable for both the team and the contractor. Instead of thinking of the contractor as a hired gun whose sole responsibility is to finish a feature or fix a defect, the founder should think of the contractor as a teacher or a coach. Hire contractors when your team needs to learn a new skill or improve some aspect of their development cycle. Approaching contracting with this mindset ensures that each successive contractor hired improves, rather than degrades the team's skills. Otherwise, your team becomes trapped in a maze to which they don't know the exit, and you wonder why every new version seems to have fewer improvements and worse performance than the last.
EDIT: After further reflection, there is another way that contracting can improve the business in a sustainable fashion. I know of a few companies that practice "contract-to-hire". In other words, you're brought on as a contractor for a period of 6 months or so. During that 6 month period, you and the company have a chance to evaluate each other. At the end of that period, the company makes an offer to you if you've managed to prove yourself as a good fit for the company.
Re: The CEO's job
#14Re: The CEO's job
#15> 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
#16> 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
#17Absolutely.... If you can find someone who is _equally_ good at all of those. Very rarely (I personally have never) you will see someone _equally_ apt (and good) at both left (Writing programming logic, Solving tough technical problems etc. ) and right ( designing User Interactions, Doing business deals etc.) brained work. Humans are not programmed like that.
Sure there are people who can get by doing multiple domains, but they are rarely fit/enjoy/brilliant at all of them.
Re: The CEO's job
#18I understand that "war for talent" is a popular narrative, but you note that those writing about it are almost always journalists who aren't programmers themselves. Non-technical writers don't understand quality developers want something more than a paycheck: they want to work on challenging problems, with people who they can learn from and in a company that has a shot at making an impact on the world. If you want to hire quality people than you should take hiring (all steps: from employment branding to interviewing to closing) a top priority: give employees time to interview candidates (expect each engineer to interview at least two or three candidates each week), be willing to let a position go unfilled for a _long_ time until the right person is found.
In short, be ready to reply "we'd like to do Y, but either we must strip out a feature X from Y, spend more time working on it or transfer an engineer working on Z to work on Y". If you're working on a hard technical problem, then your investors and customers shouldn't have a problem with that. If you're not (and there's nothing wrong with that), change your hiring strategy appropriately e.g., if you're building CRM software, stop trying to go after TopCoder finalists and ex-Google Search Engineers and instead look for engineers who are interested in business and product design/development. The former aren't going to be interested in joining you (other than at an exorbitant rate) until you're ready to use their talent, the latter will help you build the business to the point where you will need their help scaling it.
To use a vulgar analogy, the strategy of hiring a contractors to "move faster" is analogous to a man having nine one night stands hoping to conceive a baby in a month ("because I can't find the right long-term partner, and nine months is too long to wait anyway"): it's wrong on many levels and will poison your culture. It's long been known (Brooks' Law) that adding more "bodies" to a project to a project that's at risk of being late will only make it more late. Creating a company full of dubious quality contractors (with no loyalty, no "fire in the belly" about the product) will make your company look toxic to engineers used to working at "talent brand" companies where engineers are passionate about what they're working on and are confident in their technical abilities.
The CEO's real job is to manage the managers ("no, we don't have the resources to ship X at time T"), and sell the company (including to prospective employees). The blog post doesn't read "wow, this is a company worth leaving or turning down an offer from {Google, Facebook, Microsoft, etc...} for!".
Re: The CEO's job
#19> Someone who can do business deals, write code, and do user interface design, is 5X more valuable to us than a typical backend engineer. Absolutely.... If you can find someone who is _equally_ good at all of those. Very rarely (I personally have never) you will see someone _equally_ apt (and good) at both left (Writing programming logic, Solving tough technical problems etc. ) and right ( designing User Interactions…
In programming, design is just as important as logic. Code not only needs to be functional, but it also needs to look good. A visually attractive codebase is much more maintainable due to the basic human response to beauty.
In design, logic is also just as important. When designing an interface, for example, you are constantly solving problems about how the user is going interact with the design. The process of getting there is exactly the same as solving a programming problem.
I think there is a lot of ebb and flow if you don't typecast yourself. As a young kid I was quite interested in the arts. I remember spending a lot of time drawing and honing my visual skills because that's what I enjoyed doing. As I got a little older, I became fascinated by logic problems, remember spending a lot of time learning how to program.
Interestingly, as it relates to this discussion, now that I have grown older still, I actually have become much more interested in business and is one of the reasons why I follow this website. While I've closed a few deals along the way, my business deal abilities definitely lag behind the aforementioned skill sets. That I chalk that up to being much less experienced, not because of any genetic hinderances, however.
It is of my opinion that the biggest limiting factor is time. I was, perhaps, lucky that I started young which afforded me more time to put focus on both design and programming. Whereas for someone else who started programming in college it becomes difficult to fit in time for other interests, such as learning design. I know I spend less time doing business type work than I would otherwise like to because my plate is already full with other jobs. Because of that I miss the opportunity to grow in that area.
Re: The CEO's job
#20> 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!