Hacker News Reader

Comment by rquantz | Hacker News Reader

Another difference between actors and the engineers the OP is talking about is that engineers are salaried employees who do a job search every few years at the most, and actors are self employed freelancers whose jobs last at most a few months. In that sense it almost doesn't make sense to talk about the unemployment rate for actors.

An area where it may make more sense for engineers to have agents is in the freelance space. Any dev shop that has a sales team is doing essentially the same thing.

I would consider paying a finder's fee to an agent-type entity who could find me decent projects and keep my pipeline full so I didn't have to worry about it.

View on HN

That's a difference now, but should it be this way? Realistically, any engineering project you work on should only be lasting a few months. If you built it correctly, you should finish it and hand it off to contractors for maintenance. Top-level engineers should be spending their time implementing hard new projects, not maintaining old ones.

Is there any inherent reason why companies could not hire top engineers on a contractual basis for 6-12 months at a time? Given how specialized many projects are, it seems it would be more efficient to do this than hiring a new specialist full-time for each new project. The only reason I see that companies do not do this now is because it simply isn't the norm.

Also, as an engineer, I would prefer to work on a new project every couple of months.

Many engineering projects (especially outside of software) can last many years, making engineer (knowledge and understanding) retention quite valuable, and the engineers involved wish to see it through. In addition, we should keep the nature of the firm in mind, and remember that keeping a team together has the potential to greatly reduce transaction and switching costs.[1]

[1] http://en.wikipedia.org/wiki/The_Nature_of_the_Firm

I'm familiar with that essay (did you also just watch Aaron Levie's stanford talk?), and that's a good point.

How greatly are transaction/switching costs affected when segmenting projects in 6-12 month intervals? I would guess, that when you're throwing senior engineers at projects, the switching costs are non-trivial, but low. It's probably an acceptable tradeoff to pay when developing specialized projects you don't expect to carry over to future ones.

There's also the argument of developing a labor force to compete with other enterprises. However, if the best engineers are in sufficiently high demand, it may be more economically rational for them to move between projects every 6-12 months, gradually increasing their pay-rate and improving their portfolio after completing each one. If this is the case, then companies would be forced to hire top engineers on a contractual basis (or pay them a significant markup annually), purely to compete in the labor market for top talent.

It was my impression that most top engineers already do this by either being freelancers or through poaching.

Or even, at the very least, by switching projects internally.

> Is there any inherent reason why companies could not hire top engineers on a contractual basis for 6-12 months at a time? If you built it correctly, you should finish it and hand it off to contractors for maintenance. Top-level engineers should be spending their time implementing hard new projects, not maintaining old ones.

Many if not most technology companies want their expertise institutionalized, especially when it comes to the most complex aspects of their business. This is where they create the most value and have the greatest opportunity to build competitive advantages. There is no incentive to outsource their high-value work to somebody who is going to be gone after a few months.

This is why companies like Google, Facebook and Apple are willing to lavish the most desirable candidates with significant cash and equity compensation.

> Also, as an engineer, I would prefer to work on a new project every couple of months.

Become a consultant. You may be able to make a lot more money, but:

1. You may find that there are no opportunities to work for the type of companies you'd like to work for because they don't hire consultants in any real volume.

2. Limiting yourself to two or three month engagements will exclude many of the lucrative opportunities, which typically demand multi-month if not years-long commitments.

Hi -- I checked out your other comments. I really like your perspective. If you would be willing to chat with me, I'm graduating in December and looking for the next opportunity. Email in profile, if you're interested/have time. Thanks.

In #2 are the "lucrative opportunities" for consulting on a multi-month/year contract or were you referring to the equity/benefits/stability of being a salaried employee?

I was referring to lucrative consulting opportunities.

Side note: the "equity/benefits/stability of being a salaried employee" are somewhat overestimated.

1. Equity has risks associated with it that are discounted during good times but become painfully obvious when the business cycle turns. Think Google or Facebook are great companies with bright futures? You can buy their shares without having to work for them for 4 years.

2. If you're working as a high-end consultant, you will easily be earning enough to create a tailored benefits package for yourself. For instance, you can set up a self-directed 401(k) and defer up to $18,000 of your salary (2015 limit). Your business can also contribute up to 25% (or 20% if you're a sole proprietor) of its profit as a profit-sharing contribution. All told, you can stash away up to $53,000/year pre-tax in a 401(k).

3. Stability is an illusion. Most salaried employees are at-will and can be terminated at any time for any reason, or no reason at all.

I completely agree with you. And honestly, I'm surprised how many people on these salary/negotiation HN threads say startup equity is a serious part of their financial plan. I treat any equity offer like Monopoly money -- it's probably worthless, but if not then it's just a nice surprise.

By the way, any advice for salaried engineers who'd like to start consulting? Anything you wish you'd known or things you'd do differently in hindsight?

Few people get rich on salary. There are many, many examples of folks rich off of equity. They are clearly different propositions, and the value people assign to them depends on the person.

> There are many, many examples of folks rich off of equity.

This is true, but you need to look at who they actually are. The majority of folks who become fabulously wealthy off of equity (read: owning a piece of a business) are the folks who start those businesses and manage to hold on to most or all of the equity.

Most of these businesses are obviously not in tech, but if you want to filter out non-tech companies, the power law distribution of equity-derived wealth in Silicon Valley still doesn't favor employees, even those who join companies early on.

And yet I know several personally. Wealthy off of equity from being early employees. Maybe half a dozen. That's enough to make a person believe.

Yes, there are anecdotes of individuals who had a large payout from being an early employee. It's a major risk/reward proposition, and the likelihood of the reward is quite low.

It's basically like being paid in lottery tickets. Fine so long as the rest of your salary is enough to pay the bills, not fine if you depend on it for your retirement, and either way, some of us would prefer the well defined payout of cash.

Except its not really like that at all. You get paid in cash plus equity. The value of the equity part is somewhat under your control. Hard to affect the value of the lottery ticket.

It may seem hopeless, and indeed many other factors do make good product companies fail. But when other factors do NOT intervene, then the remaining value does depend on your execution.

I think you both are right and therefore you both have answers to your own question. The freelancer model is supposedly ideal: the company pays for a project, the engineer works on it for a definite time, and then both move on. No internal politics, promotions, boring projects, relocations, layoffs, etc.

The price to pay is that you have to find a job every 3-9 months, and that's not easy, even if your skillset is in high demand. You'd have to invest a significant amount of time. Conversely, the company couldn't build upon assets that they invested heavily in to acquire (job postings, resume screenings, interviews, offers, training, firing, etc.). If a reliable 3rd party could act as the agent for engineers, vetting their skills and credentials, maybe this market could become more fluid, but even if the benefits would be huge, the article clearly explains why the environment is not favorable.

It would make sense to bring on someone with knowledge that isn't held in house (i.e., you need to interact with X, and no one is familiar with X, so hire someone for a few months who knows X backwards and forwards), on a contract to contract basis, but it doesn't make sense to do that for the entirety of new development. The cost to bring someone up to speed can be quite sizable, and you're looking at paying out that cost again every time you replace a contractor.

Similarly, I really, -really- dislike the idea of institutionalized discrepancies between "the rockstars who develop" and the "grunts who maintain it". Because then any problems with your code after the initial "it works"...are blamed on the maintainers not being good enough, rather than the fact you wrote it as quickly as possible, without concerns for long term sustainability. In fact, it provides an incentive to getting code written as quickly and sloppily as possible, rather than as robustly and maintainable as possible.

Great points, re: discrepancies. In a way, I'm seeing both sides of the coin with a client for whom I designed and developed custom business software. Initial monthly budget gave me the flexibility to be a rockstar that actually put in quality tests and refactored for long-term maintainability.

The client is happily using the software and has many more ideas to implement, some of which I supplied! The system helped them explosively grow their business but over time has become part of the daily business routine which inevitably means they want to reduce costs.

Naturally, this means we are building fewer features each month but the cost focus pressures me to sacrifice some refactoring, testing, and UX quality which makes me feel more like the grunt that maintains it. On the plus side, my effective hourly rate has improved since I negotiated a fixed monthly fee into our contract and I've had time to find a couple more clients :)

Well if company uses something or does something that is not common in market place and becoming fluent in it takes month or two. Changing engineers all the time would mean that no matter how hard core coder would come he would be total newbie in terms of productivity for a while compared to average programmer who just stayed there and knows both the programming environment and target market for programs inside out.

> Top-level engineers should be spending their time implementing hard new projects, not maintaining old ones.

Au contraire. Top-level engineers should still spend much of their time on maintaining projects they designed, otherwise they start forgetting what works in the long run and what does not. It's not that good engineer throws in some secret juice only most advanced know; it's that good engineer knows what makes problems when maintaining the system or scaling it up.

Only unpopular or unscalable software projects are done in a few months. What you're describing is already the norm for custom internal software or other categories of software that aren't necessarily designed to scale beyond a specific purpose. This kind of work is often outsourced to contractors who are hired for months. But the reason that these projects have a definite time horizon is because they are seen as the cost of doing business, not a core revenue generator.

Successful, scalable, revenue-generating software projects that compete in a big market, on the other hand, are never finished. Microsoft still has top engineers working on Excel and Windows. Google almost certainly has some of their best people incrementally improving Search and Maps and Gmail. Many of Amazon's top engineers are working on improving AWS. Apple's certainly not transferring their best engineers off iOS.

The economics of software competition is such that making even a very small improvement to a successful software project that scales to millions of users can be worth billions of dollars, while creating entirely from scratch something that is half as good as another extremely valuable software project can be worth close to nothing. This means an extremely large number of top engineers are going to be working on incremental improvements to successful products purely as a matter of economic necessity.

Also, the idea that top-level engineers should constantly move to new projects is superficially alluring because new projects are supposed to be fun and challenging and the best people should be rewarded with fun and challenging tasks, but in the real world, engineering is mostly about constraints. From a product standpoint, coming up with a new product is challenging, but from a software engineering standpoint, greenfield development is not very challenging because there are so few constraints that make engineering difficult.

Edit: I'd also add that in companies that specialize in the type of projects I described in the first paragraph, what you're advocating is pretty much what happens - the best developers in non-product companies often become architects and managers who get to make technology choices, talk to clients, produce specs and/or working prototypes, while their less-talented, lower-ranking peers are left to deal with the details and implementation issues. When quality isn't important, this is efficient.

Edit2: I think part of the reason why people get the impression you do is that most people's greenfield projects are disproportionately fun hobbyist projects where they get to be the sole guy in charge, whereas most people's non-greenfield projects are disproportionately corporate projects where they are subordinate to the wishes of many others, including other developers, managers, product people, customers, designers, etc.

>Successful, scalable, revenue-generating software projects that compete in a big market, on the other hand, are never finished. Microsoft still has top engineers working on Excel and Windows. Google almost certainly has some of their best people incrementally improving Search and Maps and Gmail. Many of Amazon's top engineers are working on improving AWS. Apple's certainly not transferring their best engineers off iOS.

I'd suggest that products of this size and scope are an extreme minority of projects in general, that projects of the class you describe in your first paragraph are the norm, and an agent would help for those. Also, agents are good for renegotiation (and outside work, for that matter); David Letterman still has an agent. His agent negotiates his continuing to work on the same project, and monetizes his experience within that project as he accumulates it.

I would think the opposite, it's hard to think of a class of software where a project could ever be described as "done", even the most boring business applications have constant scope change as the nature of the business changes.

The only example I can think of might be a video game, but even this is becoming less the case.

> Top-level engineers should be spending their time implementing hard new projects, not maintaining old ones.

Maintaining old but widely used code is a hard project.

The last time I was involved in a project that was over in a few months, I was still doing hardware development.

If we get a project out the door in 3 years, that's considered amazing. Then it's in the field for 10-15 years. I can't imagine working on something that's over in a few months.

I'd say the opposite. The current engineering market is too much like the contractor world.

Real progress is made by working for decades on a particular team, on a particular problem set. See the work done in Bell Labs in the 40s and 70s, the work done at Cray in the 70s and 80s, and the work done at Intel at the beginning of the transistor revolution.

A strong team of people, working together, growing to fill in each others weaknesses - that is what produces the best results.

One of the big benefits to having a talent agent is that they negotiate your rate of pay, with an incentive to maximize it since they're paid a percentage.

It's a little different from consulting shops that might want to maximize the rate the customer pays, but often pockets any 'extra', with your rate staying the same.

Talent agents also know the market infinitely better than the talent does, since it's their day to day job to deal with the going rates.

Add in the benefit of them getting to play the 'bad guy' in negotiations if need be, so you can keep good personal relations with the client. Hell, a good agent is practically expected to be pushy.

For top talent doing short term freelance work, it would definitely have some benefits.

>>with incentive to maximize since they're paid a percentage

No, in this case dealmakers will often want to just make more deals and may even negotiate less aggressively for you.

For example a realtor would rather sell your house for less immediately rather than risk a transaction falling through.

The commission upside of pushing for a 20k higher salary is often just not worth the time compared to getting the next deal done.

Reply on news.ycombinator.com