
Pioneers vs. Process People - olieidel
https://www.eidel.io/2020/01/31/pioneers-vs-process-people/
======
zdw
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
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
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
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.

------
kristianc
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
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
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.

------
mr_tristan
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.

------
pdimitar
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.

------
tel
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.

------
k__
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.

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

~~~
Ididntdothis
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.

~~~
ScalaFan
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.

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

~~~
pif
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.

~~~
scarface74
If they shipped, gained customers and allowed the company to make money, they
did their job.

~~~
fogetti
I have to ask. Does this mean that maintenance is always someone else's
responsibility and never someone's responsibility directly?

~~~
scarface74
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.

------
jojo2000
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 !

