Infrastructure economics jobs in Indonesia: PwC

I noticed this week that PwC Indonesia were advertising for economists from the Associate (fresh-grad) to Assistant Manager (4-5 years experience) to join their Capital Projects and Infrastructure team. You can see the link to their full ad here.

I never worked for PwC, but the work that the Capital Projects and Infrastructure team do is pretty much exactly what I blog about, and working for firms like them is where I learnt almost everything I know about what I do. They call the job "economist", but in this part of the world, most of the work sits around the nexus of economics and finance; which I like to think is a particularly fascinating area!

So, if you're interested in the issues I blog about, and you're at around the right level, give it a shot and apply.

---

Disclosure: I have no affiliation with PwC, I just thought readers of this blog may be interested in the job advert. If other firms that work in this field are also recruiting, I'm happy to link to those ads too!

How much do you need to know about a field to give advice about it?

I enjoyed this article in the Harvard Business Review on leading people when they know more than you do. It makes the distinction between specialist leaders and generalist leaders. "A specialist manager knows what to do; the generalist manager knows who to call. The specialist leader tells her staff the answer, the generalist brings them together to collectively find the answer."

This got me thinking: this doesn't just apply to leadership of teams, but also to contributing to teams, dealing with clients or counterparts, and, really, any sort of endeavour when you have the option of interacting with other people to try to solve a problem.

When we are trying to solve a problem, even as a leader, there are points in time where we need to act like generalists and get people's inputs, and times we need to shut down the review process to focus on the task at hand. The generalist may be the superior manager for a broader range of tasks, but a generalist's success as a manager depends on the existence of specialists in their team that actually know the industry or technical skill required to get the work done. 

In the real world, as the authors hinted at, it's not as simple as "specialists are bad" and "generalists are good." The authors were responding to the very common problem of specialists struggling to make the transition to being generalists. In fact, there also exist generalists that struggle with a lack of specialist skills.

A common concept that is used as an ideal for consultants by many big firms is that of the T-shaped professional. You can read the Wikipedia page or google for more info, but the figure below illustrates the knowledge of a pure specialist, a pure generalist, and a t-shaped professional.

All of the knowledge maps above have the same area. Someone that is smarter or works harder to learn can increase their area, in terms of depth and breadth, but most of us are never going to fill in the square entirely. 

And that's ok. In fact when a client hires you to do something for them, it's not usually because you know their industry better than them, it's because you can do something they can't and it's cheaper/better/faster to hire you in to do this one thing than it is to try to develop the capacity to do it in-house. 

A lot of professional services firms tend to have a comparative advantage in knowledge of particular techniques, that can be applied across a fairly wide range of industries. For example, tax planning, financial modelling, business strategy, legal drafting, technical writing, project management, and so on. 

The best consultants I know are very clear with their clients in what they know, and where the limits of their knowledge lie. This helps both client and consultant work best together to identify potential blind spots that one or both parties may have, to focus attention there, and have the best chance at coming to the right decision. 

The key thing that creates value in team building is complementarity of skill sets. The problem for pure generalists is that when they're working within a single domain, a lot of their knowledge is either not related to the domain, or duplicated by others in a team. A pure specialist, at least can add a lot of value if deployed correctly. 

 So, to answer the question I pose in my title: how much do you need to know about a field to give advice about it?

The HBR article's answer is something like: Not much. You're a generalist manager, don't waste your time duplicating knowledge that exists elsewhere because you don't want to look ignorant and ask a question. Rely on your specialist minions to deliver and get out of their way!

I think that's pretty solid advice, but I might add that you need to learn as much as you need to know how to leverage your specialist knowledge  in the field. If you are truly the "leader without expertise" that the HBR article mentions in its opening paragraphs, then you'd better develop some expertise soon, or you're probably not long for leadership!

So, in conclusion: know thyself! Are you a specialist that needs to generalise, or a generalist that needs to specialise? The right answer will depend on you, your personality, your abilities, and the career and life you envision for yourself. Finding the right balance for you will give you the best chance at developing a satisfying career working with, and managing others.

If you're making a real financial model, don't make this simple mistake...

This is the first  of what will probably be a series of pretty technical posts dealing with some of the nuts and bolts of infrastructure finance and economics. I don't want to do too many of these, but there are a few things that I figured out that took me a lot of blood, sweat and tears that I'd like to save some others if I can. If you're not in the business of making or using financial models on a regular basis, please feel free to skip this one!

---

When you build a financial model, there are two ways you can manage your numbers: real, and nominal. In real models, you pick a base year, and do all your calculations using constant real dollars, rupiah or whatever currency you’re working in. In nominal models, you need to adjust all of your numbers by the relevant inflation figure.

Whether you use real or nominal is largely a matter of personal taste. They are (or, at least, should be) mathematically equivalent. It’s more a matter of presentation. I have always been a bit of a nominal model man. The first professional model I ever took over from someone was a nominal model, and I guess that shaped how I think about these things, but, at least theoretically, I don’t mind much which flavour you want to use.

I said “at least theoretically”, because in practice, I have had lots of problems with real models. In fact, a significant number of the real models I have come across in my professional career have had the same glaring mistake. Take a look at the simple models below and see if you can see what it was.

Let’s imagine you work for the government and your boss wants you to analyse an infrastructure project to find out how much a private party will charge users to provide the service.

The project will operate at full capacity for a 10-year period providing a service for which it charges a tariff and incurs operating expenses that both increase with inflation. The business is pretty capex heavy and the capex is all incurred in the first year of operations, then depreciated on a straight-line basis over the 10 year operating period. You’ve got some cost estimates, and a pretty good idea of what the weighted-average cost of capital is for businesses in this industry, so you put all the costs in and run a goalseek to get your full-cost-recovery tariff.

First you make a real model (but unknowingly, make a mistake in its design). See below:

 Then you make a nominal model to check your work (which doesn’t have the equivalent mistake). All you need to do is adjust the WACC, your revenues and your opex by inflation; everything else flows on from those.

 You are alarmed to see that your full-cost recovery tariff is different between the two models that should be mathematically equivalent. What have you done wrong?

 Have you found the mistake? Last chance…

….

….

….

The mistake is in the depreciation. In the real model (and in a significant proportion of real models I have seen in the real world) depreciation has been assumed to be constant. In fact, straight-line depreciation is constant in nominal terms, and decreases in real terms. The 50 units of your year 1 capex that you depreciate in year 10 is worth a lot less in real terms than the 50 units of the capex that you depreciate in year 10. This doesn’t affect your pre-tax cashflows, but, if you keep the depreciation constant, the tax shield impact of your depreciation is overstated.

Here’s the real model with deflated depreciation that results in the correct full-cost-recovery tariff.

 This effect of this mistake is not always very large, it’s only so large here because I used an example that was particularly capex heavy, but it can have a significant impact on decision-making in businesses like infrastructure where profit margins are very slim.

People think that in a real model, they don’t need to assume inflation. This is true if it’s a pre-tax model, but in a post-tax, or vanilla model, you still need to assume an inflation rate to calculate your depreciation correctly (and amortisation, etc.). So, I said earlier that it was largely a matter of taste what sort of model you make. That’s true, but if you’re building a real model, which is anything other than pre-tax, I might question your taste… Having to assume an inflation rate for a real model, to me, should make you question why you are using a real model in the first place.

So, now you know. Next time you see a real model, have a look at the depreciation, and let me know if you find the same mistake. The ones I have found have been made by very successful, multi-billion dollar companies, so the people making these mistakes aren’t in bad company, at least…

---