The Merits and Ethics of Learning on the Job in App Dev

Another Monday, another successful reader question Monday.  Today’s question is about learning on the job.  Let’s take a look.

This is more of an app dev shop question than a consulting question, but here goes.

Say you’re consulting for a client and the client has a specific need for some app dev work which they ask you to do. That work requires you to use a technology that’s either completely new to you, not quite in your line of specialty, or you haven’t used in several years, but you’re constrained in some way to use this technology and to do the project you would need to “ramp-up”.

The question is: do you bill the client for this “ramp-up” time or do you take the hit against your own personal time to come up to speed? Does it make a difference in the response if it’s a legacy technology that you may never use again (FORTRAN) vs. a “hot” language that it would benefit you to learn (Python)?

First of all, for everyone else, here’s what the reader is referring to about consulting vs. app dev.  I’ve written a good bit about how writing software for someone else isn’t “consulting” no matter what people might call it.  So the question concerns either app dev shops or app dev freelancers.

Learning on the Job: The Quick Answer

I’ll start by answering the question at the tactical level.  Should you bill for this ramp-up time?  Absolutely, as long as you can negotiate it and you do so in good faith.

The last time I agreed to app dev work, I dealt with something like this.  I’d worked with the client before, and they liked my work.  I had domain knowledge and we had a good rapport, so they engaged me for some work.  I told them that I had to learn an important technology as I went, and they were fine with this added cost.  They viewed it as worth it.

Contrast this with a different situation.  Imagine you’re a Ruby on Rails developer and you need some work.  So you answer an RFP for help with an ASP MVC site, knowing nothing about ASP MVC but claiming you’re competent.  That’s pretty much the opposite end of the spectrum, and obviously problematic.

So start with the requirement that you’ll be frank about anything you need to learn to execute on an engagement.  The matter of who bears the cost of that learning then becomes a matter of negotiation as part of the contract.  And, that should make sense, since you’ll always have to learn something to help a client.  If you need the gig more than they need you, you might need to spend unpaid evenings learning a framework.  If they really need you and you’re on the fence, you can require that they include your onboarding as part of the deal.

Looking a Little Deeper.  Why Does This Happen, Anyway?

Learning on the job becomes almost entirely a matter of negotiation at the tactical level.  But I’d like to go back to the reader question for a moment.  There are some interesting parameters baked in there that speak to the plight of the software pro masquerading as a consultant.

How does this sort of situation come up, anyway?  How do you wind up spending an hour teaching yourself some framework and wondering who should pay for it?  And how do you wind up (potentially) getting paid not to know what you’re doing?  It comes down to two things:

• Billing for time spent instead of outcomes delivered.
• Operating as an order-taker instead of a problem solver.

I say this with no judgment.  After all, I told a story about my last app dev gig a couple of years ago.  This applied to me then, as well, and also to tons of app dev gigs I’d done in the past.  It’s the nature of being a software pro (as opposed to an actual consultant or a service provider).

Software Pros as Order Takers

Say you’re a software pro.  A client calls you up and says, “So, I’ve got this old green-screen system…”  He proceeds to explain to you that both the hardware and the folks that can program it are aging out of the workforce.  He needs you to come in and build a modern system to replace it.  It should involve a Java-based server for the back-end processing, and so that he can support both a web interface and, later, a mobile app.  It’s a textbook modernization play.

As a software pro doing app dev, you say, “sure, boss, when do I start?”  And that’s when you start negotiating the on-the-job learning.  Those green screen things are driven by COBOL, and you’ll need to learn at least enough of that to reverse engineer the requirements.  You claim that warrants hazard pay, and the client agrees.  So you get paid to build a Java backend, some kind of snazzy web front-end, and to teach yourself COBOL.

Consultants and Service Providers as Outcome Providers

That’s what a software pro/order taker does.  But not so much a consultant.  The consultant would want to understand a lot more first.  How do you know this system is worth replacing?  What if you just let it die?  Or, if not that, why not just buy a COTS product to replace it?  Could you build an adapter over the green screen backend and build only your web front end?  And, so on.  The consultant would want to have a value conversation and decide that the project would yield a return on investment.

These conversations can lead to surprising revelations.  Maybe they’re doing this whole modernization basically just to get years and years of customer data out of the old system.  “Ahh… okay!  Why don’t I just build you a one time migration to a cloud-based CRM system?”

“You know, I think that might work.”

And just like that, you can save the client tens or hundreds of thousands of dollars.  It’s a rather dramatic example, but stuff like this really does happen.

Consultants chase outcomes like this.  They don’t come in as laborers, but rather as strategic partners.  Having these conversations about the purpose of the engagement is sometimes known as “moving up the value chain.”  And when you do that, the tactical details of how you spend your hours or what frameworks you use doesn’t matter any more.  Once you’ve proposed the CRM migration, do you think that client cares anymore in the slightest whether you script that in Powershell or Python?

Stop Competing with Everyone and Find Your Unique Positioning

After answering the question relatively succinctly, why am I spending so much time on this?  Well, because I’d like ultimately to answer the question by making it so people never have to worry about this.  If you’re doing good business as a freelancer or agency, this shouldn’t come up.

When you offer yourself as an app dev generalist, you offer yourself as a staff augmentation and a laborer.  A client (really pseudo-boss) has a bunch of stuff for you to do, and you compete with a billion other generalists just like you for the labor.  One of your competitors will know all the techs or do a better job of faking it, creating a race to the bottom.  Your competition will claim to know things and learn unethically on the job, squeezing you out.

So stop being a generalist.  Stop competing with everyone that has a pulse and an Upwork account.  Make what Jonathan Stark calls a “laser focused positioning statement.”

I help companies with untenable green screen apps define and execute the simplest viable migration to modern systems.  Unlike my competitors, I don’t do forklift upgrades that drag on for years and try to recreate 40 year old systems in the modern web browser.

Never Worry about Learning “On the Job”

Once you define a service or productized-service that you offer, you can more easily price it without selling hourly labor like an employee.  You can sell the green-screen modernization by the database table or by the number of lines of COBOL in the old system or something.

If you price based on something other than hours, then finance is no longer a zero sum game between you and the client.  You no longer choose who absorbs the cost of your learning.  You absorb it, but that’s fine, because it helps you deliver subsequent contracts more efficiently.

But, here’s the thing.  When you offer a specific and outcome-based service, you become an expert, and you dictate the techniques, tactics, and technologies involved.  You learn to deliver this service get good at it, and your cost goes down with each gig while your price remains the same or goes up.

I’ll close by answering the question for myself, personally.  I’ve stopped doing generalist app dev work, and I never charge anyone for me ramping up on anything anymore.  It’s not relevant, because I only take on work where I’m telling the client what outcome I’ll deliver and exactly how I’ll do it.  Tactical decisions are mine to make.  And I’ve never been happier, and I’ve never had happier clients.

Fire Away with More Questions!

If you have a question, please feel free to ask:

No Fields Found.

And, by the way…

If you like the wisdom here, such as it is, you can get a whole lot of that more in my recently released book, Developer Hegemony.  If you want a sample of that, you can sign up to download some chapters below.