DaedTech

Stories about Software

By

The Resignation Counter Offer and the Danger It Presents

It’s been a bit since my last reader question Monday post.  But, hopefully you can forgive me.  The last two Mondays were Christmas and New Years Day, so I was a bit distracted.  Let’s get back to business today, though, with a reader question about the counter offer.

Buckle up, because this is a pretty infuriating tale.

I have a coworker who had an opportunity to go to a new company/job where he would have received a major promotion and raise. When he told his current boss about the opportunity, his boss countered by offering him an equally major promotion and raise.  So he decided to turn down the other offer and stay at his current job.

However, once he turned down the other offer and told his boss he would accept the counter offer, his boss came back and said that for “logistical reasons” he couldn’t do a major promotion and raise right now. His boss offered him a small raise and token promotion for staying and said that they would “re-evaluate the situation in 6 months”. Have you seen this type of bait-and-switch tactic before?

Okay, I can actually answer the question pretty simply.  While I’ve seen a lot of things in my travels, I’ve never actually directly seen this.

But I think the real question here is less whether I’ve seen it or not and more about my take on it.  So let’s take a look at that.

The Employment Counter Offer

First of all, let me set the stage a little just so we’re crystal clear on what’s going on.  This bit of back and forth between the person in question and his employer centers around the idea of a counter offer.

You go out and do some interviewing while gainfully employed.  One of these interviews bears fruit, and you find yourself with an offer in hand.  With that offer, you resign from your current post.  But your boss counters with, well, a counter offer.  “Tell you what — we don’t want to lose you, so we’ll match their offer to keep you here.”

Here be dragons, though.

Here be dragons, like this one, when you accept a counter offer.

I’ve offered my opinion on counter offers before, but I’ll recap here briefly.  You shouldn’t accept counter offers.  If you work with a recruiter, a recruiter will tell you this emphatically and cite tons of reasons.  This is because every time a developer accepts a counter offer, a recruiter loses his wings.  Or, wait, I mean his commission.

But it actually is a pretty bad idea for you, recruiters notwithstanding.  The counter offer comes from you having temporary leverage.  It’s generally the employer’s least bad short term option, but it doesn’t age well because you’re now in a role and earning an amount of money they don’t really think you deserve.  It’s probably the last promotion you’ll ever earn there.

So the first issue I have here is actually with the apparently aggrieved party.  Accept counter offers at your own peril.

Read More

By

How to Talk to a C Level Executive

This week, I’m successfully doing reader question Monday on an actual Monday.  So the week’s already off to a good start.  Let’s double down on that momentum and look at how to talk to a C level executive.

Like last week, I’m running afoul of my attempts at a FIFO model, but I just got this question and it set my brain in motion.  I think this should be an interesting post to write.  It’s another fairly straightforward one.

I was sent a Gartner article today and found it nearly unreadable. Buzzwords, new terms, etc. Yet I can follow, say, ThoughtWorks articles. Is this a language I need to speak to talk to the C suite or is it just hype? Thanks!

Let’s Quickly Examine the Article

The Garnter article in question has 4 authors, and they originally collaborated on this thing about 18 months ago.  They then “refreshed” it in October.  I won’t lie — it’s a pretty brutal read.  Let’s take a look first at the summary of the article.

Addressing the pervasive integration requirements fostered by the digital revolution is urging IT leaders to move toward a bimodal, do-it-yourself integration approach. Implementing a hybrid integration platform on the basis of the best practices discussed in this research is a key success factor.

Do you remember this post, where I quoted descriptions of enterprise architecture?  In it, I remarked how each quote tanked the post’s readability score.  Well, those quotes had nothing on this one.  That block quote above, singlehandedly slaughtered my readability by 13%.  The writers designed it for shock and awe — not for consumption.  And that’s the summary — the part that’s supposed to say “hey, I’m an easily digestible teaser for the real meat of this thing.”

So you can only imagine what the “meat” includes.

Gartner has defined “pervasive integration” as the act of integrating on-premises and in-the-cloud applications and data sources, business partners, clients, mobile apps, social networks and “things” as needed to enable organizations to pursue digital business, bimodal IT and other modern business and technology strategies. The proliferation and growing importance of decentralized integration tasks — driven by these business and IT trends — are forcing directors of integrations to rethink their approaches, organizational models and technology platforms.

Readability just went through the rhetorical equivalent of sublimation with that paragraph.  Straight from green, past orange, and right to red.

The "naked emperor" shown here is not a good look when talking to a c level executive.

Mercy, William, Mercy

I tried to read this article.  Seriously.  I gave it a good faith effort.  But it was like walking through a swamp, wearing concrete boots.

I spent some time as a CIO, myself.  And, for years after that, I’ve advised CIOs (and boards of directors, CEOs, VPs, directors, and managers).  Whatever purpose that article serves, it’s not simple comprehension and groking by leadership.

It’s hard to speculate about the purpose of something at the intersection of technology, marketing, guest posting, and public presence.  I can’t imagine exactly who, if anyone, these four people hoped to reach and persuade with that buzz-word carpet-bombing campaign.

But it’s not as hard to speculate about how and why people talk like this within organizations.  And it’s really not hard to speculate about how you should talk to a c level executive.  In fact, I can, quite easily, speak to that last bit.

But first, let’s revisit the corporate pyramid and help ourselves to a lesson in how people in it speak to one another.

Read More

By

Your Specialty Should Be Easy to Explain

I know, I know.  I’ve been on a bad run lately with doing reader question Mondays on Tuesdays.  But I have what I think of as a pretty good excuse.  For my wife’s birthday, we spent the weekend in New Orleans, dining out, listening to live music, and exploring the city.  I don’t think I cracked my laptop, let alone had time to write a post.  C’est la vie, no?

Anywho, on to the reader question.  I’ve been talking a lot to people about this, so I’m going away from the typical FIFO-ish approach and am pulling a question from the comments of a recent post.

Great article. I’m a Software Engineer currently focusing on Machine Learning and Natural Language Processing (NLP). When I think about specialization, I always have trouble in the granularity of it.

I’m working on difficult NLP problems so I think I have something there, but is NLP a specialization or is it too general? What could be the right specialization? some branch of NLP like Natural Language Generation or some vertical like “Real Estate”?

I’m not sure about this process, I guess that you start at the top level (NLP for example) and then you start getting some information about which path to take, kind of organically.

What do you think?

Good questions, all.  And thinking about how to answer this brought into focus that I might be muddying the waters when I use the term “specialty” in some contexts.  To clarify, I’ll go outside of the software world with a hypothetical story.

The What-Do-You-Do Conversation at a Party

First off, understand that I’m going to take some liberties here to talk about a domain in which I’m a relative novice: cooking.  So if you’re a serious chef or even a seasoned amateur, I make no pretense that this will hold up to much scrutiny.

That said, imagine the following conversation at a dinner party.

Alice: Hi there. I’m Alice.  It’s nice to meet you, Bob.  So, what do you do?

Bob: Well, I’m very into cedar plank techniques lately.  It’s become my specialty.

Alice:  Huh.  So, I’m sorry, what do you do with these cedar planks?

Bob: It’s a roasting technique that actually imbues a smoky flavor, so you kind of get the best of all worlds: smoking, grilling and roasting.

Alice: So, you’re a cook or something?

Bob: Yes, I’m a chef.

Alice: Oh!  Where do you work?  I should come try your food sometime!

Now, this conversation probably wouldn’t happen in real life.  And that’s because chefs (and people in most non-programming domains) easily adjust for context and know how to talk to their buyers.  But the world has coached us as programmers to instead impress our peers.

We think of specialty and niche in terms of creating such a granularity of expertise that nobody understands what we do, including our peers and competitors.  But we should be heading in the opposite direction, like Bob through the course of this conversation, as Alice dragged information out of him.

Specialty vs Competitive Advantage

So what is Bob’s specialty?  Well, we don’t really know because he managed not ever to actually talk about it, in spite of Alice’s passing interest.  Oh, sure, he told her that he had a specialty.  But think of that really more as a competitive advantage.

So what is Bob’s actual specialty?  Well, let’s assign him one.

I make huge portions of stick-to-your-ribs meat dishes for an affordable price in an otherwise expensive neighborhood in New Orleans.  If you like barbecue and oven-roasted meat dishes, you’ll find a flavor here you can’t find anywhere else, and you’ll go home stuffed.

Now, if you’ll excuse how much it would sound like a commercial, imagine Bob answering Alice’s question with that little spiel.  She would immediately know not only what he does, but also whether she’d like what he had to offer or not.  Bob’s value proposition would scream through this description of how he earns his living.

Where does the cedar plank shop talk fit in?  That’s Bob’s “secret sauce” (pun not intended) — his competitive advantage.  Bob solves a market problem (large portions of really good food inexpensively) by doing something novel.  For argument’s sake here, let’s say his work with cedar planks allows him to simulate flavor that would otherwise be more labor-intensive, and thus expensive to create.

NLP and Other Techs/Techniques are Metaphorical Cedar Planks

Let’s talk about natural language processing, specifically, since that’s the reader question.  But you can map your own “specialty” onto what I say here.  People have written me about all sorts of topics in the programming world as potential specialties: architecture, ORMs, database performance, block chain, etc.

You don’t go to a party, explain to someone that you specialize in natural language processing, and then hear them say, “oh, awesome, I could totally use some labor focused on natural language processing.”  There’s just no human alive who would say such a thing, even as nobody would say “oh, nice — I could use some cedar plank work!”

For NLP to be useful, you need a bunch of other people.  First, you need someone that comes up with a product or service offering that makes NLP a competitive advantage.  Then you need someone like a CTO that can mentally bridge the gap between the business problem and how a heavily technical competitive advantage solves that problem.  And, finally, you need some kind of project manager to navigate the day to day of making your competitive advantage useful and keeping you on track.

In short, picking a heavily technical and granular specialty helps you and your peers stake out territory that the wider world neither understands nor cares about.  And it tees you up to be an employee or contractor.  NLP isn’t a specialty in the way I’m talking about — it’s a competitive advantage to a business that someone other than you owns, runs, and strategizes about.

We’re Really Talking about Value Propositions

So to clear up confusion, I think it’s better that I start describing this not as a specialty, but a value proposition.  I cringe a little at that, since value prop is a very hand-wavy, consultant-y term.  But it also accurately conveys what I’m driving at.

In a nutshell, value proposition is a clear statement that:  (1) explains how your product solves customers’ problems or improves their situation (relevancy), (2) delivers specific benefits (quantified value), (3) tells the ideal customer why they should buy from you and not from the competition (unique differentiation).

I’ve often, in my writing here, condensed this to the shorter form of “I help [who] do [what].”  But the idea is the same.  Your specialty value proposition isn’t about you — it’s about the people you help.  When I go to the restaurant on the corner to get a huge plate of ribs, I don’t care whether the chef used cedar or not.  When I get annoyed that Alexa can’t understand me with a mouthful of ribs, I don’t care about the finer points of natural language processing.

You care about your competitive advantage so that your buyers don’t have to.

Building a Bussiness around NLP

Does this mean that that you should be a martyr and abandon doing work that interests you?  Should you identify a value prop and then deliver that value, however odious you find the work?  No, of course not.  Figuring out how to exist as a free agent or efficiencer (or even the right kind of salaried employee) is the art of discovering the intersection between some value proposition and your competitive advantage.

That’s messy stuff.

You’re going to have to iterate and brainstorm a whole lot before getting started.  And, as you go, both your value prop and your competitive advantage will necessarily evolve.  This isn’t easy — but it’s crucial.

And that makes it hard to offer a specific blueprint.  I can offer some answers to the questions in the broader reader question.

  • Is NLP too general?  As a competitive advantage, it’ll probably serve you well.  As a value proposition, it’s certainly not too general — it’s way too specific and technical.
  • Is some branch of NLP a good value prop?  No, that’s worse.
  • Should you focus on a vertical, like real estate?  Definitely getting warmer!

Aside from the framework of this post, I don’t know how to advise on specifics.  You could focus on a particular vertical.  This is a process known as market segmentation, and it’s closely tied with your value proposition.  But you could also focus on, say, building products or SaaS and offering a consumer application.  You can match a lot of value props to your competitive advantage and vice versa.

Taking Helpful Next Steps

I’ll close by offering advice — not so much on which value prop to pick, but on how to pick one.  First, do some market research and start to learn a lot about the different sorts of business problems that NLP solves.  Learn about the people for whom it solves these problems.  As you do that, you may find that not only does NLP appeal to you, but so does some particular vertical or general consumer of the technology.

From there, you can start to conduct informal interviews with people to see what solutions exist and also what gaps exist.  Are there companies using NLP in some way where they fail to take full advantage?  Or are there companies not using it at all that could really benefit?  Go lurk on NLP project forums and see what feature requests come up that nobody seems to implement.

This style of research will let you learn more about your prospective competitive advantage and toolbox, while giving you ideas for value propositions.  The more research you do, the longer your list of potential offerings will grow, and the more intersection points you’ll find between doing what interests you and scratching real itches that others have and will pay for.

It is indeed an organic and evolutionary process.  But it’s important to be very deliberate about setting up the framework to to engage that process.

By

Hacking Your Career as a Non-Developer

It’s Monday again, which means another Reader Question Monday.  This week, rather than renew my assault on all things sacred to software developers, why don’t I mount an assault on the design profession?

I’m kidding about the assault part.  Probably.  But today’s question comes from a designer.  I consider this cool because we knowledge workers should band together and because I’m glad that people beyond software developers read the blog and my book.

Here’s the question.

Loving Developer Hegemony – tons to think about.  I would love your thoughts on this situation.

I’ve applied for a green card, but that means I’m unable to leave my current, underpaid job.  I’m also stuck with the ‘designer’ branding through the eyes of execs, and the CTO (owner), who I report to.

What’s the best use of my time?

Inspired by your book I’d like to at least experiment with distancing myself from line-level design work, but I also don’t want to over-work, as my current deal is economically terrible, and I’m obviously an unlikely candidate for promotion.  Is it a matter of smartly deferring loser-work and snapping up, or inventing the ‘best’ projects for me, while cultivating my external network and side projects?

I’ve been pushing your book on the devs I work with – but most of them are too idealistic!!

First of all, thanks for your support buying the book, for reading the blog, and for your question.  Let’s get you some answers.

Examining and Inferring the Nature of Your Organization

First of all, a few things about this scream small-ish, perhaps not super-mature startup type of shop.  Why do I say this?

  1. Executives are interested in what (no offense) some line-level designer is doing.
  2. You regard the CTO as an “owner” rather than a shareholder or even co-founder.
  3. You’re underpaid.
  4. You report to the CTO.

Of course, the operation can’t be too rinky-dink, which I infer from the following.

  1. You say devs, plural.
  2. You have a staff role as a designer instead of a part time/freelance deal.
  3. They’re sponsoring foreign workers.

Why do I mention all of this?  Well, it’s good to establish some axiomatic context for the readership.  But it’s also important to paint a picture related to the corporate hierarchy that I so frequently reference, both in the book and on the blog.

You are, quite probably, in a company with an anemic idealist buffer between pragmatists like yourself, and the controlling opportunists.

Read More

By

Learning in a World Where Programming Skills Aren’t That Important

After a couple of weeks doing Reader Question Monday on a Tuesday, I’m back on track.  I’ll briefly congratulate myself before moving on to the potentially pot-stirring topic of programming skills.

Today’s question is one I’ve gotten a LOT, but have struggled to answer.  I didn’t want to write on the subject until I had what I considered to be a coherent, defensible position.  So I’ve pondered and stewed.  And I think I’m finally ready to answer.  Be warned, though.  This post will probably be lengthy and, at times a bitter pill.  But I think it’s important.

Here’s the question, as a composite from all of you who have written me about it.

How will experience work, especially at the entry level, in the efficiencer world?

What on Earth is an Efficiencer?

A little background, for anyone who isn’t up on secret language of the DaedTech blog.  Efficiencer is a neologism that I used to describe what I perceive as the more business-savvy, more autonomous software developer of tomorrow.  I’ve written a number of posts about it, but I actually defined the term in my book, Developer Hegemony.

Briefly, efficiencers are different — more — than programmers.  Programmers ingest specs and spit out source code.  Efficiencers solve problems.  To illustrate, consider the following.

  • You go to a programmer and say, “I need an ASP MVC website that uses Entity Framework, .NET Core, and SQL Server on the backend.”  The programmer says, “sure, boss, give me the wireframes and I’ll code it right up for you.”
  • You go to an efficiencer and say, “Right now our company takes all of our orders over the phone, and our website is purely ornamental.  I don’t know how this will work, but I know that we need the ability to take orders over a website, 24 hours a day to keep up with our competition.”  The efficiencer says, “I help businesses like yours automate their ordering process, so don’t worry, I’ll make sure your site not only competes with, but outperforms, those of your competitors.”

Can you spot the difference?  Can you tell which professional needs six layers of management and bosses in order to do anything useful, and which one IS the boss?

The Conundrum of Entry Level Efficiencers

The programming world of tomorrow is one in which we, as software developers, stop being the least important people in the software development industry.  In my book and in general, I propose a future in which efficiencer firms, structured like law firms, consist of efficiencers (professional automaters) who call the shots and delegate things like project management (status reporting and schedule coordinating) to subordinates, instead of superiors.

That has resonated with a lot of people.  People like the vision in general, but it leaves a lot of folks wondering about the question that is the subject of this post.

What does entry level efficiencer-hood look like?

The Efficiencer Career Plan in the Short to Medium Term

I won’t bury the lede any further.  I’ll answer the reader question here, in this section.  What will follow for probably thousands of words after that is an explanation and the pot-stirring controversy that I mentioned.  You’ll see why I need to explain further after reading the efficiencer career path.

  • Skip a CS program, because that’s not worth the investment anymore.
  • Do whatever is necessary to get yourself an entry level programming job.  (Boot camp, lateral transition, self-taught, whatever.)
  • Spend 2-4 years as a corporate programmer in a few jobs, where you get paid to learn programming.  This is kind of like a doctor’s residency: you’re an actual programmer in the wild, but also a student.
  • Quit your job and become an actual efficiencer because 2-4 years is plenty of time to become as good at the general skill of “programming” as anyone needs to be.  After your employed residency, you should start to focus on your particular specialty and on growing your brand/career/business.

Alright, deep breaths.  To channel emperor Palpatine, “I can feel your anger.  It makes you stronger, gives you focus.”

Like Anakin here, I can feel your anger at the idea that programming skills aren't as valuable as you think.

How can I possibly make this claim?  2-4 years of programming is barely enough not to make a mess, let alone to perfect this elusive craft.  Am I out of my mind?  Or maybe just an idiot?

Read More