Stories about Software


The Opportunist’s Guide to Start Consulting (Abridged)

Given the recent launch of Developer Hegemony, I decided to address a reader question.  This question hits near and dear to my heart and to the subject matter of the book. I’m going to paraphrase for the sake of anonymity.  But, either way, it amounts to a question about how to start consulting.

But First, Some Housekeeping

Before I dive into that, though, I’d like to make offer some links.  If you want to hear and read more from me, I offer you the chance.  Check these out.

And now, back to your regularly scheduled post.

The Reader Question

Without additional preamble, I’ll offer up the (paraphrased) reader question.

I’m currently a developer, and want to transition to freelance consulting. But I’m not quite sure where to start.. Do you have any advice on that? How did you manage to start a consultancy business?

First of all, understand the dichotomy here.  He asks for my advice and he also asks how I did it.  I ask everyone reading to understand that these aren’t necessarily the same thing.  In other words, I can tell you exactly what I did, but that doesn’t mean I think you should do it in exactly that way.

Oh, don’t get me wrong.  I don’t think I made any horrible mistakes or anything like that.  But I kind of wandered my way through the experience, not entirely sure at the time what I wanted.  Unlike the reader asking the question, I never explicitly decided to become a freelance consultant.  In fact, I just had some free time and wanted some extra money.

Read More


Eliminating the Job Interview via Partnership

If you follow this blog with any regularity, you probably know my take on the job interview.  One of my more popular posts asserts that hiring, as we know it, isn’t worth fixing.  And, my book, Developer Hegemony, contains an excoriating treatment of job interviews.  The practice started as a silly whim about 100 years ago, and we’ve just kept doing it, uncritically, ever since.  I’m going to talk today about partnership, and how I think we can leverage it to help.

But let me set the scene a bit, first.  In Developer Hegemony, I talk in more detail about the world without job interviews.  On the blog, however, I’ve just advised developers to interview with companies that minimize the stupidity of the process.  On the company side, the only advice I’ve offered is to picture a world where you weren’t allowed to interview.  Using this creative constraint, come up with alternatives.

Because of this less than detailed treatment, I’ve received reader questions like the following.  And, understandably so.

I love these articles, but I wish you would write one about what I should be doing to make good hires, instead of reinforcing how bad all the possible options I can think of would be 😉

So I’ve decided to address this.  In today’s post, I’ll offer an idea for an alternative.  I may turn this into a series, with different ideas, but I don’t want to get ahead of myself.

Caveat Emptor

First, a quick disclaimer.  What you’re about to read contains absolutely zero long-contemplated, research-backed academic work.  I haven’t even asked anyone for an opinion on this.

Instead, you can think of this more as something I dreamed up in the shower a few weeks ago.  Since then, I’ve idly contemplated it while waiting to board a plane or going for a walk in nice weather.  In this post, I will actually flesh it out in a bit more detail for my own clarification.

I won’t belabor the point further, but I do want you to understand that holes will exist.  I’m not writing this post to give you a ready-made playbook, but to give you the seed of an idea that you might incorporate as you make hires.  And, plus, it feels good to write something optimistic instead of frustrated and cynical every now and then.

Read More


Reader Question Round-Up

I’ve just returned from a vacation.  So, after a week of R&R, I’m going to write a post instead of cross posting one.  And I thought that getting back to reader questions after a hiatus might make for a good “welcome back” post.

I mercifully do not struggle with writer’s block.  As someone who gets paid to produce content for a number of outfits, writer’s block would present a deal-breaking problem.  I do, however, struggle with answering some reader questions at times.  Recently, it occurred to me why this might be the case.

Simply put, not all reader questions necessarily require a 1,000+ word post to answer.  Thus, I don’t struggle with writer’s block, but rather with “how do I expand this into a proper post?”  As I sunned myself in tropical climes this past week, it struck me.  Maybe I don’t.

As such, I’m introducing something that I’ll call “reader question round-up.”  In this new style of post, I’ll answer a series of questions — ones that I think I need fewer words than a full post to answer.  Hopefully, this keeps me from rambling and starts to clear out my rather sizable queue of backlogged reader questions.

Reader Question Round-Up

So, here goes.

Read More


Top Heavy Department Growth

I’ve been somewhat remiss in answering reader questions lately.  Largely, I’ve lapsed because I’m choosing to focus on my upcoming book.  Nevertheless, I apologize for the lapse.  I do appreciate all the questions you folks send my way.  I’ll try to compensate today with this post about organizations engaging in top heavy department growth.

I’ll paraphrase this reader question because the specificity of the titles and information involved could make it sensitive if I didn’t take a couple of liberties.

I read your article about architect title over-specialization.  I’m a software developer with senior level experience.

Recently, my company has created “levels” above me.  I used to have only a dev manager above me.  But recently, the organization has brought in both new team leads under the dev manager and architects under a different manager.  Both take precedence over the existing developers.  These people now have authority to tell us what to do and they get to choose what they want to work on, leaving us with the leftovers.

I feel as if i’m being promoted down hill. Can you please advise?

How Companies Expand

If you’re up for it, I’ll offer a good bit of background reading to flesh out the terms.  If not, I’ll furnish minimal definitions here for reference.  A while back, I wrote a post describing the company hierarchy.  That post contains excerpts from my upcoming book, which you can pre-order and read on leanpub.

Here you have an apt illustration of the average company.  At the top, in executive roles, you have opportunistic individuals who define (and violate) the rules and culture of the company.  Then, in the middle, sit the idealists, who guzzle that same kool-aid and ask for more.  Finally, at the bottom toil the pragmatists, who roll their eyes at the company but put up with it for lack of better options.

Significantly, pyramids retain their stability by maintaining their shape.  Thus the most stabilizing growth pattern involves rewarding (over-promoting) loyal pragmatists, and hiring a bunch of grunts beneath them.  If you think of an existing pyramid that needs to get larger, you wouldn’t heap stuff on top.  Instead, you’d build from the bottom.  You’d pull some senior developers, make them architects or team leads to reward them hanging around, and hire a bunch of new grunts to report to them.

Read More


Preemptively Identifying Dead Seas

Today, I’m going to try to tie various strands of my life together into one lanyard of efficiency.  I haven’t done a reader question for a while, so I’ll change that today.  In this post, I’ll offer a terminology nod to dead seas, a now-defunct term that became one of my favorites.  The best context I can now offer lies here, in a post of mine, summarizing it.

A few months back, I made a post on NDepend called, “What to do When Your Colleague Creates Spaghetti Code.”  In this post, I described a caricature that I randomly named Bill, who you might recognize as sort of a quintessential expert beginner.  I subsequently received a reader question about this subject.

How can I tell if the company interviewing me has a “Bill?” (i.e. “How can I preemptively identify expert beginners?”)

Well, I’ll take a crack at that.

Expert Beginner Primordial Soup

I think that a meaningful examination of this question requires us to look at the conditions that give rise to such archetypes.  In the original series/book, I cover part of it.  The organization must draw sort of a neat little box around the techie group and then put an advanced beginner in charge.  From there, the concoction needs to simmer in a nicely insular environment, in which the budding expert beginner receives no real negative feedback, second guessing, or industry exposure.

But this assessment focuses entirely on the software development organization.  An ensconced expert beginner reigning over some miserable, backward fiefdom requires “the business” as an accomplice.  Simply put, it requires the operational laziness to allow your business to be ruled by an unaccountable “expert” operating with utter opacity.

Expert Beginner Hut

Imagine you started a pizza shop and hired a pizza chef to run the kitchen.  Then imagine that you completely delegated the cooking to the chef, as you should.  Life treats all of you well for a while and you develop some business.

But now complaints from customers start to come in about the taste and presentation of the pizza.  “My pizza was incredibly salty and all of the pepperoni was isolated to three slices!”  When you bring this problem to the chef, he tells you that such is life when it comes to making pizza—and, also, get out of the kitchen.  You don’t taste the pizzas coming out or look at them or launch any sort of investigation when his pizza chef assistants serially quit, muttering about his incompetence.  You just count the inbound trickles of revenue and assume that’s as good as it gets.

Read More