Good Companies Don’t Ask You to Share. They Make You Want To

“So please, go ahead and share this with your social networks.”

I imagine that your company says stuff like this to you all the time.  So frequently, in fact, that you’re probably sorta numb to it.

• Hey, we’re hiring!
• Our company was just nominated for Who’s Who in American High School Students Companies!
• We’ve got a new product release coming up!
• Steve is talking at a networking event!

“So please, go ahead and share this with your social networks.”

It’s an Innocuous Request… And It’s Also Okay If This Rubs You Wrong

I can remember the first time I heard this.  Before, I’d spent the first part of my career working in companies that manufactured products, with software as only part of the equation.  Because of the developers’ relative anonymity and the relative newness of social networks, I never encountered any request like this.  It simply wouldn’t have come up.

But this particular year found me working at a shop selling app dev (and calling this “consulting”).  With the people as their product (or at least the people’s labor), the individual contributor software developers had more of a prominent role.  And so the request came.

“So please, go ahead and share this with your social networks.”

I don’t remember what it was that we were supposed to share or tweet or whatever the verb for that on LinkedIn is.  The company may have been asking for help with recruiting, marketing, sales, or something else.  It doesn’t matter.

For our purposes here, what matters to me is that this rubbed me the wrong way.

I didn’t really know why at the time, and it’s taken me years to start to understand why.  I wasn’t embarrassed to work there or anything.  It was… a place that gave me money in exchange for labor. And that’s a thing that most people do.  The request wasn’t onerous and it didn’t compromise my morals and ethics in any way.  Even the fact that it was a request to do something of value for free occurred to me, but didn’t bother me.

Still, though.  I didn’t like the request and didn’t do it.

Years later, this request is probably much more common.  For the rest of the post, I’m going to expand on why this might rub you wrong, why that’s okay, and what should happen instead.

Read More

How to Write Software: 5 Lessons Learned from Running Businesses

I used to write software for a living.  I did that for a lot of years, as a matter of fact. And, in doing so, I learned a lot about how to write software.

But I learned this from the perspective of, well, a wage software developer.  Today, I’d like to reflect on how my view has evolved over the last number of years.

Software as a Software Developer versus Software as a Business Owner

As longtime followers of this blog know, I’ve had a meandering career.  I started this blog as a software developer, new to moonlighting.  Eventually I moved into management and then started doing developer training activities.  From there, it was a number of years of consulting.  And finally, these days, I’m mostly running a business that is growing rapidly.

I say all this not to treat you to an unsolicited autobiography, but rather to set the scene and to help explain what I’ve been doing between my last full time software development gig and now.

These days, for Hit Subscribe, I’ve started writing software again.  I don’t do it full time, by any stretch.  But I am building a line of business app used directly by four of us and indirectly by something like 30 people.  So it’s not my primary living, but it’s not trivial either, in terms of importance or scope.

Dedicating some time to this has caused me to reflect on how my perspective has changed.  Don’t get me wrong.  I never stuck my head in the ground pretended “the business” didn’t exist or didn’t matter.  But then again, I never was the business, either.  It was never my money in play.

Now that it is, here are some musings.  And please bear in mind that I’m not teeing these up as lessons you learn.  They are simply how my perspective is different.

Read More

Coding as the Boss: My Story of Developer Hegemony

Last night (this morning), I clicked “publish” at about 3 AM and went to bed.  Now, those of you who follow this blog probably assume that I clicked “publish” in WordPress, firing off a 3 AM blog post.

Not so.

I did this in Visual Studio, where I published a little web app called El Dorado to Azure.  I source control the thing in Github and I publish to Azure, where it serves as a little line of business application for me and some of the staff at Hit Subscribe.  And, while a Visual Studio publish isn’t exactly state of the DevOps art, it gets the job done.

The significant thing here isn’t any of the techs that I’m using.  It’s also not the fact that I was up late coding, nor is it the purpose of the app.

What matters here is that I own a non-trivial and growing business and that I’m also writing code.

The Classic Management Track vs Technical Track Conundrum

Years ago, I wrote a blog post in which I told a story of something most enterprise-y/corporate programmers encounter sooner or later.  It’s the “where do you see your career going, management or technical” question.

Choose wisely, young programmer.  Down one path, expense accounts and Gantt charts await.  Down the other, UML diagrams, and… well, probably also Gantt charts.

I could never really wrap my head around this dichotomy.  I mean, I get that furiously banging out code and leading departments are somewhat divergent activities.  But I never understood why the line blurred so little and so infrequently.

I poked around the internet a little to see if this was still true, and I think it mostly is.  I found some posts like this one, talking about the coding dev manager.  But this has always seemed like just taking the role that most companies call “architect” or “tech lead” and having people actually report to it.  That just kind of kicks the can down the road slightly.  If you’re a “coding manager,” you’re probably in a fairly vertical, tech-focused organization where line managers still don’t really think about “the business.”

Are Technical and Business Savvy Mutually Exclusive?

So this begs an interesting question.  Are technical savvy and business savvy mutually exclusive?

Oh, I mean, don’t get me wrong.  I’m not honestly asking whether techies can become startup CEOs or whether leaders with f-you money couldn’t learn to code.  Of course those talents can both exist in the same human being.

What I’m asking is whether or not someone can do both of these things meaningfully, at the same time.  Can someone run a department (beyond a “tech-lead-y” line management role) and also have legitimate business reasons to bang out code, and do it halfway decently?

I have a hypothesis that the answer is yes.

Yes, people can run non-trivial organizations while having good reason to code.  And no, applied, simultaneous technical and business savvy are not mutually exclusive.

Read More

Transmuting Low-Value Programmer Cred into High-Value Status Illegibility

Not long ago, I wrote a post about that one, “top” software engineer role that companies don’t hire directly into.  I’m going to pick up where I left off there.

For a quick recap, recall the diagram I made (and my wife kindly GIF-ified for me).  In red, you have the positions that a company will hire into, and in white, you have that one position that they won’t.  It’s usually “Principal Engineer” or something like that.

A Recap of The Surface Narrative and the Real Motivation for This

In the last post, I talked about the surface explanation for this, accepted by idealists and pragmatists.

This role represents the most valuable software developers in the group to the company.  These developers combine technical skill with a certain je ne sais quoi that combines experience, domain knowledge, inside company baseball, and embodying the company’s values and training.

But I also talked about how that doesn’t stand up to scrutiny.  I talked about how if you picked the brains of leadership, you’d probably hear something like this.  (Assuming you also gave them truth serum.)

It seems like a win for everyone.  It rewards people for staying, makes us seem more prestigious, and it’s a non-monetary reward.  They love it, and it doesn’t cost the company anything to do.

Significantly, that top role that requires hanging around the company for years, serves a very pragmatic purpose.  It creates a position whose salary can creep up, unbounded, without dragging up the salary for the rest of the group.

In other words, create a bucket, put your lifers in that bucket, and give them 2% increases a year forever.  Without that bucket, you’d either (1) have to stop giving them increases or (2) potentially have to pay new hires a lot more.

So you create this policy to keep labor costs down.  And then you stand aside while the pragmatists and idealists manufacture and believe a merit-driven narrative.  Easy-peasy.

Read More

The Curious Case of Not Hiring Directly into Software Engineer V (Or Whatever)

“What about the principal consultant role?”

“Oh, we don’t hire into that position.”

This exchange occurred over 6 years ago.  At the time, I was interviewing for a role with a consulting agency (or something calling itself that, anyway).  They had four salary bands for their developer/consultants, and shooting for the top wasn’t out of bounds with my experience level.  So I asked.  And then they told me about this policy by way of dismissing the question.

I’m not exactly sure why this instance stands out so much in my mind.  Perhaps because it occurred so explicitly.  But when I think about it, I think every salaried gig I ever had featured some kind of unique role like this at the top of the individual contributor set of software people.  In other words, at every job I ever had, there was always exactly one titular band — Senior Software Engineer II or Principal Developer or whatever — reserved only for the company’s dues-payers.

Not having been a wage worker for a long time, I hadn’t thought about this for years.  But I heard someone mention a corporate policy like this in passing the other day, and it got me thinking.

I dunno.  Call it nostalgia or whatever, but given my recent opting for whimsy with the blog, I figured I’d riff on this.

The Curious Case of “We Don’t Hire for X”

Stop for a moment, at this point, and think about how deeply weird this little corporate quirk is.  I mean, you’re probably used to it, so it might be a little hard to do this mental exercise.  Like the job interview, fundamentally nonsensical practices can create a sort of Stockholm Syndrome in corporate denizens.

So let’s blast away the cobwebs with a helpful graphic.  Below is the skeleton of what some org chart might look like.  As the GIF flashes, you’ll see color coordination.  In red, you have the positions that the company will staff from the outside.  Remaining clear, you’ll see all of the positions that the company has a policy to staff only via promotion.

Interesting, eh?  Trickling down from CEO to C-suite to VPs to directors to managers, you have positions that a company will staff from outside, if need be.  Sure, sometimes they may want to promote from within, and often they’ll do exactly that.  But companies will bring in outsiders for leadership roles.

They’ll also typically look for outsiders to fill any of the roles at the individual contributor level, from Software Engineer I through Software Engineer XVI, or whatever, depending on the richness and thickness of the HR matrix.

But then you’ve got that one… it’s always an impressive sounding title, and it’s always where individual contributors go to max out, collecting COLAs and generally demurring against nudges to management.

Strange, huh?

Read More