I read a good book over Christmas break, The Digital Transformation Playbook, by David Rogers. This is a good book because it has both theory and practice, plenty of research and real-life examples, and practical “how to” guides.
Just when you’re thinking, “oh yeah, when has that ever happened?” Rogers comes up with an example. Many of the these include commentary from the people who worked on them. It’s clear that the professor gets out of his classroom for a fair amount of consulting.
Digital transformation is not about technology – it is about strategy and new ways of thinking.
Most books like this focus on digital native startups. That’s the sexy stuff and, in fact, where I have most of my experience. I chose this book for its focus on digital transformation, in existing companies and hidebound industries (like auto retail).
The book is organized around five strategic themes: customer networks, platform marketing, upgrading your value proposition, data as an asset, and innovation through experimentation.
I did grow a little impatient with Rogers’ incessant enumerating: five core behaviors, four value templates, three variables, two trajectories (and a partridge in a pear tree) but I appreciated the effort to boil everything down to a foolproof recipe. There are a number of these:
Customer Network Strategy Generator
Platform Business Model Map
Value Train Analysis
Data Value Generator
Experimental Design Templates
Value Proposition Roadmap
Disruptive Business Model Map
Disruptive Response Planner
Digital Transformation Self-Assessment
I was even inspired to start making value train diagrams of our business, and platform model maps:
On the theory side, Rogers reexamines familiar models from people like Drucker and Levitt. He shows, for instance, that Christensen’s theory of “digital disruption” is a special case, and broadens it.
By the way, this discussion of digital disruption is one of the most lucid (hype-free) that I have read. As usual, there is a checklist: analyze three features and choose one of six strategies. If that doesn’t work then, yes, you’re disrupted. Time to update your resume.
I read all the time, though I don’t often write book reviews (here is the last one) so Rogers’ fifteen-page bibliography was an extra treat. That should keep my Kindle stoked for a while.
Things are going well here at Safe-Guard, and I am looking to hire another eCommerce Product Manager. Posting is here. We need someone who can not only manage a shopping site but, as we are in the midst of a digital transformation, also establish the required support and fulfillment processes.
The eCommerce department manages the development and support of these properties, whether they are standalone web sites, dealer-site storefronts, or web services …
The successful candidate will have solid product management experience, and maybe some digital marketing. Agile development experience a plus. Self-starter. Relocation. Salary commensurate with experience.
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.
Feeling quantitative again today, so … suppose you have an F&I Director, or a menu trainer, or somebody, and their goal is to move product index from 1.0 to 1.2 over some time period. To keep the numbers simple, let’s say the variable comp component is $10K.
One way to do this is to say that 1.2 pays $10K and the current performance, 1.0, pays zero. This makes sense, right? Why pay for no improvement? This only works, however, if you place a cap on it. As the salesman, I could come back and say, fine, if the two points of product index are worth $10K to you, what happens if I hit 1.4? Are you willing to pay me $20K for that?
Most people resist the idea of capped pay plans. Mathematically, you are making a linear relationship between compensation and performance, and you should be willing to honor that relationship up and down the line. The problem here is that the line is too steep.
So, let’s try a shallower slope. Once again, 1.2 pays $10K, but this time the zero point is 0.0. That means the current performance, 1.0, still pays $8,333 and the salesperson doesn’t go hungry unless the index actually falls all the way to 0.0. Obviously, this plan is too weak.
The weak plan may be desirable if your sales force is really counting on some of that money, and the “variable” is not as variable as advertised. It also protects the company on the up side. In this example, I can achieve a 1.5 index and it only earns me an extra $2,500 (on top of the $10K).
Now we have examples of two pay plans, one too strong and one too weak, as in the story of The Three Bears. The key to making the pay plan just right is to observe that the zero point is arbitrary. In the papa bear case, too strong, we set the zero point at 1.0, the current performance. In the mama bear case, we set it at an index of 0.0.
Recall that a line on a graph is determined by two points. One point is fixed by the target and the bonus (1.2, $10K) the other point is set by where you place the zero (z, $0) and between them they determine the slope:
If you’re making this chart right now remember to place the independent variable, product index, on the x-axis. All that remains is to compute the y-intercept of your line. The point where the bonus is zero, z, is the x-intercept. A little algebra gives the y-intercept as:
Now we are ready to start plotting. This time, let’s split the difference and set the zero point at 0.5. This seems to be just about right. Comp for standing still, 1.0, is $7,143; for 1.5, only $14,286, and our guy doesn’t starve until 0.5.
If you have this set up in a spreadsheet, you can tweak the zero point until you have the desired amount of exposure for both parties. Below is the chart for my “goldilocks” line, with the mama bear case for comparison.
We always give careful thought to the target, but sometimes neglect the slope of the payoff line. Next week, we will talk about two-dimensional pay plans, combining product index and PVR.
Gartner Group says “the API is the product.” I am looking for an experienced product manager who knows what Gartner Group is and why they say that. The API in question is Safe-Guard’s collection of dealer-facing web services. This is a topic I have worked on and written about extensively, as here, and now I plan to try the product manager approach.
The successful candidate will have solid product management experience, preferably with an API, and maybe some pragmatic marketing or agile development. Software development experience a plus. Self-starter. Relocation. Salary commensurate with experience.
I am in the process of creating an eCommerce department for Safe-Guard. Regular readers know that I specialize in creating new organizations, and my record is pretty good. The training function, which is also a kind of sales function, is likely to grow. So, this is an opportunity to get in early.
The job is to train all of the F&I managers who sell products administered by Safe-Guard, and ensure they know how to present them properly using any of the top ten menu systems. For one person, at least to begin with, this will be a challenge. We are in thousands of dealerships.
Thus, the successful candidate must have the skill and temperament to leverage the resources of our affiliated agents, vendors, manufacturers, and dealer groups. Self-starter. Travel. Proficiency in F&I procedures and software, notably menu systems. Salary commensurate with experience.
Since I posted Why I Freelance a few months ago, people have been asking me for advice on how to get started. So, this week I fulfill a promise to share some pointers.
There are probably books on this, and they’re probably better organized, but here is my experience. We start with the easy stuff:
Form a legal entity. I have tried various forms over the years, including a Latin American SA. What I recommend for you is an LLC. This leaves you free to elect C- or S-Corp tax status later – and you don’t need a lawyer. You can form an LLC online for a few hundred dollars.
Draft a consulting services agreement. For this, you will need a good lawyer. It is always better if you can send a prospective client your standard contract. This frames the negotiation in terms favorable to you. Pay special attention to the non-compete terms.
Find a good accountant. If you are good at tax prep, and using a “disregarded entity,” you may be able to do the firm’s returns on your own. Otherwise, seek professional help. Pro tip: pay Uncle Sam quarterly to avoid a surprise at tax time. Canadian pro tip: keep your HST receipts in a separate account.
Choose a tax status. The last time I was incorporated in the U.S., I used an S-Corp. This is a hassle because you have to deal with payroll tax. It was handy for me because I was able to have my wife on the payroll. The Canadian version of this is called “income splitting.”
Set up a web site. No, don’t look at mine. It’s overdue for an update, and this here blog is my main presence online. Depending on how you plan to market yourself (see Networking Tips for Consultants) you will spend more or less money on the web site – and you may have to learn about SEO.
Open new bank accounts, and obtain a corporate credit card. Using the corporate card is an easy way to keep your business expenses separate, and it’s a source of working capital. When I started at GMAC, it was months before I got paid, and I had accrued thousands of dollars in expenses.
Learn how to use QuickBooks. As you can tell by now, keeping the books is a big part of running your own business. You will need to keep track of your accounts, and payroll, and 1099s, and present your clients with professional-looking (and accurate) invoices.
Obtain health insurance. I can’t help you here. I haven’t lived in the U.S. since Obamacare took effect. I understand it’s expensive. At present, I have an international Blue Cross policy. Depending on your tax status, this is deductible on either your business or your personal return.
Plan your budget. Figure out how much income you need to pay the bills, and then figure out how you can earn that much – after taxes – assuming you are on the beach for three months of the year. That’s a sardonic Big Six expression, “on the beach.” It does not mean happy hour in Playa Bonita.
Identify your prospective clients, as specifically as possible, and where they’re located. Unless you have a versatile skill set and live in a high-demand area – developing software in Seattle, for instance – you will be on the road. I could write a whole ‘nother article about living on the road.
I presented the easy stuff in a short list that you can print out and check off. Now, the hard question is, why should somebody buy what you’re selling – and for how much?
As of this writing, I know that I can rent a good software developer for about a hundred dollars an hour, and down to $65 for newbies. The rental agency may keep up to 25% of that, which is not the scam it sounds like once you consider they have to do all the stuff on that list – plus find the gigs.
If you can possibly manage it, work under contract for whatever agency serves your trade – they’re ubiquitous – and learn everything you can about how they do business. Learn how they handle sales, contracts, billing, payroll, benefits, beach time, and something called “realization.”
Your situation will depend on how old you are, and where you are in life. The best way to start is with a firm, while you’re young, and before you have kids. Consulting can be demanding. If you have a family, I recommend keeping your day job, and then picking it up after the kids are grown. I know a bunch of successful “mature” consultants.
I was fortunate to start in a Big Six firm (there are four now) that taught me how to manage clients, how to sell an engagement, and how to write a statement of work. I had classroom training, role playing, one-on-one instruction, and a whole lot of hard knocks. That early experience was priceless – and I can’t distill it into a blog post, sorry.
The good news is that I was a lousy staff consultant. All of this stuff is trainable. I hope these few pointers from me will help you to make the transition. On the other hand, if you’re having second thoughts – that’s valuable too. It’s not for everybody.