Tag Archive for 'LSE'


WTF?

I just got this email from the careers service here at LSE (emphasis mine):

A Conservative MP is looking for support in his role on the Public Accounts Select Committee.

The position is paid £7.85 p/h and will be for approx 15 hours per week.

The successful candidate must have excellent financial understanding in order to examine and analyse accounts.

The candidate should be inquisitive and have an interest in challenging public accounts.

The candidate should also be able to draft their findings into concise briefings and press releases.

To apply please send your CV and covering letter (1 page max) to XXXX by email XXXX@lse.ac.uk ASAP

£7.85 per hour?  Are they kidding?  They’re sending this to every economics Ph.D. candidate at the London School of EconomicsWhat the f*** are they thinking?  (the first person to say “non-monetary incentives” gets a clip ’round the ear)

Update 23 September 2010: Professor Frank Cowell, over on facebook, points us towards:

Gneezy, U. and Rustichini, A. (2000) “Pay Enough or Don’t Pay at All“, Quarterly Journal of Economics, 115, pp. 791-810.

Here’s the abstract:

Economists usually assume that monetary incentives improve performance, and psychologists claim that the opposite may happen. We present and discuss a set of experiments designed to test these contrasting claims. We found that the effect of monetary compensation on performance was not monotonic. In the treatments in which money was offered, a larger amount yielded a higher performance. However, offering money did not always produce an improvement: subjects who were offered monetary incentives performed more poorly than those who were offered no compensation. Several possible interpretations of the results are discussed.


Teaching, teaching

It’s the new academic year.  I’m once again teaching (not lecturing!), this time in EC400, the pre-sessional September maths course for incoming post-graduate students, and EC413, the M.Sc. macro course.

I’m also a new (Teaching) Fellow in the school, which means that a) I’m now a formal academic advisor (my advisees are yet to be determined); and b) I’m technically part of the academic staff at LSE (even though I’m only part-way through my Ph.D.).  That last point gets me access to the Senior Common Room (where the profs have lunch) and into USS, the pension scheme for academics at most UK universities.

Here’s what’s amazing about USS:  It’s a final salary scheme!  I’m honestly amazed that there are any defined-benefit schemes still open to new members.  Well, there you go.  I’m in one now.


Gratuitous self-promotion

I’ve removed my research page from this site and properly updated my LSE site.


Negative productivity shocks are conceptually okay when applied idiosyncratically to labour

This is mostly a note to myself.

Way back in the dawn of the modern-macro era, the fresh-water Chicago kids came up with Real Business Cycle theory where they endogenised the labour supply and claimed that macro variation was explained by productivity shocks.

The salt-water gang then accepted the techniques of RBC but proposed a bunch of demand-side shocks instead.

The big criticism of productivity shocks has always been to ask how you can realistically get negative shocks to productivity.  Technological regress just doesn’t seem all that likely.

Now, models of credit cycles like Kiotaki (1998) show how a small and temporary negative shock to productivity can turn into a large and persistent downturn in the economy.  In short:  Credit constraints mean that some wealth remains in the hands of the unproductive instead of being lent to the productive sectors of the economy.  The share of wealth owned by the productive is therefore a factor in aggregate output.  A temporary negative shock to productivity keeps more of the wealth with the unproductive for production purposes and it takes time for the productive sector to accumulate its wealth back.  If some sort of physical capital (e.g. land) is used as collateral, the shock will also lower the price of the capital, thus decreasing the value of the collateral and so imposing tighter restrictions on credit.

But Kiyotaki’s model still requires some productive regress …

Looking at Aiyagari (1994) and Castaneda, Diaz-Gimenez and Rios-Rull (2003) today (lecture 3 by Michaelides in EC442), I realise that small negative productivity shocks are conceptually okay if they’re applied idiosyncratically (i.e. individually) to labour.

Let s_{t} be your efficiency state in period ts is a Markov process with transition matrix \Gamma_{ss}e\left(s\right) is the efficiency of somebody in state s.  Castaneda, Diaz-Gimenez and Rios-Rull use this calibration, taken from the data:

State s=1 s=2 s=3 s=4
e(s) 1.00 3.15 9.78 1,061.00
Share of population 61.1% 22.35% 16.50% 0.05%

The transition matrix would be such that the population-shares for each state are stationary.

A household’s labour income is then given by e(s)wl.

A movement from s=3 to s=2, say, is therefore a negative labour productivity shock for the household.

The trick is to think of the efficiency states as job positions. Somebody moving from s=3 to s=1 is losing their job as an engineer and getting a job as an office cleaner.  They will probably increase l to partially compensate for the lose in hourly wage (e\left(s\right)w).

Remember that in the (Neo/New) Classical models, there’s an assumption of zero unemployment.  However much you want to work, that’s how much you work.  [That might sound silly to a casual reader, but it’s okay as a first approximation.  There are (i.e. search-and-matching) models out there that look at unemployment and can be fitted into this framework.]

If everybody is equally good at every job position (as we have here) and all the idiosyncratic shocks balance out so the population shares are constant, then – I believe – there shouldn’t be any change in observed aggregate productivity.

However, if you introduced imperfect transfer of ability across positions so that efficiency becomes e\left(s,\theta\left(s\right)\right) where \theta\left(s\right) is your private type per job position, then idiosyncratic shocks could therefore show up in aggregate numbers.

This is essentially an idea of mismatching.  A senior engineering job is destroyed and a draftsman job is created both in Detroit, while the opposite occurs in Washington state.  Since the engineer in Detroit can’t easily move to Washington, he takes the lower-productivity job and a sub-optimal person gets promoted in Washington.


On the importance of sunk costs

This is mostly for my students in EC102.  There’s a concept in economics called sunk costs.  A sunk cost is one that is spent and unrecoverable:  it’s gone and you can’t get it back.  Since you cannot get them back, you should ignore sunk costs when deciding what to do in the future.  To illustrate the importance of that dictum, consider the following:

You are a software company.  Your business model involves a large, upfront expenditure as you develop and write your program, followed by extremely low variable costs when selling it (the marginal cost of producing another DVD is very low).  Since you’ll be the only company selling this particular piece of software, you will have pricing power as a (near) monopolist. Before you start, you can estimate the demand curve you’ll face and from that estimate what your total revenue will be (remember, MR = MC will give you the (Q,P) pair).  If your expected revenue is larger than your estimate of the total cost of developing and selling the software, you should go ahead.

For simplicity, we’ll assume that the marginal cost of producing a new DVD is zero. That means that your Variable Cost is zero and Total Cost = Fixed Cost.  For any uber-nerds in the audience, we’ll also assume risk-neutrality (so that we only need to look at expected values) and a rate of time preference equal to zero (so that we can compare future money to today’s money without discounting).

Here’s the situation we start with:

Month Fixed Cost (actual) Fixed Cost (future, estimated) Fixed Cost (total, estimated) Total Revenue (estimated)
January 0 100 100 120

In January, since you expect your revenue to exceed your costs, you decide to go ahead.  But in February, after spending 50, you realise that it’s going to take more work than you first thought to write the software.  In fact, you still need to spend another 80 to get it ready for sale.  You’re now facing this situation:

Month Fixed Cost (actual) Fixed Cost (future, estimated) Fixed Cost (total, estimated) Total Revenue (future, estimated)
January 0 100 100 120
February 50 80 130 120

Should you still keep going?

The answer is yes!  The reason is that, in February, the 50 you spent in January is a sunk cost.  You cannot get it back and so should ignore it in your calculations.  In February you compare a future cost of 80 and a future revenue of 120 and decide to go ahead.  The 40 you will make will offset your sunk costs for a total profit of -10.  If you stopped, your total profit would have been -50.

This sort of situation is depressingly common in the IT industry.  You can even get awful situations like this:

Month Fixed Cost (actual) Fixed Cost (future, estimated) Fixed Cost (total, estimated) Total Revenue (future, estimated)
January 0 100 100 120
February 50 80 130 120
October 140 10 150 80

By October, you’ve already spent 140 – more than you ever thought you might make as revenue – and you still aren’t finished.  Thankfully, you think you’ve only got to spend 10 more to finish it, but you’ve also now realised that the demand isn’t so good after all (maybe you’ve had to cut back on the features of your product so not as many people will want it), so your estimated future revenue is only 80.

Even then you’re better off ploughing ahead, since you’re choosing between a loss of 140 and a loss 70.

For extra credit:  Imagine that you’re the bank lending money to this software company.  In January you lent them 100, in February an extra 30.  In October, knowing that the company is going to go bankrupt, would you lend them the last 10 as well?  (Yes, I realise that I’m ignoring the cost to the IT company of interest repayments.)