21 ms·

Implementers, Solvers, and Finders

205 points by RKoutnik 10y ago

reitanqild 10y ago
This seems like it can become truly useful.
pleasanthipster 10y ago
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
- SatvikBeri 10y ago
  Yeah, I've had a similar experience. Programmers who show that they care about the business tend to get a lot of trust, and therefore a lot of autonomy.
- Delmania 10y ago
  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 10y ago
    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.
henrik_w 10y ago
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 10y ago
  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).
gtrubetskoy 10y ago
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.
- RKoutnik 10y ago
  That's a fantastic quote, wish I had known about it before publishing this! (I might just add it in post-facto anyway).
  - deleted 10y ago
    [deleted]
- p4wnc6 10y ago
  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%20functional%20mindset.pdf http://business.unr.edu/faculty/Kuechler/788/breaking%20the%... >
augb 10y ago
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
SatvikBeri 10y ago
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 10y ago
  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 10y ago
    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.
thinkingkong 10y ago
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 10y ago
  "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 10y ago
    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.
- ryancox 10y ago
  Could not agree more with this. FWIW: Some of these ideas are echoed and further developed in "The Art of Action" http://www.amazon.com/gp/product/B004CRSN2O http://www.amazon.com/gp/product/B004CRSN2O "The insight is that alignment needs to be achieved around intent, and autonomy should be granted around actions. Intent is expressed in terms of what to achieve and why. Autonomy concerns the actions taken in order to realize the intent; in other words, about what to do and how."
awinter-py 10y ago
'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.
outworlder 10y ago
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 10y ago
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.
6stringmerc 10y ago
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.
lliamander 10y ago
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_ladder http://changelog.ca/log/2013/08/09/software_engineer_title_l... edit: minor grammatical issues
mindcrime 10y ago
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.
lliamander 10y ago
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.
russell 10y ago
The Koutnik links to this article, which inspired his essay. http://thecodist.com/article/my-biggest-regret-as-a-programmer http://thecodist.com/article/my-biggest-regret-as-a-programm.... 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 10y ago
  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 10y ago
    Thanks, now I'm missing the Mission... =/
kabouseng 10y ago
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 10y ago
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.

205 points by RKoutnik 10y ago

This seems like it can become truly useful.

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

SatvikBeri 10y ago
Yeah, I've had a similar experience. Programmers who show that they care about the business tend to get a lot of trust, and therefore a lot of autonomy.
Delmania 10y ago
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 10y ago
  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.

henrik_w 10y ago

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 10y ago
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).

gtrubetskoy 10y ago

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.

RKoutnik 10y ago
That's a fantastic quote, wish I had known about it before publishing this! (I might just add it in post-facto anyway).
- deleted 10y ago
  [deleted]
p4wnc6 10y ago
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%20functional%20mindset.pdf http://business.unr.edu/faculty/Kuechler/788/breaking%20the%... >

augb 10y ago

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

SatvikBeri 10y ago

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 10y ago
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 10y ago
  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.

thinkingkong 10y ago

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 10y ago
"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 10y ago
  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.
ryancox 10y ago
Could not agree more with this. FWIW: Some of these ideas are echoed and further developed in "The Art of Action" http://www.amazon.com/gp/product/B004CRSN2O http://www.amazon.com/gp/product/B004CRSN2O "The insight is that alignment needs to be achieved around intent, and autonomy should be granted around actions. Intent is expressed in terms of what to achieve and why. Autonomy concerns the actions taken in order to realize the intent; in other words, about what to do and how."

awinter-py 10y ago

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

outworlder 10y ago

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 10y ago

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.

6stringmerc 10y ago

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.

lliamander 10y ago

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_ladder http://changelog.ca/log/2013/08/09/software_engineer_title_l... edit: minor grammatical issues

mindcrime 10y ago

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.

lliamander 10y ago

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.

russell 10y ago

The Koutnik links to this article, which inspired his essay. http://thecodist.com/article/my-biggest-regret-as-a-programmer http://thecodist.com/article/my-biggest-regret-as-a-programm.... 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 10y ago
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 10y ago
  Thanks, now I'm missing the Mission... =/

kabouseng 10y ago

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 10y ago

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.