Currently a Development Associate more involved on the finance side of the business. Had my 2.5 year review recently and asked the typical "what should I do to further progress my career" question. Their response was to further get involved in data management across the company, specifically sharing data across Development and our Asset Management team. Data points I'm referring to include I'm referring to income and expense, construction costs, rents, and land sales.
Eventually, I want to spread my wings into an executive level development role, and am concerned whether becoming more data focused is the most efficient way to get there. On the one hand, I could leverage my knowledge from knowing the data better than anyone and could inform/make recommendations to the exec team. On the other hand, I could see taking on this role remove me from the development process and make me more of a glorified analyst.
By data management do they just mean databasing and facilitating information sharing, as well as populating new market research? This may be their way of saying "get a better understanding of key assumptions and where the market is at for construction costs, rents, expenses, etc.", which is absolutely critical to understand and stay on top of in development.
What's progression look like in your company? Is the next step Development Manager and taking on project management, or do you have an internal development finance team that is more focused on the numbers and likely where you'll get pushed to? Regardless, I think understanding the data is very important, but obviously the management side of it would fall more into the latter roles' realm longer term.
No, that is not a natural progression for a developer. That sounds like good information that can be shared in an email or kept in a company database, not the basis for a career.
What would you say the natural progression is?
Typically junior development people are burying their heads in the model to get the financial aspect down pat, they'll work on underwriting new opportunities, updating current projects, working with debt and equity on closings, etc. Once you get enough experience in that usually you'll be moved into a more supervisory role regarding the UW and take on the project management aspect. Some firms make this switch abruptly (day 900 of analyst is all model, day 1 of associate is all PM), some handle it more smoothly by integrating analysts into the PM team to get a hang of reading drawings, speaking with architects and other consultants, being on an active construction site, etc. before pushing them into the deep end.
Once you're past that you are typically a mid-level employee and you're running the projects on your own, sometimes responsible for acquisitions as well, but not always, depends on how the firm is structured. Above that it depends on the depth of the org chart at your firm, but it's going to be some variation of overseeing multiple PMs/MDs, not in the day-to-day or week-to-week at all and really just popping in when something major comes along, and you're dealing with broader market direction, relationship building and maintaining, etc.
Think their comment needs more context personally - I don't interpret it as a "this is what you'll be doing going forward" and more as a "you need to be more on top of this and actively sharing information and facilitating discussion is a good way to make that happen".
Start looking for new jobs. Fuck them. My team has somewhat been pushed in this direction and it is a huge drag on time. Limits my ability to learn.
This is an awesome question and something I've had to deal with as a Development Associate too. Brought this post up to my boss. When I started as a Dev Assoc, we had 0 routine data/information sharing across the team unless a specific request for information was needed. There wasn't like an aggregate "dashboard" of everything. Essentially everyone was independently responsible for certain information and kept it in their head or on a spreadsheet, and because of it, information was siloed. It was horribly inefficient.
I spent a couple of months learning what variables are important by each deal, where each variable was stored (which legal doc, where in our accounting software, which vendor, etc), and ended up building a big data base/"Dashboard" from it. The keyword is transparency. Now our team uses the Dashboard as a starting point to do analysis for decision making all the time. I learned a lot over such a short period of time trying to solve this.
Totally understand why you would hesitate to pigeon hole yourself as a data guy vs a developer guy, but I don't see it like that. I'm a developer/business guy. It's just a very useful application of our skillset/training as an Analyst, which will in turn make you more knowledgeable about what's actually going on. It's like coming into development from a law school background and running the contracts.
There's a lot more to it, but here's essentially how I broke the project down, feel free to PM me to share ideas.
1. INPUT: Entity Detail (on going deals by entity)- deal on x, following variables on y: projected/actual acquisition date, projected/actual funding date, predevelopment/"spec" cost, project cost (with breakdowns for land cost, development cost/construction budget, project cost), deal acreage, current zoning, expected zoning, deal capitalization, tenant commitments (count)
2. INPUT: Pipeline Detail (ongoing deals by parcel development)- parcel on x, following variables on y: entity, deal type, parcel status, acreage, [actual or underwritten] NOI, [actual or underwritten] cap rate, [actual or underwritten] gross sales value, [actual or underwritten] disposition date
3. INPUT: Cash Schedule (all deals) - deal on x, time on y: contractual deposit amounts, contractual escrow releases
4. INPUT: Scoreboard (completed deals)- deal on x, following variables on y: acquisition date, final disposition date, project equity, project debt, total distribution, address, deal type, user, market, return on equity, levered IRR
5. Then I have an "Engine" that pulls all the information together by time.
6. OUPUT: Capital Schedule - returns the following variables by quarter, essentially a bunch of sumifs and sumproducts from the Engine tab: equity/debt investment, equity/debt returned/extinguished, equity/debt balance, net sales proceeds, before tax profit, after tax profit, commissions, change in cash, liquidity generated from sales (return of equity + after tax profit), deals purchased, deals exited, parcels sold
7. OUTPUT: Pipeline breakdown: measures the % of our development pipeline "status" over each quarter. Status is broken down into Unlocked (in marketing), Letter of Intent (executed LOI), Inspection Period (tenant in IP), Locked (lease signed or tenant through IP).
Hope this helps.
Thanks for the insight. Did you create a database/program to compile all this information? That's one thing I've been trying to figure out. There has to be a faster way than inputting all these data points in an excel spreadsheet. Would love to hear more about how you built this.
I'm sure there are more efficient ways to handle the input process. Takes me a few hours a week in Excel. I know now which data points are concrete and which are subject to change. There's a tab reminding me of what the "refresh" period is for each. For example, our accounting team reports pre-development costs (due diligence spend and deposits) on the first of the month, so I have a note to take a look at those reports and update. Most of it is copy and pasting from PDFs or other Excel docs.
I work on a lean, recently formed, merchant development unit within a larger 90+ year old real estate investment company. We had a 30-acre development pipeline at the beginning of the year, and we're expecting to grow by another 109 in FY23. Management and financial partners had a hard time keeping track of everything.
I kept it simple. Entities are broken down by Owned and Under Contract. This allows us to bifurcate between deals we're committed to and those we can chop. I work on most of the proformas we do, so I have the financial information accessible, and that's where I can pull ownership%, acreage, PP, development cost, project cost, equity, debt, etc. I start the portfolio profroma with an "analysis period" that is used to reference the "funding date" (outside date on land PSA) of each deal. The nature of the deals we do allow us to issue a capital call/equity raise and draw a subnote from our line of credit in one sweep, so makes it easier. Those inputs don't really change once approved. The majority of the other inputs have to do with underwriting sales: improved land sales, ground lease sales, build-to-suit sales - each parcel is pegged to a projected disposition date. Every other week in our pipeline meeting, I revise the values or disposition dates depending on development manager feedback.
With having all that information and a few dates by project, you can use sumif, sumproduct, and index,match,match to compile it into a quarterly financial projection. Once it's all in there, and you add stuff like your companies G&A expenses, PSA deposit schedule, escrow releases, etc, there's a lot of cool stuff you can do: quarterly portfolio debt balance, debt repayment, quarterly portfolio equity balance, return of equity, liquidity, investable equity, partner distributions. We started using this simple metric we call "Project Ledger:" BoP (Project Cost *-1) + net sales = EoP Portfolio Ledger. It shows how much cash we have left in each deal, and when there's a lot going on, it allows you to measure how out of the money or in the money we are on a portfolio level. Anyways I'm getting off track, but my point is the data stuff can be valuable and teach you a lot.
I don't understand why this is viewed so negatively. When I was a dev analyst and associate I spent maybe 25% my time on data management and it made me highly effective.
So.... interesting question, and I think OP should maybe make something clear (as the responses indicate a mixed view). Is the suggestion...
A. Move away from a Development Assoc. role into a Data Management role?
OR
B. Start doing some data management tasks/responsibilities for the projects you work on? And start working with/across corporate groups?
I'm going to safely assume the answer is B, as suggesting A to a development assoc. makes little sense unless you have some prior background/interest (which you don't seem to have). That said..... sure doing B makes perfect sense and is getting you more involved in corporate/firm operations which is exposure to management and systems, all of which would be beneficial to getting more exposure, cross functional experience, and understanding of the overall enterprise. Those are generally things to do to get promoted to "management" at most firms.
So, if this was a simple, do this as expanded role/responsibilities then YES, if it is a major role shift, then I guess I'd need more info to say if good or bad. Not sure how your firm tracks people or timelines them for promotion, maybe doing cross-functional work (outside of traditional dev work) is part of the rite of passage. Again, can't say, too little info!
Yes I'd say its more B with one small modifier- I am already involved in data management tasks. I'm the only junior level "analyst type" in my development group of about 15 people. A lot of the market research portion of the job already falls on me. The age gap and lack of young finance based professionals will likely mean this will continue to fall on me for years (if I stay that long).
When asked how I could further develop professionally, getting more involved in market research and managing data was really their only answer. They suggested an eventual promotion to more of a corporate level rather than just being focused in our development group (which I like) but suggested it would be a "VP of data" type title (which I don't like).
I have no problem being the expert at the firm on the market, but don't want this to fall on me TOO much. I feel skill sets such as negotiating financing with the city or debt/equity provider, understanding of the capital stack and timing of cash flows in a model, formulating a development plan and getting through entitlements, would not be fully developed if I spend too much time being involved in putting together data for corporate.
Yea I think from their eventual promotion suggestion you need to have a frank conversation with them about your goals (e.g. you enjoy the market research, data management, etc. aspects of the role but are more interested in broader scope development longer term).
From your description it sounds like you're more interested in a Development Finance role than project management (e.g. underwriting, research, capital structure, deal structuring, etc.)?
So, first just so I understand... the entire development team/arm of your firm is 15 people? Or is that like just in your market/city or something like that? Scale kinda matters, but not really majorly to my thoughts below...
- Development teams have all sorts of "specialties" and being the market analyst/researcher type is one of them, and one with lots of crossover to general investment management world. So, doing more "data" and "market analysis" style stuff isn't really bad or all that unique. In fact, it theoretically makes you strong on being able to do deal making as valuations and market analysis are super core skills.
- If you don't want to do this, what do you want to do? Did you propose or ask about such? What response did you get? I guess it's a missing part... what do you want to do to progress with this firm.
- As to the "VP of Data" thing... I have seen more and more job postings with similar type titles or ideas in past few years, so your firm is far from unique in doing this. That said, they usually look for people with data analysis/computer-IT skills or at least economics/statistics type backgrounds. Generally not the traditional "development assoc." who uses excel types. But maybe they think you could do this, and they must think you might want it (like why do you think they suggested this to you?). Personally, unless you want to full into this area (and in fairness, it is clearly growing in demand), then probably not wise to do as they suggest. (side note, we have a main "data" person at my firm, they actually report to me, they are not the developer type and didn't ever set out to be one either).
- In context, it sounds like your firm sees you as a finance/acquisitions/markets style person more than a project mngt type (is this correct?), there really is nothing wrong with this and many stay along these lines and progress far into leadership (to be honest, it is often higher value add and thus pay than being a proj. mngt type). The "data" thing is really hard to judge in fairness, so I'd just suggest you keep having more and more discussions with your firm's leadership.
More glorified analyst. Not the typical path and would push back unless that’s something you want to do.
Being pushed into managing data is NOT a good thing for your career.
Absolutely crushing the assignments given to you IS a good thing for your career.
Not following exactly. Why shouldn’t he leverage his experience and leave, rather than fulfilling what his manager wants him to do despite it not serving OP’s individual needs as well.
Everyone gets crap assignments from time to time. I don't think that's a reason to cause a stink or start interviewing, especially when OP is already in the exact division they want to be in long term. I suggest OP do an impeccable job at managing data while going above and beyond with true development work. "I have completed this stupid mind-numbing data entry project and took the additional step of summarizing it all on the first tab, see attached. Hey by the way I was walking our construction site this weekend and thought that if we value engineered the roof deck that would allow us to....."
Voluptatibus et veritatis architecto eius. Repellat ea consequatur fugit quisquam deleniti. Eum assumenda sunt sed excepturi aut delectus excepturi dicta. Non doloribus possimus officia dolorem a officiis. Asperiores quae eius dolore expedita quidem non.
Expedita atque facere molestiae sint minima aut. Voluptatem in aut fugiat.
See All Comments - 100% Free
WSO depends on everyone being able to pitch in when they know something. Unlock with your email and get bonus: 6 financial modeling lessons free ($199 value)
or Unlock with your social account...