
Implementers, Solvers, and Finders - RKoutnik
https://rkoutnik.com/2016/04/21/implementers-solvers-and-finders.html
======
gtrubetskoy
This reminds me of a Steve Jobs quote "it doesn't make sense to hire smart
people and tell them what to do; we hire smart people so they can tell us what
to do." Any company that doesn't have this as part of its culture will feel
very depressing to creative people.

~~~
p4wnc6
Even Apple doesn't do it that way. Like many things Steve Jobs said, it
contradicts what he did. The things we say about ourselves espouse ideals and
far-mode thinking to enrich our status and legacy. But the brass tacks of what
we actually do is still boring, controlling, manipulative, micromanagerial,
and petty.

I've never encountered any company, nor heard of one, that enacts the advice
of that Jobs quote.

In fact, I've recently been taking a deep dive into some organizational
management literature to try to better understand where these absolutely ass
backwards ideas of "cross functional" and "full stack" teams came from, and
why they are so bundled together with open-plan offices.

I found an interesting paper [0] that seems to serve as somewhat of a basis
paper in this area, and which makes bald and unsupported claims about the
superiority of what are called "process complete teams" (this, as far as my
research has yielded so far, seems to be the prototerm that led to "full
stack" and "cross functional").

The entire idea of this management philosophy is that you _exactly_ should
hire smart people then tell them what to do. The advice is basically to take
generically smart people and then re-train them to have a generalist skill set
as it relates to your business, so that every person can do every task, from
talking to the customer to filling out the right paperwork to actually writing
the code (whether it is front end, back end, whatever) and walking through all
of the steps from start to finish.

The paper advocates having a small number of job titles in an organization,
each of which has many employees with that title, and to create teams and
positions with enormous overlap in terms of their skill set and responsibility
set.

The paper makes all sorts of weakly supported (or entirely unsupported) claims
that organizing by specialization (what they call "functional" units) is bad,
and spends time talking about how to "break" specialist employees form their
mindset that their specialization matters and instill into them a cross-
functional "sense of responsibility" for the entire possible pipeline of work.

This is where the ties to open-plan seating arrangements come from. It is
argued that open-plan, community seating creates a communal sense of
responsibility for the entire pipeline of work, whereas even changing to an
organizational structure that is "cross functional" or "full stack" is not
enough whenever employees are allowed to have privacy while doing their work
-- their privacy, so it is argued, and private work habits prevent you from
successfully "breaking" their mindset that they are a specialist focusing on
their special subset of tasks. _Eerily similar to both military indoctrination
and prison inmate indoctrination..._

It's very easy to see how this mid 1990s organization literature has created
the bizarre dysfunction of modern "cross-functional" teams and "full stack"
developers, leading to Agile/Scrum bullshit, pan-everything job ads with a
million bullet points, the treatment of specialized workers as
undifferentiated cogs, and the flagrant hostility on the part of the modern HR
apparatus towards employees whose sense of pride in their personal specialty
(something they had to protect in order to have a resume that would have
gotten them hired in the first place) leads them to protect themselves by
demanding an employer provide relevant work resulting in HR labeling them as
"not a team player" or some other buzzword meant to "break" them (isn't it
insane that a professional management article is using language like
"breaking" an employee, like this is boot camp or something??).

Anyway, while I love indulging in some good far-mode thinking about the peachy
world where companies actually hired specialists and did the real work of
managing them (instead of the lazy "throw it all in a cross-functional bucket"
non-management they do now), it's just not the world we live in.

[0] "Breaking the Functional Mind-Set in Process Organizations" Ann Majchrzak
and Qianwei Wang. Harvard Business Review, Sep/Oct Issue 1996. <
[http://business.unr.edu/faculty/Kuechler/788/breaking%20the%...](http://business.unr.edu/faculty/Kuechler/788/breaking%20the%20functional%20mindset.pdf)
>

~~~
RKoutnik
> I've never encountered any company, nor heard of one, that enacts the advice
> of that Jobs quote.

You should read our culture deck (especially the section about "context, not
control", starting at slide 80):
[http://www.slideshare.net/reed2001/culture-1798664](http://www.slideshare.net/reed2001/culture-1798664)

~~~
p4wnc6
I've read the Netflix document many times. To be fair, I don't have any
special knowledge about working at Netflix to suggest that Netflix doesn't
actually empower specialists. I am curious if Netflix avoids Agile/Scrum or
offers real private working conditions though, and if not, why not? Answers
focused on "collaboration" would count as evidence that, contrary to the slide
deck, you aren't actually "hiring smart people and getting out of their way."

~~~
RKoutnik
Generally we have cubes (as far as working space goes). It's up to the teams
if they want Agile/Scrum (most don't, a few find it useful, folks are
encouraged to experiment).

Collaboration, in contrast to many other valley companies, isn't a big
priority. Since we only hire senior (Finder) devs, each is capable of taking
on one or more projects almost solo. So where you'd have an ~8 person team at
Google, Netflix has a single developer. There are pros & cons to this
approach, I might talk about them in a future article. The practical upshot is
that everyone does what they think is best for their particular project
(others are encouraged to provide feedback but the ultimate decision is left
up to the project owner [who is not a manager]).

Does that help?

~~~
p4wnc6
If you can guarantee that non-Agile teams never have deliverables required for
Agile teams (and it sounds like such a guarantee is something you strive for),
then this seems reasonable. But it seems very fragile if you can't guarantee
that condition.

"Do what you feel is best" is the right attitude, so at least it suggests you
treat employees as grown-ups. But I would worry how that "do what you feel is
best" property could possibly trickle down to subordinates within Agile teams.

~~~
RKoutnik
> But I would worry how that "do what you feel is best" property could
> possibly trickle down to subordinates within Agile teams.

Simple, we don't have subordinates (at least as far as I know). Netflix only
hires Sr. devs and then empowers them.

~~~
p4wnc6
Subordinate is just anybody who has to take direct instruction from someone
else. Doesn't have to be codified via job title. If you have a "team" that
does Agile, you thereby have subordinates (the members of that team,
subordinate to whomever is reviewing e.g. burndown) even if no one calls them
subordinates or explicitly thinks of them that way.

------
russell
The Koutnik links to this article, which inspired his essay.
[http://thecodist.com/article/my-biggest-regret-as-a-
programm...](http://thecodist.com/article/my-biggest-regret-as-a-programmer).

It was very painful to read, because I made exactly the same decision. I was
VP/chief developer at a company that withered on the vine after a 10 year
roller coaster ride at a software company that I had co-founded. I had two
paths: I could have looked for a VP/Director job or I could have continued on
as a Developer/Consultant. The money was pretty much the same, so I took the
consultant route. The money was pretty much the same and programming was more
fun.

All went reasonably well until September 2008. I had just finished a very
satisfying consulting gig, but I walked out into a very changed world. The day
after was the banking crash. Even earlier a divorce had taken me to the
cleaners. But far worse, small interesting companies had no use for older,
still up-to-date, still competent developers. I found myself going from Finder
to Implementer. Agile development, which had seemed like a boon, turned into a
tool to lock everyone into two week death marches controlled by upper
management. Technical decisions where made by people who didnt have a clue.

Just as in the linked article, a woman working for me in the 80s took the
management route and was a VP in a major SV software company a few years
later. Now she is quite well off. Good for her; we are good friends.

Moral? If you are a software developer, dont get old. (I'm still doing it
because I like it.)

~~~
RKoutnik
Wow, I'm sorry to hear about your experience. That must have been an
exceptionally crummy time in your life. Here's hoping things have been better
for you. If you're ever in the bay area, shoot me an email (in my profile) and
I'll buy you a burrito just to hear more of the stories you've got (and
hopefully, happier ones).

~~~
seangrogg
Thanks, now I'm missing the Mission... =/

------
lliamander
On Job Titles: I think it is unfortunate that Senior Engineer is a title that
is often now in the middle of the career ladder[0] but I feel that has more to
do with the fact that historically most companies didn't have a technical
career path like some do now.

Those companies that only have the three levels (Junior, Intermediate, and
Senior) are generally speaking not looking for Finders to fill their senior-
level positions; their business model just doesn't call for it. At most, their
looking for Solvers who can also give direction to the more junior engineers.
In many places that's all you need.

However, I think at companies where technological innovation is a strategic
business value, you need to be able to distinguish between different levels of
Solvers (Senior vs. Staff engineer) as well as identify and reward Finders
(Principal and beyond).

I think its important to have the larger list of job titles because I think it
communicates valuable information to non-engineers, but I also think
separating out this notion of autonomy is really useful and I think can help a
lot of technical people think about where they want to go with their career.
Thank you for sharing.

[0][http://changelog.ca/log/2013/08/09/software_engineer_title_l...](http://changelog.ca/log/2013/08/09/software_engineer_title_ladder)

edit: minor grammatical issues

------
henrik_w
Maybe my experience isn't typical, but working as a SW developer gives me a
lot of autonomy, even if am "just implementing features".

First off, the requirements are "what should happen", not "how it should be
done" (the latter is up to me, or the team).

Secondly, I often end up discussing the requirement with the product owner.
What should happen if this happens? Why don't we do it like this instead? It's
often a back-and-forth before we arrive at the actual requirements.

Then comes the implementation phase, where it's up to me how to solve it in
code. So in my opinion, I do get a lot of say in what to do, and get to make a
lot of decisions - which is why I still love coding, even after 25 years:
[https://henrikwarne.com/2012/06/02/why-i-love-
coding/](https://henrikwarne.com/2012/06/02/why-i-love-coding/)

~~~
cableshaft
I don't know about how typical it is necessarily, because I have a more
similar experience to you, but I've definitely worked at jobs where I wasn't
only told what to do, but how to implement it (usually by architects).

------
thinkingkong
There are two really good rules for building teams that have worked well for a
bunch of companies I've observed and been a part of.

\- Only hire people better than you

\- Ensure you create a workplace with high alignment and high autonomy

Management's job is not to dictate solutions or to be "the people with the
answers". It's their _responsibility_ to make sure the constraints are set
properly, and that the environment allows smart people to do their best work.

~~~
wccrawford
"Only hire people better than you"

I've got a few issues with that. First, and I know it's ego-centric, but I
don't get a chance to hire many coders who are _better_ than me. I've only met
a few of them, IMO. That's partially because it's so hard to judge others, but
partially because I honestly don't think they code as well as I do.

Second, just because they aren't better than me right now doesn't mean they
can't surpass me in the future. If I rejected people just because they aren't
better than me, I'm denying them the chance to grow and the company the chance
to help and prosper from that growth.

I'm sure I'd have other objections if I sat and thought about it for a while,
but those 2 came to mind rather quickly.

~~~
RKoutnik
I've switched to using "Only hire people who bring new things to the team"
rather than "better than" because the latter assumes that talent is linear. So
if your team already had expertise in one area, don't hire in that area - add
people who will be coming to the problems you have from a different direction.
It's hard to innovate when everyone's just a carbon copy.

------
mindcrime
I think that, at the end of the day, most companies have no clue how to
properly utilize really smart and self-directed people (Finders). And that's
at least due, in part, to the way granting people serious autonomy break the
"command and control" structure that most people are so familiar / comfortable
with.

Many (most) of the Finder types are probably better off leaving and launching
startups, as opposed to trying to carve out a niche in someone else's company.

------
SatvikBeri
I like this framework–it captures different levels of autonomy in different
development jobs. As my career has advanced, it's definitely moved from
implementer to problem solver, with occasional elements of problem finder. I
have a lot of autonomy, but still get to spend most of my time writing code
(or rather, thinking about code.)

I don't think I want to be a problem finder, at least not yet. Being given
business problems and solving them feels like the point where my brain can
really engage without feeling like my work is either too vague or too
controlled to be important.

~~~
RKoutnik
Glad this article helped you out - and no worries about needed to shoot to the
next level. There are some great advantages to the Solver level - as you've
mentioned, there's plenty of space to play & learn without worrying about
incredibly vague instructions.

Enjoy it all you want. I can't begrudge someone who's found someplace that
makes them happy.

~~~
mindcrime
_and no worries about needed to shoot to the next level_

I think it's a bit off to characterize them as "levels" in the sense that a
"higher" level is "better" than a lower level. My sense is that some people
want near complete autonomy (I do, for example), but other people would be
very uncomfortable in that kind of role (or at least, ineffective). I suspect
this overlaps to some extent with some basic personality characteristics as
well as goals / intrinsic motivation.

Still, it's a very interesting and worthwhile article, and I believe this
definitely contributes something new and useful to the overall discussion.
I'll definitely use some of these ideas in the future when it comes to hiring
and what-not.

------
outworlder
Three years is more than enough for a good and motivated programmer to become
disillusioned and want to be a manager to "escape" or to "do it better". Only
to fall in the same traps previous engineer-turned-managers fell into.

One of the things that I've started to say to friends for the past few years
is that "The worst thing that I ever did was to turn a hobby into a full-time
job."

I mean that only half-seriously. I imagine how much worse it would be to do
something I did not enjoy doing previously even as a hobby.

Still, the motivation dies from a thousand cuts, until all that remains is
looking forward to having more free time, so that one can finally do really
interesting things.

Unless one is afforded John Carmack-levels of autonomy...

------
ChuckMcM
This is an awesome insight. In the past I've matched them up this way, coder =
implementor, tech lead = solver, architect = finder. It has always been
interesting to me to look at the skills that made people good in each of those
roles, whether it is attention to detail in implementors, breadth of
understanding in solvers, or skill diversity in finders.

------
augb
Perhaps _problem finder_ should be _solution seeker_? Not everything requiring
this level of insight/autonomy is a problem (in the sense of a negative),
often a new opportunity for an entity or an individual _does_ need a solution,
however.

Edit: Grammar fix

------
lliamander
On Autonomy:

For those developers who are complaining about management anti-patterns, I
don't think they necessarily want autonomy. I think they really do want just
better managers, but the truth is that, whether or not they want it, they need
autonomy to counteract/avoid bad management.

Everyone is flawed, including managers. You can try and "fix" managers, but
that generally works out as well as trying to "fix" anyone else that isn't
yourself. The best thing to do is to restrict the scope of those who manage
you and increase the scope of your own self-management.

However, most people (if they are honest) are their own worst boss. They work
for other people because the alternative would be to work for themselves.
Having come to that realization a few years ago, I have definitely been
working to improve my self-management. A consequence of this is that I come to
crave that autonomy.

I also get to be more picky about who I work for: if I do a pretty decent job
at managing myself, you're going to have to really impress me if you want me
to hand that job off to you instead.

------
pleasanthipster
It's not about skill. My brother who recently started programming has a lot of
autonomy at work because he's trying to help out the business in anything he
does there. Same thing has happened to me. Your boss is more likely to let you
do your own thing when you actually want to help make the company and your
boss succeed. Again it's not always about skill

~~~
Delmania
The quickest way up the ladder is to prove to the person above you that his
(or her concerns) are yours, and to proactively solve them.

~~~
taneq
This depends entirely on the person above you. I've found in the past that
doing this just results in the person above me either (a) feeling threatened,
or (b) relying on me to solve all their problems. Neither is good for career
progression.

------
kabouseng
Just remember, becoming a manager will not necessarily lead to more
automation, in fact in most cases I have seen in my career is it leads to even
less autonomy. (and in many cases more unhappiness)

Middle management sucks because you are stuck between a rock and a hard place.
You are expected to produce results by top management, but can't produce those
results yourself, instead you are to cajole those results out of your team.

That is the ultimate in powerless, the unreasonable demands from the top and
the stupid developers constantly not working fast / good / hard enough to
produce those results. And constant firefighting...

------
SerLava
Great article, but I want to rant a bit about this:

>Turns out science agrees on this: People want power because they want
autonomy. Most of the time, folks desire to move up the career ladder not for
pay, better title, or keys to the executive washroom (are those still a
thing?) but because they wish to be able to exercise greater autonomy over
their lives. Psychologist Daniel Pink agrees - he’s found that the three
qualities that contribute most to workplace satisfaction and overall
productivity are autonomy, mastery & purpose.

It's very common to cite psychology to explain human behavior. But I hate that
it can often come off as dismissive of a person and their decisions. There's
implied irrationality.

Often times the psychological need aligns fully with rational objectives.

If I were to program a robot to work a human job, and I wanted to maximize its
generated income, I would try to program it to maintain its own autonomy in
that workspace. Because without autonomy, resources are endangered.

------
6stringmerc
An interesting write-up and perspective, yet in my experience, has no
practical or pragmatic designs by which to replace seniority-based,
heirarchical and heavily engrained systems. Re-naming titles is a start, but
it's still wishy-washy. I mean, sure, start from scratch and implement, but
can it work in software or running a bakery or for a pool cleaning business?
Context is important, and while I enjoy reading 'open mind' type educational
riffing (of which this is clearly an example), it's hard to capture any
genuine take-away approaches for, well, generalization.

------
awinter-py
'done and get things smart' is such a good take on people & work. It gets to
the heart of what everyone wants to be, I think.

------
reitanqild
This seems like it _can_ become truly useful.

