Wednesday, June 22, 2011

Emergency Hospitals vs Urgent Care Facilities

It's no secret that it costs a hospital a LOT more money to see a patient in a hospital emergency room setting than in an off-campus facility. I recently heard and Atlanta hospital CEO quote a 10-to-1 cost difference.

It's also no secret that new urgent care facilities are opening pretty regularly. On a good note (to a hospital), these facilities handle many of the issues that clog ER's, offer lower reimbursements, and don't require hospital admission. On a bad note (to the hospital), the hospital loses control because it's tough for the hospital to influence whether they or competing hospital get the hospital-bound patient.

"Emergency Hospitals" are a way to address this balancing act AND add value to the community. Baptist Health System in San Antonio Texas is a great case in point... for a full write-up on what they're doing, click here. The article discusses how they're approaching it and does a great job of describing the differences between an Emergency Hospital and Urgent Care facility.

Monday, June 20, 2011

Myths of Sustaining High Output

Balancing output versus burn-out is a struggle in any line of work, so I was immediately interested to read a recent Tim Ferriss blog post addressing that very issue in the context of software productions.  While I don't write code, many of my technology clients do so I'm interested to get a glimpse into their world. AND I'm a big believer that we can all pick up great ideas through the best practices of others.

A little about Tim:
Tim Ferriss is a NY Times Bestselling author... twice. His first book, the 4-Hour Workweek,caused me to re-examine many of my philosophies in regards to time usage and income generation. The book made me a more efficient and effective person, with more zest for life. His 2nd book, the 4-Hour Body, became the catalyst for me getting back into good physical shape. I've followed his blog for a couple of years now, continue to enjoy his fresh perspectives, and highly recommend following him to anyone with a curious nature. There are several embedded links to his blog below.

Family guy that I am, I do have to warn you that not all of his material is safe for the whole family...

Here's Tim:
Posted: 07 Jun 2011 03:31 PM PDT
For the last two years, one name has come up again and again when talking with A-class start-up investors: Pivotal Labs.

See, Pivotal Labs quietly helps dozens of the fastest-growing tech companies in the world, including freight trains like Groupon and Twitter. If your start-up needs to get good coding done quickly, as in lightning fast — or if new hires need to get good at coding quickly — top venture capitalists are likely to look over their shoulder and confide: “Call Pivotal Labs.”

I first met the Founder of Pivotal Labs, Rob Mee, when one of the start-ups I advise, TaskRabbit, began working with them.

One thing is immediately clear: Rob is obsessed with how to get obscenely high output. But that’s nothing new. Here’s the differentiator: he’s obsessed with how to get obscenely high output with sustainable effort. One of his first remarks to me was “3am with Jolt and pizza can be fun, but it’s a myth that it’s the fuel behind scalable success…”

My kinda guy.

I then posed a few questions:

How do you create a scalable, bullet-proof business? In this case, “bullet-proof” meaning that there’s no single point of failure — it won’t nose dive if any single player (like you) is taken out… or opts out.

What are the myths of tech product creation (software specifically, and entrepreneurship more broadly) that he’d like to expose?
This post contains his answers.

Think software doesn’t apply to you? If you’re in business, rest assured that at least a few principles of good software development most definitely apply to you. Translate them into your world and prosper.

Enter Rob Mee

Software development is a rapidly evolving field that got off to a very rocky start.

Conventional wisdom for many years was that software engineering should be like other types of engineering: design carefully, specify precisely, and then just build it – exactly to spec. Just like building a bridge, right? The problem with this approach is that software is just that. Soft. It’s endlessly malleable. You can change software pretty much any time you want, and people do. Also, since software can be used to model just about anything, the possibilities for what you can ask software developers to do are pretty much infinite. Want to simulate a circuit in software? Go ahead. Run a bank? No problem. Connect half a billion people to their friends? Why not, piece of cake. Not only that, but what we ask programmers to produce changes in the middle of the development, often in unpredictable ways.

This is not bridge-building.

Denying the reality of constant change doomed many software projects, for many decades, to either abject failure or huge budget overruns. So why did an entire industry hew to this conventional wisdom that flew in the face of all evidence? Hard to say. Finally, however, there has begun to emerge a new consensus: software development needs to respond well to change. In fact, it needs to be optimized for change. Nowhere is this embraced more than in today’s web start-up development community. So-called agile methods have gained currency, and the “lean start-up” movement calls for exceedingly rapid change, often automated and based on experimentation with the live system.

So we’re all good, right? Not so fast. In spite of the acceptance of more agile methods, there’s plenty of received wisdom hanging around… and most of it ought to be thrown out the window.

1. Myth: You have to hire “ninjas”.
The myth of the hero hacker is one of the most pervasive pathologies to be found in Silicon Valley start-ups: the idea that a lone programmer, fueled by pizza and caffeine, swaddled in headphones, works all hours of the night to build a complex system, all by himself. Time out. Software development, it turns out, is a team sport. All start-ups grow, if they experience any meaningful success. What works for a lone programmer will not work in a company of 10. And what’s worse, encouraging the hero mentality leads to corrosive dysfunction in software teams. Invariably the developers who do a yeoman’s 9-to-5, week after week, cranking out solid features that the business is built on, lose out to the grasping egomaniacs who stay up all night (usually just one night) looking to garner lavish praise. Rather than reward the hero, it’s better to cultivate a true esprit de corps.

2. Myth: Programmers need to work in quiet, without interruption.
This makes sense … if people are working on their own. Every interruption does indeed break concentration, and it takes a while to get back “in the zone”. Some well-known software companies even insist that each programmer have their own private office. That way they’ll never be interrupted, right? Except that modern-day interruptions have little to do with an actual person tapping you on the shoulder, and everything to do with instant messaging, mobile phones, Facebook and Twitter, email, and the music coming in through headphones that programmers swear helps them concentrate. The reality is that most programmers working on their own only spend a small fraction of their day actually programming: the interruptions are legion, and dropping in and out of a state of concentrated focus takes most of their day. There is a solution, however: pair program. Two programmers, one computer. No email, no Twitter, no phone calls (at least not unscheduled; you can take breaks at regular intervals to handle these things). If you do this, what you get is a full day of pure programming. And “getting in the zone” with someone else actually takes almost no time at all. It’s a completely different way of working, and I maintain that it is far more efficient than working alone ever can be. And in fact, with the current level of device-driven distraction in the workplace, I’d suggest it is the only way that software teams can operate at peak efficiency.

3. Myth: Start-ups run hot, so we’re just gonna have to burn everyone out.
Working crazy hours doesn’t get you there faster. In fact, it slows you down. Sure, you can do it for a week. But most start-ups plan to be around for a little longer than that, and developers will going to have to keep programming for months, if not years, to build a successful product. Many start-ups operate as if the pot of gold is just around the corner; if we only work a little harder, we’ll get there. Pretty soon developers burn out, and simply go through the motions of working long hours without any corresponding productivity. Working intensely, for shorter periods of time, is far more effective. Pivotal has helped hundreds of start-ups build systems, and has done it on a strict 40-hour week.

4. Myth: Looming deadlines necessitate shortcuts.
Many software teams use the excuse of a high-pressure market and the need to ship product right now as an excuse to do shoddy work. Writing tests goes by the wayside; careful design is forgotten in the rush of frenzied hacking. But software teams are no different than other teams we’re all familiar with, and the way high-performing teams succeed is not to lose their cool: on the contrary, when the pressure’s on, you stay frosty, and let your training carry you through. How many times have we heard stories of remarkable performance under unimaginable pressure – whether it be military, professional sports, or a pilot landing a plane on a river – and the explanation almost invariably involves the heroes saying, “We trained for this situation.”

5. Myth: Developers should take ownership of their code.
Ownership sounds good. As American as apple pie. Personal responsibility, right? But “ownership” in a software team implies that only one developer writes – and understands – each module of code. This leads to defensiveness on the part of the developer. It also creates risk for the business owner, since the loss of one person could slow the team, or potentially cripple the business if they were responsible for a particularly crucial part of the system. A much healthier process allows any developer to work on any code in the system. Pair programming facilitates this, because knowledge is passed from person to person. The so-called “bus count” (how many people in your team have to get hit by a bus before you’re all dead in the water) is a critical indicator of risk for the software start-up. And it’s not really a bus we’re talking about here – it’s your competitors, who would love to hire your best developers. The more people who understand the whole system, the stronger and more resilient your organization.

6. Myth: You need a quirky hiring process.
Would you hire an actor without an audition? You wouldn’t last long as a director if you did. But this is exactly what almost all companies who hire software developers do today. Usually the process involves talking through an applicant’s experience with them. And that’s all. Imagine asking an aspiring actor if they enjoyed their role as Hamlet. Did you play him well? Good. You’re hired! Many famous software companies propose brainteasers for their applicants. Some top companies even give candidates an IQ test. The best of them run candidates through a simulated software problem on a whiteboard. This is a sorry state of affairs. I’m going to state (what should be) the obvious: the only way to hire good programmers reliably is to program with them. I run programmers though a one-hour, rapid-fire, pair programming interview – and that’s just the start. Having done it over a thousand times, I can score developers relative to each other on a 100-point scale. What do I look for? Mental quickness, ability to think abstractly, algorithmic facility, problem-solving ability. And most importantly, empathy. Because collaboration is the most important thing we do, and it doesn’t matter how smart you are if you can’t relate to how other people think.

7. Myth: Specialization is essential.
Managers, quite naturally, want to attack problems by dividing and conquering. In software teams, this often manifests as an urge to force specialization. Front-end vs. back-end, database administrators, and so on. Brad Feld suggests in his blog that every team should have one “full-stack programmer”, someone who’s a true generalist. He’s right, but he’s not going far enough. Everyone, in every team, should know the full stack [Tim: read Carlos Bueno's piece here]. Why? Because specialization makes a team fragile. Remember that bus count? Every specialist is a liability; if they leave, and you can’t replace them, you’re sunk. Not only that, but it makes a team sluggish. Specialists need to make their disparate parts of the system communicate through defined interfaces. In effect, they end up writing informal contracts with each other about how to do it. This leads to a lot of overhead, and often defensiveness or finger-pointing. At Pivotal, every developer works on every level of the system, from HTML and JavaScript, to Ruby, and down to the database. And the argument that specialists will be better at a particular layer of the system if they’re allowed to focus on it doesn’t really hold water. The state of software technology today is simply not that difficult. Programmers are better off knowing all layers and how they interoperate. By the way, another important implication of all this: you don’t need to hire for a particular technology. Ruby programmers in short supply? Fine, hire a Java programmer and train them in Ruby (pair programming works great for this). Someone defines themselves as a “server-side” programmer? No problem, make them do JavaScript, they’ll pick it up.

If they’re any good, that is.
Read more about Pivotal Labs and find their collection of tech talks here. If you’re in SF or Boston, try TaskRabbit while you’re at it :)
Click here to browse this blog’s other Entrepreneurship posts (covering everything from Twitter and FUBU to selling companies and angel investing).

Thursday, June 9, 2011

How NOT to Improve Medical Practice Profitability

Research indicates that real estate is typically the 3rd highest expense on a healthcare provider's P&L statement, right behind labor and supplies, yet many seem to regard it as a fixed cost that can't be adjusted until the next lease expiration.  And yet physicians sometimes look elsewhere to compensate for reimbursement shortfalls...

I recently encountered a revenue enhancement strategy that caught me off guard and accentuated the need for physicians to look at real estate as a way to preserve profitability. 
My son had to visit his pediatrician this week for a pre-sports physical.  At the end of the visit, the office manager told my wife that we would be billed an extra $100 as part of the practice’s annual patient fee to make up for reimbursement shortfalls on immunizations.  My wife was stunned... so much so that she bit her tongue and suggested that they bill her for it rather than paying it then and there (I married well).  When she mentioned it to me that night, "stunned” was one of the softer words I felt!

In a follow-up call, here's what I learned.  This $100 is an annual “membership” fee the practice began assessing when their accountant told them they has crossed into the red operationally.  And it's not just $100 for everyone… kids under 2 and under are charged $100 every 6 months because they incur more visits and more immunizations.  Once they hit 2, it reduces to $100 per year.  Oh, and it’s per child, not per family.

What interested me about this professionally is that I don't doubt that the practice has been squeezed.  These are challenging times for Physicians, and they have to find ways to reduce costs. (earlier today I attended an MGMA conference focused solely on that topic. )  But rather than looking to patients to make up shortfalls out of their own pocket, did this physician engage a various professionals to investigate the possibility of reducing their overhead (real estate costs, for example)? I'll find out soon enough in this specific case, but in the meantime the question has to be raised more generically.

Our Healthcare Properties Group routinely helps medical practices reduce costs through strategic real estate decisions, and these decisions can be tied to a number of factors which my or may not be related to the timing of one's lease expiration.  Landlord events, tenant events, community trends, etc. can all impact what's possible.  The keys are (1) understanding these triggers and having being able to research them, and (2) approaching the landlord in the most effective manner.  Don't forget to consider this large balance sheet item when investigating cost-cutting possibilities.

Finally, for those who are wondering, I did have the pediatrician reverse the $100 charge.  Not because I'm unsympathetic, but because it wasn't disclosed in advance.

Here's to your success!


Friday, June 3, 2011

Exit Strategy is often overlooked

I met with a doctor this week who owns multiple medical real estate parcels AND a successful multi-location practice.  The doctor has some vacancies to fill, is contemplating an expansion at one location, would like to open an office in a particular area, and is open to sell at the right price.  Oh, and this doctor is 61 years old.

Whether you caught it or not, that last sentence DRAMATICALLY impacts all of the answers. 

Every decision this doctor makes needs to be considered in light of its impact on the marketability of the real estate AND the practice, as well as on the decision's payback period.  And for the non-medical business owner, the same principles apply.

Here are a few of our thoughts in the case of the doctor:
  • Unless there's a very large and very rapid payback on a building expansion, or if NOT expanding would hurt revenues or operations, it's not wise... particularly since healthcare reform muddies the payback period analysis.
  • If the plan is to sell the practice, then a sale-leaseback should be considered NOW.  The doctor can set the term and future rent levels now to maximize property value to an investor, and then sell the practice in 5 (?) years when the long term lease may not be as scary since 5 years of it is gone.  But... that rent level must not hinder the practice's P&L statement, lest the practice's marketability be affected.
  • Opening a new office may not be the best thing to do unless it can be carved out of the rest of the practice and become a place that this doctor settles into as a "retirement practice."
See how it works?  When developing any business plan, it's best to have exit strategy in mind from day one. When real estate ownership is part of the picture, it's critical.

WHOEVER you rely upon for your real estate advice, please be sure that they think strategically. I see far too many situations in which an "order taker" executes on the wrong strategy with results that limit future options.

Here's to your success!