For 2020 I’ve committed to a new morning routine, cut out everything that isn’t essential, and dialed it in for maximum effectiveness. If you try it, let me know how it works for you!

5:00 AM — Wake up to daylight alarm
5:10 AM — Pre-dawn yoga
5:30 AM — Walk in nearby woods for forest bathing
5:45 AM — Insight meditation
6:00 AM — Compassion meditation
6:15 AM — Settle in for free-form journaling
6:45 AM — Consume 16 ounce of water and a scientifically designed probiotic/prebiotic mix — break my intermittent fast
7:00 AM — High-intensity interval training
7:15 AM — Strength training
7:30 AM — Make and drink Bulletproof coffee with imported yak butter
7:45 AM — Make and drink 13-fruit and vegetable blend smoothie
8:30 AM — Shower and shave
9:00 AM — First nap — sleep is so important
9:30 AM — Text with children to say I’m sorry I missed them leaving for school
9:45 AM — Listen to inspirational podcasts
10:30 AM — Bullet journaling
10:45 AM — Gratitude journaling
11:00 AM — Text my wife to say I’m sorry I missed her this morning too
11:30 AM — Feed the dog, she should be hungry by now
11:45 AM — Walk the dog
12:00 PM — Catch up on email from last night
12:30 PM — Catch up on email from this morning
1:00 PM — Catch up on email that came in while I was catching up
1:30 PM — Second nap
2:00 PM — Connect with an old friend
2:30 PM — Spread 3 random acts of kindness

Then I bike to work, refreshed and ready to kick butt — in a highly mindful way of course — about 3:45.

That’s a funny thing about our minds. In the absence of information, they fill in the gaps and make up all sorts of plausible things, without the owners of said minds even realizing it is happening.

If your friend didn’t just assume you’d understand but thought to text you and say “phew, I just got a new assignment at work, I’m gonna be pretty scarce for the next few weeks,” not only would your mind be at ease, you might even offer to bring them dinner or take their dog for a walk. (It’s an adorable dog.)

This is a simple example of overcommunication. There is no strict need to keep you in the loop. You don’t have an agreement or contract that makes it mandatory. But saying more than is strictly necessary makes things better for both of you.

This same skill can dramatically improve your work life, not just in the short term but for the entire arc of your career.

“The single biggest problem with communication is the illusion that it has taken place.”

– George Bernard Shaw

At Glowforge, one of our cultural cornerstones is that we “take care of each other.” The type of overcommunication we are about to discuss in detail is one of the ways that we do that. An employee helps take care of their manager by proactively communicating project status and what, if anything, is impeding success. A manager helps take care of their employees by making that communication psychologically safe even when it contains bad news, and by offering constructive support to solve problems.

Isn’t This Just Communication?

Sure. Except that most people don’t do nearly enough proactive, detailed, thoughtful communication at work. So, relative to the baseline, it is overcommunication.

A Note About Privilege and Bias

This article assumes a degree of privilege. It assumes you work at a job where you are respected and valued, both for your work and as an individual. Many people work in jobs where they are treated more or less as a replaceable commodity, and also there are systematic biases around race, gender, class, religion, disability, and many other aspects of diversity that can make this kind of direct communication riskier for some individuals than others. You have to be your own judge of how much and what kind of communication your manager and your company can handle.

Also, Skip This Article If …

I can read your mind right now. Some of you are thinking, “Communicating more sounds great, but I work in a no-excuses industry.” Maybe so, although clear communication isn’t the same thing as excuses.

But if you’ve chosen to work in a company or industry that has no room for anything but perfect execution every time, regardless of changing circumstances, I hope it is worth it!

And this article probably isn’t for you.

When To Overcommunicate (Hint: Pretty Much Always)

If you are a new employee, in a new role, or on a new team, overcommunicate and make it easy for your manager and teammates to have visibility into what you are doing and what decisions you are making. You’ll be rewarded with better feedback earlier, and get on a much faster path to being trusted and highly valued.

Are you implementing a new process? Overcommunicate so that you and all of the stakeholders catch opportunities for improvement before it becomes set in stone.

Do you have a new personal struggle? Do you have a parent that needs more care, a baby that just won’t sleep, or a back that’s suddenly killing you? Don’t feel you need to carry that weight alone, or risk being thought less than. Everyone, and I mean everyone, no matter how bullet-proof they seem, has personal problems that affect their work from time-to-time. Overcommunicate and get the support and understanding that you need.

A bit of advice on this particular one: it isn’t necessary, or necessarily wise, to go into great detail on your personal problems. Depending on your relationship with the receiver and your sense of safety, you may want to say as little as “I’ve got a problem in my personal life that I expect will cause me to operate at reduced capacity for the next month or so.”

Have you ever worked on a project for days, weeks, or months, only to have the result rejected and send you back to square one? Did you show your work in progress along the way? I bet not. If you had, not only would you have gotten feedback sooner and corrected course, but the person giving the feedback would feel much more personally invested in the success of the project. By the time you get to the end, final approval should be a mere formality.

Another benefit of communicating along the way, particularly if you use a structured set of documents, is you and your leader have a place to refer back to, to remember when and why a decision was made, in case you need to revisit it in light of new information. At a startup like Glowforge, new information is something we welcome and expect! It is helpful to remember that your leader probably has to multitask more than you do, so having past context to go with that new information is an empathetic way to help them help you!

Did something awesome just happen? Did you finish a project early, or get better results than anyone anticipated, or delight a customer? Don’t keep the good news to yourself, overcommunicate! (But do use your empathy to make sure you share in a way that will be well received by everyone involved.)

Have you received feedback that you are underperforming or felt that your manager doesn’t understand what you do day-to-day? This can be scary, and effective overcommunication is the key to rapidly improving the situation. Even if you aren’t worried about losing your job, you don’t want to be perceived as underperforming for long. Now is the time to get 100% on the same page and be crystal clear about expectations. Don’t wait for more feedback. Let your manager know on a consistent, possibly daily basis what you’ve done, what you are about to do, and any place that you are blocked. They will appreciate it, see that you want to turn things around, and have the information they need to help you get things back on track fast.

By the way, a common outcome in these situations is that the employee starts reporting in a lot more detail. Then their manager seems happier with their work even though they think they haven’t done anything differently. That’s a bummer. The perception is, “this is so dumb that they have to check up on me.” In reality, just the act of communication likely helps to focus effort on the most valuable work. And it also misses the point that communication is itself a crucial part of the job. If you are a manager and are coaching an employee to communicate more, be sure and share your appreciation and help them to see the value their extra effort is creating!

I’m Overwhelmed!

And then there is the most common situation at all, which is simply being overwhelmed. We’ve all been there. You’ve got so much on your plate that you don’t know where to start. Things that look like they will take fifteen minutes balloon into five-day poop-storms. Every item you cross off your list seems to spawn three more. The check engine light just went on in your car. And now your boss is chasing you down for an unexpected fire drill.

I can hardly breathe reading back through that paragraph. But you don’t have to suffer in silence. Here’s what I do when I find myself in that situation.

1. Make a list of everything and take a stab at the right priority to attack it. Assuming you work someplace reasonably humane, no-one is expecting you to deliver all of that on time under those circumstances. But they need to know what is going on!
2. Write a calm, clear email to your manager and stakeholders. Let them know the situation, your plan, and realistic estimates of when projects will be done. You may even need to suggest entirely cutting some work, or see if it can be reassigned. Ask for feedback on whether your proposed course of action is the right one.
3. Agree on a plan, then, keep them updated on a regular and frequent basis.

By overcommunicating, you will engage their empathy and invite them to consider whether there is anything they don’t actually need, or need right away. By calling out the problem early and often, you are building trust. If you keep trying to spin all those plates and don’t say anything until they are crashing and shattering and it is too late to do anything about it, you lose trust.

I can’t stress this enough. For many people, the instinct under stress is to hide and try to dig out of the hole by themselves. This rarely works. Usually, the hole gets deeper and the options for solving the problems get narrower as time goes by.

If you develop the habit of communicating problems as soon as you suspect them, instead of waiting until there is no hope, you and your team are going to be much happier.

How To Overcommunicate

So what does excellent overcommunication look like? I don’t know that I can do any better than to share (with permission) an email that one of our Glowforge product managers sent to their stakeholders:

No action needed — but an awareness I’m dropping certain things to focus on getting Q1 kicked off. I’ve organized what I’m working on and thought I’d send a status update for both my sanity and general communication

… so I can move forward and ship.

TLDR:

• There is too much moving right now, and I’m answering questions about most of these things most days
• To make real progress towards checking them off and shipping, I need to focus on some things while letting others drop for a week or so
• Chart showing all the things I’m working
• Details beneath chart

… [details redacted]

Why is this email so impactful?

• They don’t bury the lede. From the first sentence, you know that they need to decommit from some projects. It is fundamentally honest.
• They focused on the crucial result, which is that they want to “move forward and ship,” which makes it highly relevant to the stakeholders.
• They’re overwhelmed, but have still taken the time to do the work of organizing projects into a coherent chart and clearly stating the status of each, suggesting which ones to drop or delay, and laying out the impact of those changes. They ask for support and set up the stakeholders to be successful at supporting them by concisely providing all of the necessary information. In other words, it is respectful of their time and attention.

You should make an effort to get to know your manager’s preferred style. When you’ve communicated this way, especially the first few times, I recommend following up with them in person — where you can see their reaction — and check whether it was ok and helpful, and how it could be better in the future. Sometimes an overcommunication won’t have the desired effect and that is an opportunity for you and your recipient to practice empathy and make a great repair.

Really, So, Always?

Of course, there are risks to overcommunicating. If you have a manager that makes it psychologically unsafe to have a project go wrong, or that has a tendency to micromanage your every move, this isn’t going to be a helpful tool. But maybe you need a different manager! You deserve a responsive, encouraging receiver of your messages. I could (and should) write another article for managers on how to be a great receiver.

If you find yourself wanting to write something just to make sure it is documented so later you can say “see, I told you so” when something goes wrong, that’s not overcommunicating, that’s CYA (covering your a__). You can easily spot the difference because a CYA doesn’t come packaged with thoughtful solutions.

And of course, overcommunicating can be taken too far. If you are taking 4 hours to write up a detailed status on a 2-day project, that is obviously not the right return on investment! Get in the habit of writing status that is honest, relevant, respectful, and also concise.

Not Just For Today

It is easy to think about this style of communication as nothing more than a productivity hack, or a way to get out of a short term jam. It certainly is those things, but it is so much more.

Imagine you were to take two identical twins and give them the same starter job, same manager, same skills, and the same personality. One competently does all of their work behind a veil of silence, not sharing good news, opportunities, or challenges, but just plugs away until asked for a status update. The other does the same level of work but communicates effectively, keeping their manager and stakeholders proactively informed. Which one is going to get the next opportunity for growth?

If you compound that over the course of a decade, the first twin will likely be doing about the same thing they were when they started. The second will have earned much more trust, more responsibility, a wider range of experiences, and have a much more fulfilling career. I’m 92% sure of it.

This isn’t just a tool for individual contributors, it is a skill that you can use in every role. Even our CEO makes a huge effort to overcommunicate with our board of directors and our entire company so that we all have the context to give effective input and make great decisions.

So what do you think? Has overcommunication worked for you or bitten you in unexpected ways? Overcommunicate in the comments and share your experience.

You Aren’t Communicating Nearly Enough was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Something I’ve observed in many contexts: the smaller your world, the bigger the drama. Drama in the sense of sound and fury, signifying nothing.

Another way to say it: the smaller the teapot, the bigger the tempest.

Remember Milton?

His world is pretty small, so he’s got an awful lot invested in that stapler.

But what about the reverse? If you find a way to let go of some drama, do you get to play in a bigger world? Try it and see! What is your red stapler?

I misspent just about every night for 7 years at an old school pool hall in Milwaukee. This was an “action” room, where a regular lineup of shady characters was perched, ready to relieve you of any excess cash that might be burdening you. Most of the betting was on pool, but it wasn’t unusual to see wagers on cards, dice, sports, weather, or the time it would take a cup of water to boil in the snack bar microwave. Basically, if two people could be found with opposing viewpoints and an American dollar, it was on.

Betting on pool is a highly calibrated affair that makes it at least theoretically possible for a rank amateur to arrange a fair match against Efren Reyes. For example, in the game of 9-ball, you can adjust the number of games each player needs to win a set, which balls win the game for each of them, who gets to break, etc.

When you bet on games of skill, you learn that the expected value of your bet depends as much on how accurately you assess your chances, and thus the handicap you negotiate, as it does on the skill itself. Gamblers that hold an inflated view of their chances (i.e., almost all gamblers) will lose money eventually, and the feedback loop is generally short. Overconfidence is folly and will be ruthlessly exploited. If I think I can beat Efren with the 5-ball and the breaks, I and my wallet will be corrected rapidly.

Toxic Certainty Syndrome — Could You Be Its Next Victim?

And yet, in the tech industry, with our motto of “strong opinions, loosely held”, we’ve glorified overconfidence. The same foolishness that would cost your money and pride in a pool hall is the stuff of legend in Silicon Valley. Stroll through an engineering office and you are likely to hear the (mostly white, mostly male) denizens making statements like:

“Only an idiot would use MongoDB.”

“We should absolutely build this using GoLang.”

“All of our users would kill for that feature.”

“Linguini’s is the worst restaurant in the world and I’d rather eat dehydrated bat vomit for the rest of my life than have lunch there again.”

The idea of strong opinions, loosely held is that you can make bombastic statements, and everyone should implicitly assume that you’ll happily change your mind in a heartbeat if new data suggests you are wrong. It is supposed to lead to a collegial, competitive environment in which ideas get a vigorous defense, the best of them survive, and no-one gets their feelings hurt in the process.

On a certain kind of team, where everyone shares that ethos, and there is very little power differential, this can work well. I’ve had the pleasure of working on teams like that, and it is all kinds of fun. When you have a handful of solid engineers that understand each other, and all of them feel free to say “you are wrong about X, that is absolutely insane, and I question your entire family structure if you believe that, clearly Y is the way to go”, and then you all happily grab lunch together (at Linguini’s), that’s a great feeling of camaraderie.

Unfortunately, that ideal is seldom achieved.

What really happens? The loudest, most bombastic engineer states their case with certainty, and that shuts down discussion. Other people either assume the loudmouth knows best, or don’t want to stick out their neck and risk criticism and shame. This is especially true if the loudmouth is senior, or there is any other power differential.

Members of your team that are from groups historically underrepresented in tech may be less likely to have experienced the collegial, open debate environment, and may feel uncertain of their position. This means you might not hear their ideas. Given the extensive research that shows diverse teams make smarter decisions, this is tragic.

Even if someone does have the courage to push back, in practice the original speaker isn’t likely to be holding their opinion as loosely as they think. Having stated their case, they are anchored to it and will look for evidence that confirms it and reject anything contradictory. It is a natural tendency to want to win the argument and be the smartest person in the room.

Finally, in most cases, the feedback loop on these decisions won’t be closed quickly. Unlike my foolish 9-ball matches, a major engineering choice might not bear full fruit for months or years, by which time we’ll have forgotten how we made the choice and what the alternatives were. There is great value in thoroughly evaluating the key alternatives up front.

This (Really) Won’t Hurt A Bit

Fortunately, there is a remarkably simple solution to the problem, which I picked up from Dan Shapiro, our CEO at Glowforge. He tells me he inherited it from our company’s co-founder, Tony Wright. The behavior change required is very small. You can easily model it for your team by adopting it yourself, and you can easily and gently guide other people into making it a habit. It isn’t even deceptively simple, it is just … simple.

All you need to do is add a degree of uncertainty to your statements. For example:

“I’m 90% sure we shouldn’t try to build our own social network.”

“I’m 50/50 on whether to do this with Cloud SQL or Cloud Datastore.”

“I have a low conviction hunch that the airplane icon will work better than the gift box.”

The effect of adding this qualification is twofold. First, you’ll keep your own mind much more open. As world-class poker player Annie Duke points out in Thinking in Bets, even if you start at 90%, your ego will have a much easier time with a reversal than if you have committed to absolute, eternal certainty. You can safely update your beliefs and say “Hmm, you make a good point. Now I’m only 60% sure.”

Second, the folks around you will now feel invited to participate. When the opinion that you express has explicit room to evolve, they know there is going to be a respectful space to share their own ideas. If you are a leader, this is also a useful management tool, because it helps to calibrate your team as to how much effort they should put into alternatives. If you are already 90% sure, there is less reason to invest in counterarguments than if you are simply throwing a guess into the pot.

So, what about the situation where someone else goes first and makes an absolute statement? There is a simple ninja move! Just say “It sounds like you are 100% sure of that, is that right?” If the answer is yes, you can ask them to explain why they are certain and see if they have any data to back it up. If not, you’ll have prompted them to assess their actual level of conviction, sharpen their thinking, and open up the conversation. It is a simple, kind way of helping them develop a style of thinking and communication that will improve your organization.

One last point. If you have been an engineer for a while and are accustomed to the strong opinions, loosely held mindset, it can be easy and even more disastrous to bring it home with you. I may have had a significant other or three tell me that my certainty was obnoxious. Honestly, I thought I was being funny, and I took for granted that anyone else would feel free to put forward their own opinions. But hey, it has only taken me 30 years or so to get the message and start to work on it! I’m 80% sure it is helping.

This article originally appeared on The Glowforge Blog. Michael Natkin is Glowforge’s VP of Software Engineering. We are hiring for software and many other roles. We also happen to make an amazing 3D laser printer.

Strong Opinions Loosely Held Might be the Worst Idea in Tech was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is part 3 of a series, “Your Contract Developer Is (Probably) Hosing You”, aimed at helping non-technical founders get their first product built. If you missed the beginning, start here.

There are three broad categories of contractors that you might hire to build your project: full service agencies, offshore teams, or freelance engineers. Each of these types has its pros and cons, and within each one you’ll find massive variation in capability, skill, and cost.

Full Service Agencies

These folks will give you the most service, and be by far the most expensive. You’ll have meetings with polished professionals that will sell you on the company. You can expect to sit in a nice conference room, watch sharp presentations, and be presented with a statement of work (SOW) in a sexy PDF with an eye-popping number on the last page.

In addition to the actual software development, they will offer design, project management, user testing and maybe other bells and whistles. Some of these will be non-optional overhead that they require on every project. You’ll get regular updates from your project manager and they will solicit your feedback and keep the team in the loop. You may rarely, or even never, meet the actual developers that work on your project.

The biggest downside to this model is, of course, cost. Just like your lawyer, only instead of the 70th floor views over the skyline, your are paying for polished tables lovingly made of bike tires and recycled old growth redwood, not to mention craft beer for the company dog parties.

I kid, of course, but this really is a boutique experience. The best if you can afford it, and possibly the fastest, and probably the way to go if you are very well funded but don’t have the ability or time to hire and grow your own software team.

You’ll find variation, but usually the absolute lower end of a project cost with these agencies would be at least $50k, at a billable rate across all of the people you have on your team averaging maybe $150/hour. A more realistic medium-size project could easily cost $150k or more.

Also, keep in mind that within this category, there is a range from relatively small boutiques to very large consultancies that specialize in projects for Fortune 500 companies. You’ll want the small end of that scale.

Offshore Teams

There are skilled offshore development teams for hire all over the world, from Bulgaria to Mexico to Kenya. Generally they offer much less in the way of design, project management, and warm/fuzzy handholding than you would get from a full-service agency. What they lack in service, they make up for in cost. Rates could be as little as $30–$50/hour, and with much less overhead. Almost all your spend will be directly on developers.

Sounds great, right? You just might be able to get that v1 built and out into the world before you spend the money your Uncle Nate gave you and max out your credit cards.

Slow your roll though, there are plenty of potential problems in this paradise:

• You’ll most likely be dealing with a timezone difference. Meetings will be at a time that is inconvenient for one or both of you, and turnaround time on emails or Slack messages may lag by the eternity of a full day.
• You should try to choose a team with a primary contact that speaks your language fluently, but still there may be communication challenges.
• Culture can vary widely. You should do some reading about business culture and customs in the country you select. You may find that “Yes, by next week for sure” means “There is no chance of that happening. But yes, I hear you really want that.”
• Competence and skill can vary widely. Further down we’ll talk about how to assess any potential contractor, but with an overseas team there is perhaps even a greater risk than usual of ending up with developers that just aren’t actually very good. There are absolutely gems out there too! But do you, as a non-technical founder, have the ability to tell who is who?
• Hopefully this will never matter, but legal recourse could be a real issue. There is no way to avoid developers having the keys to many of your important assets. If a local developer changes the password to your Heroku account or wipes your database or refuses to turn over your source code, you could sue them. And they know that, so they probably won’t do anything that stupid. If someone half a world away burns you, what will you do? We’ll talk more about how to manage these risks later in the series.

I don’t say any of this to suggest that you shouldn’t use an overseas team to build your product, but you should absolutely have your eyes wide open. You might also consider hiring or contracting an engineering manager locally to manage the overseas team on a part-time basis, acting as your liaison.

Freelance Developers

You can also find freelance developers, either locally or remote but in-country, that can take on moderate sized projects. They are usually a single individual, but sometimes can be a small team, or the developer might have a few friends they collaborate with on some projects.

Unlike an agency, you won’t get the slick business interactions or the wider sets of skills (UI/UX, QA, project management, etc.), surrounding the developers. Unlike an overseas team, you’ll have shared (or nearly shared) timezones, language, culture, and legal systems.

Hourly rates will depend on the experience of the developer and where they live, and could range anywhere from $50/hour for a total newbie in an inexpensive area to $200 or even $300/hour for a super seasoned pro in a major city, particularly if they are an expert in a specialty that you need. Even at the higher end though, they may be less expensive than a full-service agency because you have less overhead and more coding.

The upside of this option is that you can save some money without necessarily taking on all of the challenges of an overseas team. The downside is that, compared to an agency, you’ll have to do a lot more of the project management yourself, and you have fewer guarantees of professionalism.

In the next article in the series, we’ll talk about how, once you’ve chosen a category, to find developers in that category and then select the one you want to work with for the highest probability of success.

Reminder: This is part 3 of a series, “Your Contract Developer Is (Probably) Hosing You”. If you missed the beginning, start here.

About Michael: I’m a senior technical leader and startup CTO based in Seattle Washington. I’ve built everything from dinosaurs to sous vide cookers, and I’m looking for my next role.

This is part 2 of a series, “Your Contract Developer Is (Probably) Hosing You”, aimed at helping non-technical founders get their first product built. If you missed the beginning, start here.

Are You Ready?

The first question to ask, before you go looking for a contract developer, is whether you are properly prepared to use their time efficiently. If you aren’t, and you engage them, you’ll blow through your cash very fast and have nothing to show for it.

There is a bit of a fork in the road here. You can go to a full-service agency with only a general idea of what you want build, and some screen sketches on the back of a napkin. This won’t work at all with individual developers or overseas teams-for-hire, but an agency can typically provide UI/UX services to flesh out and prototype your plans before you start to build them. However this is a very expensive path, and I wouldn’t recommend it unless your pockets are deep.

M To The V To The P

As a founder, you’ve probably already heard a lot about getting to your MVP, the minimum viable product that will let you determine if you have product-market fit.

I would bias strongly in favor of waiting to engage engineering until you have a very clear plan of what you want them to build to achieve an MVP. The first step of that is to get brutally clear on what you think your initial product is. You are the one with the dream and the vision, so no one else can do that for you. You should be able to describe it in the proverbial elevator pitch. A sentence or two that summarizes the opportunity and paints a clear picture in anyone’s mind.

The next step is figure out what are the bare minimum features you would need to be able to release that product to an initial audience. To take our “Recommend Lladro figurine gifts based on a user’s tweets” example, it might be something like:

• A webpage with an input box where you can enter a Twitter handle; it should autocomplete to help them find the right person
• An account creation page; we’ll require an account before you get your recommendations so that we have your email address and can market to you.
• A system for scraping the Lladro website to ingest all of the catalog information.
• A machine learning system for reading the user’s tweets and displaying the best 3 figurines. This could use sentiment, style, keywords, similarity to other user’s choices, etc.
• The displayed figurines should include their description, and an affiliate link so we can make money from the sales
• There should be a share button so people can have fun with the recommendation. Like “@michaelnatkin LladroPicker says you’d like the puppy, the crying baby, and the diapered angels!” and include a link back to the results.
• A forum system that allows Lladro enthusiasts to discuss their favorite figurines
• A collection gallery where you can keep photos of your favorite figurines
• An auction system that integrates with the main recommendation page so we can act as a two-way marketplace, and recommend figurines that are for sale and collect a percentage instead of just the affiliate link.
• A computer vision system that can look at a picture of a figurine (either current or antique) and identify exactly what model it is, and what condition it is in and then show the approximate value

This is pretty good! You’ve identified an MVP.

See What I Did There?

Ok, if you think we’ve just identified an MVP, we really need to talk. That list has a whole bunch of features that are way beyond the original “Figurines based on tweets” plan. They might be fantastic features for your next several releases. Or they might be great ideas on their own. Or maybe once you wrote that list, you would decide that you actually want to do the marketplace features first.

Whatever you do, do not run off to a contractor with that whole list! It might seem like I’m exaggerating, but I’ve honestly seen a number of startups that begin with that much complexity. This is called “feature creep” and it is a mortal enemy of your wallet.

The Golden Triangle Of Destiny

Everything about software (like life!) is tradeoffs. And there are many kinds of tradeoffs, but the following one is so fundamental to software engineering that developers take it for granted. Yet it isn’t always obvious to non-engineers. There are three fundamental quantities that are at play on a software project, whether it is a one hour hack or a five year mission to conquer the galaxy:

• Time (equals Your Money!)
• Features
• Quality

If you want more features, it will either take longer (and cost you more money), or they will have to be done at lower quality. If you want to ship high quality software without horribly embarrassing bugs, it will take time and you’ll need to ship fewer features. This law is as immutable as gravitation. If someone tells you different, show them the door.

So, pop quiz, what do we need to do with that feature list above? That’s right, cadet, we need to be disciplined. Now, killing your favorite features is painful. So here’s the trick. Don’t kill them. Prioritize them. Put everything in the right order, then take the ones you don’t need for version 1, write them down somewhere secret, and forget about them for now. Or better yet, when the time comes, discuss them with your developers as future directions so that they can architect in a way that doesn’t preclude them. But DO NOT start building them.

For our example above, I’d probably start with:

• A webpage with an input box where you can enter a twitter handle; it should autocomplete to help them find the right person
• A system for scraping the Llladro website to ingest all of the catalog information.
• A machine learning system for reading their tweets and displaying the best 3 figurines. This could use sentiment, style, keywords, similarity to other user’s choices, etc.
• The displayed figurines should include their description, and an affiliate link so we can make money from the sales
• There should be a share button so people can have fun with the recommendation. Like “@michaelnatkin LladroPicker says you’d like the puppy, the crying baby, and the diapered angels!” and include a link back to the results.

Still Kidding

You can still make a radical and effective simplification here. Get rid of the ingestion system and the fancy machine learning algorithm. Manually enter the top 20 figurines. Let the user still enter a Twitter handle, but ignore the tweets and just randomly offer 3 of the top 20.

Why would I do this? Am I not killing the entire core of the beautiful LladroMatcher idea? Nope. This will be plenty good enough to determine whether the idea has any value at all. In fact, I’ve made it so simple that a single good developer could build it very quickly. I could then take all the money I’ve saved and use it to run social media ads to try and drive people to it, and measure whether I’m getting any visits, clicks, and sales.

If it isn’t converting at all, than most likely this just isn’t a great idea and I should move on. Or, if I want to double down, I can decide what my next experiment or improvement should be and try again.

If it is converting at a rate where I think there is a possibility of a real business here, then by all means I can invest in the machine learning to optimize conversion, along with all of those other features I was dreaming of. In fact, we’ve preserved the optionality of deciding that one of those should come before machine learning.

And one more thing: you’ve gotten a cheap look at the contractor you used! If the project is going well, and you’ve enjoyed working with them, you can give them the next set of features. If it succeeded in spite of them, and it has been frustrating, you can pack up your tent and look for greener pastures.

One More Step

Unless you are going to a full service agency, there is one more thing you need to do before hiring your engineers. You need a UI design. Design is the great non-linear variable in the success of software projects. I’ve seen this throughout my career. If you let an engineer just take your idea and translate it literally into whatever kids of screens, buttons, sliders, text inputs, etc. seem like the most obvious mapping, you will end up with something that looks and works like an engineer designed it — bland and literal. Even if they use a modern UI toolkit that provides decent baseline appearance and interaction, it will probably suck. A good designer will take your concept and both simplify it and make it sing, providing that element of delight that will encourage users to come back and to share it with their community.

For a small scale project, it is probably reasonable to use a freelance UI/UX designer that you can find on, say, Upwork. Look carefully at portfolios and ask questions about their approach. Even if the results they produce are imperfect, it will be better than what you or your engineers will do, and you can always go for a fancier version in v2. Work with that designer and your list of features to nail down a logo (if needed), colors, typography, and the basic screens (both desktop and mobile if appropriate). Iterate until you are satisfied, keeping in mind that this upfront work will save you lots of time and money once coding begins.

With those design deliverables in hand, you are ready to choose an engineering contractor and negotiate with them, which will be the subject of Part 3 — Choosing A Contractor.

Reminder: This is part 2 of a series, “Your Contract Developer Is (Probably) Hosing You”. If you missed the beginning, start here, or continue to part 3.

About Michael: I’m a senior technical leader and startup CTO based in Seattle Washington. I’ve built everything from dinosaurs to sous vide cookers. I’m looking for my next role.

Does this sound familiar?

• You have a big dream for a product, app, or website that you want to build.
• You aren’t an engineer or highly technical.
• You’ve got a limited budget.
• You’ve hired, or are considering hiring, contract developers to build your product.

Sadly, this is a recipe for getting badly hosed. You could easily spend all of your savings and end up with a barely functional, buggy, ugly, unmaintainable prototype. If that happens, your dream won’t see the light of day, and that is both sad and avoidable.

I’m really glad you have a dream! I don’t want to discourage you from following it. Quite the contrary, I want you to have a realistic idea about how to bring it to life, and save you from wasting your time and money going down dead ends.

I’ve spent time with quite a few super-smart, ambitious, energetic founders that are in this position, and I’ve started to see some patterns. In this article series, we’ll talk about what those mistakes are, and how you can avoid or correct them. Here’s what I have planned:

1. (This Article) — Overview
2. Preparing To Use A Contractor
3. Types of Contractors
4. (Coming Soon) — Choosing A Contractor For The Win
5. (Coming Soon) — Incentives and How To Align Them
6. (Coming Soon) — Holding A Contractor Accountable — The Big Picture
7. (Coming Soon) — Holding A Contractor Accountable — The All Important Details

How You Got Here

I’m assuming you’ve done some basic validation to give you confidence there is a market waiting for your app that uses AI to select the optimal Lladro figurine for a wedding gift based on your cousin’s tweets, or offers BitCoin micropayments to yoga instructors that optimize your headstands. You’ve thought of a name, bought the domain, started an Instagram feed and gotten 57 likes on the headstand photos. Good!

You aren’t a programmer yourself, so you can’t just go build it. You might think you can run off to a coding bootcamp and then build it yourself, but I can tell you right now, you’ll be no more qualified to build a shippable product at the end of bootcamp than you will be to build a car from iron ore. There is a massive difference between even a good final project and a usable, professionally built app.

Your best option, at this point, is to get a technical cofounder. Maybe you think you don’t need to do this, because, hey, this idea is worth millions… billions… why should I give up a big chunk of my company to someone who just comes in to write code? Or you might be open to the idea, but don’t have the network to find a good technical cofounder that is willing to work for little or no pay initially, but take equity.

The problem is, your idea is basically worthless if you can’t get it built, and built reasonably well. This should be like a mantra to you. You don’t want to believe it, but it is true. Without a good, reasonably non-buggy, somewhat delightful product that you can put in the hands of actual customers, you’ll just be another sob story at the bar. Seventy five percent of millions is WAY more than one hundred percent of zero. If you can find a technical co-founder, do that! (And I should probably write a whole ‘nother tome on how to choose and validate that person.)

Let The Hosing Commence

So you’ve got the dream, you’ve done some rough validation, you desperately want to get building, and you’ve concluded you can’t build it yourself or find a technical cofounder. That means you are going to have to use some flavor of contractor, whether it is a fancy agency, an offshore team, or an individual developer. We’ll talk about those tradeoffs in the next article.

It sounds pretty straightforward. You’ll pick your developer, agree on a budget and a timeframe, keep a close eye on them, and soon you’ll have your first version ready to roll out. What could… possibly… go wrong?

Here’s a partial list. Don’t freak, in the upcoming articles we’ll talk about how to prevent or resolve these problems.

• They don’t actually have the expertise to build your product, they are planning on learning on your dime
• They choose a technology stack based on what they know, rather than what is appropriate to your product
• You have massive time and budget overruns, but you can’t afford to fire them and start over
• You haven’t adequately specified the problem, and you haven’t hired a designer to help figure it out
• They load spectacular overhead charges onto your project
• Because of time zones, it takes days to resolve the simplest problems
• You keep changing your mind, and each change order costs a pretty penny
• They build literally what you ask for, but don’t use any common sense
• They build you into a corner, so it does literally what you asked for but what seems like the simplest little change is practically impossible
• They don’t build automated tests or use any human QA, so the app only works on Wednesdays if you are standing exactly in the right spot and cross your toes. Especially if you are showing it to customers. When you show it to customers, the worst bugs immediately start popping up.
• They haven’t planned for deployment, security, scaling, analytics, logging, data warehousing, server costs, compliance, documentation, or a million other operational details that can burn you instantly
• They write incompetent code that, even if it serves as a first prototype will have to be thrown away and rewritten from scratch
• The breakthrough you need is always just right around the corner, if you can just keep paying them for one more sprint
• And in the worst case end game, they stop answering your messages and run away with your source code and service passwords

Now, admittedly, I made that list terrifying because I really want to get your attention. If you are non-technical, haven’t hired contractors before, read that list, and your feeling is “I’ll be fine”, then… godspeed! If you read it and thought, “There be dragons”, then stick with me on this journey and we’ll see if we can reduce your risk and increase the odds that your money and time are well spent.

Also, none of this is to say that there aren’t great agencies and contractors out there, or that you can’t be successful with them. It is totally possible, but you need to know how to improve your odds.

If you have specific questions or topics you’d like me to address, add a comment. And if you have found this helpful, don’t forget to give it some claps, share, and pass it on to a friend with a dream.

Continue to Part 2 — Preparing To Use A Contractor.

About Michael: I’m a senior technical leader and startup CTO based in Seattle Washington. I’ve built everything from dinosaurs to sous vide cookers. I’m looking for my next role.

There will be a day when your boss is insisting you to do something that you believe is impossible.

There will be a day when the sound of a coworker chomping an apple during a meeting makes your head pop off.

There will be a day when the new kid you advocated hiring is asking the same question over and over again, and you fear they will never stand on their own two feet.

There will be a day when an argument over technical pros and cons turns personal, and you get your feelings hurt. Or hurt the other party.

There will be a day when the newly announced corporate strategy seems so wrongheaded that you are sure customers (not to mention the stock price) will suffer.

There will be a day where you are so tired from taking care of a sick, cranky baby that you can barely keep your eyes open, and everything your colleagues do is maddening.

There will be a day, probably many days, when the idea of sitting in front of a computer (or whatever you do) for 8 hours seems like utter misery.

There will be a day where you feel frustrated beyond belief, and worried you’ll never solve the problem you are working on.

There will be a day when you feel like a complete charlatan, and can’t believe anyone thinks you are good at your job.

There will be a day when someone calls you out unexpectedly in a meeting in front of your boss.

There will be a day where you are asked to do something that seems ethically dubious.

There will be a day when you say something intended to be funny, and then worry it might be taken to be sexist, or racist, or homophobic, or otherwise offensive.

There will be a day where you are asked to do something that benefits some internal process-oriented team, not your customers.

There will be a day when you engage in gossip, and later regret it.

There will be a day when you are jealous of a coworker’s achievements, or intelligence, or promotion.

There will be a day when you engage in office politics, and later regret it.

There will be a day when you say something intended to be funny, and instead it comes across harsh, and you realize that you’ve hurt a coworker’s feelings.

I Feel Your Pain

I know, because I’ve had every single one of these days. Some of them I’ve had lots of times. Granted, I’ve been programming, and leading programmers, for over 30 years, so I’ve had ample opportunity. But I’m convinced that there isn’t anyone who works in a business environment who hasn’t experienced most of them, and doesn’t have their own list as well.

The myth of business is that we are supposed to hide all of these difficult feelings. That it is unprofessional to bring emotion into the workplace. We should stuff those feelings deep inside, deal with them ourselves, decompress with our spouses and Netflix after work, and maybe go to HR if something gets too bad. Or, the testosterone-fueled alternative, argue every point like it is a battle to the death.

The truth is, if we are willing to be a little bit vulnerable and human, even at work, we can handle these difficulties with relative ease and grace, and in a way that brings us closer to our coworkers. Yes, I just said “vulnerable”. You can do the easy thing now and throw up in your mouth a little bit, close the tab, and forget you read this. Or you can hang with me for a minute. We can actually improve our own, and our team’s, performance in the process.

I’m not suggesting that you should melt into a puddle of tears or start pounding desks the moment something goes wrong. Not at all. That isn’t going to help you, and it will just spread the burden without solving anything. Nor do I think you should run to your manager with every complaint.

Instead, let’s look at a brief, lightweight process for handling a bad day and getting back to productivity. I wish someone had told me this a long time ago, because I spent at least the first 20 years of my career doing it the hard way.

Caveat — First World Problems

While I think being human and vulnerable is generally good advice, the suggestions I have below might not be appropriate if you dig ditches or clean houses for a living. They are fairly tailored to white collar office workers, especially knowledge workers like engineers, designers, etc. that have a fair amount of autonomy, leverage, and control over their time. That’s the world I know best.

Step 1 — Move Your Body

Assuming your job gives you this much flexibility, take a break and radically change your physical environment. Go for a walk, lift weights, do some deep breathing, go to a yoga class at lunch, hit the sauna at the gym, plunge yourself in ice water, whatever. Sometimes this is all it takes! Our minds are deeply, profoundly affected by our bodies. You might find that after a good sweat, the whole problem has evaporated. If not, at least you’ll be energized and creative in dealing with it.

Step 2 — Think It Through

Now is the time to check in with yourself. Can you clearly identify what emotion you are experiencing? Is it anger, sadness, fear, anxiety, shame? Particularly if it is anger, is there something else beneath it? What button is getting pushed for you? Where do you feel it in your body? Is it reminding you of a problem you’ve experienced in the past?

Ask yourself, “Is there a part of this problem that I’m blaming on someone else, but actually I own some or all of it?” For example, maybe you are pissed off because you are being asked to move your office or change projects, but really it is the right thing to do and you are just feeling resistant to change. Or maybe you feel attacked by a coworker, and you legitimately want to address how they spoke to you. But there could still be a kernel of truth in their criticism that is worth acknowledging.

Step 3 — Get Support

Particularly if your emotion still feels hot, you might want to talk the situation through with a trusted friend. That could still be someone at work who isn’t too involved in it, or it could be a pal or significant other. You’ll get the most out of this chat if you don’t just use it as a venting session. The temptation is to just get them to agree with you about how aggrieved you are. More useful is to think of it as a dress rehearsal for how to address the problem directly. See if you can listen to yourself talk about the problem, and hear where you are being honest and where you are being defensive.

Step 4 — Talk It Out

If you’ve done those first three steps and it feels like there is something left to handle with the person you have a problem with, now you are ready. Don’t try to plan the whole conversation and work out all your arguments. It won’t turn out the way you planned, and you’ll probably end up madder than you started.

Instead, work out just the first thing you want to say, and phrase it in terms of an “I feel” statement, and take responsibility for any part that you can. For example:

“I felt hurt that in the standup meeting you said I’m putting the project behind schedule. I know I’m a couple of days late, but I also thought you would trust me to come through, or at least talk to me privately first.”

“Looking back at our one-on-one, I think I might have pushed too hard for the solution I believe in. It looked to me like I didn’t so much convince you, I just used my power as your manager to win the argument. I feel embarrassed about that, because I respect your opinion. Can we start over and help me really see your perspective?”

“I know you asked me to work on Project X, but I really feel a strong urge to wrap up my current project, both for the customers and my teammates. Does that make sense? Maybe that is really misguided. Can you help me understand why I should switch right now?”

“I feel terrible that I teased you at lunch. I was just trying to be funny but I saw that I hurt your feelings and I’m really embarrassed about it. I like working with you, and I hope you can forgive me.”

When you read these examples, do you feel a flush of embarrassment? Would you rather pull your own tooth without anesthetic than say them? Good! That’s a totally natural reaction.

Here’s what I can tell you: it isn’t as hard as it seems, and it gets way easier after you try it a few times. Think of it as the same kind of courage you need to summon in order to ride a roller coaster or take an improv class: it might be scary as hell but it isn’t actually going to hurt you, and you’ll probably feel amazing afterward. This kind of vulnerability is just a skill like any other, and you can totally develop it, and you can help other people do it it too.

What’s the worst that can happen? Sure, the person you are talking to could be rude, dismissive, angry, etc. I can only remember that happening maybe once out of the many times I’ve had these kinds of conversations. You haven’t really lost anything even if this worst case happens. You still have all the options open to you: go ahead and get mad, or quit, or talk to HR, or whatever you feel you need to do. Nothing lost.

But much more likely, you’ll end up having a connecting conversation. The person you are talking to will probably be expecting a fight, and when you are gentle and open with them, you’ll totally disarm their anger. Give them some space to process and tell you their feelings as well, agree on a new path together, and odds are you’ll have totally changed the terms of your working relationship going forward.

One more parting thought. If these ideas interest you, I highly recommend Brene Brown’s book, Daring Greatly. It solidified for me the role that shame plays in our lives, how big it looks, and how easily it withers in the sunshine.

If you are facing a challenging work situation and want to talk about it, or if you try the process above and it works (or doesn’t!), I’d love to hear about it in the comments below.

Michael Natkin has spent the last 30 years building movie dinosaurs, shrink-wrap software, cookbooks, and sous-vide cookers. He was mostly recently CTO of ChefSteps. He’s currently looking for his next role. He’s also written more words.

If you are like me, when you ship a software product or a feature, you’re filled with optimism. There are a million good ideas, so I’m always working on the one that I think our customers will love the most. When I ship it to them, I’m convinced it will be a game changer. Surely crowds of adoring fans will be smiling from ear to ear and sharing the love on social media within hours.

That does happen. But rarely.

Far more often, you are going to hear from detractors. They are going to tell you that the UI is confusing, the design is hideous, they are running into bugs, it is too slow, it is killing their battery, it would be AMAZING if it only had THIS ONE FEATURE, and that you are ugly and your mama didn’t raise you right.

This is great.

Don’t get me wrong — it can be discouraging to get this kind of feedback, especially early in your career. The trick is to start hearing it like this: “I want to love your product.”

The worst post-launch response is crickets and tumbleweeds. If no one cares enough to even criticize what you’ve built, you really do have a problem. You should take a big step back and figure out why you appear to be shouting into the void. If you are lucky, it is just a PR problem and you need a bigger microphone; more likely, no one is responding because they simply aren’t interested. In that case, it might be time to move on.

But let’s say that something great has happened: you’ve gotten a ton of feedback, much of it negative. Now the hard, meaningful work starts, and this is what separates the pros from the wannabes. No good deed goes unpunished.

Accept that you aren’t smarter than your customers or your community. If they all agree that a certain problem is the crux, then they are probably right and you should focus on that. If they all use the product in the same “wrong” way, it is the product that needs to change, not them. More often, there will be a long tail of smaller usability issues, and having the persistence to iterate and refine as many times as necessary will turn your rough-around-the-edges product into a valuable asset.

Often there is feedback that can shade into trolling and ad hominem attacks. Perhaps you are right to ignore these more hostile responses, but try to put aside your ego for a minute and see if there isn’t something important to learn behind the angry words.

I’ll give you an example from when I worked on Adobe After Effects. I spent more than nine months building the first version of Javascript expressions in AE, which allowed artists to write a few lines of code and create complex motion effects that would take hours or days to arduously keyframe by hand.

A lot of the feedback was constructive and actionable, for example, “I need a way to convert my expression to keyframes,” or, “I’d use this every day if only it could be attached to layer masks.” With each passing version of AE, I added more of these features and helped more customers to achieve their vision and complete their work with less effort. Each improvement might have seemed minor, but I tried to visualize the thousands of animators who were able to produce art they were proud of and leave work a little earlier to spend time with their families. The same is true at ChefSteps. When we make our site or app or chatbot better, it means our community is eating and cooking better.

However, not everything about the expressions launch was rosy: bringing even simple programming into an artistic tool was polarizing. Some artists felt threatened, as if this technology detracted from their skills or that engineers were going to take their jobs. This was never close to the truth. Expressions are just another paintbrush in the quiver; there are super successful After Effects artists who use them on every project, and others who haven’t used them once.

Still, it stung to read the complaints on the boards and forums, and that made it hard to see that there was valuable, actionable information in those hyperbolic reactions. What these users needed, I realized, was a network effect: artists who built useful expressions should be able to share them as reusable presets that others could apply without understanding (or even having to see) the code. For various technical reasons, I only partially succeeded at creating this preset system, but even so, terrific community websites popped up to share useful expressions. I believe that if I had fully engaged with that feedback and put the effort into making it easier to share and reuse expressions, this could have turned into a vibrant marketplace.

When we launched Joule at ChefSteps, we frequently heard, “This is amazing! My burgers came out better than ever. If only you had a guide for venison!” Replace venison with cauliflower, sea slug, and Ukrainian pickled goat milk, and you can readily see the problem.

The easy way out would have been to say, “Welp…we can never produce guides for the endless long tail of foods. It would be too time-consuming and costly. Don’t they see that?” Instead, we took a step back and realized that if we didn’t insist on having highly produced video content for every item, we could support our customers by adding sous vide times and temperatures for hundreds of less common foods much more rapidly. We released this new “slim guides” feature recently and can already see that it is solving a major pain point.

But we won’t stop there. As amazing as our kitchen and content team is, there will always be community members who know more about a given ingredient or recipe, so we’ll inevitably attack the complex problems of user- generated content. Refusing to be discouraged by complaints — indeed, seeing them as compliments in disguise — is going to make Joule vastly better.

So there you have it. If people love your product, great! If they hate your product, great! If they ignore your product…panic.

Michael Natkin has spent the last 30 years building movie dinosaurs, shrink-wrap software, cookbooks, and sous-vide cookers. He was mostly recently CTO of ChefSteps. He’s currently looking for his next role. He’s also written more words.

Stop Freaking Out: Negative Feedback is your Northstar was originally published in ChefSteps on Medium, where people are continuing the conversation by highlighting and responding to this story.

It is a seller’s market for software developers right now. If you can write code, many companies out there are looking for you. It seems that a lot of programmers look at that fact and draw the wrong conclusion about how they should go about finding a job. They will apply to a bunch of companies, trying to find one with a short commute or a nice ping-pong table, or a place where they can use the particular shiny software stack they have fallen in love with. Or they will apply for positions they don’t have nearly enough experience for, hoping to find a company that will take a chance on them.

This approach will absolutely land you your next job.

It won’t be the best job you can get.

The best job you can get is at a company where you will love to come into work everyday, because it has a mission which aligns with your interests and values, a culture that suits your personality, and products you think are great. You should be able to see both how you can contribute right away and what you believe you could learn — not just about technology, but also about business and the application domain. Growing in your career takes hard work over the course of years. Starting with a great fit will sustain you through the good times and the hard ones.

Once you’ve chosen a company to focus on, learn as much as you can about them. Read everything you can on their website, especially the about page and jobs page. Read about their products. Read their customer forums. Read blogs by their prominent employees. Check out their social media. See what other people are saying about them. Use your network and see if you can have an informational coffee with a current or former employee. Doing this research will both confirm for you that you’ve chosen the right company and arm you with the information you need to apply and interview successfully.

Then, make sure the job is a realistic match for you. If you have only been programming for a few months, even in an intensive programming school, don’t apply for a senior full-stack developer role. You aren’t ready yet; it takes time — and experiencing the long-term consequences of your coding decisions — to learn what you don’t know. Instead, take an entry-level position where you can learn from people who have shipped a lot of products. Work your butt off, be humble, and learn everything you can, and in a few years, you’ll have a much wider array of options for your next position.

Next, take the time to do the basic application well. Have a nicely formatted resume. Write a cover letter that shows you’ve done your homework. Good lord — don’t have freaking typos in it. Don’t puff up your skills or make it sound like the company has been lucky to survive this long without you — that is for them to decide! In the past, it was considered good form to fill your cover letter with boasting and bravado. I don’t know if that works at, say, a hedge fund, but it isn’t going to work in software. Just lay out succinctly what you’ve concretely shipped in your career so far that shows you are a great fit. Have a friend, preferably a good communicator, read your resume and letter over for both errors and tone.

Congratulations, your resume made it past the first level of screening at the company of your dreams! If that company is ChefSteps, I’ll be sending you a set of email questions to give me a basic sense of how you think about the world and how you code. I get a lot of responses that are obviously dashed off with little thought or care, so let’s talk about how to stand out.

Perhaps you’ve heard the expression “How you do anything is how you do everything.” I don’t believe this is literally true; not everything in life is worth crushing, but if you do the minimum when you do something as important as apply for the job where you will spend a large percentage of your waking hours, I have to assume you will do the minimum when you are on the job as well.

Sure, if you are applying to develop web services and your last role was on the core team for Amazon Web Services, or you want to work on an iOS photography app and you just left Instagram, your job history may be all you need to land the position. Strong open-source contributions can also make the case. But if you have set your sights high and your past experience alone doesn’t clearly demonstrate that you are skilled enough for the job, the best way to make up for that is to go above and beyond with your application.

I ask a very simple programming question in my email screen. There are two fantastic people on the team here at ChefSteps who answered that question by deploying web apps complete with fully functional and attractive frontends. They could have answered correctly with just a few lines of code, but they realized that going for “extra credit” would both show their interest and skills and make them stand out.

The particulars will vary from company to company, but I guarantee you that putting 100 percent effort into a small number of applications is a much better way to find a job you will love than putting 50 percent effort into lots of them.

Remember: you have the great fortune that the thing you love to do is in very high demand right now. You can be choosy. Take advantage of that opportunity!

Michael Natkin has spent the last 30 years building movie dinosaurs, shrink-wrap software, cookbooks, and sous-vide cookers. He was mostly recently CTO of ChefSteps. He’s currently looking for his next role. He’s also written more words.

If You Want To Land An Awesome Job, Do An Awesome Job Of Applying For It was originally published in ChefSteps on Medium, where people are continuing the conversation by highlighting and responding to this story.