Category Archives: Career

Great, but incompatible

It’s painful how sometimes you can put in lots of effort and sacrifice  into a project (or a career) in the hope that it will pay off, only for it to fall through in the last moment.

It’s worse when the motivation that was used sustain that effort was based on the fact that “there’s only X months to go; we’ll be done soon,” but X months has passed and we’re no closer to our goals than we were X months ago.

And sometimes it’s not even the first time this has happened. It could be the second or third (or forth) year you’re telling yourself, “not this year, but maybe next.”

But there will come a time when we have to tell ourselves that it’s time to cut our losses. There will come a time when we have to realise that the seed and soil may both be great, but simply incompatible.

The question is when, and will we know it then?

If it’s not a ‘Hell, yes!’, it’s a ‘No.’

The title of this post, “if it’s not a ‘Hell, yes!’, it’s a ‘No.'” comes from a Tim Ferriss book I’m currently reading called Tools of Titans, and is one of Ferriss’ favourite rules of thumb. Here’s a little more context (Ferriss is quoting Derek Sivers here):

Because most of us say yes to too much stuff, and then, we let these little, mediocre things fill our lives… The problem is, when that occasional ‘Oh my God, hell yeah!’ thing comes along, you don’t have enough time to give it the attention that you should, because you’ve said yes to too much other little, half-ass stuff[.]

It reminded me of how uneasy I was when being tasked with a slew of little projects that I knew were nice to have and that closed a few “open loops” (if only for the sake of closing them). I wasn’t too keen because I knew these were not the game-changing things I wanted to work on, things which I anticipated were on the horizon for myself and the team.

I concurred that, in principle, these were things needed to be done eventually, but that they would have be pushed to the back of the queue the moment something more momentous opened up.

We agreed to putting these tasks on the back-burner, with one or two trickling through during periods of slack and/or while we gained more clarity on any “Hell, yes!” projects that might be coming up (the act of scoping and gathering requirements may turn what seems like a “Hell, yes!” project into a solid “No.”).

I’d never actually though too much about it, but this has been one of key plays of my career thus far. Admittedly, it’s difficult to say “no” to customers (internal and external) early on, when you’re still finding a career niche, building up work experience and interpersonal clout (in fact, saying “yes” to just about everything is likely the better strategy when starting your career).

But once past that, saying “yes” to each and every opportunity and task is a recipe for mediocrity. If I’d continued doing that since starting work a decade ago, I’d probably still be copying and pasting data from spreadsheets, generating business reports by hand because somebody else told me so (albeit in an excellent manner, no doubt).

Instead, I’m working on developing my data science career, leading a great sales operations team, and thinking in my spare time about how I could bring my company’s analytical capabilities to the next level. Things I’d very much rather be doing, because I’ve said “no.”

How I Said No

  • Sure, I understand the report is essential, but does it have to be done that way? (Can we change the process or data sources a little so we can automate this?)
  • Can a self-service option be considered?
  • Can it be done by somebody else in the team?
  • What if we could generate a report that had 80% of the information but that could be churned out at 20% of the usual time?

The questions above are actual examples of those I’ve asked over the years. They were my way of saying “no” to projects that would have sucked up my or my team’s time, without which the many “Hell, yes!” projects (highly impactful, hundreds-of-people-thanking-us projects) would never have come into existence.

 

What are you doing to help the person next to you?

Was taking a break from my studies (exams next week, people!), having my dinner and watching some YouTube vids on “leadership” (just because) when I came across Simon Sinek and this video.

Reminded me of something I knew very well sometime back, but forgotten in the hustle and bustle of corporate life: that we sometimes have to put ourselves aside, ignoring the modern social beat of “I, I, me, me“, and think about how we can help and serve others, not in the hope for some future karmic gain, but because we can.

Developing a Culture

Seth Godin wrote a wonderful post on how we sometimes need an external push (through laws, policies, cultural guardrails) to do what’s best for us. It can be basically summed up by the following statements (from the post):

  • We know that wearing a bicycle helmet can save us from years in the hospital, but some people feel awkward being the only one in a group to do so. A helmet law, then, takes away that problem and we come out ahead.
  • Guard rails always seem like an unwanted intrusion on personal freedom. Until we get used to them. Then we wonder how we lived without them.

I was just thinking about true this is for so many other aspects of our lives. The friends we choose, because of the context they set, determine many of the decisions we make, and consequently many of the paths of life we take.

When setting up a company, a department, a team – how important it would be then to make sure that the cultural norms we encourage and enforce are the ones we want.

Whether it’s a culture of success (however you define it); freedom of experimentation; openness of communication; risk taking; or hard work, it is our job as servant leaders to ensure that it’s the least awkward thing to do.

 

 

On Hiring for the Long Term

This was something I read in a book called The Art of Scalability, something I believe I’d always intuitively known but never had spelt out explicitly: that having additional hands (or brains) does not necessarily equate to a proportional increase of output – it is often less, especially at the start.

The problem is relatively new. In the old industrial economy where work was relatively simple or specialised, it was possible to have somebody come in and make widgets at almost the same productivity level as someone who had been there for a far longer time.

If one widget-maker can make 100 widgets in a day, two should be able to make 200, or maybe 150 if one of them is new.

But in the knowledge economy where work involves far greater scope and interdependencies, with steeper learning curves, this model doesn’t necessarily replicate very well.

If one analyst can create a spreadsheet model within a day, can two create the model within half a day? Or three quarters of a day? Probably not. And if the second analyst is new, it’d actually probably take two days. Throw in a third analyst and you’d probably get that model done in a week.

There is often a learning curve on the part of new joiners; and though we often take note of the the learning of process and technical skills, we often forget there’s also cultural and general adaptation, which can take far longer.

And if the new hire has had plenty of prior experience, there’s also the time needed to spend unlearning old behaviours if they are incompatible with current ones.

There’s also somebody who’s got to give the training, often a senior team member or manager, whose productivity would likely decrease during this period as the new joiner’s increases; and this increase/decrease is often disproportionate, with the drop of productivity in the trainer being far worse than the increase of productivity of the one being trained.

If the new joiner leaves just as he or she gets up to speed, which could be a year into the role, then there’s simply no justification for bringing him or her into the team in the first place.