Here is a pattern that repeats in almost every growing property management company. The portfolio expands, the team feels stretched, and so you hire. It helps, for a while. Then you hire again. And somewhere around the third or fourth round, someone in finance looks up from the numbers and notices something uncomfortable: the team is a third bigger than it was last year, and the operation is not a third faster, or a third more profitable, or a third easier to run. The extra people are absorbing work, but they are also creating it. That gap is the whole subject of this article. There is a real difference between growing a property management business and scaling one, and most operators do not find out which they are doing until their margin tells them. Growing means your costs rise in step with your units. Scaling means your capacity rises faster than your costs. Adding people, counterintuitively, tends to produce the first while feeling like the second. Growth and Scaling Are Not the ...
Every operator believes their data. Right up until two reports disagree. The occupancy number in your leasing tool says 94 percent. The finance report says 91 percent. The board deck, assembled from both, says something in between. Nobody falsified anything. Every system did its job. And yet the organization cannot answer a basic question about itself with confidence. This is not a software failure. It is an architecture failure, and it comes from conflating two concepts that sound interchangeable but do fundamentally different work: the system of record and the system of truth. Understanding the difference between a system of record vs system of truth is one of the most consequential distinctions in enterprise architecture. Get it right, and every team in your organization reads from the same page. Get it wrong, and you spend the next decade reconciling spreadsheets that were never designed to agree. What Is a System of Record? A system of record (SOR) is the authoritative ...
A property manager in Detroit collects two months' rent as a security deposit from a new tenant. The amount feels reasonable for the unit. But under Michigan security deposit law, it is illegal. Under MCL 554.602, confirmed directly from the Michigan Legislature, a landlord may not require a security deposit exceeding 1.5 months' rent. Collecting more than the statutory maximum violates MCL 554.602 and places the landlord in non-compliance with the Landlord and Tenant Relationships Act. Michigan security deposit laws are governed by Act 348 of 1972, codified at MCL 554.601 through 554.616. Unlike Ohio, which imposes no cap, Michigan draws a hard ceiling at one and a half months' rent. Unlike many states, Michigan also imposes a mandatory inventory checklist requirement at move-in, a specific tenant response procedure for disputing deductions, and a landlord lawsuit deadline that - if missed - can result in the landlord owing the tenant double the amount of the security deposit ...
A property manager in Columbus collects a $2,500 security deposit from a tenant moving into a two-bedroom apartment. The tenancy ends after eight months. The landlord makes deductions for cleaning and repairs - legitimate ones, properly documented. But the itemized written notice is sent 35 days after the tenant vacates. Under Ohio security deposit law, that five-day delay may expose the landlord to liability under ORC §5321.16(C), particularly if any portion of the deposit is determined to have been wrongfully withheld. Ohio security deposit law sits in an unusual position among US states. Unlike most, Ohio imposes no statutory cap on what a landlord may collect as a security deposit. A landlord may charge any amount they deem appropriate. But the absence of a cap does not mean Ohio is permissive - quite the opposite. The 30-day return requirement, the interest obligation on larger deposits, the itemized notice requirement, and the double-damage penalty under ORC §5321.16(C) create a ...
Tennessee's eviction process operates under two parallel frameworks depending on which county the property is in, and property managers who apply the wrong framework produce defective notices, file premature complaints, and lose cases that they should win. In the URLTA counties with populations exceeding 75,000, a structured statutory process under the Uniform Residential Landlord and Tenant Act governs every step from notice through writ execution. In the remaining counties not subject to the URLTA, a separate set of procedures applies with different notice requirements and fewer tenant protections. Procedural errors in Tennessee eviction cases are not corrected mid-case. A defective notice requires a new notice, a new waiting period, and a new filing. A complaint filed before the notice period expires is subject to dismissal. A detainer warrant served by the landlord rather than by the sheriff or constable is improperly served. Every error resets the clock and extends the period ...
Renting property in Philadelphia requires more than signing a lease. Before any residential unit can legally be rented, landlords must obtain a Rental License from the Department of Licenses and Inspections, provide a Certificate of Rental Suitability to every new tenant at the start of every tenancy, and, for properties built before February 1978, comply with lead paint certification requirements as part of the Rental License application. Missing any of these steps can prevent a landlord from collecting rent or enforcing the lease in court. The framework is sequential. The Rental License must come first. The Certificate of Rental Suitability cannot be issued without a current Rental License and a property free of outstanding violations. The Certificate must be provided before the tenancy begins. Property managers who enter the Philadelphia market without understanding this sequence encounter compliance failures that are discovered in the worst possible context: when a non-paying ...
There's an old military line, usually credited to the Prussian general Moltke: no plan survives contact with the enemy. Process maps have the same problem. You spend a week building a clean swimlane diagram of how leasing or maintenance or move-outs are supposed to flow, you get everyone to sign off, you pin it to the wall. Then real operations show up, and within a day the map and reality have quietly parted ways. It's not that your team is undisciplined or your map was drawn badly. It's structural. A process map shows how work is supposed to go, and operations are made of everything the map left out: the exceptions, the judgment calls, the one-off owner request, the document that didn't arrive, the workaround somebody invented on a Tuesday to keep things moving. The map is the happy path. The work is mostly detours. Why We Reach for the Map Anyway Process maps are seductive, and it helps to be honest about why: They make a tangled operation legible. Boxes and arrows you can actually ...
For a decade, property companies have been told to get their data into one place. One source of truth, one dashboard, one number instead of four. Most firms are somewhere down that road, and it was worth the effort. But data centralization is the easy half, and it's the half that matters less. A single source of truth guarantees everyone sees the same facts. It guarantees nothing about what they'll do with them. Two managers can open the same record, see the same numbers, and make opposite calls, because the rule they're applying doesn't live in the system. It lives in their heads. The harder move, and the one that actually holds a growing operation together, is centralizing the decisions. Data Is Only Half of a Decision A decision is two things: facts, plus a rule applied to them. The facts are your data. You centralized those. The rule is your approval threshold, your pricing logic, your screening bar, your concession policy, your escalation trigger. Centralizing your data put the ...
Think about the last time something important got dropped in your operation. Odds are it wasn't because one person failed at their job. It's because the thing that got dropped wasn't clearly anyone's job at the moment it fell. That's the pattern almost every time. Work inside a team is safe. Someone owns it, someone's watching it, and someone catches heat if it slips. The danger zone is the space between teams, the moment a task leaves one group and hasn't quite landed with the next. In that gap, the task is finished as far as the first team is concerned and hasn't started as far as the second team is concerned. For a while, it belongs to nobody. And nobody watches the thing that belongs to nobody. The frustrating part is that this isn't a discipline problem. You can hire conscientious people, and the work will still fall, because the crack it falls into is built into the structure, not the staff. There's a Name for the Space Where Work Disappears Back in 1990, two consultants named ...