I currently work as a development analyst and have about a year of experience. I really love development and am getting my msred in a few months.
My ultimate goal is to start my own shop down the road and I’m curious what makes someone a talented developer? I feel like lots of people on this forum have a hard on for modeling skills, but what else is important?
| +52 | Leave brokerage to be GP | 12 | 1d | |
| +46 | New Comp Database - Google Form (Now with Data Validation) | 24 | 1d | |
| +24 | Seeking Career Guidance in Real Estate Development Post-Graduation | 3 | 2d | |
| +23 | Going out on your own | 4 | 1d | |
| +23 | Spreads over SOFR/UST | 5 | 2h | |
| +22 | REPE/Development GPA | 15 | 4d | |
| +21 | Real Estate = complicated + underpaid | 15 | 1d | |
| +17 | MSRE/MSRED with no RE experience; Naive to think I’ll land a job afterwards? | 4 | 5d | |
| +17 | Fisher Brothers | 6 | 1d | |
| +15 | Can you exit from Fund to Asset management or Investment in Real Estate ? | 21 | 6h |
Career Resources
Get instant access to lessons taught by experienced private equity pros and bulge bracket investment bankers including financial statement modeling, DCF, M&A, LBO, Comps and Excel Modeling.
Understand Information Power. As a development manager, you have to deal with many variables, but your power as the person sitting in that seat, is related to information power.
You know the most about the deal, the players involved, the important relationships, the risks, and more or less you’ve done a good job - then you’ll likely stay employed.
Information power. Sometimes consultants, try to keep info from you. Coworkers. Understand information power and get as much of it as possible. That is one of the most important skills in development.
This is a very underappreciated point. And not just for development, for all business and life in general. Information and knowledge is the key.
Modeling is meaningless.
The most important skill is being organized. Your job is the funnel the right information, at the right time, to the right people. Doing that effectively means being organized. Once you've got that down, you're 90% of the way there.
The part of modeling that isn't meaningless is creating a rock solid development budget without missing costs and with good backup for your opex and construction assumptions. But yes, getting overly fancy is pointless.
Right, but as a developer, you aren't responsible for the creation of a "rock solid development budget". It is coming from your GC. Obviously when you're evaluating a deal you need to get as close as you can, but until you bid out a job you just don't know. Do your take-offs, make your estimates... but you cannot and will not have a "rock solid" budget, so pretending like it is important to the process is silly. May as well just stick in a plug number and cross your fingers; as long as you're within some tolerable error range it will not matter
Successful developers have the mentality that if you aren't personally driving something to completion, it isn't going to happen. Often, this involves following up constantly, keeping track of everything, coordinating multiple groups, and pushing the people you hire to do their job on time and on budget. As the developer, there is no "oh this idiot I hired didn't do X" or "oh this idiot I hired is a month late" because they are all idiots, they are never going to care as much as you do, but it is still your job to make sure the do X, do it on time, and do it well. If you're asleep at the wheel, no one is going to grab it from you.
At the same time, as the developer, it is not your job to literally do everyone's work. The architect knows more about architecture than you. The GC knows more about construction than you. The designers know more about design than you. The ADA consultant knows more about ADA than you. Both the city manager and the overpriced zoning attorney knows more about the zoning and approvals process than you. The property management team knows more about property management than you. Like in the Steve Jobs movie, it is not your job to play an instrument. You are the conductor. You play the orchestra. It is your job to get the trumpet player to play the trumpet the best, know their trumpet motivations, ask the right questions about their trumpet choices, and keep them trumpeting on beat. You don't have to play the trumpet. You don't have to know how to play the trumpet. You just need your trumpet player to kick ass.
Finally, you have to make genuine relationships and build on them in order to get things done. You need to know everyone from bankers and equity partners to surveyors and fitness equipment providers. I can't tell you how many times I've been able to solve a problem by calling someone who I have interacted with and been chill with who has stroke. Again, I'm not solving the problem by doing it, I'm solving the problem by knowing the person who can do it. AT&T never delivers to your building after you've told the residents you have Google, Comcast, and AT&T? It helps to know someone at AT&T who can make it happen next week. Bank won't release retainage because you need a final As Built Survey and it slipped your mind? It helps to know a surveyor who can get it done in a few days. Building delivering on the 10th but the fitness equipment still hasn't been installed three days out because the GC is two weeks past your original install date in delivering the shell? It helps to be able to call up the president of the company and plead for them to reschedule someone else so you can open your fitness center on time. Interest rates double over a 12 month period and you need a capital call to cover? Certainly nice to be on good terms with not only your equity partner, but also your lender, who you then convince to increase the loan amount instead of the shortfall coming entirely from equity.
You can hire someone to build you a model for cheap, or shit, just re-use someone else's that got sent to you or you used at a previous job. It's much harder to hire someone who cares. It's much harder to hire someone who just gets shit done. I have absolutely zero clue if my analyst can do math above a 4th grade level or not. I don't care. He gets shit done.
Everyone under the age of 25 and interested in development, pay attention to this post. We talk about the modeling and the construction knowledge and fancy financial engineering, but when it comes down to it, being a developer is being a CEO of a 5-7 year company. Get a good team and trust, but verify, their work.
For juniors who want to know what it actually means to follow this? It's being shameless in sending emails every day to follow up, it's not being scared to pick up the phone the second you have a question, it's driving to site at 7am so you can walk with your GC to understand the big change order. And it's knowing the balance of the job. Sometimes it's worth it to bust your budget a bit if it means you keep a great relationship with a key player because you never know when it will return dividends. A small, but revealing, example, I always build good relationships with my project accountants and will drop (almost) everything to get something when they need it. When you need a check overnighted to make sure some material gets released and it's 4pm, you want to be able to call in a favor.
This is a great comment, and I totally agree with your main point that if the developer isn’t “personally driving something to completion, it isn't going to happen”. That said, I want to push back or provide nuance on a few things you wrote. My perspective is that of a developer who used to be one of the “idiots”: an architect who worked for developers.
I think the “idiot” label is not usually correct in the literal sense. In my experience, many of the main project team members- structural engineers, land use attorneys, civil engineers, architects, etc.- are smarter than the developer is. Moreover, many of the tasks that these consultants have to complete are more intellectually difficult than any of the developer’s tasks. Your average structural engineer would find real estate development math laughably easy compared to some structural calcs. (When I was making the transition and learning how to do DCF models, I was actually a little disturbed by how simple they are.) I find development easier than architecture in many ways.
And I’m certain that the ratio of difficulty and stress to compensation is better for developers than for many of their key project team members. I decided to make the switch when I came to believe that, and, having made the switch, I’m even more convinced now.
The issue, which used to be a source of frustration for me, is exactly what you said: the developers know less about these disciplines than the specialists do. Often they don't know what they don't know, which means that they have no appreciation for how difficult certain things are and how much effort goes into them. So they have difficulty distinguishing between consultants who aren’t working that hard (which does of course happen) and consultants who are working hard on things that are just very time-consuming and complicated. Often they aren’t even grateful when their project team skillfully solves difficult problems for them, because they don’t fully realize how difficult those problems were.
If you’re on the receiving end of this, your experience is that you work very hard, for not very much money, and complete a difficult task while the developer is hounding you to finish it. They don’t look too closely at the details of what you did: their analysis is mostly “is Deliverable X complete/if complete, submit to Recipient Y”. Then they take their time paying your invoices, sometimes fight you about relatively small amounts of additional services billing, and maybe sue you if something goes wrong. Then you commute to your outer-suburban home or your too-expensive apartment in your used Honda.
It would require a longer essay to go into this, but I think the process of procuring design and construction is not working very well anymore for a lot of consultants. The litigiousness, codes, design standards, and permitting processes have become difficult enough that the modest pay isn’t really worth the brain damage and stress. I reacted to this realization by pivoting into development, which took years of hard work. Others can't, so they maintain their mental health by turning off their phone after 45 hours of work per week and coaching soccer. To the stressed developer, this looks deceptively similar to being an "idiot" who "will never care as much" as the developer does.
This is where the idiot label is deserved - there is infinitely more stress that the developer faces compared anyone working for them (the contractor being the only one that gets close). You must not have only responsibilities outside of project management functions because there are huge problems you have to deal with from every angle. The largest of these are navigating capital relationships, raising money, and selling the vision for a project for land you have under contract. Not to mention the risk of building the project and losing money because the market tanked - most developers take out recourse loans and are literally putting their house on the line to pay for the project.
All consultants have to do is do the work CORRECTLY and they get paid. Sure, there is a professional liability risk for them, but if you are getting paid hundreds of thousands to millions of dollars to design something I think it's a fair expectation that you have some liability.
Then there is all the money you lose on fighting over change orders because the architect and consultants couldn't be bothered to coordinate the design. You talk to anyone who has been in the field a long time and they will tell you the work product being produced today is garbage.
You are still an idiot.
One other thought, which is separate from my other comment. It's certainly true that you can't be an expert on everything and can't micromanage everyone. You have to rely upon your team. But I do think that the developer needs to intensely focus on certain select issues, the ones that threaten your project's overall viability, and learn almost as much about them as the responsible team members know. If there are are no issues with steel procurement on my project, I won't spend much time thinking about it. I'll leave it to the suppliers, subs, and GC to manage. But if there's a critical component, like some electrical switchgear, whose timeline keeps slipping until it threatens to delay the CO, I'm eventually going to start reaching out directly to the electrical sub, then the supplier, and then the factory the supplier is buying from until I'm eventually talking to some mid-level employee at the factory who is directly responsible for that component.
I find that the best way to address the really critical problems is to learn as much about the nitty-gritty details as possible. Then you see ways that things could be done differently, assumptions that should be questioned, and the specific roadblocks that are holding things up.
The alternative approach, which plenty of developers take, is to identify the project team member who's domain the problem is in and just harass them more and more. Or, if that doesn't work, hire a "fixer" type, like a permit expeditor, and throw them at the problem without getting into the weeds themselves. In my experience, selectively getting into the weeds is a more effective approach.
I actually hate how much you saying switchgear triggered my PTSD from this past year. I know more about fucking switchgear than I ever wanted to.
Great point
Family money.
Don't forget about the friends' money, likely made with connections from the family money!
Honestly, not wrong
Agree with what the others above are saying. There's a huge emphasis on people management here. You'll deal with so many consultants and so many unique problems that the solution isn't always going to be clear. You'll need to coordinate with these consultants or sometimes do your own homework and determine what options you have that will come with the least compromise.
Skills:
Sigma Male Grindset
Source: Me, working as a developer
An appreciation for developing relationships with the regulatory community (e.g., state lawmakers, local elected officials, state departments of housing). These elected and administrative officials can create pockets of alpha tailored to your product category via tax abatements/exemptions, favorable tax-exempt financing, entitlements/zoning changes, and streamlined permitting. Similar to this is appreciating the issues that gain the attention of the regulatory community, e.g., housing affordability, downtown revitalization, etc, and serving those specific needs with development.
Putting the two together: Serve the real estate development needs of elected/administrative officials (often focused on housing affordability or area revitalizationin) in exchange for their creating incentives that make serving those needs profitable.
Aperiam vero ipsam quia eligendi. Et occaecati culpa rerum expedita. Minima architecto exercitationem expedita omnis ipsum maiores vitae.
Et labore dolorem expedita omnis deleniti. Impedit blanditiis qui ratione ipsam commodi. Eum fugit facilis consequuntur neque voluptatibus quia necessitatibus. Et mollitia perferendis aut nesciunt fugiat deserunt.
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...