I’m an ideas guy and it’s been very frustrating to have to raise to ascend the stigma.
I iterate solutions much faster than most. Ive also since college done the hard yards to learn to execute/lead and obtain multiple deep skills including coding.
I know what people are talking about with the “all talk no action” person.
That’s not me, some of us really are excellent at iterating good ideas. It’s a discarded skill, but highly valuable once I’m on most teams, I can just never promote this strength due to the stigma.
Maybe your not following through enough? I feel like if your one to always iterate on ideas and follow through and do a good job, you'll be more of a bad ass, I doubt there would be any stigma
generating an idea or a solution is of course easier than following through, if you generate solutions and ideas quicker than most people it means you will have lots of ideas and solutions, you then need to develop the skill of only saying the best ideas otherwise with all the ideas you will be too enervating (and some times you will fail at this task)
furthermore there are some careers that mean you will not develop a reputation for follow through before you develop a reputation for ideas, for example if you are a consultant and brought into a place you will say a lot of ideas before you have the chance to follow through. In these situations you will be seen as all talk no action because you start off with lots of talk and nobody has experienced your actions. I'm sure similar scenarios can spring to mind.
> Ive also since college done the hard yards to learn to execute/lead and obtain multiple deep skills including coding.
If you’re actually executing and delivering results then you aren’t the stereotypical “idea guy” referred to here.
The problem with the stereotypical “idea guy” is that their flurry of ideas and constant changes becomes a roadblock to delivering anything at all. Their team is constantly destroyed by direction changes and burned out from chasing moving targets before they can possibly hit those targets.
The idea guy personality is the embodiment of the phrase “perfect is the enemy of good”. Every team has constrained resources, so delivering something imperfect is better than not delivering anything at all because the team burned out and ran out of money because the ideas were iterated faster than execution could allow.
This is why economic thinking should be a part of every team's process. One of the major problems with technical projects is that many people can give an estimate of their value but only the developers can give an estimate of the cost—and they can usually only do that effectively after some iterations and starting to sketch out the problem. Usually organizations just ignore this problem and try to fix the cost upfront, which is where the whole "mythical man month / hours" phenomenon comes from. In a well-functioning Lean/Agile/whatever-you-want-to-call-it organization, there should be a constant ongoing evaluation of the work and its cost/benefit, and that should be updated as the devs learn more about the problem. When you do this, ideas are no longer "good" or "bad," they just have a value estimate and can be evaluated against other ideas. (And you can factor in things like switching costs when people throw out something totally new.)
While I think that kind of thinking the kind that encourages bean counting and half-assery in the name of profit? I would certainly agree that having an ongoing basis for calculation is a metric. But when that metric becomes a target (and it will), you get disasters like the 737 MAX.
Bean counting is happening in your organization whether you like it or not, it's just a question of whether it's visible to you. I would much rather have it be an explicit part of the development process where the developers get some kind of input than have it hidden away and have edicts emerge from the ether to mess up their whole month. For a thoughtful view of this topic, I recommend "Principles of Product Development Flow."
I don't think anybody is questioning the value of good, fresh ideas, but what the article outlines is a real problem. The "armchair quarterback" non-technical type is especially annoying because it creates a bad feedback loop:
- Idea guy says we should make a water-powered ferrari that costs $100.
- Technicians shut it down as impossible.
- Idea guy complains that technicians are short-sighted and shut down all of their ideas.
- Goto step 1.
I'm myself somewhat of a daydreamy type, but we have to understand that unless there's a specific, detailed plan, ideas really are a dime a dozen.
It's always fun to take an "impossible" ask and figure out a way to make it possible. In your case, this one is far closer to possibility that you might've realized - take a H2GO [+], make it ~20% cheaper and slap a ferrari logo on it, and you're good.
I'm not even trolling - sometimes playing with the 'impossible' demand yields useful results. You were just trying to create an artificially-impossible demand, so in this case it's not useful - but if it's a real customer "impossible" demand, trying to make it possible by rethinking the constraints can be actually valuable.
I agree that what you are saying is useful, i.e. identify the minimal sets of contradicting constraints, but if you can relax a constraint, then you are effectively solving a different problem.
OTOH it's pretty well known that customers mostly don't know what they want, so deciding what is actually a constraint and what isn't is, paradoxically, a part of the job.
the point to me here is that the really valuable ideas aren't just some thing that someone has in the absence of context. given the situation on the ground - this approach will nicely balance all the constraints. this idea explicitly recasts an existing machine into one which is simpler and more general.
you dont have these ideas unless you are intimately familiar with the territory. and if you aren't, its very likely that any suggestions you might have wont be relevant because of its features.
I was the tehnician type for a very long time, until I realized it was keeping me back. Now, whenever I encounter an idea guy, I just ask 'how' and 'what' (never 'why!') until I understand what they actually want, and the idea usually turns out to be a lot tamer than how it initially comes across.
Even in these situations, there will be the idea guys that really don't even have an answer to the first how, or what. The advantage is that you don't have to be the nasty technician telling them it's impossible, and turns the problem around to them being unable to formulate their ideas, usually due to not exploring it in depth.
Why not "why"? Having an understanding of his or her motivations, while possibly not serving the purpose of knowing whether an idea is feasible, may help in formulating your own methods to solve the problem.
I guess it’s a matter of life experience. I couldn’t point to a research paper on it more than Chris Voss’ work on negotiation.
I find “why?” is more aggressive and makes people talk more about the generalities of the idea, whereas with “how” and “what” I feel like I can get the why without asking it directly, and closer to the truth.
You should market it as "iterations delivery guy" as "ideas guy" makes me just think of a guy with a notepad writing down random things every few minutes.
I'm a pretty idea-ish person, and I sometimes intentionally rein in the "where we really want to get to with this" talk if I feel like the audience isn't right, but I think the real key is emphasizing what has been done already and what the immediate next steps are— that puts the accountability out there and keeps the conversation grounded in reality.
I think another litmus test for idea-executor vs pure executor is your willingness to do throw-away work. A pure executor reads the design doc, says "sure", and just builds it— an idea-executor recognizes that the long-term maintenance of the system will almost certainly dwarf the initial cost of coding it up, and is willing to extend the discovery phase with partially-functional prototypes and so-on in order to really get a firm handle on whether the thing is going to go where they want it to go.
(Recent example— building up chunks of a moderately complicated build setup in parallel in Jenkins Pipeline and GitLab CI in order to understand how the two solutions would compare on maintainability, end user ergonomics, permissions hassles, flexibility, how much documentation we would need to support it, etc etc.)
If you're actually good at iterating solutions, then you may not be an "ideas guy"—or at least, not just an ideas guy.
My wife, in her previous job, was asked to do various kinds of "strengths evaluations" as her department wallowed and wandered trying to find a better direction (part of why it's her previous job...) and while I'm not sure how scientific any of them were, they were somewhat interesting.
One of them divided people up into four groups (whose precise names I may not all be getting right): Creatives, Executors, Marketers, and Refiners.
Each of these was vital at some point in the lifetime of a product or service, but the one that particularly interested us was Refiners. Previously, she'd thought of herself as very much a Creative type—an ideas person—but this drew a distinction between someone who just comes up with all kinds of crazy ideas—the Creative—and someone who can take ideas and iterate on them until they're actually executable—the Refiner.
Particularly in the environment she was in, that was a very useful distinction to be able to make, as there were a lot of people around her who just came up with idea after idea with no real concept of a) how to execute it, or b) whether it was actually going to be a good idea if they could.
My team has an ideas person. But he is only responsible for the first iteration of an idea. I get an uber-complicated idea I break down into small pieces and iterate on it until it's good– I'm executing.
I set the target and keep the team focused on the current main goal. The idea person hates me for it, because he sees good ideas being ignored. Those good ideas won't deliver substantial value to users until the next milestone is completed, because it is blocking something more important.
This describes me perfectly. And the struggle to be better at execution is huge. But with a lot of dedication and habit building I've been able to (partially) overcome it.
Echoing the other comment that was talking about stigma... I think we should at least admit that, of course, without execution ideas aren't worth much, but without ideas you don't even have anything to do. And in fact, most of the people that are not good at "ideas", are not good at executing either. That is, making good plans to create things. Of course, executing as "following orders" is another entirely different category that many more people can fulfill adequately.
So, we should look at ourselves to make sure we are not only daydreamers, that ideas don't only work in our heads, that they might actually make sense in the real world too... But creativity is not the same skill as planning, and that's kinda ok too. It's good to keep your feet on the ground to avoid selling dreams, and I also really hate the people that will only talk big and then show no interest on working on some of their "best" ideas, but creativity is not the same as the ability to fully realize ideas, from creative inception to success. This later part requires many skills. Having reasonable and interesting ideas is only one of them.
Funny, it describes the opposite of me. When the high-level idea people start talking, I have already phased out. It seems somewhat useless to me, they spend so many hours talking about possibilities that shatter at the first contact with the real world. Without at least a bit of practical time to attempt things and fail, I am basically useless at design.
I fall on the idea person end of the spectrum more than the work-horse end, and when someone comes talking about big ideas without some baseline plan, hypothesis, or validation I zone out too. I get so frustrated with people who spend 40 hours working on shitty slide-decks trying to convince me something is a good idea instead of finding a way to show proof.
"The armchair quarterback. They love to wax poetic about what could be done yet when asked to get the ball rolling, they show no interest.
The act of calling out gaps and offering solutions is their sweet spot."
Is this saying that 'calling out gaps and offering solutions' is awesome as long as they help implement the solutions?
Asking because for every person I knew who espouses ideas and won't help (too few to recall any) there are scores upon scores upon scores of people who compulsively resist fixes - no matter how many resources are provided for.
It's possible that they recognize that a team is necessary for execution (and if they don't realize this nothing gets done) but still think of the product as stemming wholly from them.
Yeah this part really rubbed me the wrong way. Don't buy into an ideas person without committing to providing the proper support. Otherwise that person will get burnt out.
I have noticed that the only productive unit of execution from idea to functional proof of the idea, is exactly one person. It helps tremendously if they have others to talk to about their idea, ‘idea people’, if you will. But it doesn’t work to have a separation between authority over ideas and responsibility for execution. I assume that is what prototypical ‘idea person’ is looking for in a team.
Having worked with 'idea people' at various companies of various sizes, I've found that what the best 'ideas people' bring to the table is the ability to sell that idea up the food chain to get resources and time for the 'execution people' to actually be able to execute.
I was pulling from experience. In that instance, you are correct, they did realize it was a team effort.
But what I failed to share will hopefully clear up the confusion. They didn't call that out during the hiring process. They talked themselves up as if they could succeed single-handedly. It wasn't shared until they were failing to show progress and then it became an excuse. It wasn't possible to give (or hire) them a team. In the end, the person was let go to find a bigger company with the resources and capacity they would need to succeed. No hard feelings... just not a fit.
I'm an "execution" guy. I make things happen. Been doing it my entire adult life. It's incredibly valuable, and "idea people" know it.
But they won't say it.
If I had a dime for every "idea person" that wanted me to realize their harebrained AI-powered cheese straightener, for nothing, and they get all the money and credit, because it's "their idea," I'd be rich.
I feel like this article kinda confuses "idea people" and "people with an idea." Idea people should know how to prove an idea. I've had a lot of similar hairbrained ideas come my way looking to build an MVP for something, and typically the end of our conversation is "use an excel spreadsheet and prototype this idea and come back in 6 months, then I'll charge you $75-$200k to build the tech"
I've prototyped enough of my own ideas to know that most ideas are shit.
I think a lot of ideas are good, but they need to be "walked through," and refined. They are generally great at the hand-wavy level, but the devil is always in the details.
I believe that a lot of these colossal startup failures are great ideas; poorly executed.
The people I'm working with now, had a great idea, but didn't have it "thought through."
I said "I'll realize it, but expect big changes. I'll be developing a running prototype, and we'll be tossing out things that looked good on paper, but fall flat, in execution."
That's exactly what has happened. It takes a lot of patience; on both the "idea person" level, and the "execution person" level. I need to take their ideas seriously, and they need to shut up and pay attention when I catalog the costs of their ideas in the real world.
It'll work out, and won't look at all like they thought, but I'm designing an excellent baseline for creativity. It will work very well, will be localizable, accessible, and will allow creatives to put a lot of chrome on things.
I think you’re both right, but it’s the definition of “an idea” that has some assumptions.
Take Noah Kagan’s term “wantrepreneur” as the groundwork for what I mean:
Person A’s ideas are: Get business cards, build a website, get pamphlets, buy equipment, buy a business car, and so-on.
Person B’s idea is: find 3 clients first, do the rest after.
Person A’s ideas are all objectively good, but many of us who have seen businesses come and go won’t count those as ideas, and therefore will say “you have a good idea that needs refining” when talking about the core idea for the business.
I think for startups in general you gotta blend a bit of those two strategies to be successful too. You gotta build a nice landing page to convince people you're serious to get some of those early meetings to convince other people you're serious.
On the other hand, I will say what I consider a fairly obvious idea and suddenly all the "execution guys" are working on building a better birdhouse instead of a bikeshed.
I used to put a lot of energy into making clear that "execution guys" are allowed to climb up out of scope and change their minds about an approach. But at a point I think it's reasonable to look at this pattern and make the assessment that I do indeed possess some kind of skill.
Ah, yes, the two-wheeled conveyance storage building...
One of the issues I have had with "idea people," is that they think that every deviation from their Big Idea is "bikeshedding."
On the other hand, I like to keep the product at "beta" quality from as close to the beginning as possible. That often means that I spend a lot of time developing infrastructure scaffolding (like persistent preferences, error handling, security, accessibility, localization or messaging systems).
This means that I'll suddenly stop producing new features for a few days, while I set up some infrastructure (that will result in an explosion of features in a few days).
In fact, I'm doing that, right now. I am writing a "developer" screen for the app I'm developing. It won't ship, but will allow other technical team members to do things like set up test servers, and evaluate REST interactions. The non-tech people aren't gonna see much for another week or so. They'll have to be happy with what I've already given them (and they are quite happy).
> One of the issues I have had with "idea people," is that they think that every deviation from their Big Idea is "bikeshedding."
That's probably a confusing example.
I don't mean that implementers aren't doing anything. What I mean is something like this: the people who are building (or planning to build) a bike shed are often the last people to realize an obvious problem like a) the target audience is birds and b) birds don't ride bikes.
My professed skill is that I can get people to shift to working on a birdhouse. That avoids the danger of ending up with something like a bike shed retrofitted with pneumatic tubes designed to pump in birds from the outside world.
I'm not claiming this is a unique skill. But things like SVG's path arc syntax exist, so it's not ubiquitous.
I'm an ideas person, but I can back it up with the necessary toil to bring an idea to life. But frequently, ideas require multiple people's worth of expertise to succeed.
A healthy attitude, in my experience, is for others to workshop an idea that has a potential for a good payoff; both finding flaws and finding workarounds. This occurs with an open, collaborative culture.
An unhealthy attitude is expecting somebody with a good idea to put in 100% of the effort themselves, because that requires them to relearn/reinvent everybody else's specializations. This happens more with a rigid or competitive culture.
A survival strategy in the latter environment is to keep one's ideas secret, and (theoretically) solve future problems before anybody else knows that they'll crop up. In this way, an ideas person becomes the clinch-problem-solving-person because when the house is burning down, people are more willing to collaborate.
I've always found that an iterative collaboration between "idea" people and "execution" people has yielded the best results.
If your idea is that good, and you can't trust your "executor," then it's an idea that will either die in the crib, or will come out as a mutated, unhealthy monster.
Collaboration, between dedicated, creative ("execution people" can be very creative, you know) team members, working on an equal footing, with mutual respect and authority, works well (in my experience).
The company I worked at for years was not an especially creative one, but it had some heavy-duty science going on. Some of the folks they had in their R&D department were some of the best in the world.
But they also had a codified system, that worked fairly well, to realize their inventions in a way that could be commoditized, and that was because some of their "execution" people were also among the best in the world.
> "execution people" can be very creative, you know
Echoing me here :) -- main problem with the article is that it represents, no, encourages, black-and-white thinking at a management level. Most of us are quite flexible, and tick both boxes, but we'll identify stronger with the label that feels more rewarding.
> An unhealthy attitude is expecting somebody with a good idea to put in 100% of the effort themselves, because that requires them to relearn/reinvent everybody else's specializations. This happens more with a rigid or competitive culture.
Yeah currently suffering from this... losing my mind coding the fifth 'refactor' (or better, learning I did everything wrong the last four times) so I can get to a product to generate enough revenue to appreciate a teammate's time by putting bread on their table. Self-inflicted.
I'm lucky I don't need many calories to maintain a healthy body weight, but I may have traded all this for some crispy dendrites.
Whenever I hear "execution guy" I shudder a bit. There are people who produce a product/service, which I believe is the direction the article is inclined, and there are people who work hard as in checking blocks on an infinite checklist. Both are "execution guys", but they are not the same thing. The difference is goal orientation.
I, personally, find substantially greater value in a person that produces something and is now sitting idle thinking of the next original product to complete opposed to the person who is busy or hard working.
Idea person doesn't trust the execution person, vice-versa (and for good reason). Capital offsets those risks, but reduces the market to only those with sufficient capital.
DAOs seemed promising to improve this, however "crypto" is just a [potentially uneccesarry] piece of that puzzle. The real innovations that will make a DAO work haven't been discovered yet.
As a semi idea person, I agree with you, most of my fellow idea people do not realize that importance of execution and it's a lesson I've learnt the hard way.
> Not every “idea person” is a good fit for your small business. In fact, most will be a terrible fit. How can you tell?
TFA goes on to list three characteristics of people who are dud team members, and 5 characteristics of good team members, but it doesn't do what it claimed it will - tell you how to identify such a person at the hiring stage.
Well, just don't hire an "idea person", especially not if your company is not gigantic.
If you are running a startup, at least one of the founders is "idea person". You don't need another one, especially not as an employee. It just doesn't bring any value to the business. Hire "execution person" to bring existing ideas further. An if "execution person" is not good, it will show, if not during the hiring phase, then soon later.
My comment was that you don’t need to worry about hiring wrong idea person because you should not hire them at all.
As for execution person objective criteria exists, and it’s possible to evaluate performance, either at the hiring stage or soon afterwards. Evaluating idea person objectively in a short period of time is way harder.
If people came with a label that says "Idea Person" or "Execution Person" we could just read their label and do like you say. But what do we do when candidates claim to be both, and there is no label?
Another potential red flag attribute I've witnessed is shifting of the idea deliverablee\objectives after the green light is given. A partner I once had developed a pretty great idea we decided to execute on after 20+ hours of planning. He started proposing entirely new (follow-up) ideas mere hours into our execution. Then started morphing the original plan. 1 week later he was dropping idea bombs left and right. I finally delivered something close to the original plan and he spent the next 2 months slowly backing out of the project entirely, having put in less than 10% of the effort.
That's a recurring experience. Sorry you got bitten by it. I've had it as well and others I know as well.
This is normal for what is here given as 'idea' persons. It used to generate a lot of frustrations within me. Now I know that an idea person, or for that matter most entrepreneurs, will have ideas. They'll share their current version with much enthusiasm and will wake up energized the next morning with, for them, tiny iterations on that idea. For others, such as the engineer implementing it, those 'tiny iterations', are completely new and will require large amounts of rework.
One of my colleagues described it as the idea person being a little boat that is swarming around a large container ship. The container ship just isn't able to change course on the whims of the little boat.
You can only be useful as an ideas guy if you're smarter or more knowledgeable than everyone else. Everyone knows that, and that's why calling yourself and "ideas person" is received in exactly the same way that calling yourself the smartest person in the room is received: with some eye-rolling.
The "how to start" point resonates with my experience. There's a cohort of "idea" people who are efficient at anticipating and clearing obstacles (including those that occur at inception around "how to start") without actually being all that great at executing those adjustments.
I think we value that type of contribution (often allocating it to leaders, though every contributor does it to some extent) even though it might not materialize as "doing" anything.
Daydreaming in software development is imo not a disease but a symptom, and it's a form of escapism. Broken processes, extreme technical debt, tight project constraints, very limited resources, etc. all can lead to engineers wanting a way out.
> While ideas get most of the fanfare, they don’t really matter unless steps are taken to make them work in your business.
Stopped reading here. It's not about ideas, it's about having an understanding what could be done. If thinking is grounded in reality and your resource constrains, ideas are worth a lot. Otherwise all your company would do is copy other companies.
Just wanted to add - the worst "ideas person" I ever knew delivered an endless stream of really obvious ideas. An ideas person who delivers good ideas that no-one else has thought of can be useful, independent of their implementation skills
Agreed. There is some room for someone that can provide great ideas, however, small businesses need to (at least) pair them with someone capable of executing. This is more "exception" than rule though.
The problem with people who think of ideas and don't try to execute them is that they can't incorporate feedback. At best you get a second-hand explanation of why the magic thing can't be built.
You also end up with an attribution problem: it's easy to say what the big idea is, but it takes a lot of work to make it happen. Why give credit to the guy with the big picture, when the big picture is probably something the guy who implements it had as well? Devil is in the details.
You also don't get good ideas if you don't try to implement them. The implementation process is a creative process, which btw your ideas guy might not recognize, leading to issues.
I've had ideas guys where I worked before, and it was toxic. My view is basically that ideas guys are a kind of leech: they take credit for positive things that are obvious, they come up with excuses for things that are negative (team failed me boohoo), and they don't generate better ideas than people who are doing the implementation.
My experience is in quant trading, where you have people who can code, and sometimes people who just fluff about strategies. With the randomness and noise it's easy to be fooled by ideas guys, and it's taken me a long time to just dismiss the concept entirely. I actually just got off an interview where we discussed this problem in the space, and we agreed it's absolutely essential that people can code, otherwise their trading ideas are worthless.
That's why I was quick to call out that ideas have little true value without execution.
Ideas are born and die every day. We're naturally creative but we also (generally speaking) don't tend to follow-through. That's the real and hard part.
There is no such thing as an "idea" person who is valuable because of their ideas. If they appear valuable, it's because they also have actual experience with execution, or more frequently, they have money or connections (which I don't say to necessarily denigrate, this kind of person can be very useful as well.)
Easy to get snowed though if you don't know what to watch out for. That was my motivation for writing this. I've been kicked a couple times by (good intentioned) people that did not realize their success (ideas) had been team efforts.
An idea is a base quantity. A bad idea maybe worth 1, a good idea 10, a great idea 100. But execution is a multiplier. Good execution is a 10x. Great execution is a 100x.
An average idea with excellent execution is worth a lot more than a great idea with poor execution.
My two cents: a good idea is 1, A great idea is also 1. It doesn’t mean jack till its usable.
So it would be more like -
Good idea (1) x good execution(10) = 10
Great idea (1) x great execution (100) = 100
Ex: my great idea is that faster-than-light travel will REVOLUTIONIZE HUMANITY! Of course I’m an idea guy, so I cant be bothered with physics and engineering and special relativity and all that riff-raff. Let a specialized team figure that out. But hear me out - this is a BRILLIANT IDEA when finished.
(That’ll be 100M seed funding, thank you very much.)
This article has a limited perspective. People have different skill sets, and valorizing one skill set and demonising another is something that is not very helpful. You as an engineer may want to say that your skill set is the most crucial one and others are worth less, but you know what? Other people are going to do the same to you, and often with more success.
For example, UX and design is now quite valued, and frequently you hear UX and design guys disparage engineering. Is that something we want to encourage? It's better to encourage making rational decisions about what skill set you need and who is best to supply them, so we are all judged on our merits and not based on self-marketting. Idea-generation is useful in a lot of contexts. Personally my best ideas have often been to figure out a way where we didn't need to execute a bunch of difficult stuff that the execution types were about to take on.
It never fails to amaze me how many non technical people - run of the mill (fill-in-a-word) people are on "hacker"news.
The person who said that he was an idea person who executes ideas all the time that it was stigmatized by morons is right.
In programming in particular, coming up with "ideas" and executing them immediately in your programming is pretty much a constant. And it's arguably what hacker, a real hacker, means by definition of word.
My experience is people who don't appreciate ideas are the first to plagiarize them, steal, or cover it up. In fact, its arguably what a lot of current big companies that are stagnating the country are running on. Advice - make sure you have no people in the company you make that think that way. Make it part of the interview - give them an opportunity to say the acceptably stigmatizing thing, and then eliminate them.
I think the ideas vs execution is a false dichotomy.
In fast growing startups, there are people who can hack they way out of most problems quickly. Such people are immensely useful during the exploratory phase and early growth phase.
If the startup continue on their growth trajectory into next hyper growth phase, they need deep systems thinkers to build better end to end systems that can deal with the inevitable product complexity, org growth and user growth.
They obviously cannot build complex systems all by themselves. They need that team of hackers to believe in and execute their systems vision. They are usually good at selling their vision to the hackers as well as to the org leadership.
In really successful startups that become unicorns and beyond, there are also great visionary org leaders who can curate and evolve harmonious and motivated teams that execute well to keep pace with the growth of the company.
Of course, while in middle of it all, it feels very chaotic and out of control.
This is a classic problem with successful startups. At some point, there's pressure to bring in "adult supervision", which usually means a CEO from a big company. Sometimes this works, and sometimes it makes things much worse. Microsoft and Amazon stayed with the founders for a long time. Apple famously went for an outside CEO, got into trouble, and went back to the founders. Google/Alphabet is back with the founders in charge.
I think, becoming or finding a humble "adult" CEO isn't easy.
I worked with brilliant founders, who were really bad managers. It almost seemed like their high skills in engineering came from letting every other part of their personality deteriorate.
> Microsoft ... stayed with the founders for a long time
no, Microsoft brought in Jim Towne (from Tektronix) and then Jon Shirley (from Tandy), only then returned to founder Gates and, not founder Paul Allen but, Gates pal Steve Ballmer.
I agree. But to add to what you say, in fact, when presented with a binary choice in matters as complex as society / organizations / culture etc. the "pontificator" is almost always wrong / inexperienced / has a hidden agenda / love to hear their own voice. In retort to this article, "an execution guy" with no ideas is just as vacant as "an ideas guy" with no ability to execute anything. And, in fact, there never are such simplistic personalities to start with, so please ... Casey (the articles author) ... what I think you're doing here is just self promotion, no?
Hi. No self-promotion whatsoever. I seek to share.
My motivation here was to share what I've learned. To benefit from my mistakes. Sidestep my missteps.
Ideas are great and necessary, but even great ones are only valuable if they can be acted upon. In a small business, an ideas-only person will have trouble succeeding. Being able to also (at least) kickstart the effort is critical.
Idea people are most of the time really creative. Creative people are most of the time more chaotic. This article is all about a well balanced team composition in the end. A team full of code robots does not work and a team full of 'idea people' does also not work.
How so? I wrote from my gut here and am not one to think I have all the answers (far from it).
I wasn't attempting to dismiss leadership in any way, shape, or form. Merely calling out the difference between personally "doing" (in the sense of small business) versus the "orchestrating" that is more typical in a larger company.
I've worked in both and have seen how people that spent their career in a large company may struggle in a small business setting. No shame. Just a (often overlooked) distinction.
Given the list of what makes an execution person, would be a dumb mistake for someone like that to work for someone else. If you can do it all yourself, others would just slowly you down, seemingly.
This just sounds like bad understanding of how to hire the right people for the needs of your business.
If a coach fields a football team that's made up exclusively of quarterbacks, who's fault is that?
A team that can execute flawlessly, but has no vision and no solid ideas is not useful. A team that can come up with a million 'good' ideas, but has no ability to execute is just as bad.
Ultimately, your org needs to be built of the right balance of both sets of skills.
108 comments
[ 4.7 ms ] story [ 156 ms ] threadI iterate solutions much faster than most. Ive also since college done the hard yards to learn to execute/lead and obtain multiple deep skills including coding.
I know what people are talking about with the “all talk no action” person.
That’s not me, some of us really are excellent at iterating good ideas. It’s a discarded skill, but highly valuable once I’m on most teams, I can just never promote this strength due to the stigma.
furthermore there are some careers that mean you will not develop a reputation for follow through before you develop a reputation for ideas, for example if you are a consultant and brought into a place you will say a lot of ideas before you have the chance to follow through. In these situations you will be seen as all talk no action because you start off with lots of talk and nobody has experienced your actions. I'm sure similar scenarios can spring to mind.
If you’re actually executing and delivering results then you aren’t the stereotypical “idea guy” referred to here.
The problem with the stereotypical “idea guy” is that their flurry of ideas and constant changes becomes a roadblock to delivering anything at all. Their team is constantly destroyed by direction changes and burned out from chasing moving targets before they can possibly hit those targets.
The idea guy personality is the embodiment of the phrase “perfect is the enemy of good”. Every team has constrained resources, so delivering something imperfect is better than not delivering anything at all because the team burned out and ran out of money because the ideas were iterated faster than execution could allow.
- Idea guy says we should make a water-powered ferrari that costs $100.
- Technicians shut it down as impossible.
- Idea guy complains that technicians are short-sighted and shut down all of their ideas.
- Goto step 1.
I'm myself somewhat of a daydreamy type, but we have to understand that unless there's a specific, detailed plan, ideas really are a dime a dozen.
I'm not even trolling - sometimes playing with the 'impossible' demand yields useful results. You were just trying to create an artificially-impossible demand, so in this case it's not useful - but if it's a real customer "impossible" demand, trying to make it possible by rethinking the constraints can be actually valuable.
[+] https://www.amazon.com/Hydrogen-Powered-Radio-Control-Standa...
OTOH it's pretty well known that customers mostly don't know what they want, so deciding what is actually a constraint and what isn't is, paradoxically, a part of the job.
you dont have these ideas unless you are intimately familiar with the territory. and if you aren't, its very likely that any suggestions you might have wont be relevant because of its features.
https://www.youtube.com/watch?v=BKorP55Aqvg
Even in these situations, there will be the idea guys that really don't even have an answer to the first how, or what. The advantage is that you don't have to be the nasty technician telling them it's impossible, and turns the problem around to them being unable to formulate their ideas, usually due to not exploring it in depth.
I find “why?” is more aggressive and makes people talk more about the generalities of the idea, whereas with “how” and “what” I feel like I can get the why without asking it directly, and closer to the truth.
I think that's the thing the article notes to look for to find the right ideas person.
They're 'risky', but the article isn't saying they're 'bad'.
It sounds like you would pass their test as far as being able to execute.
I think another litmus test for idea-executor vs pure executor is your willingness to do throw-away work. A pure executor reads the design doc, says "sure", and just builds it— an idea-executor recognizes that the long-term maintenance of the system will almost certainly dwarf the initial cost of coding it up, and is willing to extend the discovery phase with partially-functional prototypes and so-on in order to really get a firm handle on whether the thing is going to go where they want it to go.
(Recent example— building up chunks of a moderately complicated build setup in parallel in Jenkins Pipeline and GitLab CI in order to understand how the two solutions would compare on maintainability, end user ergonomics, permissions hassles, flexibility, how much documentation we would need to support it, etc etc.)
My wife, in her previous job, was asked to do various kinds of "strengths evaluations" as her department wallowed and wandered trying to find a better direction (part of why it's her previous job...) and while I'm not sure how scientific any of them were, they were somewhat interesting.
One of them divided people up into four groups (whose precise names I may not all be getting right): Creatives, Executors, Marketers, and Refiners.
Each of these was vital at some point in the lifetime of a product or service, but the one that particularly interested us was Refiners. Previously, she'd thought of herself as very much a Creative type—an ideas person—but this drew a distinction between someone who just comes up with all kinds of crazy ideas—the Creative—and someone who can take ideas and iterate on them until they're actually executable—the Refiner.
Particularly in the environment she was in, that was a very useful distinction to be able to make, as there were a lot of people around her who just came up with idea after idea with no real concept of a) how to execute it, or b) whether it was actually going to be a good idea if they could.
I set the target and keep the team focused on the current main goal. The idea person hates me for it, because he sees good ideas being ignored. Those good ideas won't deliver substantial value to users until the next milestone is completed, because it is blocking something more important.
So, we should look at ourselves to make sure we are not only daydreamers, that ideas don't only work in our heads, that they might actually make sense in the real world too... But creativity is not the same skill as planning, and that's kinda ok too. It's good to keep your feet on the ground to avoid selling dreams, and I also really hate the people that will only talk big and then show no interest on working on some of their "best" ideas, but creativity is not the same as the ability to fully realize ideas, from creative inception to success. This later part requires many skills. Having reasonable and interesting ideas is only one of them.
Some people are more explorers, others executors. Probably are lots of other words to fit in there with slightly different meanings.
There is some (too much) pressure for everybody to be great at everything and when they are different enough are labeled as having a disease.
This is why people work together, to build on each other’s strengths.
The act of calling out gaps and offering solutions is their sweet spot."
Is this saying that 'calling out gaps and offering solutions' is awesome as long as they help implement the solutions?
Asking because for every person I knew who espouses ideas and won't help (too few to recall any) there are scores upon scores upon scores of people who compulsively resist fixes - no matter how many resources are provided for.
yet in the paragraph author states,
> As it turns out, they’ve spent their career at a big company and didn’t fully realize that much of their success was actually a team effort.
Insisting that an idea needs a team means that the person DOES realize that their success was a team effort.
Glaring inconsistency, I stopped reading here.
But what I failed to share will hopefully clear up the confusion. They didn't call that out during the hiring process. They talked themselves up as if they could succeed single-handedly. It wasn't shared until they were failing to show progress and then it became an excuse. It wasn't possible to give (or hire) them a team. In the end, the person was let go to find a bigger company with the resources and capacity they would need to succeed. No hard feelings... just not a fit.
Does that clear everything up?
But they won't say it.
If I had a dime for every "idea person" that wanted me to realize their harebrained AI-powered cheese straightener, for nothing, and they get all the money and credit, because it's "their idea," I'd be rich.
Yeah, I'm cynical.
Same. And I don’t worry about having enough work, or whether or not my big idea will work.
Pick the achievable ideas and make sure your team delivers. As capability improves, goals can get bigger.
Life is good.
I've prototyped enough of my own ideas to know that most ideas are shit.
I believe that a lot of these colossal startup failures are great ideas; poorly executed.
The people I'm working with now, had a great idea, but didn't have it "thought through."
I said "I'll realize it, but expect big changes. I'll be developing a running prototype, and we'll be tossing out things that looked good on paper, but fall flat, in execution."
That's exactly what has happened. It takes a lot of patience; on both the "idea person" level, and the "execution person" level. I need to take their ideas seriously, and they need to shut up and pay attention when I catalog the costs of their ideas in the real world.
It'll work out, and won't look at all like they thought, but I'm designing an excellent baseline for creativity. It will work very well, will be localizable, accessible, and will allow creatives to put a lot of chrome on things.
Take Noah Kagan’s term “wantrepreneur” as the groundwork for what I mean:
Person A’s ideas are: Get business cards, build a website, get pamphlets, buy equipment, buy a business car, and so-on.
Person B’s idea is: find 3 clients first, do the rest after.
Person A’s ideas are all objectively good, but many of us who have seen businesses come and go won’t count those as ideas, and therefore will say “you have a good idea that needs refining” when talking about the core idea for the business.
I think for startups in general you gotta blend a bit of those two strategies to be successful too. You gotta build a nice landing page to convince people you're serious to get some of those early meetings to convince other people you're serious.
I used to put a lot of energy into making clear that "execution guys" are allowed to climb up out of scope and change their minds about an approach. But at a point I think it's reasonable to look at this pattern and make the assessment that I do indeed possess some kind of skill.
One of the issues I have had with "idea people," is that they think that every deviation from their Big Idea is "bikeshedding."
On the other hand, I like to keep the product at "beta" quality from as close to the beginning as possible. That often means that I spend a lot of time developing infrastructure scaffolding (like persistent preferences, error handling, security, accessibility, localization or messaging systems).
This means that I'll suddenly stop producing new features for a few days, while I set up some infrastructure (that will result in an explosion of features in a few days).
In fact, I'm doing that, right now. I am writing a "developer" screen for the app I'm developing. It won't ship, but will allow other technical team members to do things like set up test servers, and evaluate REST interactions. The non-tech people aren't gonna see much for another week or so. They'll have to be happy with what I've already given them (and they are quite happy).
That's probably a confusing example.
I don't mean that implementers aren't doing anything. What I mean is something like this: the people who are building (or planning to build) a bike shed are often the last people to realize an obvious problem like a) the target audience is birds and b) birds don't ride bikes.
My professed skill is that I can get people to shift to working on a birdhouse. That avoids the danger of ending up with something like a bike shed retrofitted with pneumatic tubes designed to pump in birds from the outside world.
I'm not claiming this is a unique skill. But things like SVG's path arc syntax exist, so it's not ubiquitous.
You get a +1 for that. ;)
Totally get your example.
A healthy attitude, in my experience, is for others to workshop an idea that has a potential for a good payoff; both finding flaws and finding workarounds. This occurs with an open, collaborative culture.
An unhealthy attitude is expecting somebody with a good idea to put in 100% of the effort themselves, because that requires them to relearn/reinvent everybody else's specializations. This happens more with a rigid or competitive culture.
A survival strategy in the latter environment is to keep one's ideas secret, and (theoretically) solve future problems before anybody else knows that they'll crop up. In this way, an ideas person becomes the clinch-problem-solving-person because when the house is burning down, people are more willing to collaborate.
If your idea is that good, and you can't trust your "executor," then it's an idea that will either die in the crib, or will come out as a mutated, unhealthy monster.
Collaboration, between dedicated, creative ("execution people" can be very creative, you know) team members, working on an equal footing, with mutual respect and authority, works well (in my experience).
The company I worked at for years was not an especially creative one, but it had some heavy-duty science going on. Some of the folks they had in their R&D department were some of the best in the world.
But they also had a codified system, that worked fairly well, to realize their inventions in a way that could be commoditized, and that was because some of their "execution" people were also among the best in the world.
Echoing me here :) -- main problem with the article is that it represents, no, encourages, black-and-white thinking at a management level. Most of us are quite flexible, and tick both boxes, but we'll identify stronger with the label that feels more rewarding.
Yeah currently suffering from this... losing my mind coding the fifth 'refactor' (or better, learning I did everything wrong the last four times) so I can get to a product to generate enough revenue to appreciate a teammate's time by putting bread on their table. Self-inflicted.
I'm lucky I don't need many calories to maintain a healthy body weight, but I may have traded all this for some crispy dendrites.
I, personally, find substantially greater value in a person that produces something and is now sitting idle thinking of the next original product to complete opposed to the person who is busy or hard working.
DAOs seemed promising to improve this, however "crypto" is just a [potentially uneccesarry] piece of that puzzle. The real innovations that will make a DAO work haven't been discovered yet.
Somewhat of a false dichotomy.
Execution is the most important thing :)
Ideas are necessary. Without ideas, execution is hollow. I really value "idea people."
We just need to work together.
TFA goes on to list three characteristics of people who are dud team members, and 5 characteristics of good team members, but it doesn't do what it claimed it will - tell you how to identify such a person at the hiring stage.
TFA is an example of what it warns against.
If you are running a startup, at least one of the founders is "idea person". You don't need another one, especially not as an employee. It just doesn't bring any value to the business. Hire "execution person" to bring existing ideas further. An if "execution person" is not good, it will show, if not during the hiring phase, then soon later.
> if not during the hiring phase, then soon later.
How soon? A week? A month? A year?
Effective interviewing strategies are valuable to organisations because the trial and error approach to recruitment is so costly and disruptive.
As for execution person objective criteria exists, and it’s possible to evaluate performance, either at the hiring stage or soon afterwards. Evaluating idea person objectively in a short period of time is way harder.
https://www.businessinsider.com.au/daniel-kahneman-on-hiring...
This is normal for what is here given as 'idea' persons. It used to generate a lot of frustrations within me. Now I know that an idea person, or for that matter most entrepreneurs, will have ideas. They'll share their current version with much enthusiasm and will wake up energized the next morning with, for them, tiny iterations on that idea. For others, such as the engineer implementing it, those 'tiny iterations', are completely new and will require large amounts of rework.
One of my colleagues described it as the idea person being a little boat that is swarming around a large container ship. The container ship just isn't able to change course on the whims of the little boat.
I think we value that type of contribution (often allocating it to leaders, though every contributor does it to some extent) even though it might not materialize as "doing" anything.
Stopped reading here. It's not about ideas, it's about having an understanding what could be done. If thinking is grounded in reality and your resource constrains, ideas are worth a lot. Otherwise all your company would do is copy other companies.
You also end up with an attribution problem: it's easy to say what the big idea is, but it takes a lot of work to make it happen. Why give credit to the guy with the big picture, when the big picture is probably something the guy who implements it had as well? Devil is in the details.
You also don't get good ideas if you don't try to implement them. The implementation process is a creative process, which btw your ideas guy might not recognize, leading to issues.
I've had ideas guys where I worked before, and it was toxic. My view is basically that ideas guys are a kind of leech: they take credit for positive things that are obvious, they come up with excuses for things that are negative (team failed me boohoo), and they don't generate better ideas than people who are doing the implementation.
My experience is in quant trading, where you have people who can code, and sometimes people who just fluff about strategies. With the randomness and noise it's easy to be fooled by ideas guys, and it's taken me a long time to just dismiss the concept entirely. I actually just got off an interview where we discussed this problem in the space, and we agreed it's absolutely essential that people can code, otherwise their trading ideas are worthless.
That's why I was quick to call out that ideas have little true value without execution.
Ideas are born and die every day. We're naturally creative but we also (generally speaking) don't tend to follow-through. That's the real and hard part.
An average idea with excellent execution is worth a lot more than a great idea with poor execution.
outcome = idea x execution
So both are "multipliers" in the language of the model. The formula is completely symmetric in the two quantities.
So it would be more like - Good idea (1) x good execution(10) = 10 Great idea (1) x great execution (100) = 100
Ex: my great idea is that faster-than-light travel will REVOLUTIONIZE HUMANITY! Of course I’m an idea guy, so I cant be bothered with physics and engineering and special relativity and all that riff-raff. Let a specialized team figure that out. But hear me out - this is a BRILLIANT IDEA when finished. (That’ll be 100M seed funding, thank you very much.)
* Without execution, an idea is worth 0.
* Even without an idea, execution has value - go schedule a 45 minute meeting with a smart person with no set topic and something will happen.
* Execution is infinitely more effective than ideas at producing value.
For example, UX and design is now quite valued, and frequently you hear UX and design guys disparage engineering. Is that something we want to encourage? It's better to encourage making rational decisions about what skill set you need and who is best to supply them, so we are all judged on our merits and not based on self-marketting. Idea-generation is useful in a lot of contexts. Personally my best ideas have often been to figure out a way where we didn't need to execute a bunch of difficult stuff that the execution types were about to take on.
The person who said that he was an idea person who executes ideas all the time that it was stigmatized by morons is right.
In programming in particular, coming up with "ideas" and executing them immediately in your programming is pretty much a constant. And it's arguably what hacker, a real hacker, means by definition of word.
My experience is people who don't appreciate ideas are the first to plagiarize them, steal, or cover it up. In fact, its arguably what a lot of current big companies that are stagnating the country are running on. Advice - make sure you have no people in the company you make that think that way. Make it part of the interview - give them an opportunity to say the acceptably stigmatizing thing, and then eliminate them.
In fast growing startups, there are people who can hack they way out of most problems quickly. Such people are immensely useful during the exploratory phase and early growth phase.
If the startup continue on their growth trajectory into next hyper growth phase, they need deep systems thinkers to build better end to end systems that can deal with the inevitable product complexity, org growth and user growth.
They obviously cannot build complex systems all by themselves. They need that team of hackers to believe in and execute their systems vision. They are usually good at selling their vision to the hackers as well as to the org leadership.
In really successful startups that become unicorns and beyond, there are also great visionary org leaders who can curate and evolve harmonious and motivated teams that execute well to keep pace with the growth of the company.
Of course, while in middle of it all, it feels very chaotic and out of control.
Related: https://blog.gardeviance.org/2015/03/on-pioneers-settlers-to...
I worked with brilliant founders, who were really bad managers. It almost seemed like their high skills in engineering came from letting every other part of their personality deteriorate.
no, Microsoft brought in Jim Towne (from Tektronix) and then Jon Shirley (from Tandy), only then returned to founder Gates and, not founder Paul Allen but, Gates pal Steve Ballmer.
My motivation here was to share what I've learned. To benefit from my mistakes. Sidestep my missteps.
Ideas are great and necessary, but even great ones are only valuable if they can be acted upon. In a small business, an ideas-only person will have trouble succeeding. Being able to also (at least) kickstart the effort is critical.
I had to change the development process and cycle of my team, and even with instant buy-in it was tough.
Wow, since when "leading" isn't the most difficult/well-paid job in our society?
Overall, I think the author is mixing up apples with oranges and that's why this article sounds so weird. It's a very contradicting piece right here.
I wasn't attempting to dismiss leadership in any way, shape, or form. Merely calling out the difference between personally "doing" (in the sense of small business) versus the "orchestrating" that is more typical in a larger company.
I've worked in both and have seen how people that spent their career in a large company may struggle in a small business setting. No shame. Just a (often overlooked) distinction.
The 'skill' is to distill the ideas into an operational basis.
Both ops and new thinking are important.
If a coach fields a football team that's made up exclusively of quarterbacks, who's fault is that?
A team that can execute flawlessly, but has no vision and no solid ideas is not useful. A team that can come up with a million 'good' ideas, but has no ability to execute is just as bad.
Ultimately, your org needs to be built of the right balance of both sets of skills.