DaedTech

Stories about Software

By

Positioning Yourself to Coworkers as a Stealth Consultant

In a nod to yesterday’s announcement, I’m going to demonstrate how just unaltered the DaedTech blog might be, content-wise.  To wit, here’s a both that qualifies in both my reader questions series and my “developer to consultant” series.  This makes sense, since it’s a question about the developer to consultant series.

Today I’ll talk about positioning yourself as if you were an independent consultant, but with the caveat that you’re trying this out on your coworkers.

Positioning Revisited, But Internal to a Company

When it comes to posting on this blog, I love not having to make the caveat that my opinions aren’t my employer’s, or whatever.  The more used to that I’ve become over the years, the fewer punches I’ve bothered to pull.  And so it went with my first developer to consultant post.  In that post, I unapologetic declared that every developer should become a consultant.

If I were writing a book, that post would have been the prologue.  Chapter one, then, would have been this post about positioning.  It’s a long read, but I recommend it for understanding the nuance of positioning.  At the 10,000 foot-iest of 10,000 foot views, your positioning is your plan to ace the question, “why should I hire you, specifically?”

The reader question came in the comments of that post.  And here it is.

For an employed software engineer, what are some of the ways to “signal” your positioning strategy? In other words, how do you let the org/team/manager know what your unique value prop is? I’d love to get your thoughts on this.

This is an interesting thought exercise, because to participate in the standard hiring process is to have the worst possible positioning strategy.  When you do this, you’re saying, “I’m slightly better than dozens of otherwise interchangeable resources whose resumes you’re holding, so hire me.”  To have a good positioning statement as a consultant is to say “I’m the only person that can deliver X for you in exactly the way you need.”

So today’s topic is about how to develop the latter flavor of positioning strategy in the former world.  But who am I to shy away from nuanced topics?

Let’s Start with a Tangible Example: The API Facade Expert

When speaking about these topics, it’s all too easy to remain in the abstract realm of generalities.  So let me pick a specific, if probably not ideal example.

Let’s say that, for better or for worse, you’ve decided that your unique value proposition is API facades.  Specifically, there are a lot of terrible APIs out there.  Some force weird out and ref parameters on you. Others demand global state and render everything they touch untestable.  Or maybe they just suck.  You get the picture — we’ve all used something like this.

And that’s where you come in.

You have a unique knack for taking some nightmarish API for a library and building a neat, non-leaky abstraction over the top of it.  The APIs you give your fellow developers are well tested, easy and pleasant to use.  It’s a win among management because of the defects and development labor that you save.

For the rest of the post, I’ll refer to this example to make the advice more tangible.

(As an aside, this would be a tough row to hoe, from a positioning perspective.  When you have a lot of overlap with your users/consumers/buyers in expertise, you’ll find yourself in a lot of shop arguments that you wouldn’t with a better division of labor.  But this example is a good starter one, I think, that everyone here will grok.)

Don’t Overthink It.  Start by Telling Everyone It’s Your Specialty.

Let’s start out simply.  You’re Developer val-Developer 24601 at your company, defined only by your experience tuples.  And now you want to develop an actual, human name and to be known for your API expertise.  How do you start?

Well, that’s easy.  Work into conversation that this is your specialty.  In appropriate moments, tell your boss, coworkers and anyone else that this is both what you’re good at and that it’s your area of interest.  It would be best if you had some anecdotes and examples that you could refer to when making this claim.

Now, I’m not saying that you should beat anyone over the head with this or be weird.  Just work it into conversations where appropriate.  Your teammates will ask you about past projects, which presents a great opportunity to mention that you specialize in facades for facepalm APIs.  A boss asking you about your interests results in the same.

Get the word out.

Talk about It.  A Lot.

Next up is a similar, but distinct piece of advice.  Talk about the subject a lot.

Now, I’m not saying to crow about yourself a lot.  Once you’ve told everyone that API facades are your bread and butter, you don’t need to keep telling them that.  But you do want to keep talking about APIs and facades.

Establish yourself as an API connoisseur among your teammates.  Offer insightful critiques of libraries you’re currently using and prospective ones that you’re evaluating.  Mention blog posts about APIs and swap API war stories.  Mention to project managers or leadership that you just read an interesting case study about the economic impact of different levels of API quality.

You want to create a strong association in everyone around you.  You’re talking about APIs all the time, so, after some time, it’ll be natural for everyone to call you in anytime such expertise might be relevant.

Go Looking for Opportunities and then Volunteer

Talk is great, but it’s also cheap.  You want to show AND tell, or else you’ll start to seem like a blowhard.  So look for opportunities to show off your expertise.

Ask your boss if you can run point on bringing in a new logging framework, saying that you’ll evaluate it and see if it’s good as-is or if it needs a bit of an abstraction to smooth things over for the team.  Offer to trade work with teammates if the trade puts you in a position to work with a third party library.  Or volunteer to write a facade over that weird, legacy ORM that everyone hates.

And, if you’re serious about it, offer to cough up work above and beyond your normal duties.  If you’re comfortable sacrificing some temporary work-life balance, nothing speaks to your passionate about showing and telling like giving up some of your own time for it.  Spend a weekend reworking your codebase to make everyone’s life easier by hiding some nasty web service, and people will really start to think of you as the API magician.

Seek External and Social Validation

These three points are going to be sufficient to position yourself within the org.  In all honesty, specializing and having expertise is something like 90% (full disclosure: I just made that figure up) just showing up.  Work with something a lot, talk about it a lot, and help people with it a lot, and suddenly you find yourself the resident expert.

So now I’ll offer advice that’ll tee this up as a more permanent piece of positioning for you — one that will transcend your current gig.

Once you’re established in your org, start to spread your reputation beyond its walls.  If you work for an app dev agency, you can do this simply by repeating the same behaviors in front of and around your clients and their staff.  This might also be true in other contexts as well.

If it’s not, though, no worries.  Look to speak about your expertise at user groups.  Share articles about it on social media.  Talk about it at parties on the off chance that someone around is a developer and can appreciate the API facade guru.

And the person appreciating it doesn’t necessarily have to be a developer.  Learn to articulate your value proposition to anyone.  “I take code that’s really hard to work with and make it easier for other developers.”  Just about anyone in the corporate world can appreciate that on some level.

Start a Blog/Site and Show Everyone

I’ll close with a predictable piece of advice.  Once you’ve established yourself at your company and started to spread the word beyond its walls, you should start immortalizing your efforts.

Start a website with a blog, and blog about APIs and how to make them nicer.

It’ll be hard for an employer to object to this because you’re not necessarily looking to hang out your shingle or even to moonlight.  You’re just talking about your super power, which will, by now, surprise no one at work.  Sure, doing so reinforces future positioning for possible gigs, but you’re not (yet) capitalizing on it.

This can also be part of a virtuous cycle for you.  Having an actual blog showcasing your expertise certainly makes it easier for you to both show and tell at the office.

But, beyond that, it establishes a track record.  The work you do for your employer is often hearsay since you can’t show off the particulars.  And user group talks or conversation at parties is ephemeral.  But your weekly content about API facades is eternal (relatively speaking).

So start out establishing a reputation for yourself with internal interactions at a company, and then build on those to externalize the whole thing and gain broad recognition.  I promise you this will result in opportunities for you.  And those opportunities will transcend both your current job and any one job.

 

  Subscribe  
newest oldest most voted
Notify of
Denise M Tinsley
Guest
Denise M Tinsley

Great article, one question though for those working in feature factories with scrum. If you are under the thumb of a project manager who needs to make sure “resources” are 100% utilized. You get stuck being a jack of all trades, doing everything from the database to the UI. On the other hand, self-forming teams naturally let people specialize somewhat because it pays to have the diversity in skills but most current dev environments want people to be replaceable widgets.

Rudolf Olah
Guest

“The work you do for your employer is often hearsay since you can’t show off the particulars. And user group talks or conversation at parties is ephemeral. But your weekly content about API facades is eternal (relatively speaking).” This is precisely why more devs should be blogging, though I find the difficulty lies in figuring out what appeals to different audiences. For example, developers love to hear about those API facades, but potential clients’s eyes may glaze over unless you include “I’ve done this in production for real” in the blog post. I’ve written a blog post on cause &… Read more »