business development, craft, data and metrics

Critique My Code, Please

note, this article was originally published on LinkedIn

Image by Jae Rue from Pixabay


ROUTINE ShouldYouHireAWriter(ContentCalendar, SubjectMatterExpertList)

DIM ContentCalendar AS array(ContentIndex, ProductionDate, ContentType, SkillRequired, LeadTime)

DIM SubjectMatterExpertList AS array(Name, AreaOfExpertise, WritingSkill, AvailableHours)

FOR EACH ContentIndex IN ContentCalendar

    FOR EACH Name IN SubjectMatterExpertList

        IF Professionals.WritingSkill < ContentCalendar.SkillRequired THEN

ShouldYouHireAWriter = TRUE

            CALL Hire(Writer(ContentType, SkillRequired))


        ELSE IF Professionals.AvailableHours < ContentCalendar.LeadTime THEN

ShouldYouHireAWriter = TRUE

            CALL Hire(Writer(ContentType, AvailableHours))


        ELSE ShouldYouHireAWriter = FALSE

        NEXT SubjectMatterExpertList.Name

    NEXT ContentCalendar.ContentIndex



Let me Real-People-Speak that for you all.

For those who aren’t programmers, here’s what this says.

If you’ve got some kind of content your marketing team has decided is necessary to the essential function of your business (a Case Study, perhaps, or a blog post about a new product you’re developing for a growing market), you may want to get some outside help for that.

But – how do you decide whether or not to engage that outside professional? I have two criteria:

1) Do you have skill in that type of content?

Maybe you’ve never written a blog post before. Maybe you’ve never written anything before. Your skill is going to be defined not only by your writing skill, but your professional area. Are you a programmer? Maybe you shouldn’t be writing about end-user support, even though you’ve been asked to. If your skill is not up to what’s required of the piece of content, you should probably hire a writer.

2) Do you have enough time to do it?

Perhaps you’re neck-deep in requirements and coding for that very same model update that you’ve got to get out before quarter-end, and you know that taking ten hours of your time in the next month to write this stupid case study just isn’t in your budget. At that point, perhaps you need to spend less time writing and outsource that project. A good one could potentially cut your ten hours of drafting, revision, and review into a one-hour interview. What else could you produce in those nine hours? Might it be better to let you specialize there?

This mini-program essentially cycles through each piece of content and asks those two questions. Yes, it’s written a little facetiously. I know the syntax is probably way off, and there are clearly undefined subroutines that, should I try to get this to compile, would be throwing off errors like the Bad News Bears. Give me a break, I haven’t actually coded anything in like 6 months.

But the point is to show that there are pretty good reasons why you might look to outside help. And this routine would apply not only to writing content, it should apply to everything you do. [I use content creation because, frankly, that’s what I’m neck-deep in right now.]

First, evaluate whether your team has the necessary skill to complete the project upcoming. If not, you’re going to need some help.

Once you decide you do have the skill, determine if they have enough time to complete it. If not, you’re going to need some help.

And “need some help” doesn’t always mean hiring a professional to do that exact thing you want done, whether it’s building a retaining wall, shooting a promotional video, or even meeting with a client.

Sometimes, you might wish to hire another full-time person to do those specific tasks. Others, it might be that you should remove some of the lower-level tasks on your professional’s to-do list by reassigning them, thus freeing up more time in that high-level production arena.

The point is, you have options. Remember that, and don’t just assume that everyone you already employ can do everything. That’s why we’ve created this specialization economy, anyway. You should take advantage of it.


Stephan Mathys is a technical content writer for really smart professionals in the actuarial, data science, and engineering fields. You can reach him with questions about this article or his book, The Handbook of Content Marketing, at

business development, data and metrics

Your “Average” Stinks

Please note, a version of this post was first published on LinkedIn.

Your “average” stinks. Doesn’t matter what that average is, I know it’s rotten to the core.

Average cost per click.

Average user time on page.

Average length of time to close a sale.

Average height of a delivery driver who fills up your vending machine.

Regardless of what you’re talking about, if you’re talking about “average”, you’re doing it wrong.


Because average, as a measurement or a descriptor, sucks.

I’m not the only one saying it.

“Average sucks” gets 83 million hits on Google. A German advertising agency agrees. All the time, people are wondering how to get better than average, because, well, reasons:

image_Quora_Why does average suck

When you’re average, there’s a lot of people who are better than you. Yes, there’s a lot of people who are worse than you, too, but in this success-obsessed culture, being average is often seen as being a failure.

And, despite the subtle indications that this post is going to be another about self-improvement, I’m actually going to talk a bit differently about average and how its use is failing you.

I’m going to talk about why using average, as a descriptive metric, is holding you back. It’s actually obscuring your insights, and keeping you from learning what you could from your analyses and your models.

Quick Recap

Okay, I shouldn’t have to do this, but just so everyone’s on the same page: when I’m using the word “average” hear I mean the mean, or the sum of the individual components divided by the number of components. If there are 3 dice rolled, and they are a 1, a 3, and a 6, then the “average” roll is 3.33 ((1 + 3 + 6) / 3 = 3.333).

There’s also the “median” and “mode”, other measures which may sometimes be used for average. But here, we’re talking mean, as is usually considered when looking at values.

Organizations and individuals all over the world use average, to describe something like a central tendency of a group. They look at the average high or low temperature of the place they’re going to vacation next month, so they know what to pack:


The problem is, most of the time, things that are “average” don’t actually show up in real life. Like the dice rolls above: even though the average is 3.33, it’s actually impossible to get 3.33 on any one specific roll. Sure, roll a die a hundred times and you should get a total pretty close to 350, for an average of 3.5, but on any one specific roll? You will NEVER actually get 3.5

[side note – don’t you hate it when Google doesn’t play nice? I have this idea that there’s a Far Side cartoon perfectly describing the phenomenon I’m thinking of, but I can’t find it. It’s a family with the average “0.5 dogs and 1.5 kids”, and the dog and one of the kids are just like the “left” side, not the whole thing.]

So in this situation, making some kind of prediction or evaluation based on averages is rather meaningless. Anything that’s a quantum action (how many times did someone click on my website?), or isn’t a continuous variable (what are the expected values from rolling a 2D20?) probably shouldn’t be evaluated using “average”.

And yet, we do it all the time.

We Talk About Average Way Too Much. Distribution, Not Enough

So is there a solution? Clearly.

This guy goes into more detail than I’m prepared to right now. The point is, though, that talking about percentiles of a distribution provides vastly more information than simple averages.

Here’s a real clear example. These two data sets have exactly the same # of elements and the same average:

image_2 columns equal average

Obviously, I manipulated this data set a little bit to prove a point. The first column, Set #1, is just a set of random numbers. The second column, Set #2, is an operation on the first, for all but #20. That last one? Well, I solved for the value that would make the total and average the same (for this example).

The point is, if you were just looking at 2 different data sets, or perhaps how a data set modified over time (you’re looking at compile times for your program, for example, and checking to see whether your servers are performing better than they were last year), you may be missing crucial data if you only look at average.

Your average may be exactly the same, or only slightly worse than before, but you may have introduced significant outliers that are being obscured by the measurement. Here’s the same data, but with some percentiles added on (some rows omitted for clarity):

image_2 columns_with percentiles
Don’t hate, I know that Column 2 is different, I’ve still got Rand() in the formula…

With this presentation, it would be obvious that something was systematically different between Set #1 and Set #2, and you’d have an indication that you had more investigation to work with.

Uncovering Outliers

And this example was for a set with very few elements. What happens if you’ve got a vast data set (something accessing big data, for example, or a time series with daily stock prices stretching back generations across thousands of stocks)? How might looking beyond averages help you identify problems?

Well, one way is to look at results graphically. Here’s what I mean.

Again, I have two data sets, much larger than before, but I’m still simplifying for the example. [This is based on an actual issue I encountered while still an actuary.]

Let’s assume that you’ve got some kind of measurement which produces these values:

image_2 columns_systematic error

What’s going on here? Average looks good. Minimum, 25th percentile and 75th percentile look good. Spot-checking one or two seems right. How are we getting a max of 11.79? And, importantly, is that a problem?

The reason this is a problem is that the maximum that should come out of this expression is 10.0. Mostly because I forced the issue by defining these two columns to be a formula of Rand()*10, which means I expect the max to be no more than 10.

Hmmm… is it something in the data? Let’s look. First, I sorted from smallest to largest (as you might do for a stochastic simulation):



As you can see, there’s something strange going on. [You can’t really see Set 1, but trust me, it’s there.] The strangeness is that jump at the end. Something systematic? Might this suggest there’s an error in the model, or a source data element?

Let’s dig further. What if I go back and reorder by item number (or scenario number, in a stochastic simulation)? What does that look like?


Now we can see that there’s clearly something going on with Set 2 in the first few trials or so.

When I look back through the model, I see that I had a slightly different formula in the first 100 cells. Instead of Rand()*10 (to force it to be a random number between 0 and 10), I had Rand()*10 + 2. 

Yes, this was a little bit of a contrived example. But a similar experience actually happened during some stochastic testing of insurance liabilities once. When reviewing results, the average looked reasonable and ordered smallest-to-largest looked reasonable also. When we looked at the results in simulation order, though, we saw that there was something different about a set of early results.

It turned out that these stochastic scenarios were reading the inputs for a set of deterministic scenarios for that first batch, and throwing off the ultimate effect of the model.

It didn’t take long to correct those inputs, though, and re-run. But if we hadn’t looked at more than just the average, we never would have caught the mistake.

Yeah, But Is It That Worth It?

I don’t know. Some might find this a level of detail too specific for much of your work. But, when you’re dealing with huge data sets, complex relationships, and razor-thin margins for error, perhaps it’s not too precise.

Would the company have made different decisions about the insurance portfolio had those erroneous results been incorporated into the regular reporting? Probably not. The magnitude of their error wasn’t that great, just like the magnitude in my contrived example wasn’t that big. Heck, it wasn’t even large enough in the first 100 to move the average. So is it that big a deal?

Well, unfortunately, the answer is the standard: It depends.

Sometimes it will be. Sometimes it won’t be. And there’s no cut and dried formula to tell when it is and when it isn’t worth it to investigate your results for anomalies further.

Some of it comes with experience. Some of it comes from just being curious and following intuition. Some of it comes from your superiors needing to be absolutely sure of every decimal point you can give them, so you do what you’re asked for without worrying about it.

But, eventually, you’ll learn to add your own systems for spotting anomalies. And you’ll implement them early enough in your process that you can head off distractions before they appear.

Look, I’m all for taking shortcuts when they’re called for. Nobody really needs to take the back roads every time. That’s why we built the highways, damn it. That’s also why, to be frank, your average stinks. It’s a shortcut, and, as I’ve shown, just using an average (heck, even just using percentiles alone) can keep you from the insights you need to make informed decisions.

Because even with shortcuts, automation, dashboards, and whatever comprehensive views your C-suite is looking for, sometimes it’s good to actually get back into that data sandbox and play around a little bit.

Who knows – maybe you’ll see me there.

better language, business development

Salary “Negotiation”? More Like “Battle”

There’s a problem with the phrase “Salary Negotiation”. And no, I’m not talking about how the public school system has left millions woefully unable to spell “negotiation”.

I’m talking about the fact that this phrase even exists. In today’s modern age of taking all kinds of feelings into account, shouldn’t we have advanced past this simplistic, unenlightened mentality?

The Problem Of “Negotiation”

The problem lies in the word negotiation. Inherent in this is the perception of adversarial conflict. Two sides, each on their end of the battleground, coming together to “negotiate” a resolution to their disagreement.

courtesy of Wikipedia

The implication is that each side is going to have to give up something, in order to get something else. It’s a zero-sum game. Everyone loses something, and nobody goes away happy.

Because if you could have achieved everything you wanted without the negotiation, then there wouldn’t have been one in the first place!

But why should you care about this when discussing salaries? Doesn’t everyone have the same goal during salary negotiation, whether for new employees or at performance review time?


Not even close.

For the employee (or potential employee), their perspective is to get as much compensation for as little as possible. And for the employer, their desire is to pay as little as possible for that same employee.

Thus, conflict.

Why Normal Doesn’t Work

The standard salary negotiation doesn’t work, because, as in any negotiation, one side must make the first move. Generally, this puts the first mover at a disadvantage.

Poker players know this, which is why they want to be able to make their moves after the other player. (This is called being “in position”.) The advantage comes from the chance to gain more information about the other player, or the other negotiator, by their first action.

And now we get into game theory! Those who have to act first know that their adversary will get more information from their actions, so they try to bluff by making their position seem stronger (or, sometimes weaker) than it actually is, to induce a targeted action by the other.

In our salary discussion, this shows up in a couple of ways. Neither side wants to go first – employers don’t want to commit to too high a value, and potential employees don’t want to feel like they’re not getting what they’re actually worth.

I’ve noticed that employers have stopped putting salary ranges on job descriptions. That’s fine, because it eliminates one of the disadvantages they had before.

When they listed a salary range, they’re often automatically excluding qualified candidates who would have worked for slightly more than that range, but feel constrained because there might not be any flexibility.

And second, they’re attracting unqualified candidates who think they’re worthy of the salary, which leads to excess HR waste and time spent dealing with it.

From the candidate’s perspective, though, this is removing the advantages they had of knowing what the minimum and maximum are. It gives them some opportunity for additional conversation, though, and that’s really what I want people to start doing more.

Let’s Get It All In, Shall We?

The other problem with listing “salary ranges” is that it doesn’t accurately reflect the total compensation of the position. Two companies might each promise to pay a coder $75,000 for full-time employment. Seems fair. But one has benefits (health insurance, retirement, flexible time off, taxes paid, etc.) that are worth about 20% of that salary ($15,000), while the other has benefits worth 40% ($22,500). If you’re just “negotiating” on salary alone, without taking into consideration all the other elements, you’re missing out.

So, what to do about this? I think there are two changes that need to be made when discussing compensation, and one easy process to help make that happen.

First, Let’s Call It A “Compensation Conversation”

Because, frankly, there is much more to compensation than just “salary”. It’s the whole package that must be considered, and, unfortunately, since most of the additional benefits aren’t ever actually quantified, it has been a hidden factor for far too long.

Thus I think we should start including the financial value of benefits as part of the job offer or raise discussion, rather than simply talking the dollars on the paycheck. This will force into the open many elements that previously have been hidden, allowing for full disclosure and consideration by both sides.

An image from the promotional poster for the movie "Disclosure"
courtesy of Google, just like everything else

Next, Let’s Make Sure Neither Side Has To Overcompensate By Going First

Remember, the problem of going first leads to overinflating your position, because you know your opponent is going to try to negotiate you off your power, and since you know they’re going to do that you’ve expressly inflated your position, and they’ve expressly inflated their own, leading to a growing divide between the two parties. Rather than helping mitigate the conflict, I contend that having a “negotiation” widens the disagreement and further entrenches each side in their own position, lowering the chance of success.

Let me give an example. Suppose the software company wants to hire the coder for $90,000 ($75,000 salary + $15,000 benefits). But they know that coders will try to get every extra dollar possible out of them, and there will be a negotiation, so they purposely start out low ($70,000 salary listed), expecting the coder to ask for $78,000, and then they go back and forth.

The coder, too, has to play this game. Suppose he would have been happy with $80,000 total compensation ($66,667 salary + $13,333 benefits). But he knows the game, he knows that the posted salary from the company is “lower” than what they finally expect to pay, so he counter-offers the $70,000 with $80,000, expecting them to go back and forth from there.

Now, it may seem like everyone’s happy here. But are they, really? Sure, they got to a final agreement, but it took a lot of time, and wasted the chance for a lot of goodwill that could have been created through a better process.

But if I’m suggesting neither side go first, how do I plan to fix the process?

Instead Of One Side “Going First”, Have Both Sides “Go Together”

The difference in this situation is that both sides will, at the point of being willing to extend (and receive) an offer, agree to a Mutual Declaration. In this instance, instead of either the employer or the (potential) employee going first, both will reveal their position at the same time.

How this works would be that each side determines a range of total compensation over which they would feel is fair for the position, the expectations, travel, etc. Once each side has their range determined, both sides then exchange with the other, or an impartial third party.

If their ranges overlap, then the middle is automatically selected. If they don’t, then you actually get to have a conversation about what each side believes is fair. And that conversation can, and should, include much more than simply salary.

How It Might Work

Let’s go back to our coder. The company obviously has an upper limit somewhere around $90,000 for their position. They create a range that says [$80,000 – $92,000].

The coder, for his part, looks at the requirements of the job, the people, the benefits offered, and decides that he thinks it’s worth [$78,000 – $86,000] to him. Others might have a different perspective, but for him, anywhere in that range is fair.

Once they’re both done, they reveal their ranges. Since there’s an overlap from between $80,000 to $86,000, they pick the middle ($83,000), solve for a salary ($69,167) and benefits ($13,833) that each is perfectly happy with.

The main advantage is that both sides feel the process is fair, it’s taken a lot less time, and you’ve eliminated the confusion about total compensation, since you’ve added in the value of the benefits up front.

And what happens if the ranges don’t overlap? Suppose the coder feels that in order for him to accept this job he would need somewhere between [$95,000 – $105,000]. Well, now the differential is between $90,000 and $95,000. If there is flexibility on either side (work from home, more retirement benefit, more vacation, less vacation, higher salary offered from the company, lower salary accepted by the candidate), then all of those elements can be quantified and the conversation (not negotiation!) can continue.

In the end, they’ll either reach an agreement or not. But at least they’ll do it with the full faith and confidence that all of their positions have been taken into consideration.

An Obvious Limitation

I do suggest that there be some limits on the ranges. For example, you shouldn’t just list [$0 – $1,000,000], in the hopes of forcing the other side to accept the middle of their range automatically. That’s just ridiculous. At the same time, nobody should have a range that’s too narrow [$60,000 – $60,500] to, again, not really give anything away about their interpretation of the process.

So I recommend a range where the upper limit is no less than 10%, and no more than 30%, above than the lower limit. This creates a reasonableness check on the two sides and ensures nobody’s manipulating the other and the process. So if the software company above really wanted to pay around $90,000, they should have that as the middle of their range, something like [$85,000 – $95,000], and should be comfortable if they have to pay a couple of thousand dollars more than their “target”.

A New Term – Hopefully Used Often

I know this is a bit of a departure from my typical blog posts, but it’s an issue that’s been on my mind lately. It’s especially important because lately I’ve been doing so much thinking about terminology (“retention”, teaching, and inappropriate “Thank You” spring to mind). This is another area where a shift in perception will only happen with intentional shift in language.

I hope this perspective catches on. I truly believe it could add much value to the process.


Do you like this article? Or don’t? Send me a note and let me know what you think.