I’m too High to Write

I was going to write an article today, but I’m too high. In fact, this is my second day living out of a trailer at 9,000 feet while I attend an immersive, 6-day leadership training in the Uintah Mountains.

I’m spending about 10 hours a day in leadership training. In the evenings I meet back with my family at the trailer. They’re here, too.

My daughter, Emma, is old enough to attend her own week-long leadership camp. I won’t see her again until Friday.

The rest are wearing my wife out getting dirty or doing crafts. I’ll debrief my wife Sunday and tell you later if the family version of this training was a good idea.

You might think we’re learning about wood-craft and orienteering. Well, we’re in the woods. So there’s an element of that.

The majority of the content comes from respected thinkers in the business world like “Ken Blanchard (author of the One Minute Manager series of books), Stephen R. Covey (author of The Seven Habits of Highly Effective People and Principle-Centered Leadership), and Spencer Johnson (author of Who Moved My Cheese).”

For more details about the business content of these trainings see woodbadge.ws/employer.

I have to admit, my original motivation for signing up for this course was mostly to shut up the people that keep telling me that I just have to go.

Now, I’m glad I’m here. I was surprised to hear where the material comes from. I’m excited by the authors we’re hearing from and that I can include my family.

Weasel Words Magnify Doubt

When you’re fact finding address your doubts before you return and report.

Don’t come back to your team with “allegedly” or “supposedly.” Words like that telegraph your own uncertainty in a way that paints your sources as unreliable.

If you really can’t be sure then state who reported which fact. Such as, “John told me the site was up at 5 PM.”

Even when facts conflict, simply report them.

For example: “John reported the site up at 5 PM and Eric reported that it was down at the same time.”

Notice how that phrasing points your thinking to the riddle: how could they make conflicting observations? Was there something different in their environments?

Now see how prejudicial it would be to say, “John reported the site up at 5 PM but Eric supposedly couldn’t reach it at the same time.” The weasel word “supposedly” and, to a lesser extent, the humble conjunction “but” paints a doubting arrow to Eric. We have an emotional reaction to the reporter of the fact instead of the tension in the facts.

(The affect can be subtle in alien examples like these. The doubt comes through boldly on teams that really do have trouble trusting each other.)

You can come up with more weaselly words that pretend to be reporting facts when they are really casting judgement: allegedly, apparently, purportedly.

Journalists use words like this more and more. I assume they are trying to insulate themselves from liability for slander and libel. It’s a mistake to add this kind of misdirection to our professional discourse.

When you qualify a fact with, “allegedly” you throw them into doubt in a way that often maligns the source. “Allegedly this bug was fixed last week according to Robert.”

Oh, and the same goes for “air-quoting” a portion of your colleague’s report. “John said the bug was ‘fixed.'”

Always remember, you’re job boils down to two responsibilities: deliver results and build the team. Weasel words do little to deliver results and much to tear down team.

Learn to Do

What will more effectively convince a hiring manager that you can produce results for them? Should you focus on making products? Should you complete programming challenges?

Past results are the best evidence of future results. But it’s hard to beat solving a problem before the eyes of your interviewer. Here’s Raul’s question:

Candidate Question: Preparing For Interviews

Hi Tyler,

It’s me again! with another question. I’m interested in what you think.

So I’m deciding on where to put my free time, building something or practicing algorithms/DS problems, to get the better job/opportunities out there.

I believe that someone can learn how to build something in their normal job but in opposite, they need to study/practice specifically for algorithms/DS to be good at it.

Do managers think that a candidate should be expected to know how to build things just because they have worked before in a related field? and go straight to algorithms/DS questions because they want to see how the candidate thinks? or will they care about the candidate showing them what they have built and will not be very strict on your algorithmic/DS skills?

How does this work? what is you opinion? What is more impressive to you or for what do you look into a candidate when you hire him, that he has actually answered your algorithmic/DS questions or that he has built something?

For example: I had some coworkers that were really good at building whatever you liked but they did not know what Big O, BFS, DFS, Binary trees were etc…

So they clearly won’t be able to answer most technical questions on an interview but they are really good at building something.

Thanks for your time!


ManagerJS says…

Thank you for your question, Raul. Before I give my own answer, realize that there are many important abilities that you need in order to be an effective worker. Managers often call these competencies. Each job opening will have three to five competencies that the hiring manager considers essential.

In this case I’ll limit my comments to a vague technical competency.

Results Matter Most

In short: a manager hires a candidate because she believes they will produce results. More specifically, the right results in the environment of the company she is hiring for.

The future isn’t known yet. So a manager has to guess at what information will most reliably predict good future results.

Time and again the best predictor of future results has been shown to be past results.

While it might sink you when naïvely applied to the stock market it’s really the first rule in hiring.

Have a Portfolio

If you have a product you’ve created yourself, and it’s sharp, then put that in your portfolio. That’s one of the best bits of evidence that shows you really can produce future results.

Unfortunately, many people don’t have compelling products they’ve made in isolation. When they talk about past results it’s often difficult to tease out what exactly they did versus their team. (I’m sure you’ve been part of a team with some free riders.)

No matter how good a portfolio a person has I want first-hand testimony to add to my list of evidences. I have a short list of people I trust enough to give a recommendation that fills that need for me. If you don’t have that kind of referral then I’m going to want to see you work.

Be Prepared to Audition

When I give a candidate a sample problem and ask them to solve it with me I specifically do not want them to solve it from memory. If the solution comes too easily then I’ll give them another one. I need to see them think.

At the same time, I don’t want to see them think abstractly. I don’t use brain-teasers or riddles. I ask them to solve a realistic problem that lends itself to basic analysis and problem solving.

  • Do you think to restate the problem?
  • Do you seek to divide it into smaller problems?
  • Do you build up a solution using composition, looping, and branching logic?

These basic skills will be second nature to a developer that has really delivered solutions in the past.  They will be a challenge to a scripter that has mostly use the search, copy, mutate formula for hacking together solutions.

If you haven’t formal training in computer science, or your past projects have been monotonous, then you might want to beef up your problem solving skills with intentional practice solving programming challenges.

Do Both

Should you develop portfolio projects or should you solve algorithm problems?

  1. Have at least one solid portfolio project. Sharp and created (nearly) entirely by you.
  2. Be well practiced in learning new tools and finding novel applications. You might demonstrate these in one-off experiments in your portfolio.
  3. Know how to divide and conquer, recurse, and loop. (You can practice this a lot in programming challenges.)

In general I don’t hire you for the algorithms you’ve memorized but for the results you’ve produced with those algorithms. Tools (like algorithms) help you deliver. And you can’t use a tool you’ve never learned.

Pretend It’s All Voicemail

Today’s Mad, Sad, Glad. by Wendii Lord hit dead-on for all three links.

Voicemail: Still Kickin’

I’d like to add my amen in particular to her note on voicemail: it’s still useful.

If you call me, get voicemail and don’t leave a message then I’ll probably assume you don’t need a call back. In fact, I’m not going to bother matching your number to a name if you don’t leave a message.

Sometimes I’ll call someone and get their voicemail only to realize I really could figure things out on my own. I hang up and find my own way.

I’m surprised when they call back and ask, “Hey, I missed a call from this number?” I’m sure they’re trying to be helpful. It seems kinda needy: you really have time to return calls when you have no idea whether or not they were a wrong number?

If it wasn’t important enough for me to leave a message then you definitely don’t need to bother yourself calling back.

Asynchronous On Demand

What’s really bothersome about the assumption/observation that people don’t leave messages anymore is that it points to a less forgiving communication model: talk now OR NEVER.

I’m no fan of phone tag. I don’t want to have whole conversations over voicemail. On the other hand, I’m no fan of letting my phone win every contest for my attention.

If I’m interviewing someone, if I’m meeting with an employee, or if I feel that not taking a call is a better use of my time then I should be able to let the call go to voicemail.

Phone Call Triage

Because I live in a world where voicemail exists I am free to miss calls — even when I hear the phone and am physically capable of answering.

For gee whiz, let me tell you how I decide whether or not to answer the phone.

Production Outages Win

I have a different ringtone (and different vibration pattern) for production incident calls. Since having the site go down affects hundreds of people every minute I want to immediately respond to these calls. Even if I’m in a one-on-one with my boss I’ll excuse myself and get this taken care of.

Scheduled Communications Win

If it’s not production calling, then the person I’m with beats the person on the phone. I may step out of a large informational meeting when my phone rings, but generally I prioritize planned communications over ad-hoc ones.

My Wife Has a Veto

Finally, my wife and I have a system we’ve used for years that balances both of our needs: she is free to call at any time; I’m free to ignore her call for any reason.

Really, any reason.

But, if my wife calls twice in a row then it’s an emergency and she knows that I’ll drop everything to answer. This system has worked very well.

Slow Down Jackrabbit

While it’s tempting to use on-demand communication to replace messages and post-its, it’s just not practical. The more frivolous calls I get the more I’m inclined to send you to voicemail.

As a matter of fact, before you call me pretend you’re going to get my voicemail. Prepare a quick message. If you get me instead then the call will go better anyway thanks to your preparation.

“How to Make a Performance Budget” an article by Dan Mall

My last post on performance budgets emphasized back-end service latency. Dan Mall’s brief article “How to Make a Performance Budget” does an excellent job giving concrete examples of making a performance budget for asset sizes: HTML, CSS, JS, Web Fonts, images, etc.

(Via. Jakob Anderson)

Beware Advice That Costs Them Nothing

I just finished my first reading of Taleb’s Antifragile and started listening to All Quiet on the Western Front. (I haven’t read it since middle school.) I noticed a principle from Antifragile in Remarque’s historical fiction of The Great War.

Advice From a Position of Trust

The main group of young men were inspired by their school teacher, Kantorek, to volunteer for the German army. War was very different from what they had expected. After the first of them dies the narrator reflects:

Naturally we couldn’t blame Kantorek for this. Where would the world be if one brought every man to book? There were thousands of Kantoreks — all of whom convinced that they were acting for the best, in a way that cost them nothing.

chapter 1, 16m 25s. Bold added

Benefit Without Risk

If I understand Taleb correctly then Kantorek (and his generation) was benefiting from optionality — one where he reaps the upside (possible national victory) and others the downside (death in the war).  Taleb rails on this sort of arrangement at length in Antifragile.

Don’t Abuse Trust

Managers can face this sort of issue. I’ve had employees counsel with me before making a decision on a job offer from somewhere else.  If they are a good worker then I benefit from persuading them to stay. But they may be declining an upside much larger than the downside I’m avoiding.

I’m definitely not an expert on optionality. I’m just practicing to recognize it in the wild. Whether or not this is a good example of optionality the conflict of interests is clear and I’ve dealt with it.

Declare Your Bias

In these cases I honor my obligation to represent the company and it’s interests without manipulating my employee. I make clear what benefits me and the company. I make sure they understand I’m not entirely impartial.

You might say that bias should be assumed. Anyone that takes advice without considering the source is just being naïve. Well, that doesn’t do it for me.

I work hard to have a trusting relationship with my employees. It isn’t fair for me to ignore the possibility that they might think I’m speaking as a completely independent friend when I must speak as an employee. (Reminds me of Taleb’s comments about Lawrence of Arabia: never trust a man that isn’t free.)

Be Likable

Here’s a gem from the February 20th edition of Mad, Sad, Glad from ManagerTools.com:

This is a typical HBR article in that it’s long and academic.  The important part is that people would rather work with with someone who is incompetent than someone who is unlikable.  If you think that smarts are enough, refer to our very first podcast ‘Solution to a Stalled Technical Career‘.  Yes, HBR, we said it 10 years ago 🙂

2015-06-03 Unlikeable

What! I thought this was a meritocracy! Am I not hired for my mad skills?!

Well, yes. You are.

And contributing positively to a team is a skill. One the vast majority of us can’t succeed without.

Be likable.

Be a good, kind, and gracious person. People tend to like those.

No tricks. Don’t just gently imitate others like Andy Bernard from The Office. Trickery is icky and doomed to fail — if not professionally then ultimately in the shriveling of your soul.