Dumb Ideas Look Dumb Early On. So Do Great Ones.
Watching a Future Billionaire (or, Very Wealthy Person)
I once watched a future billionaire (or, at least, very wealthy person), put together his company booth at a show. It was modest, maybe enough room for a couple of people behind a desk, with a banner above it, a couple of computers set up to show the software. He was a few booths away from us , in the downstairs room of a conference center — a typical gig, a few dozen companies repeating their patter, running their demos.
His demo didn’t work very well. It was a slow, buggy and unconvincing show of streaming sound across the internet (yes, this was a while ago). I felt pretty smug. We were a public company at the time, I was on the exec staff, the stock was doing great, and our demos were on point — smart, fast and cool to look at. I felt a little sorry for him.
He turned out to be Rob Glaser, founder of Real Networks. He got streaming to work, figured out how to make a ton of money from downloads, went public himself, rode his stock up to insane levels and back down again to something more reasonable, and became Rob Glaser, internet v.1 pioneer.
The fact of the matter is that if you’re building something new you’re going to feel exposed, things are not going to work, and you’re going to look dumb, more than once.
The question is, should you keep going? When do you ignore the signals? When do you carry on?
Successful Things Can Look Pretty Dumb
The next big thing always starts out being dismissed as a “toy”
Clay Christensen vi Chris Dixon
A friend of mine ordered the original Tesla Roadster. When he was invited to try it down at the factory, he was appalled. “It’s tiny, clunky”, he said, “they’ll never learn to make cars”.
I reviewed youtube a couple of months after it launched, and decided that there was nothing to distinguish it from the dozens of other sites that were around at the time that did the same thing. It was dead simple, kind of clunky, slow…
“The first telephone could only carry voices a mile or two. The leading telco of the time, Western Union, passed on acquiring the phone because they didn’t see how it could possibly be useful to businesses and railroads — their primary customers” (this via Chris Dixon)
Early 3D computer animation looked incredibly limited: endless scenes of regular shiny objects sliding around worlds of flat planes.
It’s a little early to declare bitcoin a lasting success, but it looked pretty silly five years ago, and closed $9,000 over the weekend.
Dumb Things Look Pretty Dumb, Too
The first startup I worked for basically went bust trying to sell a cut-down version of its highly successful personal computer. The damn thing had almost no functionality. But it was cheap! It had to sell.
The Apple Newton weighed a lot, was unresponsive and hard to use. For a short period, people would point them at each other in meetings to try and exchange contact information. It was embarrassing.
The Segway. Juicero.
There are dozens of these: Google Glass anyone?
How To Tell The Difference
I’ve been lucky. I was around enough successes to observe a couple of pattens (I learned early on that my strength was in making other peoples’ visions actually work):
- if a product will benefit from a rapidly maturing technology, it won’t stay dumb for very long. Sound on the internet, the original iPhone, Tesla cars, many others, hit the development curve of fundamental technologies at the right time. Many others didn’t. The Apple Newton was conceptually correct, but off by at least at least a decade, probably more.
- if the product is solving a problem that nobody wants solving (Segway, Juicero) it will remain dumb.
People who have a deep and fluent understanding of a particular technology set can solve for the first issue. If you’re building something that demands a technological shift (batteries, bandwidth, deep learning), you’d better have a strong grasp of the fundamentals of why that shift will occur now, for you to have a business.
People who are willing to listen, deeply and carefully, to potential customers can solve the second. Falling in love with a beautiful idea and ignoring whether or not anybody wants it, remains the single biggest failure mode of technology projects (the Internet Of Things seems particularly prone to this at the moment). Ask. Your prospective customers will tell you.
In both cases, conceptual thinking (“the world needs a handheld computer, let’s build one”) without detailed investigation of the underlying assumptions (“weighing several pounds is OK”, “battery life can be a few hours”) gets you in trouble.
Don’t be afraid to look dumb. Stuff won’t work. You will feel like a beginner, “doing it for the first time”, an amateur. You are learning, and you are discovering what your creation wants to be.
Keep going, but learn as you go. Keep yourself open to feedback from the world. What’s it telling you? Know your technology, deeply and fluently. Know your users intimately. Then you can answer the question.
(This post is about time and overwhelm. To risk paraphrasing an old Buddhist saying: if you don’t have time to read it, you should really read it).
The Bathroom Problem
When I was VP Engineering at Macromedia, I used to time my routes between meetings so I could fit in a bathroom stop. I actually planned the quickest route so there would be maybe a minute or two for a pit stop. It took me a while to realize this. It was probably on a weekend, spending another Sunday doing reviews, or Board Meeting preparation, or reading product proposals, when it dawned on me that if I didn’t have time to get to the bathroom, something might be a little off. I was not in charge of my time and attention. Which, of course, as an executive manger, was about all I had to bring to the job.
These days I coach VPs of Engineering, startup CEOs and others in the tech industry, and, guess what, the issue that shows up most frequently is overwhelm.
Usually I hear, “yes, I know I need to think about that (strategy, org planning), but there just isn’t the time”. And then I get shown a calendar: day after day of colored blocks from 8am to 6pm or later.
So I learned some things while I was still an exec, and some more things as I worked with my clients: you have to find the thinking time. It’s part of your job now think strategically, to grow your people, to develop culture, to read about other leaders, and to take care of yourself (what Ed Batista usefully calls “Deep Work”).
And you can. The solutions are at two levels: a model, and discipline around the model; and some deeper explorations of why you stay in overwhelm. Both take work, and repeated practice as you transition to really owning your time and attention — by far your most important resources. Ready?
The model is simple, and well-known. Attributed originally to Dwight Eisenhower (yes, that guy), and popularized in Steven Covey’s “Seven Habits of Highly Effective People”, it proposes two axes — importance, and urgency.
Conceptually easy. Divide your tasks into important/urgent, important/not urgent etc etc, and then do the ones that are important/urgent now, the ones that are important/not urgent later, and all is well. Something like this:
But! Everything feels important/urgent in a growing tech company. So how do we use this model to really get a grip?
Using the Model
Use the model as a lens: look at all of your time/attention decisions through the lens of the model, not just your task list at the beginning of a day or week (and anybody that can maintain a single task list for a week has my admiration). Look at emails — label them according to the areas on the model if you can.
Look at calendar invites — can you delegate attendance to that meeting? Can it be shorter? Can you attend for ten minutes instead of sixty? Look at Slack conversations: sure, that chat about code quality might be getting a little heated, but does it really need your attention now?
Be ruthless about what stays in important/urgent: Throw out everything you can. Your bias, and the bias of the company around you, will be to make everything important/urgent. Don’t fall for it. Make a conscious choice to keep something in the red bucket. If there’s not a great reason for it to be there, throw it out.
Schedule the important/not urgent time, always: if you don’t schedule important/not urgent time ahead in your calendar, you won’t get it. So schedule time for next week, and every week after that. You need at least two hours, every week (I know, seems crazy right now!). Some people need more, to let their minds wander, a few will need less.
Defend your important/urgent time: it’s inviolate (unless there’s a genuine emergency, and if there’s a “genuine emergency” every week, somebody — maybe you — is doing something wrong). Don’t allow meetings to be scheduled over it, don’t allow it to be cancelled.
Spot “Productivity Performance”, aka Noodling: noodling in the “not important/not urgent” zone can relax you, help take the stress off. But so can taking a walk, and taking a walk is good for you, noodling isn’t. So watch for “just doing some email” or “catching up on twitter” or “reading a few blogs”. If you are in full attention to those things, maybe they are productive. If you’re browsing, you’re “performing work”, not doing work. Might be better not to work at all and take the weight off for a bit.
Using Your Not Urgent/Important Time
So you got your two hours, and you frittered them away doing email. Bummer. Here’s what to do next time:
Find a different environment: get away from your desk to a different conference room, part of the building, somewhere you don’t normally go. Ideally go outside — find a coffee shop or a park. This signals to your brain that things are going to be different.
Don’t take your phone: we’re all weak, and that thing is like crack. Leave it behind.
Either limit, or don’t use, your laptop: we can think just as well with pen and paper, and they don’t interrupt us every minute or two. Leave it behind. If you need to use it, download Self Control, which lets you switch off a bunch of sites, whilst leaving the rest of the net open for research (there are other apps — I like, and use, Self Control).
Embrace the discomfort, and start: your brain is going to spend the first few minutes desperately wanting some stimulation — a twitter message, a new email, anything. Don’t feed it. Be uncomfortable and start working. Once you’re into your work, keep going for at least twenty minutes — after that, things will start to flow. And if not, do it again next week.
I Did All That — It’s Still Not Working
OK, I hear you. I said at the beginning, transitioning to owning your time and attention takes a while. Our cultures don’t appreciate it, and don’t encourage it, and they do encourage and celebrate people who can handle being continuously swamped.
Maybe it’s just that way, temporarily: there will be times when you are genuinely overwhelmed. Massive growth, a huge product push, a terrible system failure — these things happen. But they should be identifiable, and temporary. If you know what’s causing the overwhelm, and you can see an end to it, OK, well, maybe you just have to deal. If you can’t see it, and the end is many months or years away, take some action.
Maybe it’s your company culture: does your company culture celebrate overwhelm, over-nighters, “eighty hour” weeks? If so, how do you feel about that? Maybe you fit! Maybe that’s OK. Maybe not, and you’d like to start building a little bubble of sanity around yourself. You have a conscious choice here. Take it.
Maybe you’re not delegating: this comes up frequently — “I have to do all this because my team is not ready/too junior…”. Probably you’re wrong, and holding on to things out of fear of failure, the difficulty of clearly describing the tasks — something. Delegation is great: you get more time, your team gets more responsibility and growth. Find something you are afraid to delegate and do it, today. People are resilient, and grow when you least expect it. Try it.
Maybe it’s you: our business (loosely, the tech world), attracts people who get a kick out of highly detailed, massively complex challenge. I certainly do, and so did the people I hired. We tend to love the adrenaline of navigating a river of problems, endlessly dodging boulders and shooting rapids. And that can make us successful, and rewarded, and the stakes can be high (money, status, career).
So being able to live and work effectively in overwhelm is a super-power, but like many super-powers, it has a downside, and the downside is that it doesn’t work forever. Physically and emotionally, most of us are not set up to go that hard year in and year out.
So take a look at yourself. What do you enjoy about the overwhelm? How does it serve you (ego? a rush? status?). What can you let go of, just a little bit? Two hours a week of thinking time? Sunday afternoons? It may take a while to dig into this, but start — give it a shot.
Yes, It’s a Marathon, Not a Sprint
If it all works out (acquisition! IPO!), perhaps you can retire at thirty, or thirty-five,or forty. Then this won’t be an issue (although almost without exception the folks I know who did make it remain intense, focussed and, yes, overwhelmed). But probably one way or another you’ll be working for a while.
Beware of the illusion that the overwhelm is temporary. It will only be temporary if you take care of it.
Managing your time and attention will remain a critical skill, allowing you to get to the deeper work of futures, direction and growing your people. And, most crucially, taking care of yourself and the people closest to you. So you can build a long, satisfying and productive career, and remain healthy and sane throughout.
I hope this is useful to you. Let me know how it goes.
(Truth in advertising: I’m putting together a free online course to go deeper into this subject — sign up to get a ping when it’s up).
I once asked an engineer who I greatly admired, how he started building the system that he (successfully) submitted for his PhD. I’m not sure what I was expecting, but probably something about careful structural design, some deep thinking about architecture, maybe some blinding insight.
Instead, he said, “I started pulling on threads”, which really took me by surprise. It was such a casual admission that he had been finding the system rather than building from a detailed plan. But I also felt a recognition: it just sounded right. It matched how I had been building my own systems up to then, but not really admitting it. I made plans, sketched some architecture, and then started pulling on threads of ideas to begin to find out what the system wanted to be.
Writing Software Is, Well, Writing
Managing software projects is notoriously hard. The results are unpredictable, the problems are often understood in detail only by a very few, and the personalities can be strong and opinionated.
The job would be made easier, I think, if we admitted what we are really doing: managing a team of writers.
We write software: we use language to create a thing that has an existence from an idea, an abstraction.
The ideas are approximated as documents, sketches, conversations, white-board diagrams, wire-frames. We translate the ideas into a thing that has meaning, to us, and to the machine that dumbly runs it.
Anyone who’s tried writing a story will know how much goes into the translation of an idea (“a detective falls in love with a woman who he betrays in 1970’s San Francisco”), and the finished result. As we write the story, we pull on some creative source, our knowledge of language, and our skill and experience, to take the idea and build it, with all of the detail and implications that are revealed as we write.
Certainly some software is rote, in the some way that some writing is rote: the five hundredth episode of a cop show is pretty well understood before the writing takes place.
But the interesting stuff is not: it’s creative, uncertain, made up as we go along.
The Environment: It’s All Business
So we’re managing a team of writers.
Not only that, but we are usually managing in a business environment. Our creation is constrained by time and budget, and there are often competing (sometimes strongly competing) ideas about what we’re building, and, more crucially, why. The ideas we are translating into language are open to interpretation, and different groups (the CEO, Marketing, the customer) can have wildly different interpretations.
Not only that, but the stakes can be high: the survival of a company, the value of years of stock grants (sometimes measured in numbers that most of the world can only gasp at), the first (or last) shot at making it big, careers, jobs, futures.
We are managing a creative process which is by its nature unpredictable and personal, in an environment which craves certainty, predictability and consistency.
If we think of the software team as “engineers”, the uncertainty and constant variation feels like a central bug in the process, and a stressful one at that. If we think of a software team as “writers”, it’s clearer what’s going on, and our approaches make more sense.
Managing Software Creators as Writers: Some Implications
Guidance, Not Control
We tend to react to these pressures by grasping for control. If we have “good management” — firm enough deadlines, detailed enough wireframes, daily checkins, monthly project reviews — then we can keep the whole thing together.
Control is not the right paradigm. The job is guidance, sometimes tight, sometimes loose. Sometimes the “writing” is flowing, sometimes it needs to coaxed and forced. The manager (a better word is “producer”) has to understand the creative process: what is needed? what does the work want?
Own the Goals
Your writers are deep in their code. That’s where you want them, and where they want to be. They are “pulling on threads”, discovering in language what needs to be built. The writing of the code requires that they, to some extent, lose sight of the purpose of the writing. Not because they don’t care, or because they are irresponsible, but because they have to be able to be open to where the writing takes them.
Your job is to hold the purpose of the team, the goals.
You own the goals so the team can be continually course-correcting towards them. Your holding the goals (today, this week, this month, this year), constantly communicating the goals, adjusting the work so it’s directed towards the goals, is a vital service to the team.
Tight Processes, Loosely Held
Your job is to balance loose and tight process. Deadlines are good. Deadlines at the expense of a brilliant burst of creativity aren’t. Brainstorming is good. Too much brainstorming moves away from the real work. A small team working with only a notional idea of a goal may produce terrific results. A large team without a clear destination will fail.
A well-designed process allows a writer the freedom to create by limiting their boundaries. An unduly “stiff” process chafes, and rubs against the organic business of creating.
Writers are Individuals
The act of translating a concept into language is not rational, linear, open to easy analysis. Writers know that some days it comes easy, and some days it feels like it’s gone forever.
Like writers, software creators have a massively broad range of skills, approaches and personalities. What they create is a reflection of who they are. There are structure-people, speed-freaks, intuitive idea generators, generalists, specialists, language pedants, brilliant mess makers and steady, reliable builders, among many others.
How they create is equally individual: some need a complete and rigorous architecture before they can bear to start. Some just need a keyboard. Some take a week doing apparently nothing before they suddenly spit out a completed work. Some work daily, predictable hours.
Some are motivated by money and stock options. Some by the beauty of what they can create. Some by the connection that comes from working intensely side by side with other brilliant people who share their craft.
Your job is to understand these creative, highly variable human beings and get them what they need to work well.
In particular, you need to fit the job to the writer. If you want something to go fast, find a speed-freak — a writer for whom an incredibly fast solution is a thing of beauty. If you want a strong, stable, long-term architecture, find the person who loves structure, elegance and has the strength of personality to stand up for it. If you want a gorgeous UX, look for the team member with the spectacular personal website.
We are drawn to what we are drawn to — for some reason this fundamental piece of human nature is obscured, or down-played in business. Find what your writers are drawn to, and let them revel in it.
Love the Mystery
Your job is to balance the mysterious business of creativity with the hard-edged requirements of business. If you love the mystery, then the surprises, the uncertainties, the impassioned arguments about apparently tiny details — all the passionate business of creating something new in the world — will take you deeper into the work, will align you with your group.
If you are afraid of the mystery, find its unpredictability difficult, then you will be constantly wrong-footed as you try, and continually fail, to have it completely under your thumb. Control will take only you so far — a smallish (maybe ten person) group, a few years of managing. To go further, you need to love the mystery.
Why We Do It
In the software industry (which these days is almost every industry), we take abstractions, concepts, visions and turn them into something that works. And we do it inside timelines and budgets, and we do it for high stakes.
Building a great piece of software is a constant balancing act of creativity, structure, improvisation and deliberation. At the heart of it is the act of writing, an act of will, inspiration, craft and (often) sheer effort.
The job of managing software is to guide creative, brilliant, massively varied writers un writing their best work. A privilege and a joy.
HR Debt — Like Technical Debt, But For Organizations
We all know, at some level, there’s a cost to dysfunctional teams, “problem employees”, broken relationships at work. There’s the super-brilliant engineer who nobody wants to work with, but nobody will confront. There’s the team from an acquisition of a year ago who still won’t talk to anybody who doesn’t do things “their way”. There’s the manager who is a lovely person but who keeps changing his mind and then blaming product management, or sales, or marketing, or sun spots. (Feel free to supply your own examples — have a rant! I don’t mind…).
We know this is happening. We know it’s not great. But it hasn’t had a name until now, which makes it hard to grapple with. Giving concepts a name gives us something to grasp on to — naming confers power.
Let’s Call It “HR Debt”
I recently came across this rather terrific post by Jessica Rose. It kind of off-handedly introduced a notion we might call “HR Debt” — the organizational analogue of technical debt.
Coincidentally, a day later, I walked into a client session where the issue was, in fact, fixing up a team that had been badly structured and poorly lead: we spent an hour sorting out the pain, cost and emotional difficulty of getting things set to rights. The notion of “HR Debt” was immediately helpful in naming what we were wrestling with — a set of organizational and people issues that had been left to fester.
We can describe Technical Debt as the cost (time, attention, real money) of avoiding doing things the right way in a codebase. In the short term, the company saves money by not fixing a known architectural issue, by “hard-wiring” a piece of code, not fixing bugs that have “been there forever”, and so on (feel free to provide your own list here, too).
HR Debt is exactly analogous: by putting off dealing with a problem employee, dysfunctional team, broken relationship, the organization saves disruption in the short term, but pays, every day, in time and attention the team puts in to make things work: the morale-sapping arguments, the half-completed conversations, the decisions being put off or fudged to avoid (or create) confrontation. It builds an overhead into pretty much everything the organization does.
As Jes puts it:
“Having your team build informal processes to work around bad actors creates an environment where additional time and energy costs are included in all team activities”
Not only that, but when the time comes to fix it, just like technical debt, the cost is far higher than it would have been originally: people need to be moved or fired, teams rearranged, salaries re-worked, relationships repaired. It takes time, energy and courage to get in there to make the changes.
So what to do when it looks like HR Debt is starting to accumulate?
Do The Hard Thing
Much like addressing Technical Debt, the only way forward with HR Debt is the Do The Hard thing and decide to take it on, now, before it gets worse (one aside here is that although HR Debt may be emotionally harder to confront, in terms of sheer man hours, it’s almost certainly going to take fewer than dealing with Technical Debt).
Hard things have to be said, personalities confronted, difficult conversations need to take place. You will have to say the hard thing, as clearly as possible, probably multiple times, to people who may not want to hear it. It can feel like you are alone, with nowhere to stand.
So how to go about that? What’s a model you can hold onto as you go into those hard conversations?
Radical Candor is a toolkit for saying hard things so that they are heard. If we boil Radical Candor down to its essence, it is a model for confronting and dealing with difficult conversations effectively. It encourages us to be direct, to tell the truth as we see it, whilst being clear that we actually care about the other person as a human being: that the feedback is not an attack, is intended to fix a situation, help the people involved, and build stronger working relationships. It asks us to “just say it”, whilst respecting the humanity of the person on the receiving end.
In the Radical Candor model, not having the hard conversations, or fudging them (“really things are OK, I’d just like you to maybe consider…”) causes us to drift into “Ruinous Empathy”, where our HR Debt will continue to accumulate. In “Ruinous Empathy”, our fear of confrontation, of having somebody quit, or burst into tear, or simply being hurt, gets in the way of us telling our truth. And HR Debt continues to accumulate.
The concept of “HR Debt” allows us to estimate the cost of staying in “Ruinous Empathy”: how many management hours will be dribbled away by patching over poor behavior? How much real money will be spent on a team which we’re pretty sure will have to be reworked? How much would we save over time if we took on the hard conversations now? If we started to be Radically Candid, how much time, money and attention would the organization begin to save?
Take a Look At Your Organization
Where are you avoiding fixing a dysfunctional team? Where do you have people working around a “difficult character”, spending their days avoiding, fudging and dodging his (or her) crappy behavior — however brilliant he/she is? Where do you have a team that is sitting around waiting for decisions, or swapping from priority to priority on a weekly basis? What hard conversations can he you have now, today, to start reducing your HR Debt?
(Truth in advertising: I work with the Radical Candor team to give training and workshops in the Radical Candor model. I do this because it works)
(this, and more articles and links, in the weekly Tech People Leadership newsletter)
The Last 10% Is Hard
“The first 90 percent of the code accounts for
the first 90 percent of the development time.
The remaining 10 percent of the code accounts
for the other 90 percent of the development time”
— Tom Cargill, Bell Labs (ancient software
wisdom — if you know an Agile equivalent,
I’d love to hear it)
The last 10% of a software project, is hard. It just is.
There’s nowhere to move the deadlines — time’s up. The thing you are building, which used to feel like a set of well-understood building blocks, now streams towards you in an endless river of barely connected details. UX wording needs to be exactly right; reliability, which was “good enough for beta” now needs to be 100%; that niggling bug everybody has been working around for weeks needs to go away, today; a feature that you thought worked great is missing something — not clear what it is, but it is clear that the beta users have to have it; the CEO has an idea and…
The more you do it, more you learn to pattern match on traps you’ve fallen into in the past. But I’m not sure anybody ever learns enough to bring their projects into the final deadline smoothly and without stress. (Maybe you do — if so, let everybody know your secret). There’s something more fundamental going on here.
Here’s a thing that happened: we were looking for a great engineer to work on device drivers (yes, this was a long time ago). D showed up, did a great interview, and I hired him.
Here’s the story about the thing that happened: I was doing interview after interview for a great low-level engineer. I was tired of it, bored. D’s resume was sparse, but he’d written his own game, so I thought, well, maybe, sure, give him twenty minutes. D showed up to our exposed-brick, cool warehouse space wearing a suit, which was very weird, and looking like some kind of male model, which for a game coder was weirder. My skepticism increased. I looked at my watch. D started to describe his game.
This post is one in the “Incredibly Simple Management” series, dedicated to stripping great management down to the fundamentals you need to get it done.
As with any leadership activity, things are moving on two tracks: management – the art of controlling time and resources; and leadership – the art of connecting, motivating and serving people.
This post is one in the “Incredibly Simple Management” series, dedicated to stripping great management down to the fundamentals you need to get it done.
Meetings are necessary. The purpose of an organization is to have people work together. The purpose of leadership is to have people work together as effectively as possible. Well-run meetings are the most effective way to coordinate and motivate a group of people. Poorly run meetings are one of many terrific ways of doing the opposite.