Selling Yourself

This is the last thing anybody wants to do, it’s not easy, its awkward and everyone always worries how they come off.

But it’s a necessity to life – especially in technology.

Whether it be to an interview, a performance review or meeting someone at a conference for the first time, at some point you are going to have to Sell Yourself… not for the sale… but for the you.

Now this not about shilling the product you just spent 8 months working on, no this is about you the person having to show your team, your leader, your peers, etc that you deserve to be there and better yet, you deserve to take on new opportunities.

So what do you focus on when you are just selling you?

  • What do you bring to the table?
  • Why are you invaluable?
  • What unique skill sets do you have?  (Notice unique, everyone knows JQuery but what about your knowledge makes you brilliant).
  • What would be the impact if you left?  How much of a crater would you leave?
  • Keep up with your platform and fields of interest in your industry?

But then how do you do this?

  • It’s not a gathering of resumes, but the best way to show what you bring to the table it to put your work ON the table – show people what you have done, inside and outside your team.
  • Take the hard, most risky work, volunteer for it, own it, make it yours and make it sing.
  • Embed your creativity into all that you build, if we wanted templates, we wouldn’t be here.
  • If/When you leave – you want them calling you months after you have left – not because your code is so bad, but because it is so good and you took the time to understand the problem in order to build it.
  • Read, Code, Blog – Learn it, live it, love it, never stop, build your own following.

These are some ideas, but the list can go on and on and I hope your mind is whirring with ideas.

But here’s the secret to selling yourself, if you are doing it right, no one will ever know.

Becoming an Expert

It takes so much to become an expert in your chosen field… an immense amount of learning, practical application and intense focus.  It might also require you to push aside a number of other ventures at the same time so you can hone in on it and really develop your skill set.

And in the end – you will still not be an expert – not because of your effort but just become it is impossible for someone to know everything about everything.  You might be an expert for an hour or a day, but then a few hours later there could be a new release or a scenario you had not worked on that someone just blogged about.

I eschew the expert title whenever it is applied to my actions because I know what I don’t know and that immediately says “Not an Expert”.

Do I have a good idea how to approach certain problems based on my knowledge?  I’d like to think so.

Can I answer all your questions on the spot without looking it up?  Doubtful, I can’t retain everything except the understanding and more often then not have to refresh what I am working on.

This is one of the big problems with Interviews today where we expect a candidate to answer all of our questions in rapid-fire succession because we deem those 38 questions to be proof that this person is an “Expert” where in most cases, they are more likely to be an “Expert” in memorization of those facts.

Instead of becoming an Expert of what you have memorized, focus on becoming an Expert in your Understanding of what you are trying to do.

Forget the Ranking

Early on, it was very important for me to delineate myself between a Junior, Intermediate and Senior Developer – after all there is a certain cachet associated with being that “type” of developer.

I’m no longer a junior, those tasks should be handled by a junior, I’m and Intermediate now – give some meatier problems to solve.

The thing is – every problem is a junior problem if you don’t know anything about it, even to the most seasoned veteran.  Worked with databases all your life and now you’re having to build a Web UI?  Welcome to juniorsville.

I remember when my title was changed to Senior Developer, I actually freaked out and walked into HR to discuss the change and mix-up.  In my mind, the Senior resource had always been that guru of knowledge that you’d present something to and they would then spend the next 30 minutes poking holes in all that you had done.  I did not feel like that guy and like our example, in some areas I was yet in others I was not.

If you look at those words – Junior, Intermediate, Senior – if anything they are more a component of years of having done something, not necessarily having done something well and/or shipped x amount of products into production and/or only had y returns of failed bugs from QA.  No they are actually rooted within how long have you been doing something in that field.

A False Positive.

Now in most organizations, this gets tied to your salary, again as an indicator of your level of experience and not for how well you have been doing that position (after all, unless they go talk to your previous employer, it’s really going to be based on your years of experience right?).

Worse yet, how do you compare developers across different streams of work, someone who works on Database Development vs Platform Coding?  Are their Intermediate layers the same?  Is the “time” as an Intermediate the same across the different disciplines?

So, again I ask the question, what does this get you?  

  • It’s not about what you know, but how long you have been doing it.
  • It’s not about what you have delivered or what your contributions have been.
  • It’s not easily comparable to other positions in your field (after all when they ask for Senior, the first piece they put beside it is “how” many years you have in that position.

If you are doing it right, you are always a junior, always learning new things, always embracing that change.  Your shipping constantly, delivering value to your customers and clients.

Does it really matter then what rank you have in front of your job description?

Last time I checked, I didn’t go to see a Senior Dentist, but just my dentist.

 

The True Cost of Failure?

What will happen when you fall on your butt on the ice in front of everyone in attendance?

You’ll pick yourself up and start skating again.

If that latest code fix breaks the build and blocks everyone else from check-ins?

You’ll unwind your check-out, figure out what you did wrong and later build something that won’t block everyone when this happens to someone else?

What will you do if that proposal that you spent all of last week’s days and nights putting effort into does not win the bid?

Figure out what you did wrong, reach out to the client and try again.

What if while during your demo, your application crashes in front of all the senior execs in attendance?

You might crack a joke about the Demo Gods and then restart while keeping your cool and marking that as “Escaped Feature” to be culled.

What if while presenting on a topic where you are the “Expert” someone points out an error in your presentation where you are wrong?

You’ll thank them for pointing it out, look at where you made your mistake, and update your information, admitting you made a mistake.

And what if that drawing that you have tried for the umpteenth time still looks like a Picasso met Pollock?

Then you’ll try it for the umpteenth + 1 time to get it to where you are happy with it.

And what if you feel that no matter how hard you keep trying to overcome all of these failures on a monthly, weekly, daily, hourly basis you are just getting nowhere and the easiest path is to just throw in the towel and say enough?

Then you’ll pick up that towel, wipe off your brow and get back in the game because the True Cost of Failure is leaving the towel on the floor, letting it collect dust, walking around it each time you enter the room and closing your eyes so you don’t see it ever again.  In all those actions, you’re expending more energy just to avoid it, when if you just dove right in, you’d know what it’s going to take to get there.  Imagine if all that energy was expended elsewhere?  It could be worse then you thought it might be better, who knows?  Does it matter?  Will it make a difference in the end?

Now excuse me while I go do some EPIC failing.

Watch your Drift

In a Virtual Machine Cluster, you are constantly turning servers on and off and sometimes those server images are remain off for a prolonged period of time.  When you bring them up you start to notice that they have drifted from the initial configuration and haven’t been “around” for all the changes that have taken place around them.

Sometimes this happens in your professional life as well, you leave a project partway through only to come back and realize that things have drifted from their original goals.  Where you thought the direction the project was headed in, was not actually where it is going any more.

This is the Drift – the space between what you know and what is starts to take hold.

Concerns with the Drift emerge when the space between what you thought and what is grows to the degree that you can no longer remember where you came from or where you started, where empty glances around the conference room search each other trying to understand “How did we get here?”.

It’s not always a single mass event that gets you there, but a series of little events that build up that slowly take you off point and start to steer you in another direction.

So the question then becomes – how do you navigate the Drift, bringing it back to your centre?  What are the steps that you take to bring yourself and your team back to being on point and focussing on what is important.

 

For every project and/or person those steps are completely different but the first step to navigating the Drift is acknowledging with you and your team that you have drifted and working to come back to the centre… sans engaging in the Blame Game.