Tag: maturity

Organizational Debt

In today’s post, I add to the copious literature on technical debt with a discussion geared to my audience of F&I entrepreneurs, and extend the metaphor into organizational design.  What I noticed, writing Maturity Model, is that software development is rich in models and metaphors that apply outside the trade.

Technical debt is incurred when software developers take shortcuts, usually because they are under time pressure.  This debt is accrued in program code, but it must eventually be paid off with real money, just like the debt on your balance sheet.  Here is a brief discussion of how that works.

Someone once insisted that my team “just code IF State = TX, and get on with it!”  Not on my watch.  We will categorize Texas, and then we will add other states to the category as we discover them.  For example, the category might be “waiver GAP states,” or “spousal consent states.”

Operating or back-office issues, often related to IT, are recurring concerns for strategic buyers. Problems with IT underinvestment have proved to be ordeals during many integration efforts.

If you go down the road of IF State = TX, then in short order you will have code with IF <list of ten states> do this logic, and for <five of them> also do this other logic, but for <three of the ten> do this instead and for <the other two> do both of those things.

Congratulations, you have saved forty hours of programmer time versus stubborn Mark Virag and some academic exercise involving categories.  Now you are married to this gnarly decision tree, and you will be debugging it forever.  The technical term is Big Ball of Mud.

One warning sign of technical debt is the “cut and paste” approach.  If your developers implemented the latest dealer, provider, lender, product, or state by copying code from the one before, then I guarantee you have technical debt.

Any developer worth his salt will, instead, make the copied code into a reusable method.  Developers are trained to do things the right way and, in my experience, only take such shortcuts because the boss told them to.

Why not cut and paste, if it gets the job done?  Because, if there are any bugs in the copied code, now they’re multiplied and scattered throughout the code base.  You will have to spend programmer time to fix each one separately, as they are encountered over time.

I could go on with examples all day.  The point I want to make is that technical debt is real money.  You may go “quick and dirty” this week, and save $5,000 of developer time, but you will be paying those same developers later when they have to fix the bugs.

You may reasonably decide that you are a little short this month, and take a loan from the invisible bank of technical debt, but you should do so consciously.  Don’t fool yourself that technical debt is free.  I have provided an example here in the form of TILA box, something my F&I readers will understand.

Now that I have that off my chest, let’s discuss investment decisions.  For example, if you’re a startup and strapped for cash, you may choose to pile up technical debt because it’s off balance sheet and may be the only kind of financing you can get.

Of course, no one actually thinks about it this way.  What they tell their developers is, “just keep patching it until we’re profitable and you can overhaul it later.”  You may even sell the company, rickety software and all, if the acquirer fails to do proper diligence.

When I was doing international software search for BMW, our due diligence guy in Munich was Dr. Dettweiler.  We would find some software that looked pretty on the outside, and then the doctor would fly in and discover it was all a façade, like a movie set held up with sticks.

McKinsey specifically warns against acquiring a company with a big ball of mud in the back office.  Like process maturity, this is a concept that goes beyond software development.

In my time as a consultant, I have designed an organization or two, and it’s a lot like programming.  You have to have the right boxes on the org chart, with the right procedures and job descriptions, kind of like designing objects that will respond to business events (except they’re people).

Organizational debt is caused by the same kinds of things that cause technical debt.  For example:

  • The structure worked fine ten years ago when we had one-tenth the number of people.
  • It was never actually “designed” to begin with, but we reorganize ad hoc every other year.
  • The structure is based on specific people instead of job functions.
  • There are processes for which no one is actually responsible, so things “slip through the cracks.”

Fortunately, people are remarkably resourceful.  They will create their own procedures and informal networks.  Good people can prop up a bad organization, like those sticks holding up the movie façade, but they can only hold out so long.  Sooner or later, they will start to slip – and customers will start to notice.

Now I feel like I really am writing a pitch for consulting services. Call now!  Free reorg with every digital transformation.  Seriously, though, my point is that organizations can harbor technical debt just as software can.  This is why I am a fan of formal methods like ISO certification and, yes, professional organizational design.

More broadly, I am starting to notice that software development concepts – like process maturity, technical debt, iteration, and agile teams – are applicable throughout the enterprise.  We’ll explore this further in an upcoming post.

Maturity Model for Software Startups

Software companies begin life at CMM Level One, and some of them die there. You may not be familiar with the Capability Maturity Model, but you will always remember your time at Level One. This is where the developers code all night because you need that next feature, to keep paying the rent. This is where you release new code and then spend all day patching it, in production.

How many users do you suppose we’ll drop, if we reboot it right now?

On the other hand, it is possible to have too much process control. I was at a Level Four company once where we had to three-bid a project to plan and initiate a second project that would develop the software. The chart below, from Ron Patton’s book, shows the levels as stair steps.

The model contemplates an otherwise stable company that has weak processes only for software. In a startup, all processes are weak and resources are limited. To be successful, processes must mature in step with revenue. In this article, I’ll illustrate holistic process maturity with some examples.

At Level One, you have limited HR capability, and therefore no diversity training or compliance. You have no benefits, no vacation policy, no travel policy, and no expense audits. Your exposure to liability is huge, for everything from “constructive termination” to respondeat superior.

The reason for Brad’s separation from the company is a private matter which I am not at liberty to discuss.

I looked into this, and found that there is indeed a maturity model for HR. The first step, in my experience, is to crib an employee manual and make everyone sign that they have read it. At least then you can disclaim any actions that go against the boilerplate in the manual. You might also invest in an employment law poster.

At Level One, you also have no marketing function. The sales people roll their own presentation materials, talk tracks, and brand message. The first step is to hire a dedicated “marketing person,” to do sales support and organize your booth at NADA. Actual marketing comes later.

Entrepreneurs are good at tracking their sales and market share. People I work with look forward to their first thousand dealers, a public dealer group, or a big agency. Celebrate each milestone by notching up your process maturity.

I would say that you should be out of Level One (for software) after eighteen months. If you are already taking distributions, while the business depends on “heroes and luck,” then you are gambling. Raise some capital, hire a good manager, and get it fixed. My earlier article, Sales-Driven Development, describes what I feel is a reasonable level of process maturity for a young software company.

Baby Steps

I will close this post with a few pointers for leaving Level One. Basic stuff. Most readers should be able to skip this list.

  • Create a maintenance window and stick to it. Only move code to production at 6:00 AM on Wednesday. If anything goes wrong, people are in the office. It’s also not Saturday, our peak volume day. If you are constantly having “emergencies” that can’t wait until Wednesday, you need to look at that.
  • Implement a code control system with a rollback capability. If the latest build has a problem, at 6:10 AM on Wednesday, you do not start debugging. You push the rollback button.
  • Set up a reliable QA environment, and sync it with the production database. I don’t know how many times I have heard that the build worked in QA but some new data was encountered in production, and it crashed the site.
  • Create a division of labor, such that the developers stop fussing with the servers. Developers love to fuss with  infrastructure, which is not their skill set.  At all.  Hire a professional, or rent one from your cloud service provider.
  • Implement a work order tracking system. Planning at Level One is a “pushdown stack,” which means that yesterday’s panic is still simmering when it is superseded by today’s panic. Start by writing commitment dates on a bulletin board, so that everyone has visibility into the backlog.