DaedTech

Stories about Software

By

Software Career Anti-Patterns: Career Development by Coincidence

It’s been a while since I’ve posted a hot take.  And, to be fair, this is probably a lukewarm take, at best.  I’m taking a slightly aged tweet, and I’m going to react to it in a slightly oblique way.

Here’s the tweet.

I do have opinions on this tweet, and I’ll get to those momentarily.  But, as I go through this post, I’m actually going to relate it more to a different facet of the programming world.  Specifically, I think this has an tangential-but-important tie-in with how we tend to fetishize skill in the tech world, in spite of it being not that important in the scheme of things.

But let’s put a pin in that.

Conference Speaking is an Content Marketing Activity

If you’ve followed this blog for a while, you might have seen me write about this exact topic.  I titled the post, “Conference Speaking Isn’t Good for Your Career Until You Make it Good,” and that title serves nicely as a spoiler for the content.

My premise is somewhat softer than Brianne’s, in that I neither discount speaking outright, nor do I make an ad hominem implication that youth and naivete govern speakers’ decision-making.  My take is less that conference speaking is pointless and more that people tend to do it quite inefficiently.

In a professional context, conference speaking is a marketing activity and, more specifically, a content marketing activity.  You deliver value for free (in most cases) with the idea that investing your time and effort this way will pay off later.  Other activities, including ones that Brianne mention also fall into this bucket.

  • Writing blog posts
  • Building FOSS utilities
  • Starting a Youtube channel
  • Building a social media following

And Conference Speaking is Uniquely Prone to Content Marketing Inefficiency

Now, as someone who spent years creating content inefficiently, I have plenty of perspective here.  I wrote a blog like a journal, instead of an asset, and it led to all kinds of opportunities and new careers.  So, I did it, and it worked, albeit less efficiently than it could have.

So against this backdrop, I’ll offer my own spin on Brianne’s comments, which I think make sense.  When you miss the point with blog posts, software, social media, videos, etc, you can always rework that content into more efficient forms.  You can’t do that with speaking, which is ephemeral.

In other words, while all forms of content marketing activities are prone to these inefficiencies, conference speaking makes it uniquely hard to course correct later.

Read More

By

Org Chart Types: A Guide for the Aspiring Consultant

Org charts and org chart types.  How companies structure reporting relationships.  The stuff of Dilbert cartoons and tales of disaffected corporate woe, but also the glue that holds most organizations together in some semblance of order.

A Reader Question about Types of Organizational Structure

I’m overdue for answering a reader question, so let’s answer one about org chart types.  This arose out of a post I wrote a while back about how to become a management consultant.  In that, one of the pieces of advice that I offered was to become well versed in different organizational types and structures.

This led to a pretty natural reader question.

After reading your post on becoming a management consultant, I’m wondering if you have useful resources for tackling three of the areas you encourage learning:
1. Business Organization Structures

I’ve elided the second two things he asked about because speaking to all three would make for a pretty disjoint blog post.  So today, it’s all about the org chart.  (Not to be confused with organizational structures like LLC, S-Corp, etc, which I won’t talk about here).

So let’s define the actual purpose of org charts, and then walk through some of the most common examples.  I’ll structure this post by how a company might adopt these structures at different points in its maturity.  But first, I’ll speak to the philosophical why.

And I’ll try to do it all while striking a healthy balance between cynicism and exposition.

Read More

By

How to Pick a Niche: Start Listening to Other People

Last week, I wrote a post in which I answered a reader question about who writes the code in a world of empowered software developers.  In that post, I continued my thematic assault on the concept of generalizing, which prompted a question about another topic I’ve tackled before: niching.

The question was pretty simple (and kind of more of a statement).

I’m having trouble picking a niche.

I Know. It’s Hard to Pick a Niche

The commenter there isn’t alone.  People say this to me all the time.  I have conversations with folks in the Hit Subscribe author group, field DaedTech reader questions, and generally talk to a lot of people.

They tell me it’s hard to pick a niche.  They also ask me how to do so.  And so today, I’ll do my best to offer some guidance on how to pick a niche.

It really is a tough subject, both in terms of execution and in terms of advice.  And, while a lot of the reason for that is that it’s difficult to talk about a very specific thing in the abstract, some of it comes from nebulousness around terminology.

Let’s Define Some Key Terms

So let’s start by removing the nebulousness.  I’m going to establish some definitions for the sake of the rest of this post.  I’m doing this both for the sake of a working vernacular here, but also to underscore a fundamental misalignment in thinking that people tend to have.

Here, then, are the terms in question.  These are not the dictionary definitions of such terms, should you look them up, but rather a framework for progressing as you pick a niche.

  • Generalist.  As a generalist, you optimize your career for “employability.”  This means that you make yourself as deployable as possible as a human resource, ensuring that an arbitrary employer with arbitrary needs can find a way to use you.
  • Specialist.  As a specialist, you optimize your career to do only the thing(s) you most like to do.  This means that you fuse your hobby and your job, manufacturing leverage out of high demand for a narrow skill set.
  • Niche-filler.  As someone with a niche, you optimize your career to deliver value to others.  This means that you look for gaps in people’s needs and wants, and fill them.

Now, there’s a fair bit to unpack here.  In the first place, it defines a bit of a continuum of agency.  The further toward the generalist end, the more you say “I’ll flail around until a boss tells me when I’m doing it right.”  And, as you get toward the niche end, you say “I’m going to flail around until money starts rolling in and I am the boss.”

But of more interest in terms of your career, it defines whose value you’re optimizing for.  And that is, employer’s, your own, and a customer’s, respectively.

And only one of those makes for good, free agent business.

Read More

By

Software Consulting: What This Really Means and How to Start

On this blog, I’ve talked at length about both software development and consulting.  In fact, I have an entire posting tag devoted to transitioning from being a developer to being a consultant.  This includes a take on why everyone should want to.  So I’ve got the subject of software consulting surrounded.  But now, I’d like to get into the nitty-gritty.

I’ll link off to plenty of opinions for further reading as I go, but this is all about defining what software consulting is, how to start doing it, and how to make a living.

What is Software Consulting? For That Matter, What is Consulting?

Let’s start as simply as possible.  In order to know what software consulting is, we need to define consulting itself.  The business dictionary has a pretty serviceable definition (emphasis mine):

The providing of expert knowledge to a third party for a fee.  Consulting is most often used when a company needs an outside, expert opinion regarding a business decision.

Simple enough, right?  As a consultant, businesses hire you, an outsider, to furnish an opinion.  You’re selling your own hard-won knowledge.  And what you’re not selling is your labor.

So software consulting is just doing this same thing, but with a narrow focus on software.  Right?  Still pretty simple?  Case closed?

Well, the case should close there, but, sadly, it doesn’t.

Why Most Definitions of Software Consulting Aren’t Helpful

We in the software industry have managed to take a simple definition and… complicate it… to the point where it means something totally different.  Think of the way the definition of “literally” also includes “not literally.”

Go do a google search on software consultant, and look at the definitions you find.  Seriously, go look.  You’ll find various definitions, but they generally add up to the same idea.

Software consultants are software developers that work for companies that sell software development labor.

How did this come to pass?  Why does the definition of “software consultant” include “software developer that does not consult for a living?”  Why do we literally need a whole taxonomy to determine if a software consultant is a software developer, or literally a lost soul in some professional purgatory?

Well, the backstory there is complicated.  But the short version is that it comes from a time before today’s ubiquitous computer programmer.  When few people “did IT” for a living, the folks engaging them valued both their expertise/advice and their labor.  But these days, it’s mostly just labor.

I’ve got an idea for an app!  Now I just need you grunts to build it.

Way back when, companies engaged tech vendors for expertise and labor and called them consultants.  Today, they still call them consultants, but just engage them for labor.

Read More

By

What Do You Know That People Would Pay You For?

I actually started this post last week, in what was shaping up to be a long one.  Instead, I decided to spin the lead-in off into its own post about staff augmentation.

In that post, I covered a decent amount of ground, but I’d like to focus in on two main points about the software industry.

  1. We have a curious habit of calling ourselves “consultants” when we’re not.  In other words, our industry is perhaps the lone industry where we refer to labor as “consulting.”
  2. The main determining factor in what we call software development engagements is who manages the software developers.

This lead up, expounded upon mainly in the previous post, leads to an interesting question.

If Software Development is Knowledge Work, Why Do We Act Like It’s Labor?

I talk frequently on this blog about knowledge work and surrounding concerns.  Here’s a good working definition of knowledge work.

The term “knowledge worker” was first coined by Peter Drucker in his book, The Landmarks of Tomorrow (1959). Drucker defined knowledge workers as high-level workers who apply theoretical and analytical knowledge, acquired through formal training, to develop products and services.

They include professionals in information technology fields, such as programmers, web designers, system analysts, technical writers, and researchers. Knowledge workers are also comprised of pharmacists, public accountants, engineers, architects, lawyers, physicians, scientists, financial analysts, and design thinkers.

Software development certainly seems to fit the bill.  I mean, it’s literally mentioned repeatedly in this definition.  And yet, perhaps uniquely among all of these vocations (except maybe technical writing), software developers are paid for what we do with our hands, rather than what we know in our heads.

Don’t believe me that this is a curious diversion?

Then why does it find its way past even how people bill for our work and into our job titles: “architects” to do the “big picture thinking” and software developers (laborers) to bang out code?  Or into our self-selected metaphors, such as the strained guild concept, where we’re not experts offering diagnoses, but “craftsmen” building digital cathedrals or horseshoes or whatever?

Read More