Pioneers vs. Process People
eidel.io
eidel.io
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.
"I've made the MVP"
"Ok, let's have a look... uh, if any of five remote servers so much as sneezes, this service will crap itself and die"
"It's fine, it'll restart itself after a few seconds thanks to some aws magic"
"And any ongoing transactions?"
"Details, whatever..."
As an aside I wonder if almost everyone would prefer to be the pioneer, but ends up getting stuck in process-land and maintenance hell.
And I'm still having trouble explaining to our engineers that sometimes it's okay to accrue tech debt if it serves a business purpose. We can have the most technically sound product but if the money runs out the game is over. Startups are a crazy sprint, not a well paced marathon.
The problem is if the tech debt is not a conscious decision you're making
[1] https://medium.com/@magicsandbox/mvp-the-art-of-cutting-corn...
I think most engineers are just not used to ever thinking about time and money as a constraint - they're just things abstracted away from them so they can do good work (or they've worked for companies where those aren't constraints). Just being up front with them about the fact that these constraints exist will usually change how they think about a problem (in my experience at least).
> The problem is if the tech debt is not a conscious decision you're making
100%. The entire debt metaphor fails if you aren't knowingly doing something that you're going to have to "pay off" later.
Why it works in our case is because I acknowledge it's a debt and then later we pay it back. A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along.
I do agree, most devs usually work in large companies where money and salary is an abstract thing several layers removed from them.
When I was a developer I used to despise some of the places I worked at, but now when I'm trying to start a company I see them in a much different light and see that a lot of things made sense
> Why it works in our case is because I acknowledge it's a debt and then later we pay it back. A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along.
I don't think it works any other way. A lot of times the only difference between "intentionally accrued tech debt" and "shoddy work"/"bugs"/"brittleness"/etc is communication.
> A huge problem devs have is - there is a push, promises are made, and then something new and urgent comes along.
If you're constrained by time and money, this is usually the case. You accrue tech debt to meet constraints, and you pay it off over time, not necessarily immediately. It's just normal roadmap prioritization. All you can do as an engineering leader is correctly advocate for the urgency of tech debt, communicate interdependency issues ("we must pay down this tech debt before we can tackle feature X"), and pay off some debt when it makes the most sense.
I personally hate the fact that agile, which started off as a couple people saying "we're all professionals and grownups here, let's talk regularly about how to combine this abstract thing we do with actual client needs" is now a whole industry.
Oh god, it's horrific.
There's now a whole profession of "scrum masters", most of whom haven't the first clue how to actually do anything much, and none of whom are needed - the scrum master was just the guy coordinating, a monor extra duty that could even rotate. But no, we have people hanging on to our industry, claiming to add value, who spend their days fussing over jira... it's a tragedy.
Management of course loves (perhaps even needs) to make a commodity of employee skills, so process is always pushed early and often. But even the heroes will get burned out or reach a point where the product is just too big to handle otherwise.
To my knowledge, few early-stage start-up succeeds this way. It's great to think we can make up for the pioneer-style solo contributors with any army of process IC's but I have yet to see that happen during the early years. You can just look at any current tech company and see that's the case - all of them had pioneers at the beginning that pushed forward incredible progress. Google, Microsoft, Intel, Cisco, Sun, SGI, Facebook are just some recent examples that come to mind.
Pioneers are not limited to programmers - it's more a mindset and mode of execution that cannot be sustained in larger orgs.
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.
The culture within the team can go south sooner than one realizes if the 'process' types feel they're constantly cleaning up the mess of pioneers (who tend to get more attention in general for their shinny projects). And on the other hand the pioneers may perceive process-types folks resist any new changes and are stuck supporting outdated technology. The truth usually lies somewhere in the middle.
Having the right mix, with good leadership, can balance out the worst qualities and enhance the best ones.
Alternately, with poor leadership and allowing personalities to run amok, you can find a team in a toxic situation.
So you'll need a good, experienced, team-building hiring manager who understands the balance of the necessary skills and personalities.
I am currently working on team that one guys rejects every single PR that doesn't also come with a description of change in Changelog.md .
You aren't giving us enough context to know whether that changelog requirement is a good one or not. But if your team has agreed on the process, either convince them to change the process, or try to understand why your (hopefully reasonable and competent) colleagues believe it's necessary.
what if your team is dominated by process people.
> try to understand why your (hopefully reasonable and competent) colleagues believe it's necessary.
only explanation that everyone agreed to was that "it makes it easier to see what changed"
If that's not your jam, consider a new job.
> only explanation that everyone agreed to was that "it makes it easier to see what changed"
Maybe it's safety critical software or there are downstream clients? Maybe it's open source? Maybe it's not actually every PR and we have an unreliable narrator? The post did start with "I hate process people", after all.
For what it's worth, I'm notoriously not a process person. But I've seen and respect stability they can bring to a team and product
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.
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
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".)
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.
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.
“pioneers” as mentioned in this article are not critical to a business, it’s the people who can do both ends of this spectrum
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.
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.
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.
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.
The whole 'scalability engineer' and 'compliance engineer' title mumbo jumbo sounds very phoney to me. As far as the compliance part is concerned I feel inclined to make up some fake dictionary definition for it in the style of the devils dictionary for maximum cynicism. Compliance: a lot of paperwork that asserts that a set of desirable attributes apply to the mirage that management has dreamt up about a project. The mirage may or may not be in any way related to the actual state of said project.
Scalability engineer and compliance engineer very much are phony mumbo jumbo from the perspective of a software engineer. However from the business perspective they are very real and I think they are helpful to communicate one’s own level of maturity and ability for the business owners to trust you to get things done for them. It’s about communication and signaling more than the reality of what you do.
> I’d be much more inclined to agree with you if I had encountered a v1 product that wasn’t a total clusterfuck!
I'm personally working on a v1, and (you'll have to take my word for it) it is far from that.
We are making conscious decisions: "here's a guess about the future that we're confident about, so we're willing to add in more structure/abstraction here," or, "We're not sure about the future of this feature set; let's be clean but minimal about it."
Also, co-workers have raved about our work on this project, including speed. So that's further evidence that it's a false dichotomy.
The code may have been bad, thrown together, and not architected correctly, but, if the company was able to get customers and become profitable enough or get funding to hire people to clean it up, they were a success.
The Twitter codebase was a well known clusterfuck, but they got product market fit and were able to survive long enough and become capitalized well enough to rearchitect their system.
This is key, regardless of whether you think that "doing it right the first time" would have not taken meaningfully longer, and paid off in the long run over and over.
For any meaningful product, you want to get customer feedback early and often, and you want to do it before your competitors get a chance to.
I say this as a more stereotypically "Process" person/developer than a "Pioneer". I know too many failure scenarios. I overthink. I get into analysis paralysis when there is an open page. I need that Pioneer to help my company and my team get started.
But give me an existing system, and I'll mold it and expand it as quickly as that 10x Pioneer.
I love taking shipped hacked together code, and gradually refactoring it and improving it for 10x, 100x scalability of both system throughput and development team growth.
The important factor here is shipped. In production, with customers. Customers who already see the value and benefit, and don't mind the occasional blips and glitches that will take much longer to fix (and probably require massive rewrites) to fix behind the scenes.
Beautiful code without users is worse than nothing at all.
Pioneers tend to be good at many domains; engineers tend to be great at one or a subset of domains. Specialists refine the toolsets and methodologies, while pioneers main goal is to just help prove business value.
When Pioneers leave an absolute mess in their wake, changes to the project take more and more time. There is a trade-off, and the "immature pioneer" mindset (working with no thought for the future maintenance of the code) can make the scaling / maturing process of a product needlessly painful and slow.
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.
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.
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 !