Building a better salesperson

My first tech job was with a regional VAR (value added reseller). I started in phone support, then moved up to bench tech, then to field engineer – a path that increased my exposure to customers and the rest of the business with each move.

I liked the technical work and helping people with their problems, but as I began to notice the sales engine that was at work around me, I started to dread coming to work.

Over time my reaction to the projects the owner and salespeople would bring to me went from “Yes, I’m on it!”, to “Huh, this is kinda weird.”, to “WTF is wrong with you people!?”

I found myself having conversations like:

Me: “Yes, we could upgrade every part in the customer’s PC, but wouldn’t it be better and cheaper for them to just buy a new computer?”

Salesperson: “Just put in the upgrades. It’s a big sale.”

Owner: “Go to their office, install this drive, and setup backups for them.”

Me: “Umm, we’re selling this? It’s 3 years old and the box is covered in dust.”

Owner: “It’s what we have in stock.”

Me: “But these things are worth like a 100th of the price on this invoice.”

Owner: “They don’t know that.”

Salesperson: “Can you look over this bid for these school lab computers?”

Me: “Why are you putting $1000 video conferencing codec cards in them?”

Salesperson: “Because we already have them and the grant allows it.”

By the end, I wanted to burn the building down with everyone locked inside. At the time I thought my experience was unique, that my employer was just particularly evil.

That was, of course, stupid. I was new to the workforce and naïve. Working for that VAR gave me the first insight into a cancer that is easily spread into any sales org.

Cracks in the system

Sales is an important job and I have met some amazing salespeople who are both good at their job and good at being decent humans. But sales is usually a pay for performance role which has inherent flaws, at least in the way it’s structured for most companies.

Quota-driven motivation tends to isolate the salespeople on a team and can lead to acts of desperation. Even some team-based quota models drive a culture of “every man for himself” that can never end well.

Traditional quotas recreate the cutthroat conditions of a medieval bazaar and living day-to-day in a system of “I must sell five more goats or my family will starve.” has an effect on the morality and judgement of an individual. How can it not?

I feel sympathy for people stuck in this situation. They have mortgages, kids to feed, whatever else and they feel like they don’t have the convenience of always fighting to do the right thing. It’s a crummy place to be – to have a moral compass and not be allowed to follow it.

In general, I find performance-based compensation off-putting.”You sell more, you make more.” makes sense and works pretty well on a small-scale, but crank it up to multi-million-dollar-mania levels and you’ve self-selected for a certain psychology.

The worst of humanity reveals itself when you put a bunch of people in a room who tie their level of effort to how much money they make. Extrinsic motivation is the stuff of pyramid scheme tycoons, politicians, and serial killers.

The status quo is ugly

On the customer side, I have multiple conversations a week that go a little like this:

Me: “In detail, here is the problem I am trying to solve. Could your widget help fix that problem?”

Salesperson: “Yes!”

Me: “So your product can cure cancer, solve world hunger, and keep our network free of viruses?”

Salesperson: “Yes!”

Me: “Do you understand anything that I’ve said?”

Salesperson: “No.”

Me: “And you still think your widget is the right solution for me?”

Salesperson: “Yes! It’s what I’m getting the highest comp on this quarter.”

I can’t express how frustrating this is and how much this sucks, especially when the person has swaggered in presenting themselves as a trusted advisor.

Customers need honest answers and guidance. They need help, even if it’s in the form of “Hey, I don’t think our product is a good fit for this problem.”

If you’re a salesperson who wants to build trust and a long-term pipeline that practically vomits money, be willing to walk away from a sale that doesn’t make sense. Spouting half-truths and outright lies may work in the short-term, but it’s a clichéd path that leads to gold chains, cocaine addictions, damaged relationships, and early heart attacks.

Personally, I respect the heck out of salespeople who tell me “no” and “I don’t know.” I will go out of my way to seek them out for future projects even if what they’re selling costs double the competition. I’ll come back to them when they change jobs and do my best to always take their calls.

A better path (maybe)

Being honest in sales requires a company culture that allows the person to be honest. The dude-bro, hyper-competitive environment that many companies create for their salespeople is not that. Quotas don’t support that, neither does performance pay. All those things box salespeople in and make them feel as if they have to lie, cheat, and steal to keep their job.

How about this:

  • Pay salespeople a good, fixed salary based on their skill and experience.
  • Get rid of sales quotas and replace them with other metrics like customer satisfaction and product usage. These are imperfect measures as well, but have a longer-term focus.
  • Manage salespeople like everyone else. If there’s a performance problem, coach and support them. If that doesn’t work, help them move on to something else.
  • Hire people who are motivated to do a good job because it’s the right thing to do, not because they want/need to chase carrots.

What about the salespeople who need the carrot? The ones who love the game, and are going to shuck and jive even when they don’t have to.

Honestly, eff those people. That’s not a personality trait that helps move humanity forward or builds a solid foundation for a business. If they can’t adapt to a healthier culture, they can go pound sand.


In pursuit of a modern password policy

The phrase “convenience shouldn’t trump security” sounds good. It carries the weight of authority, of someone who is taking a stand to do the right thing, and in most cases they are. Problem is, outside of a high security setting, inconveniencing users tends to make things less secure.

The classic example: An IT department implements a high complexity password requirement. Numbers, letters, uppercase, lowercase, symbols, all that jazz. Policy in place, IT tells management “We’re more secure” ignoring the fact that most users are now writing their passwords down on sticky notes and putting them under their keyboard.

Someone from security will go around and occasionally wag their finger at users telling them they are stupid for writing their password down. Users will momentarily stop writing down their passwords, password reset calls to the helpdesk will spike, and then users will go back to writing down their passwords. Rinse & repeat, over and over again.

“$p4rkY_&bT” is more difficult to crack than “Bobby” and the corporate-wide use of complex passwords guards against certain kinds of attacks, but opens up doors to other attacks – like a disgruntled coworker staying late, flipping everyone’s keyboards, and using their password to metaphorically burn the business to the ground, which is a much more likely scenario than scary internet hackers trying to brute force crack end-user passwords.

Most businesses gravitate to a standard password policy that’s based more on culture and audit compliance than real world efficacy. It tends to look like:

  • 8 character minimum
  • A mix of symbols, uppercase, lowercase, and numbers
  • 90 day expiration

In certain contexts, this is absolutely the right policy, but it is the wrong fit for most. It’s based on outdated assumptions: that the most common threats are external, that stale passwords are a common attack vector, and that a blanket policy is best. Here are some different approaches.

Passphrases, vaults, and pins

It’s no longer novel to use passphrases (strings of words, usually 16 characters or more) instead of passwords. An XKCD comic from several years back helped popularize their use and highlighted their strength versus traditional complex passwords. The technical advantage isn’t as much as it once was as cracking tools evolved, but the ease of memorization remains.

“popcorntreefortunicorn” or “thereisacowinmyfrontyard” are both easier to remember than a complex string like “4_%Ca*f2(k” and less likely to be written down or forgotten.

Using a password vault like 1Password is a better option in general, as it allows you to still use complex passwords and not have to remember them, but user adoption and support keep vaults from gaining widespread use in businesses – vaults are hard to scale. Depending on your user base, passphrases may remain the better option.

The future of authentication is being driven by mobile and largely does away with passwords. Windows 10 supports secure-pin login that functions much like an iPhone. A short pin number (or biometric signature – fingerprint, face recognition, etc.) can be encrypted and stored on the local device on a dedicated, secure chip. Plugging in the correct pin unlocks the device and from there, authentication to different apps and services can be claims-based, using a standard like SAML or FIDO. Usernames and passwords may need to be occasionally re-entered to refresh an authentication token, but day-to-day, users won’t be typing in many passwords.

The pin only works with local login, so if the pin is compromised it can’t be used remotely.

What about expiry? Everyone hates setting up a new password every three months. Expiry breaks apps tied to service accounts and drives end-user helpdesk calls. So why do we force passwords to expire several times a year? Because reasons?

There’s no good reason to expire passwords every 30, 90, or 120 days. It’s not an effective countermeasure, it just causes problems. If an attacker gets access to corporate passwords, they aren’t going to sit on them, they’re going to use them almost immediately, or sell them to someone who will. The threat of stale credentials isn’t a real thing and luckily, there are now government agencies and standards bodies stepping up to the plate to say so.


No password policy can keep passwords from being compromised, especially when applied to humans. Multi-factor authentication helps though and is no longer optional. Using a soft token app on a device secured by biometrics (think fingerprint locked iPhone) as well as a password is an easy way to boost your security posture.

Multi-factor tools aren’t as difficult to manage as they once were. Solutions like Duo and Yubikey are simple to add and companies like Microsoft and Okta are building multi-factor directly into their product suites.

Right now, the most popular methods of multi-factor auth are biometrics (fingerprints), tokens/certs (Yubikey), and SMS. Challenge questions are on the way out. They face the same issues as passwords and can be compromised using the same method. From a support perspective, if a person can’t remember a password, they are probably going to have issues remembering the answer to a challenge question.

Behavior will be the next big thing in multi-factor auth. Behavioral analytics tools like Exabeam can be used to create risk profiles for user activity and trigger actions based on risky or out of the norm behavior. Geo-fencing is the simplest form of behavior MFA – “Are you logging in from somewhere you aren’t normally, like southeast Asia?”

As these tools develop they’ll be able to look deeper into the actions performed with each app a user logs into and match them to a threat profile.

“User (based in Minnesota) logged on from the UAE, downloaded 4 gigs of data from Box, then sent e-mails with attachments to several blacklisted countries.”

“Something you do” is being added to the authentication triad of “Something you are, something you have, or something you know.”

Context and controls

End users and administrators should not fall under the same authentication policy. They are not operating in the same context and have access to different resources.

Following a policy of least-access – meaning users only exist in the systems they need and only have access to the minimum functionality necessary goes a long way toward beefing up security. Paired with separation of duties, these soft controls are often more effective than a strong authentication policy.

Effective controls allow you to give your end users an easy-to-live-with password policy that matches the scope of impact. They can also guide sane password policies for admin users, who should have an easier time dealing with password vaults (like Thycotic or 1Password for Teams – Seriously, don’t use a spreadsheet.) and more strict MFA requirements.

If you’re worried about brute force attacks, lockout policy is far more effective than password complexity. Some businesses lock out with as few as 3 incorrect passwords, which is a bit too few, in my opinion. Settling around 10 or so feels more appropriate. If a user needs 4 attempts to login to get it right, maybe they are having a bad day. If they need 11, they’re either an idiot or someone malicious.

So what’s a modern password policy look like?

How about this:

For users

  • 14 character minimum, no complexity but common passwords like Password123456 are blacklisted
  • MFA required for off-network access and for critical apps
  • No password expiry
  • 10 attempts before lockout

For admins

  • 20 character minimum (or highly complex)
  • MFA required for all access
  • Yearly password expiry
  • 5 attempts before lockout

My goal isn’t to prescribe – everyone’s needs are different – but I do think it’s important to question established wisdom. If your team never revisits the “why” of things, they’ll always be protecting against the attacks of the past instead of what’s coming.

Image Credit: marc falardeau

The shape of networks to come

At last year’s Cisco Live, I sat in a room full of network engineers and architects who were openly hostile to the Cisco marketing person presenting to us. We were talking about control systems, the Internet of Things, and the networking needed to tie modern technologies together.

The presentation was basically “just buy more traditional route/switch gear and you’ll be prepped for this brave new world”, to which the audience almost universally responded “Umm, no.”

I hate being sold to, but something else irked me. I reject the philosophy they were selling all-together – that the current LAN/WAN model will be the path forward.

Popping the stack

Compute is no longer tied to individual, physical datacenters. It has become cloudified – abstracted to the point that we only really talk about the app and automation layers rather than single VMs or even datacenters. Sure, those things exist in the stack, but we don’t really care about them as discrete objects.

Transport (networking), is following the same trend. Switches, routers, firewalls, whathaveyou – are part of the stack, but managing them individually is no longer desirable or sustainable. To adapt to the flux of compute and apps, the network layer has to be handled in software via fullstack policies, rules, and configurations that are independent of individual paths, devices, or locations.

This app needs to be delivered to this user where-ever they are at, across whatever transport is available.

That’s the promise of software defined networking and the death of the LAN as the center of the universe. If we’re defining fullstack access policy and tying it to the identity and rights of each user or resource, the LAN (and WAN, to some extent) is largely dumb plumbing being assembled and re-assembled by software.

Centralized ingress/egress becomes less relevent as well, especially when host-to-host connections are built and policed dynamically. Host and platform-based firewall/IDS/IPS are able to adapt more effectively than centralized, monolithic solutions in this scenario.

VMware’s NSX is a good example of this model (at least in this transitional phase…). Assign an access policy to an app and it flows through the datacenter, across the WAN, and onto the remote device – all at an abstracted network layer that rides on top of the “dumb plumbing” referenced above.

Viptela, Silver Peak, Arista, and others (insert your favorite SDN startup)fit as well – Here are some diverse circuits, here’s the SLA for each application.  You figure it out, software.

Going forward, I no longer care about LAN or WAN – I care about data, software, and identity.

The Everywhere Network

Traditionally, if you want to build a corporate network, you order an expensive circuit from a carrier, put an endpoint like a router or firewall on it, and then build out an enclosed space behind it for trusted devices. If you want two or more locations with trusted devices to communicate with one another, you start looking at technologies like VPNs and MPLS to glue everything together.

If you want resiliency, you order more circuits and create multiple paths for your network traffic. Then you setup dynamic routing protocols and say “Perform! Self-heal! Abracadabra!”

That model, while somewhat flexible, is physical, cumbersome, and geographically pinned. It requires that IT staff wrap ever more complex and onerous controls around the network and attached devices, expanding their attack surface in an attempt to control their attack surface.

It’s a model that will continue to exist for the foreseeable future but will be pushed further and further upstream, into the domain of carriers and service providers, following the same path as compute.

A possible and, in my opinion, likely, future of the access network is one that is omnipresent and largely untrusted – a mobile, shared access WAN that obviates traditional network boundaries and segmentation.

Carriers and OEMs are testing 5G cellular network tech as I write this. It may be that 6G or 7G need to come into play before client access changes wholesale, but the progression seems natural to me; assume that the new, ubiquitous network is unsecure, collapse the security domain (reducing the attack surface) to account for that, and implement tech and controls around data, apps, and identity.

Given that direction, classical network management becomes less of a thing on the customer side and evolves to be more service provider-focused. But just like cloud compute, the corporate default will be to fallback to simpler, base network configs that serve as a underlayer to a virtualized, app-driven topology and to consume transport services rather than building and maintaining them.

This assumes that even the corporate network will be common utility rather than a proprietary diamond. (It also assumes that encryption doesn’t become illegal.) All technologies glide along the slope from rare to commodity – some take longer than others. There is no reason networking won’t follow this arc.

Photo credit: Screenpunk


A whisper and the scent of blood woke it. The blood was simple, uncomplicated. The whisper, more complex, spiced with fear, anger, sorrow, acceptance. Both trickled downward into the earth.

“Help me.”

It was spread thin and pieces of it refused to come when called, empty of life or gone wild in isolation. What returned came slowly. Hours passed as it collected enough of itself to remember what it was. The blood it smelt had long since dried, forming brittle roots and rivers that would be broken and scattered by the wind. Only a memory remained of the whisper, but it was an anchor to pull itself from deep dreaming.

It rippled across red stone and scrub as it searched. The air bent and flowed around it – liquid heat dripping upward into the sky that did not burn except what it chose to. It was colorless fire.

The djinn found the woman’s ghost in an arroyo where she wept over her corpse.

The body was wrapped in a rough Navajo blanket that had partially opened, revealing leathery skin and blonde hair burned by harsh bleaching and failed attempts to recapture youth. Her flesh was covered in dark bruises and angry wounds.

Insects scurried away as the djinn approached and the carrion birds circling above sang an ugly song. In the high heat of the day, the ghost shivered from the painful cold that follows the dead. The djinn surrounded her with its warmth.

She wept into the night and through the next day, fully consumed in her grief. It wasn’t until the following sunset that she considered her companion.

“Where do I go now?”

The djinn expressed uncertainty, nothingness and wholeness, a sky bright with stars, an empty void.

The ghost laughed, a dry bark filled with anguish. “No answer even now, huh? Well, I don’t think I could go anywhere anyways. Feels like something’s got its claws in me.”

The djinn did not respond and the ghost stood by it silently until the moon was bright and high above. When she looked towards the djinn again it was a pulsing, black star darker than the night around it.

“I don’t exactly know what you are and I figure I ain’t got no right to ask favors of you regardless, but I’m going to anyway.”

She climbed to the top of the arroyo (the djinn followed) and pointed to lights glowing in the east, then back at the body lying the dried stream bed.

“I want justice. Can you give me that?”

For the first time in five-hundred years, the djinn spoke. Its voice seemed to come from all directions and filled her mind with fire.


She began weeping again and collapsed to the ground, holding her knees tight to her chest. She rocked and sobbed, not noticing the fire light building around her. The light had reached is peak and was fading when she discovered that she felt lighter. The bonds holding her to her body had been seared away.

She turned to the shadow beside her. A soft glow pulsed from deep inside it, but soon went dark.

“I am cleansing fire, the mercy of the desert. I give you both.”

And the ghost was gone.

The djinn enveloped her body and burned it to white ash, then turned toward the eastern lights.

A highway that had once been busy with travelers split the town in half, following the path of an older, more powerful road that no humans had ever walked. Its asphalt was being devoured by time and wind.

Signs welcoming visitors to the town lay buried and its name no longer appeared on any maps. It had once been an oasis where travelers and creatures of the desert quenched their thirst, now it was an ugly wound.

The djinn moved among trailer homes and eroding buildings of cinder block and brittle, dry wood, and took notice of the life present. Only a few dozen still lived here – those too old, stubborn, or hopeless to leave. The whole valley stank of their despair and regret.

It entered a home where an old woman slept on a broken-footed couch. The floor was cluttered with liquor bottles and cast-aside romance novels. She snored loudly and exhaled alcohol fumes.

The djinn’s presence filled the room with uncomfortable heat that woke her. Disorientation and confusion gave way to terror as the black shadow surrounded her, but her scream was stopped short as understanding and calm flowed through her. She smiled sadly.

The home began to burn in merciful, silent inferno.

It visited each of the town’s inhabitants in slow succession. None resisted the djinn, several never even woke as they burned away.

By sunrise the entire town was ash and puddles of cooling metal. What remained would be hidden by sand in a few days’ time.

The djinn was diminished now, a thin, weak flame. It had covered whole valleys in waves of fire in younger days, but that power was gone now, drained away over long millennia.

It harnessed the wind to dig a pit underneath the shade of a twisted acacia tree and reached down into the earth to pull up water from the deep aquifer that had fed the wells of the town.

The pit slowly began to fill with cool water.

It looked across the dry expanse for the last time, then the cleansing fire of the desert flickered once and went out.

VMware’s Cloud Adventure

I like VMware. They’re a solid company with lots of good people (With the exception of whoever is responsible for product names – VMware vCloud Air Virtual Private Cloud OnDemand? Seriously, what is wrong with you?) and tech.

I’ve been using their products for fifteen years and still remember how magical it felt the first time I loaded VMware Workstation and had Windows running inside of Windows. I remember calling someone over to my desk and telling them “Look how cool this is.” I also remember them saying “I guess, but what would you ever use that for?”

Today, you’d be hard pressed to find a corporate datacenter that isn’t running some piece of VMware tech. They took virtualization mainstream, and built the foundation of the cloud tech that everyone is using today.

Misdirected myopia

Unfortunately, the world that they built is now eating them. Hypervisors became commodity, where “good enough” is an acceptable target. Hyper-V, Xen, KVM: they all became good enough for ecosystems to be built around them, followed by orchestration and the “cloud”.

VMware seemed completely oblivious to the scale and pace of what was happening. They sat on the sidelines while the world they helped build was being transformed. Maybe the thought was “This cloud stuff is for startups who
will grow into our enterprise products once they get tired of playing with toys.” or “Enterprise customers will move to the cloud… in twenty years.”

Sort of like Steve Ballmer’s “There’s no chance that the iPhone is going to get any significant market share.”

Too late, too little

Amazon launched AWS in 2006. Microsoft launched Azure in 2010. VMware vCloud Hybrid Service (now vCloud Air), didn’t launch until 2013 – seven years after AWS, fourty-nine years in dog/tech years.

Given their late entry, they took some shortcuts. Instead of building a native cloud platform from scratch, they pushed their on-premise, datacenter products into the cloud. That sort of works, but only at a very base level. It is heavily reliant on legacy VMware tools for management and orchestration. It doesn’t scale. It requires specific web browsers and plugins.

It isn’t cloud. It looks a lot like what would happen if a VP went to a tech conference, then came back to the office and told their engineers “Everyone has a cloud. We need a cloud. BUILD ME A CLOUD!”

Pointy-haired boss is the reason we can’t have nice things.

But it started getting better in hiccuping bursts. They added DR options and Database-as-a-Service. They stripped out a truly terrible VM backup solution. The people who’ve worked on vCloud Air should be proud of that.

Cutting losses

Then during yesterday’s VMware earnings call:

“CEO Pat Gelsinger said the service (vCloud Air) will have a “narrower focus” going forward and that money invested in it already is considered “adequate for our needs.”

In other words: “vCloud Air is dead.”

What we’ll probably see

vCloud Air might have been able to carve out a significant niche if it had been:

  • a) built as a cloud native platform or
  • b) given more focus.

But that didn’t happen, so it’s probably OK for it to die.

The biggest use case that VMware seemed to be addressing was DR – the “we need somewhere else for this stuff to go” problem. vCloud Air, especially under its original “Hybrid Cloud” moniker, mostly existed as a remote target for the tools you were already running onsite.

So we’ll probably see VMware do two things that they’ve been alluding to:

  1. Expand options for leveraging third-party clouds like AWS, Azure, and Google from within the vSphere and vCloud Director toolsets – for burst and DR.
  2. Refactor existing solutions like ESXi and Horizon to work on third-party clouds. They’re already doing this successfully with their NSX virtual networking product.

Both of these paths help VMware customers get into the cloud, but I’m not sure they’re good for VMware in the long-term. Once a customer is running in the cloud they’ll start asking “We’re here now. Do we really need these legacy toolsets anymore?” In many cases the answer will be “no”.

There’s a hybrid datacenter->public cloud model that VMware can succeed within, but that market will only get smaller as businesses replace applications and go directly to the cloud.

What do?

The onus is on VMware to make their tools more flexible, powerful, and compelling than the tools that AWS and others are building in-platform. If they can narrow and re-direct their focus on future needs (where the puck is headed), and think about cloud in a broader, multi-vendor context they might be able to.

They’ve already started that with containers. Docker orchestration platforms like Kubernetes and Mesos are still rough around the edges and there is room in the space for VMware to get in and leverage the benefit of their size and engineering bench.

Server-less code platforms like AWS Lambda will compete with container-based workloads. I hesitate to say that VMware needs to be in that space too, but it would be worthwhile to consider that containers are not the only future. Going 100% in on containers seems prone to getting stuck in the rut of “follower”, as Microsoft has been until their recent turnaround. Envisioning and pursuing alternate futures is how companies lead and innovate, but requires having leaders who are comfortable with false-starts and failure – or deep pockets and lots of acquisitions(meh).

VMware is doing some great things with end-user compute(EUC) and is starting down the path of meaningful integration between Horizon, Airwatch, and NSX in the datacenter. The story they tell about EUC is compelling and coherent (unlike their cloud narrative). If they can pull off their plans for end-to-end security and consistent access to corporate apps and data across all devices, they will likely trounce Microsoft and other competitors in that space.

They have the pieces and the people – they just need a clear direction and internal consensus to move forward.

Image Credit: Zooey

Stop asking tech people to build your ideas

Sometimes people bring me ideas.

They say “I have this great idea for an app.” or “I have an idea for a tech business.” Inevitably, both are followed by “…and I just need you to build it for me.”

This is nothing special about me – it happens to most tech people.

I used to gracefully dodge with self deprecation or whatever else I could use to let the person down easy. In most cases I was being completely honest. IT is broad and few people realize just how broad and how many different technology skill sets there are.

“I just don’t know enough about that to be helpful. I’m not a developer, I do infrastructure.”

For the last couple of years I’ve started pushing back more, either by destroying the person’s idea or by encouraging them to take action on it on their own.

“You’ve just described Facebook. No, no…stop. Your idea is not different. It’s still Facebook even if you are calling it Gerbil Town. STOP!”

“You know what? That is a great idea. You should totally build that.”

Telling someone that they should act on their idea usually makes them a lot angrier than telling them their idea is terrible.

They say stuff like “That’s why I’m talking to you. I don’t know how to do this crap. I’m bringing this to you as a favor.”

And there’s the crux. You aren’t doing anyone a favor by sharing your idea with them.

Your idea sucks because it’s just an idea.

What you’re really saying to the tech person is “I don’t believe in this enough to even attempt to figure it out on my own. I’m just the idea guy (i.e. useless) and I want you to put in the effort that I’m not willing to put in.”

Learning to code (and most tech stuff) isn’t hard. Developers/engineers/etc aren’t (generally) genius wizards, they just put in the work to learn a skill.

It’s actually easier to learn to code than it’s ever been and there are tons of great training resources like Code Academy and Udemy to help. Like most things, it’s mostly a question of dedicating time and effort – and you don’t have to become an expert, you just have to achieve “good enough” to get started.

If you’re truly passionate about your idea, you’ll make the time and put in the effort.

If you’re asking someone else to do it for you, that’s a pretty good sign that your heart really isn’t in it as much as you think it is. Ponder that. Is it fair to ask someone to be excited about an idea you’re not 100% committed to?

There are people who have pulled themselves out of literally sleeping in trash-filled gutters to 1.) learn to read, 2.) learn to use a computer, and 3.) learn to code and build their idea. And here you are, having just asked someone to commit their energy to something “kinda neat” you thought about while sitting on the toilet.

Even if you find someone willing to put in the work to build your idea (and it’s usually some idiot kid or well-meaning novice), you’ll own something that you don’t understand. Good luck with that.

Too scared to start

Maybe you really do want to do something, but you’re scared. You think “I’ll never be able to figure this stuff out.” or “What if I fail?”

  1. Shut up and start learning. It’s just work.
  2. So what? No one is going to die if you try to make your thing and it doesn’t work out. That’s a pretty good safety net.

Tech people have the exact same fears. We worry that we can’t figure out the business stuff or the biology stuff or the construction stuff, or whatever discipline we want to work with. Most of us don’t execute on our ideas either.

We all say “if only…” and stop.

I’m speaking as much to myself as I am anyone else. I constantly have to kick myself in the butt and say “Stop being stupid. Do the thing.” – Every day of my life.

If you build it they’re at least more likely to come

Great ideas and terrible ideas are of equal value until they are real. The value is in action.

Go do the thing. Build it, even if it starts out crappy. Just by existing it is infinitely better than the thing you never built.

You may discover on your own that your idea is terrible. Good for you. You learned something you can take into your next project. If it turns out to be a good idea and you put in the work to shape the skeleton of it, you won’t have to ask for help, because people will swarm to you.

Stop asking other people to build your dreams. Do it yourself.

Image credit: Tsahi Levent-Levi

Code should eat the world responsibly

I had a long car trip on Monday, past fields, factories, and construction sites on my way to and from a certification test. I passed semi trucks, delivery vans, and countless other cars with drivers all scooting along just like me, hands on the wheel, headed somewhere.

It all made me feel both excited and sad.

I thought about each of the businesses I passed and how each was being automated, either by pure software or robotics. There wasn’t much I came across that didn’t have the potential to be automated.

For those whose job involves driving a vehicle, they’ve got 5, maybe 10 years left before they start falling out of the labor market. Automated trucks will be lighter/more efficient (no cab needed), safer, and smart enough for most hauls. Human drivers won’t be able to compete against the robots.

Retail/service workers? We’re already seeing that happen. McDonalds has drink and cooking robots, you can bypass the front desk at hotels and check in(and unlock your room) with your phone, and I swear I haven’t talked to a human bank employee in at least 5 years.

Manufacturing? Just-in-time, custom manufacturing with 3D printers. Construction? On-site 3D printers, pre-built modules, and builder drone swarms. Police? Robocop.

It’s not science fiction, it’s here.


Automation is a net positive in terms of human progress – it’s enabling us to do incredible things with data, make more informed decisions, and build technology that overcomes our weaknesses and pushes the boundaries of our knowledge – but big social transitions like this one have consequences we need to account for.

In not many years, the majority of unskilled jobs (and many skilled jobs) will be gone and millions of people will fall out of the workforce. If you were able to adapt and are still working, your job will be unrecognizable from what it is today.

In the short term, taxi unions will continue to fight against Uber and Lyft, and they will lose. Uber and Lyft drivers will eventually be replaced by self-driving cars. Any group fighting against automation, doesn’t matter what, will lose. Their efforts are misdirected. Instead of fighting against change, they need to prepare for it as best as possible. We all need to.

It’s foolish to think your job or work product will always be needed. Always is a dangerous word, just ask the Neanderthals.

Marching Forward

Education is one path, but that’s not going to work for everyone. There is a skills gap, but it’s probably not big enough to absorb the number of people who’ll be out of work in the next ten years. That population growth is slowing down will probably be more helpful.

Artistry is another path. Becoming an artist or artisan is just as valid an option as being an engineer, at least if you actually produce work instead of buying paintbrushes and wood chisels – and then just talking about them. Eventually, there might be a greater consumer demand for uniquely human creations than commodity, tech widgets. These things work in weird cycles.

Some people won’t be able (not everyone has the same footing or access) or capable of adapting to the new world regardless of how badly they want to, and we’ll have to do our best to take care of them through the transition. The cost of retraining and social support needs to be considered in our technology and business models, otherwise the cost will be externalized (and not adequately addressed) and millions of people will fall through the cracks.

We don’t need to slow down innovation, we just need to think about innovation in broader terms. It’s not just technology and business, it’s systemic and social in the truest sense of the word. Building software is easy compared to the challenges of the whole system your software, customers, and employees live within.

Technologists need to think about the world our code, tech, and business plugs into, not just the technology and not just the business. We’re transforming the world and it’s our responsibility to make sure everyone has a place in it if they want it.

Image Credit: Peyri Herrera