9 ms·

Pioneers vs. Process People

122 points by olieidel 7y ago

kristianc 7y ago
I’m not sure I accept the distinction. For the amount that the concept gets bandied around, there’s actually very little evidence that people fall into discrete personality types like these. We are all stronger and more experienced in some areas than others, but simply writing yourself off as ‘Not a process person’ removes your ability to level up and takes away your ability to do any better. It’s especially sad as these ‘scripts’ often do not come from inside, but are baked into people from leadership and then justified by Myers Briggs style psychobabble.
- sgawlik 7y ago
  I like the distinction between pioneer, settler, and city planner when thinking of the people working on new products. To me, it’s more about the lifecycle of a product as opposed to putting people into boxes. I feel like I know what business/code trade-offs I should make depending on which of those characters I’m currently playing. I also know what type of flexibility I should build into the product early on and which best practices can wait until market fit has been found. I wouldn’t want to take a city planner into the wilderness (sewers and squares before we know if anyone wants to even live here, lots of high quality code that has no users). And I also wouldn’t want to be a mayor having pioneers running my subway/water system (bandaid fixes, poor long-term decisions, spaghetti code) But I agree with you overall that people can adopt these roles based on context and aren’t limited by them
  - vibrolax 7y ago
    Over the course of 35 years developing software, I completed several circuits of pioneer/settler/planner loop. Learning to function well in all three domains was as important to increasing my professional value as learning different languages, tools, OS's, and problem domains.
- foolfoolz 7y ago
  i agree with this a lot about pioneers not “leveling up.” saying you’re a pioneer and can only do the initial work on a project and not bring it past the first stage isn’t some great skill. kind of like someone who gets promoted to level where they can’t perform and then are out of a job. and quitting the company because of it just shows immaturity and inability to learn “pioneers” as mentioned in this article are not critical to a business, it’s the people who can do both ends of this spectrum
- wool_gather 7y ago
  I think you're looking at it from the wrong angle. It's not about typecasting a individual person. It's about recognizing that there are these divisions in the work that's available. It's a feature of the environment, and you should recognize it and your relationship with it. Then you can be aware, for your own good, of where your preferences and strengths lie, and make conscious decisions about what to take on, whether working on your core competencies is wallowing or increasing your depth; whether a stretch would constitute "levelling up" or just stress. (Incidentally, in response to your swipe at Meyers-Briggs, the same is true there: it's a tool to help you recognize your own inclinations and be aware of them so that you can grow meaningfully and purposefully. It's not for boxing yourself in and saying, "I can't/shouldn't do that because I'm an ABCD".)
  - watwut 7y ago
    People do treat these as binary typecasting instead of shifting scales. On the leadership side, it means that they will treat as immutable personality type something that may be just reaction to the position you are in. And once you self-identify as pioneer (because it sounds cool) you just become more of pioneer and prevent yourself advantages of process (or vice versa). That is similar to the same problem as with Meyer-Briggs - most people are in the middle of all scales and their result shift over time. Those in the extreme end are rare. But both extreme and and middle get the same type description. And you end up inflexibly casted in one group although you are more similar to people in different groups that are also in the center then to extremes of own group.
- toast0 7y ago
  > writing yourself off as ‘Not a process person’ removes your ability to level up and takes away your ability to do any better. I've worked at places with varying levels of process. I don't get enjoyment or fulfillment from following a process, defining processes for others to follow, or from enforcing process on others. When I have choices, I would rather be paid to do things I enjoy and let me feel fullfillment than working at a job where I have to spend a lot of time doing stuff I don't enjoy. You can say, that proper process enables more productivity, but I haven't experienced that, and building better process isn't something I'm good at, so it makes sense for me to seek out opportunities with less process and more individual ownership and deployment freedom so I can be a cowboy.
k__ 7y ago
Reminds me of Wardley Maps. Pioneers experiment with new stuff. Settlers try to get good ideas in a more product-y form. Town planners make a easy reproducible commodity from it.
oweiler 7y ago
Pioneers: people who leave behind a clusterfuck for the other engineers to build upon.
- pif 7y ago
  I agree with you. In my opinion, shipping for the sake of shipping and moving to other pastures is as moral as a hit and run on the road.
  - satyrnein 7y ago
    Interesting analogy, and I would agree if the developer is intentionally concealing their actions to escape consequences. However, the situation is more often someone inexperienced doing a bad job, or someone experienced doing a bad job because they're crushed by unrealistic deadlines, or someone cutting corners intentionally because the company is in a do-or-die situation. None of these are immoral, but result in the same outcome.
  - scarface74 7y ago
    If they shipped, gained customers and allowed the company to make money, they did their job.
    - fogetti 7y ago
      I have to ask. Does this mean that maintenance is always someone else's responsibility and never someone's responsibility directly?
      - scarface74 7y ago
        Maintenance is not a “problem” even if I am the maintainer or in my case, the “rearchiterer”. It’s what they are paying me to do. What a company needs at one phase of its existence is different than at another phase. It would be just as wrong for me to come into a company at the beginning of its existence when they are just trying to go from 0 to MVP and worry about unit tests, branching strategy, and “process” as it would be to promote the pioneer to a team lead.
zdw 7y ago
The absolute best technical person is a meld of these two. Pure pioneers look like the fabled "10x programmer" on the outside, but leave a hellscape of technical debt in their wake. Pure process people are so busy building their perfect ivory tower they miss the actual goal of getting stuff done. Somewhere in the middle, where you've figured out how to move fast but also avoid causing the tech debt you've encountered in the past is the right place to be. This usually boils down to having good boilerplate when you start something - for code, that might be a trivial but well understood linting and testing framework that you can add at the start of a project, or a simple way to start documenting a business process.
- Pfhreak 7y ago
  Alternatively, build a team with a mix. Sometimes having a person passionate about process can be very helpful when they have a little tension with the pioneer types.
  - dpeck 7y ago
    True. They drove me a little crazy, but one of the best people I ever worked with was a “test enthusiast” and believed that anything not automated was going to eventually cause us trouble. It was good friction and made one helluva a system that managed to serve a couple hundred thousand remote clients while basically on autopilot for several years now.
    - Pfhreak 7y ago
      For sure. It means you actually have to be intentional about what you test. Best team I ever worked on had two loud, friendly, utterly opposite engineers when it came to excellence vs velocity. But it made us really talk through why we chose the things we did.
  - jniedrauer 7y ago
    I've found this to work extremely well. I tend to err on the side of caution, building well tested systems with carefully planned failure modes. I work very well with people who drive hard and spit out a ton of rapid prototype code that's full of bugs. It's frustrating, and there's often tension. But the end result is the best of both worlds.
pdimitar 7y ago
Well, I am again gradually becoming a pioneer -- after having been a very solid repair/maintenance programmer for most of my career. So the distinction in the article feels artificial and kind of extreme to me. It did a good job illustrating two extremes though, so not complaining. Reason for my transition back to pioneer is: teammates aren't willing to listen to me and I can literally observe how they paint themselves into a corner, in real time, with front-row seat. And if I even dare imply something like "I told you so" when things inevitably come to fixing tech debt for weeks without meaningful new features deployed then I get branded as non-constructive and bad team player, with them completely skipping the part where I offered help with their concrete ticket (and a small refactoring as I go). And that's only one example out of hundreds -- obviously I'm not talking about only one workplace. It got so bad that I started using 1-2h work hours a day to work on my own stuff, or just do invisible huge coding reviews and put notes aside with the hope they'll be useful one day. That way I can't get criticised for being the only guy who doesn't idolise shipping above everything else. I do ship but not several times a day, and I try to touch code carefully. I do agree shipping should be in the top priorities but it should be balanced with expected future tech debt and the ability to revisit the code months later and be actually able to work on it again. And of course, that never happens. Shipping is always an absolute top priority with zero "if"-s or "but"-s. Sigh. /rant --- Back to the article's topic, well, I was just saying that I am one of these people who were pioneers as teens and during their early career, quickly became the trusted go-to repair guy for everyone around because that made money and helped many others, but are now drifting back to being a tinkerer and a pioneer because nobody seems to want to listen to experience.
aytekin 7y ago
Pioneers are supposed to be working behind the scenes on the next version, not quitting the company.
- Ididntdothis 7y ago
  The problem is that in mature companies there is often no next version where you need pioneers. The next version is just an incremental change to the previous version. If the business is very management or sales driven then as engineer you are told exactly what to do in the shortest time. No room for or interest in pioneering work.
  - satyrnein 7y ago
    Even worse, sometimes it turns out that the business assumptions baked into the first version were completely wrong, and now have to be undone. The original pioneers can be the worst suited people for that work, if they are emotionally invested in the old approach.
  - czbond 7y ago
    I disagree - a bit. There is often a blue ocean that can be created in the industry or around it, and usually pioneers are part of a small group to see it first.
  - ScalaFan 7y ago
    Corollary to this is when a business is so mature that they decide to no longer take risks (or higher risk) by designing a new product, or go after a new market or go for the next disruptive change that is valid. Instead they go after reliability based on exploiting a current product or resource or asset and optimize the product or process to extract out yet even more value. The latter is always viewed as safer and more predictable than the former. The truth is to recognize that that is what is happening and accepting that in the long run, the latter will not produce sustainable growth.
mr_tristan 7y ago
What makes me uncomfortable is tying my professional identity up with a part of the product lifecycle. Sometimes it's just fun to take on risk, and other times, great to be able to eliminate risk. But fundamentally, almost everything in tech is a kind of wicked problem. Sometimes that problem domain sometimes shifts to areas where you have less control. Where things usually go off the rails are when you feel like you're no longer making contributions. I find _this_ is really what "pioneer people" are really griping about. It isn't that they need to "move fast and break things" or other such BS. It's that they got used to having control and seeing the impact of their work. After a while, things become complicated, and it becomes hard to see how they make much of a difference. Usually when I see one smart, inspired person leave because of "process", there's often a team left behind frequently spinning their wheels on something useless.
tel 7y ago
I strongly like the idea of pioneers as compared to "settlers" and "town planners" (see Simon Wardley's writing). But the idea that pioneers have and/or benefit from no process is BS. The best pioneer is structured and has process. A pioneer's job is to efficiently conduct tests to derisk some space. This involves the creation of lots of artifacts which do not, usually and probably for the best, include running, trustworthy foundational code. But that doesn't mean that work wasn't full of process. It's just often a little harder to scale and comes intuitively to some individuals. The process includes things like (a) rapidly reintegrating learning, (b) listing out assumptions and attacking them with an invalidation-minded perspective, (c) brainstorming novel ways to uncover new information cheaply, and (d) rapidly building new mental models and sharing them. That's process, too, but not process that creates a functioning machine. Just one that proves such a machine could exist. It's critical to not run the wrong process at the wrong time, so leaving when the pioneering is over can be a good move, but so might finding a new place for pioneering on the edges of the "settling" that's begun to move in.
deleted 7y ago
[deleted]
jojo2000 7y ago
Very interesting piece. Same experience here (jump in, build knowledge assets, build team). Last part different, be CTO's worst fear, have you team scrambled, projects refused, go somewhere else taking on a bigger and harder challenge. Funny part is they lost 2 years, hired obedient lead, then went on building exactly what I presented them. They even went to the press claiming this stuff was their own idea. How would you feel ? Yes, we hate meetings. We understand each other fast, work together at stellar speed, clash often. Sometimes, we code without tests. Bad practice ? Break my code. Pionners and process people are at odds most of the time. Let's push this idea further. Pionners are always despised by the tenants of current state of affairs. Bourdieu explained this very well regarding art. Why ? Process people have the power and spent most of their lives perfecting their current knowledge and craft. Inventing something disruptive will disrupt their power. Galileo, one example amongst a lot. Even the most advanced people at their time have had theirs quirks around this fact. Maxwell predicted that his models had solved physics and that the few problems remaining (like Black-body radiation) were minor problems, where it led to relativity and a new revolution in physics. Process people are made of habits that work well, ensuring intellectual comfort and easiness, which is very reassuring. We make you itch and scratch, because we live in never-ending uncertainty and know that theories are ephemeral in the grand scheme of things. Some dogmas of biology have collapsed in recent time. One of the most funny was "brain cells don't divide after end of adult growth"... This line of reasoning also invalidates a whole part of human theories about things. Fukuoka explained it very clearly: we draw pseudo-conclusions, only valid in a closed-system which in itself is a pale representation of reality. We try to reduce complexity to make it manageable by our current brain power. Those conclusions are wrong, when complexity is taken into account. Economics is based on wrong assumptions, but it works most of the time. Knowing this leads to respect and not mess with fundamental building blocks we don't understand (gene editing is such a monstruosity). Tell me about discomfort. Pionners are risk-taking, and don't bother about controversies, they create those. They are despised and critisized by process people because they disrupt and destroy, as they create new paradigms. Destruction créatrice. They overthrow intellectual kings. Speaking of experience, being a pionner is very difficult as everyone is against you and you got to prove to everyone that what you're doing is better and possible. Let's digress about personal examples in order to settle those assumptions into reality. When I was a kid I could solve the problems that math teacher gave using different methods. Most teachers would not even look at the method but rather blame it. They didn't want to make the intellectual effort to understand the stuff. When I did my PhD I destroyed theories of some peers using experiments. Well, let me tell you, my academic career didn't last long. When I worked in aerospace, during the day my boss yelled at me "shitty stuff", while copying my code in another codebase at night. How can pionners bring value to this world ? It's as hard as producing metallic hydrogen. How to convince an investor when you always look at things from another POV. When the problem you're tackling is far from solved. Risk seems too high. Let's rather focus on solving big corp problems and get easy money. Funny thing is : we have an ability to connect to each other. A gang of weirdos trying to attack the doxa. So, the problem is : can there be a collaboration between those two kind of people ? Here is a very fun example. Rust. This language brings to a large audience some very powerful concepts like ownership, truly a pioneering work. What do people do with that language ? Rewrite the same tools. Problem with pionners is we cannot stand repetitive work. So after the thrill of finding a new solution is gone, we tackle some other problem. That's were we can build together as innovating is far from enough, and there is a lot of work left for process people, as told by aforementioned piece. That's why I only work in small startups. Because once the group is too large, we are naturally surrounded by process people. Pionners are a small fraction of people. Once critical mass is reached, burden to leap forward is simply too high. Don't get me wrong. Too many pioneers together is a bad mix too. Pionners have strong opinions and this may lead to frequent clash and incompatibilities. Process people all have the same processes, so there is less to argue about. Following that line of reasoning, large organisations are just unable to produce breakthroughs. When processes take over, you're doomed. So much respect for Elon Musk who has built crazy ventures that manages to break paradigms. That's a crazy achievement. Same holds for Steve Jobs, who could torture an org to squeeze new ideas. But what's important ? Intellectual thrill or steady business ? Choose your horse !

122 points by olieidel 7y ago

I’m not sure I accept the distinction. For the amount that the concept gets bandied around, there’s actually very little evidence that people fall into discrete personality types like these. We are all stronger and more experienced in some areas than others, but simply writing yourself off as ‘Not a process person’ removes your ability to level up and takes away your ability to do any better. It’s especially sad as these ‘scripts’ often do not come from inside, but are baked into people from leadership and then justified by Myers Briggs style psychobabble.

sgawlik 7y ago
I like the distinction between pioneer, settler, and city planner when thinking of the people working on new products. To me, it’s more about the lifecycle of a product as opposed to putting people into boxes. I feel like I know what business/code trade-offs I should make depending on which of those characters I’m currently playing. I also know what type of flexibility I should build into the product early on and which best practices can wait until market fit has been found. I wouldn’t want to take a city planner into the wilderness (sewers and squares before we know if anyone wants to even live here, lots of high quality code that has no users). And I also wouldn’t want to be a mayor having pioneers running my subway/water system (bandaid fixes, poor long-term decisions, spaghetti code) But I agree with you overall that people can adopt these roles based on context and aren’t limited by them
- vibrolax 7y ago
  Over the course of 35 years developing software, I completed several circuits of pioneer/settler/planner loop. Learning to function well in all three domains was as important to increasing my professional value as learning different languages, tools, OS's, and problem domains.
foolfoolz 7y ago
i agree with this a lot about pioneers not “leveling up.” saying you’re a pioneer and can only do the initial work on a project and not bring it past the first stage isn’t some great skill. kind of like someone who gets promoted to level where they can’t perform and then are out of a job. and quitting the company because of it just shows immaturity and inability to learn “pioneers” as mentioned in this article are not critical to a business, it’s the people who can do both ends of this spectrum
wool_gather 7y ago
I think you're looking at it from the wrong angle. It's not about typecasting a individual person. It's about recognizing that there are these divisions in the work that's available. It's a feature of the environment, and you should recognize it and your relationship with it. Then you can be aware, for your own good, of where your preferences and strengths lie, and make conscious decisions about what to take on, whether working on your core competencies is wallowing or increasing your depth; whether a stretch would constitute "levelling up" or just stress. (Incidentally, in response to your swipe at Meyers-Briggs, the same is true there: it's a tool to help you recognize your own inclinations and be aware of them so that you can grow meaningfully and purposefully. It's not for boxing yourself in and saying, "I can't/shouldn't do that because I'm an ABCD".)
- watwut 7y ago
  People do treat these as binary typecasting instead of shifting scales. On the leadership side, it means that they will treat as immutable personality type something that may be just reaction to the position you are in. And once you self-identify as pioneer (because it sounds cool) you just become more of pioneer and prevent yourself advantages of process (or vice versa). That is similar to the same problem as with Meyer-Briggs - most people are in the middle of all scales and their result shift over time. Those in the extreme end are rare. But both extreme and and middle get the same type description. And you end up inflexibly casted in one group although you are more similar to people in different groups that are also in the center then to extremes of own group.
toast0 7y ago
> writing yourself off as ‘Not a process person’ removes your ability to level up and takes away your ability to do any better. I've worked at places with varying levels of process. I don't get enjoyment or fulfillment from following a process, defining processes for others to follow, or from enforcing process on others. When I have choices, I would rather be paid to do things I enjoy and let me feel fullfillment than working at a job where I have to spend a lot of time doing stuff I don't enjoy. You can say, that proper process enables more productivity, but I haven't experienced that, and building better process isn't something I'm good at, so it makes sense for me to seek out opportunities with less process and more individual ownership and deployment freedom so I can be a cowboy.

k__ 7y ago

Reminds me of Wardley Maps. Pioneers experiment with new stuff. Settlers try to get good ideas in a more product-y form. Town planners make a easy reproducible commodity from it.

oweiler 7y ago

Pioneers: people who leave behind a clusterfuck for the other engineers to build upon.

pif 7y ago
I agree with you. In my opinion, shipping for the sake of shipping and moving to other pastures is as moral as a hit and run on the road.
- satyrnein 7y ago
  Interesting analogy, and I would agree if the developer is intentionally concealing their actions to escape consequences. However, the situation is more often someone inexperienced doing a bad job, or someone experienced doing a bad job because they're crushed by unrealistic deadlines, or someone cutting corners intentionally because the company is in a do-or-die situation. None of these are immoral, but result in the same outcome.
- scarface74 7y ago
  If they shipped, gained customers and allowed the company to make money, they did their job.
  - fogetti 7y ago
    I have to ask. Does this mean that maintenance is always someone else's responsibility and never someone's responsibility directly?
    - scarface74 7y ago
      Maintenance is not a “problem” even if I am the maintainer or in my case, the “rearchiterer”. It’s what they are paying me to do. What a company needs at one phase of its existence is different than at another phase. It would be just as wrong for me to come into a company at the beginning of its existence when they are just trying to go from 0 to MVP and worry about unit tests, branching strategy, and “process” as it would be to promote the pioneer to a team lead.

zdw 7y ago

The absolute best technical person is a meld of these two. Pure pioneers look like the fabled "10x programmer" on the outside, but leave a hellscape of technical debt in their wake. Pure process people are so busy building their perfect ivory tower they miss the actual goal of getting stuff done. Somewhere in the middle, where you've figured out how to move fast but also avoid causing the tech debt you've encountered in the past is the right place to be. This usually boils down to having good boilerplate when you start something - for code, that might be a trivial but well understood linting and testing framework that you can add at the start of a project, or a simple way to start documenting a business process.

Pfhreak 7y ago
Alternatively, build a team with a mix. Sometimes having a person passionate about process can be very helpful when they have a little tension with the pioneer types.
- dpeck 7y ago
  True. They drove me a little crazy, but one of the best people I ever worked with was a “test enthusiast” and believed that anything not automated was going to eventually cause us trouble. It was good friction and made one helluva a system that managed to serve a couple hundred thousand remote clients while basically on autopilot for several years now.
  - Pfhreak 7y ago
    For sure. It means you actually have to be intentional about what you test. Best team I ever worked on had two loud, friendly, utterly opposite engineers when it came to excellence vs velocity. But it made us really talk through why we chose the things we did.
- jniedrauer 7y ago
  I've found this to work extremely well. I tend to err on the side of caution, building well tested systems with carefully planned failure modes. I work very well with people who drive hard and spit out a ton of rapid prototype code that's full of bugs. It's frustrating, and there's often tension. But the end result is the best of both worlds.

pdimitar 7y ago

Well, I am again gradually becoming a pioneer -- after having been a very solid repair/maintenance programmer for most of my career. So the distinction in the article feels artificial and kind of extreme to me. It did a good job illustrating two extremes though, so not complaining. Reason for my transition back to pioneer is: teammates aren't willing to listen to me and I can literally observe how they paint themselves into a corner, in real time, with front-row seat. And if I even dare imply something like "I told you so" when things inevitably come to fixing tech debt for weeks without meaningful new features deployed then I get branded as non-constructive and bad team player, with them completely skipping the part where I offered help with their concrete ticket (and a small refactoring as I go). And that's only one example out of hundreds -- obviously I'm not talking about only one workplace. It got so bad that I started using 1-2h work hours a day to work on my own stuff, or just do invisible huge coding reviews and put notes aside with the hope they'll be useful one day. That way I can't get criticised for being the only guy who doesn't idolise shipping above everything else. I do ship but not several times a day, and I try to touch code carefully. I do agree shipping should be in the top priorities but it should be balanced with expected future tech debt and the ability to revisit the code months later and be actually able to work on it again. And of course, that never happens. Shipping is always an absolute top priority with zero "if"-s or "but"-s. Sigh. /rant --- Back to the article's topic, well, I was just saying that I am one of these people who were pioneers as teens and during their early career, quickly became the trusted go-to repair guy for everyone around because that made money and helped many others, but are now drifting back to being a tinkerer and a pioneer because nobody seems to want to listen to experience.

aytekin 7y ago

Pioneers are supposed to be working behind the scenes on the next version, not quitting the company.

Ididntdothis 7y ago
The problem is that in mature companies there is often no next version where you need pioneers. The next version is just an incremental change to the previous version. If the business is very management or sales driven then as engineer you are told exactly what to do in the shortest time. No room for or interest in pioneering work.
- satyrnein 7y ago
  Even worse, sometimes it turns out that the business assumptions baked into the first version were completely wrong, and now have to be undone. The original pioneers can be the worst suited people for that work, if they are emotionally invested in the old approach.
- czbond 7y ago
  I disagree - a bit. There is often a blue ocean that can be created in the industry or around it, and usually pioneers are part of a small group to see it first.
- ScalaFan 7y ago
  Corollary to this is when a business is so mature that they decide to no longer take risks (or higher risk) by designing a new product, or go after a new market or go for the next disruptive change that is valid. Instead they go after reliability based on exploiting a current product or resource or asset and optimize the product or process to extract out yet even more value. The latter is always viewed as safer and more predictable than the former. The truth is to recognize that that is what is happening and accepting that in the long run, the latter will not produce sustainable growth.

mr_tristan 7y ago

What makes me uncomfortable is tying my professional identity up with a part of the product lifecycle. Sometimes it's just fun to take on risk, and other times, great to be able to eliminate risk. But fundamentally, almost everything in tech is a kind of wicked problem. Sometimes that problem domain sometimes shifts to areas where you have less control. Where things usually go off the rails are when you feel like you're no longer making contributions. I find _this_ is really what "pioneer people" are really griping about. It isn't that they need to "move fast and break things" or other such BS. It's that they got used to having control and seeing the impact of their work. After a while, things become complicated, and it becomes hard to see how they make much of a difference. Usually when I see one smart, inspired person leave because of "process", there's often a team left behind frequently spinning their wheels on something useless.

tel 7y ago

I strongly like the idea of pioneers as compared to "settlers" and "town planners" (see Simon Wardley's writing). But the idea that pioneers have and/or benefit from no process is BS. The best pioneer is structured and has process. A pioneer's job is to efficiently conduct tests to derisk some space. This involves the creation of lots of artifacts which do not, usually and probably for the best, include running, trustworthy foundational code. But that doesn't mean that work wasn't full of process. It's just often a little harder to scale and comes intuitively to some individuals. The process includes things like (a) rapidly reintegrating learning, (b) listing out assumptions and attacking them with an invalidation-minded perspective, (c) brainstorming novel ways to uncover new information cheaply, and (d) rapidly building new mental models and sharing them. That's process, too, but not process that creates a functioning machine. Just one that proves such a machine could exist. It's critical to not run the wrong process at the wrong time, so leaving when the pioneering is over can be a good move, but so might finding a new place for pioneering on the edges of the "settling" that's begun to move in.

deleted 7y ago

[deleted]

jojo2000 7y ago

Very interesting piece. Same experience here (jump in, build knowledge assets, build team). Last part different, be CTO's worst fear, have you team scrambled, projects refused, go somewhere else taking on a bigger and harder challenge. Funny part is they lost 2 years, hired obedient lead, then went on building exactly what I presented them. They even went to the press claiming this stuff was their own idea. How would you feel ? Yes, we hate meetings. We understand each other fast, work together at stellar speed, clash often. Sometimes, we code without tests. Bad practice ? Break my code. Pionners and process people are at odds most of the time. Let's push this idea further. Pionners are always despised by the tenants of current state of affairs. Bourdieu explained this very well regarding art. Why ? Process people have the power and spent most of their lives perfecting their current knowledge and craft. Inventing something disruptive will disrupt their power. Galileo, one example amongst a lot. Even the most advanced people at their time have had theirs quirks around this fact. Maxwell predicted that his models had solved physics and that the few problems remaining (like Black-body radiation) were minor problems, where it led to relativity and a new revolution in physics. Process people are made of habits that work well, ensuring intellectual comfort and easiness, which is very reassuring. We make you itch and scratch, because we live in never-ending uncertainty and know that theories are ephemeral in the grand scheme of things. Some dogmas of biology have collapsed in recent time. One of the most funny was "brain cells don't divide after end of adult growth"... This line of reasoning also invalidates a whole part of human theories about things. Fukuoka explained it very clearly: we draw pseudo-conclusions, only valid in a closed-system which in itself is a pale representation of reality. We try to reduce complexity to make it manageable by our current brain power. Those conclusions are wrong, when complexity is taken into account. Economics is based on wrong assumptions, but it works most of the time. Knowing this leads to respect and not mess with fundamental building blocks we don't understand (gene editing is such a monstruosity). Tell me about discomfort. Pionners are risk-taking, and don't bother about controversies, they create those. They are despised and critisized by process people because they disrupt and destroy, as they create new paradigms. Destruction créatrice. They overthrow intellectual kings. Speaking of experience, being a pionner is very difficult as everyone is against you and you got to prove to everyone that what you're doing is better and possible. Let's digress about personal examples in order to settle those assumptions into reality. When I was a kid I could solve the problems that math teacher gave using different methods. Most teachers would not even look at the method but rather blame it. They didn't want to make the intellectual effort to understand the stuff. When I did my PhD I destroyed theories of some peers using experiments. Well, let me tell you, my academic career didn't last long. When I worked in aerospace, during the day my boss yelled at me "shitty stuff", while copying my code in another codebase at night. How can pionners bring value to this world ? It's as hard as producing metallic hydrogen. How to convince an investor when you always look at things from another POV. When the problem you're tackling is far from solved. Risk seems too high. Let's rather focus on solving big corp problems and get easy money. Funny thing is : we have an ability to connect to each other. A gang of weirdos trying to attack the doxa. So, the problem is : can there be a collaboration between those two kind of people ? Here is a very fun example. Rust. This language brings to a large audience some very powerful concepts like ownership, truly a pioneering work. What do people do with that language ? Rewrite the same tools. Problem with pionners is we cannot stand repetitive work. So after the thrill of finding a new solution is gone, we tackle some other problem. That's were we can build together as innovating is far from enough, and there is a lot of work left for process people, as told by aforementioned piece. That's why I only work in small startups. Because once the group is too large, we are naturally surrounded by process people. Pionners are a small fraction of people. Once critical mass is reached, burden to leap forward is simply too high. Don't get me wrong. Too many pioneers together is a bad mix too. Pionners have strong opinions and this may lead to frequent clash and incompatibilities. Process people all have the same processes, so there is less to argue about. Following that line of reasoning, large organisations are just unable to produce breakthroughs. When processes take over, you're doomed. So much respect for Elon Musk who has built crazy ventures that manages to break paradigms. That's a crazy achievement. Same holds for Steve Jobs, who could torture an org to squeeze new ideas. But what's important ? Intellectual thrill or steady business ? Choose your horse !