If you read this far…

There comes a time when you are writing a document and you question whether anyone will read it.  You spend hours putting it together and part way through you start asking yourself this question.  This is a document that you send out to a large group of people that you are not sure if they will look at it or delete it as quickly as it enters their inbox.

So you have two options;

  1. Stop.
  2. If you read this far…

Stop

Yes you can stop working on this document and simply make a case for it’s irrelevance.  That might work, but it might make those in the position of consuming (the reader) said document to become entrenched in their decision to have you provide it.  Still doing a document, albeit perhaps with more scrutiny at the way someone else wants to see it done.

If you read this far…

Or you can simply add a line at the end of your document, at the end of your best work, that goes beyond the document but drives the action to reader.  It’s not about being rude, demeaning or ignorant.  It’s about reaching out and starting a conversation.

In can be as simple as…

“If you read this far, did this help?  Did this provide you with the information you needed?  Could you spare 5 minutes to sit down with me and discuss what else needs to be here?  I’ll buy the coffee?”

In the best case scenario, you could spark a conversation or discussion on what is really needed and tweak your style so you know it is being consumed, in the worst case scenario, you’ll have some pretty immediate metrics on whether people are reading your work.

The Nostalgic Coder

Remember when you were a coding machine?  When you could take a requirement, design it in your head and simply start coding like the hero/heroine that you are?

When your day was 110% coding and nothing else?  No meetings, no scrums, no design reviews, no nothing.

Just pure coding bliss.

Why is the act of coding, that as developers,  let us reminisce about the good old days – the best releases we ever did, the best bugs we ever closed, the features that started off as a task but we made so… so much better.

Is it because when we were coding it was just us and the compiler and no one else?  Is it because the tasks were straightforward and we didn’t require clarification to get them done?  Is it because we were young, new, and didn’t really know what we were doing so just jumped in with reckless abandon and did what we could to get it to work.

Whatever the reason for your nostalgia of coding, always remember that someone is building that story right now, with that next line of code and function that they have never heard of but just discovered.  And now it is up to you to not become revel in your own nostalgia but help someone build their own.

Support, Empower, Guide, Encourage – because when they look back – you will be part of that story.

It’s the Getting Started that Stops Us

What takes more time?

Getting started on a new project or jumping into a project you have been working on for the last few weeks?

In the former, you don’t know;

  • How long is it going to take?
  • How hard is it going to be?
  • Who will you need to help you finish it?
  • When will you finish it?
  • How many struggles will you have to go through?
  • What, if any, other obstacles will be in our way?

That’s the story we tell ourselves because we don’t have answers to these questions, that’s our story.

In the latter, the story is different;

  • I still don’t have the answers to all those questions, but I have started, I am in there, I am doing it, I am taking baby steps every day and closing the gap with each piece of work that I do.

We spend so much time worrying about getting started and coming up with excuses and reasons to not start we spend more time worrying about starting than actually starting which could invariably be less time in total to accomplish the task.

Confused?

Good, then just go get started and ignore what is stopping you from jumping in.

Not Everyone is going to Listen to You

The title might mislead you into this being a bit of a downer post – but instead – it’s about not giving up and continuing that continual push for change.  It’s not easy,

Not Everyone is going to Listen to You

It’s not easy, if it was, everyone would be doing it.

Why Startups need Marketing

In the early days of a startup, you don’t need a dedicated Marketing person.

You do need someone who can handle the Marketing role.

This is a key difference, because even though you don’t need to have someone fully dedicated to this, you do NEED to have the responsibilities of this role fulfilled on a daily, weekly, monthly basis.

And this role should not be handled by one person – because then it becomes a Marketing person – instead this role NEEDS to be handled by everyone in your team for the reason that everyone understands the value of the role and what it brings to the company.

Some elements of a marketing role should always include;

  • talking to customers
  • promoting the company – events, social media, t-shirts, presentations
  • whitepapers & stories
  • competitive analysis
  • product roadmap input

If you focus on those five points and you look at your team, how could you not want all of them knowing the competitive landscape, what direction the roadmap is going in, what customers have great stories to sell, who will be reading the blogs they write?

They should all know these points and be well-versed in them as it extends to how they build features in the products, how they support trial sites, how they handle customer support calls and yes, how they contribute to those oh so important sales demos.

Do you need a full-time marketing person?  No.

Do you need the full-time marketing role?  Yes.