Stories about Software


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






Learning on the Job

Learning on the Job: The Quick Answer





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:

And, by the way…


Want more content like this?
