DaedTech

Stories about Software

Nov
3

By

From Developer to Consultant

Category: Free Agent Developers, You Asked For It Tags: | 4 Comments

Editorial Note: Next week, I’m going to Panama to explore the canal.  I have no idea how much internet access I will see, so next week could potentially be a quiet week for DaedTech posting, if I can’t log in to publish a few cross posts.

If you write software, but not for the company that signs your paychecks, this title may sound strange to you.  “What do you mean, ‘from developer to consultant,’ when you can be both?”  I have answered that question previously, so I won’t rehash it here.  Suffice it to say writing code for someone other than your employer does not a consultant make.  (But read that post, seriously, because it becomes even more important later in this one.)

A few readers have submitted variants of the same question, so I’ll capture it simply, and as a composite.

As an independent, how do I go from doing app dev work to consulting?

I added the bit about independent status because it matters.  Without that, I could answer trivially by saying, “get hired by a consulting firm that wants you to consult, and let them train you.”  But if you go from contract to contract slinging code or if you write code as a W2 employee, you have a less obvious transition.

The Nature of Both Beasts

Before I lay out a tactical set of steps, I need to define the underlying nature of both roles.  In the taxonomy post, I approached the matter in terms of definitions, as one might expect from a taxonomy.  Here, I want to talk philosophy.

I once gave seeking app dev work a satirical treatment.  I asked the reader to imagine a world where, instead of “I’ll fix your garage door” contractors advertised their services with “I have 5 years of hammer, 2 years of table saw, proficiency with 6 kinds of metal, etc.”  As an app dev contractor or W2 employee, you offer the world the latter.  You say, “here’s a brain dump of stuff I’ve done, so all I need is someone who knows how to make me useful and who also signs checks, and we can get going.”  You offer exactly the sum of your experience tuples.

SwankyToolBelt

A consultant, on the other hand, offers services akin to general contractors.  “Call me if you have a problem with your garage door, and let me worry about finding someone who can do the job and how many ‘years of hammer’ they need.”  An app dev free agent solves one problem (writes code for someone who can’t) even as he presents another (figure out what skills are needed and manage that person during execution).  A consultant steers clear of execution and offers only guidance.

Read More

Oct
11

By

How to Get an Edge As a Consultant

Category: Free Agent Developers Tags: , | 2 Comments

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look around at some of the documentation around code metrics and queries.

I’ve made no secret of, and even frequently referred to my consulting practice, including aspects of IT management consulting.  In short, one of my key offerings is to help strategic decision makers (CIOs/CTOs, dev managers, etc) make tough or non-obvious calls about their applications and codebases.  Can we migrate this easily to a new technology, or should we start over?  Are we heading in the right direction with the new code that we’re writing?  We’d like to start getting our codebase under test, but we’re not sure how (un) testable the code is — can you advise?

This is a fairly niche position that’s fairly high on the organizational trust ladder, so it’s good work to be had.  Because of that, I recently got a question along the lines of, “how do you get that sort of work and then succeed with it?”  In thinking about the answer, I realized it would make a good blog post, specifically for the NDepend blog.  I think of this work as true consulting, and NDepend is invaluable to me as I do it.

Before I tell you about how this works for me in detail, let me paint a picture of what I think of as a market differentiator for my specific services.  I’ll do this by offering a tale of two different consulting pitfalls that people seem to fall into if tasked with the sorts of high-trust, advisory consulting engagements.

LikeABoss

Read More

Sep
28

By

Software Architect as a Developer Pension Plan

Category: Free Agent Developers Tags: , , | 16 Comments

I’m pretty sure that I’m going to get myself in trouble with this one.  Before I get started and the gnashing of teeth and stamping of feet commence, let me offer an introductory disclaimer here.  What I am about to say offers no commentary on people with the title, “software architect” (a title that I’ve had myself, by the way).  Rather, I offer commentary on the absurd state of software development in the corporate world.

The title “software architect” is silly (mostly because of the parallel to building construction) and the role shouldn’t exist.  Most of the people that hold this title, on the other hand, are smart, competent folks that know how to produce software and have the battle scars to prove it.  We’ve arrived at this paradoxical state of affairs because of two essential truths about the world: the corporation hasn’t changed much in the last century and we software developers have done an utterly terrible job capitalizing on the death grip we have on the world’s economy.

Architect

A Question of Dignity

I’m not going to offer thoughts on how to correct that here.  I’m doing that in my upcoming book.  Today, I’m going to answer a question I heard posed to the Freelancer’s Show Podcast.  Paraphrased from memory, the question was as follows.

I work for a small web development firm.  I was in a meeting where a guy said that he’d worked for major players in Silicon Valley.  He then said that what web and mobile engineers offer a commodity service and that he wanted us to serve as architects, leaving the less-skilled work to be done by offshore firms.  How does one deal with this attitude?  It’s a frustrating and demeaning debate to have with clients.

This question features a lot that we could unpack.  But I want to zero in on the idea of breaking software work into two categories: skilled work and unskilled work.  This inherently quixotic concept has mesmerized business people into poor software decisions for decades.  And it shows no signs of letting up.

Against this backdrop, “major player’s” attitude makes sense.  Like the overwhelming majority of the business world, he believes the canard about dividing work this way.  His view of the unskilled part as a commodity that can be done offshore smacks of business wisdom.  Save the higher-waged, smart people for the smart people work, and pay cheap dullards to do the brainless aspects of software development.

Of course, the podcast listener objects.  He objects to the notion that part of what he does fits into the “cheap commodity” category.  It “demeans” him and his craft.  He understands the complexities of building sites and apps, but his client views these things as simple and best delegated to unskilled grunts.

Why the Obsession with Splitting Software Work?

It bears asking why this thinking seems so persistent in the business world.  And at the risk of oversimplifying for the sake of a relatively compact blog post, I’ll sum it up with a name: Taylor.  Frederick Taylor advanced something simultaneously groundbreaking and mildly repulsive called Scientific Management.  In short, he applied scientific method principles to the workplace of the early 1900s in order to realize efficiency gains.

At first, this sounds like the Lean Startup.  It sounds even better when you factor in that Taylor favored more humanizing methods to get better work out of people than whacking them and demanding that they work harder.  But then you factor in Taylor’s view of the line level worker and you can see the repulsive side.

The labor should include rest breaks so that the worker has time to recover from fatigue. Now one of the very first requirements for a man who is fit to handle pig iron as a regular occupation is that he shall be so stupid and so phlegmatic that he more nearly resembles in his mental make-up the ox than any other type. The man who is mentally alert and intelligent is for this very reason entirely unsuited to what would, for him, be the grinding monotony of work of this character. Therefore the workman who is best suited to handling pig iron is unable to understand the real science of doing this class of work.

Basically, you can split industry into two camps of people: managers who think and imbeciles who labor.  Against this backdrop, the humanizing angle becomes… actually sorta dehumanizing.  Taylor doesn’t think grunts shouldn’t be whipped like horses because it’s dehumanizing, but because it’s not effective.  Better ways exist to coax performance out of the beasts.  Feed them carrots instead of hitting them with sticks.

Depressingly, the enterprise of today looks a lot like the enterprise of 100 years ago: efficiency-obsessed and convinced that middle management exists to assemble humans into bio-machines that needn’t think for themselves.  Nevermind that this made sense for assembling cars and textile manufacture, but not so much for knowledge work projects.  Like the eponymous cargo-culters, modern corporations are still out there waving sticks around in the air and hoping food will drop out of the sky.

Read More

Sep
6

By

The Billing Maturity Model

Category: Free Agent Developers | 9 Comments

Editorial Note: I just want to mention that I realize I’ve done a disproportionate amount of cross-posting lately.  Perhaps no one notices or cares; these posts generally seem to be pretty popular.  But in case you were wondering why I’m doing that, instead of DaedTech-specific posts or answering reader questions, it’s because I’m trying to focus most of my non-paid writing on Developer Hegemony.  I’m getting into the homestretch with it. Once I finish the draft, you’ll probably see a higher ratio of DaedTech-specific posts.

Last week, I wrote a post about my experience with software consulting.  It generated some buzz and discussion, and I received a good bit of feedback from regular readers that they’d like to see more of these posts about the consulting game.  Today I’m going to oblige.

In that post, I talked obliquely about wanting to get away from hourly billing models.  The main thrust of the post was about two realizations that have been more central to my happiness (writing code at an hourly rate is a career-limiting activity and engagements of indefinite length create pseudo-employment).  As a result, the general theme of alternatives to hourly billing took a backseat.

The Challenge of Doing Something Other Than Hourly Billing

I have strong feelings about this topic, but I also view it as a larger topic and a larger hill to climb.  After all, I can keep myself happy by simply avoiding hourly coding (in favor of strategy consulting, training, and the like) and only agreeing to engagements once success criteria have been established.  Client don’t push back against these considerations.

But things tend to get more interesting when you propose arrangements other than hourly billing.  For many clients, this is befuddling and unheard of.  You might as well propose that they also start working from 8 PM to 4 AM.  Thus moving away from hourly billing requires more strategy and finagling.

In this post, I’m not going to delve into that strategy.  I mention the difficulty of moving away from hourly billing only as an explanation for why I haven’t yet eliminated it from my life altogether, the way that I have with hourly coding and open-ended engagements.

Instead, I will talk today about alternatives to hourly billing.  Some of these I’ve explored, and some of these I’m seeking to explore.  But I believe all of these billing models fall along a continuum of what I think of as a maturity model of billing arrangements.

It might surprise you to learn what I believe the differentiator is along this axis.  It’s not profitability nor advantage for the consultant.  It has nothing to do with status or business/management fads.  Rather, I evaluate these models in terms of the amount of partnership that takes place between consultant and client.

TopGunPerform

Read More

Aug
28

By

My Realizations about Software Consulting

Category: Free Agent Developers Tags: , | 21 Comments

I consume a lot of audio books.  Most recently, this habit led me to listen to a book by Allen Weiss, called Million Dollar Consulting.  The title yields the book’s premise in deceptively simple fashion: a guide to building a seven-figure-per-year solo consulting practice.  Sound crazy?  Two and a half years ago, when I went into business for myself full time, I would have thought so.  Now, it sounds pretty doable to me, if that’s your thing.

BigPileOfMoney

This isn’t to say that I have a million plus dollar per year consulting practice — just that I understand how someone could achieve what he’s talking about in a way that I couldn’t have back then.  Listening to this book gave me cause to reflect on my free agent journey, so I thought I’d write about that today.  (I know there are some who’ve wanted more of these posts anyway)

When I first took the free agent plunge, I had a fairly vivid picture of how it would work.  I was leaving a job running an IT department, and what I sought was a practice where I helped solve targeted technical problems for a portfolio of clients, rather than solving all sorts of organizational problems for a single entity.  I wanted both to diversify and to become more project-focused.

The Neophyte Techie Free Agent

Beyond that, I didn’t really have a firm grasp of the path to growing profit.  At the time, I assumed that technical consultants did what members of app dev groups did, but for much higher pay (due to transience and achieving better results).  That is, I might do a mixture of application development, architectural consulting, training, mentoring, troubleshooting, etc.

I’d start out charging, say, $100 per hour and then let supply and demand drive up my rates as I pleased more and more clients.  This, I reasoned, was the path to bill rates exceeding $250 per hour.  And, why not?  That seems to be how so-called app dev consultancies work, offering blended rates and billing out their principals and super-awesome-folks at $250/hour.

At the time, I remember chatting with John Sonmez of Simple Programmer.  He and I knew each other through the blogging community and through Pluralsight.  He’d made a similar career play a year or two earlier than I had, so I picked his brain about his journey.  He told me something quite memorable, in that it proved prescient, but was inconceivable to me at the time.  “I want to get away from trading hours for dollars.”  Huh.

Read More

« Older Posts
Newer Posts »