14 ms·

Where do individual contributors go once they peak?

• m0zg 7y ago
  Why do we feel the need to "progress" anywhere? I mean, why not enjoy the mastery of the field, knowing your job so well you can do it blindfolded. Somehow a welder or a plumber doesn't need to "progress" to "welding architect" or "distinguished plumber". Yet most of us in tech willingly participate in a stupid rat race that eventually causes a lot of us to burn out. You can't make all the money in the world. On my deathbed I'm pretty sure I won't be thinking of how much more money I could have made. In fact I won't be thinking about work at all.
• alexandercrohde 7y ago
  What a dumb article, the whole thing is the title. Here's my measure for "meaning density" in article. "How many sentences did it have" divided by "How many distinct points did it make" this is one of these "lightning rod" articles, where nobody upvotes it because the article itself is good, but rather because it talks about something they are angry about and agree with and want to debate.
• Ididntdothis 7y ago
  Most companies have no use for very senior ICs. They don’t have much difficult work and a lot of managers want to involve themselves in technical decisions so once you have reached a certain level there is no room to grow. Either go into management or stagnate.
  • BurningFrog 7y ago
    > They don’t have much difficult work They usually have enormous technical debt that elite engineers could disentangle.
    • tehlike 7y ago
      Technical debt is like real debt. You do it because you want to grow the business, and you can delay it as long as you can. Paying the debt down doesnt make the business grow.
      • Ericson2314 7y ago
        You try to pay down debt after growth to prepare for the next round. And in many ways tech debt is worse because while real debt just constrains you, you can maneuver just as fine within the constraints with or without it, while tech debt can gum up even your slightest movements. I'd say tech debt is more like a special VAT applied to your current actions, whereas regular debt is proportional only to your past actions.
        • tehlike 7y ago
          Paying technical debt down takes away from other areas you can grow on. Unfortunately the economics doesnt play out like this. Whether you have technical debt or not, the stack will get a rewrite every now and then because thats how senior ics will like it or will get promoted because of it. I have seen lots of infra churn that went over budget, didnt result in the impact it claimed, and so on. Technical debt is overrated.
          • barrkel 7y ago
            Even when technical debt is deliberately taken on in the interest of growth, it still can come around to bite you, as you triple and quintuple the size of the team yet see only 20% increase in velocity, and face further dilution to maintain growth momentum. (Yes, technical debt is often overrated, by young engineers unused to maintaining hairy code. But when it builds up over several years, it can add up to a real problem.)
            • tehlike 7y ago
              Sure, but you will find out that eng has more desire to rewrite than gradually increase quality. Meaning... When you choose your debt reduction strategy, you cannot go 0% debt. There will be investments you can do, like increasing deployment velocity, adding monitoring and so on, but refactoring that ugly god object may not be the greatest idea.
    • goatinaboat 7y ago
      They usually have enormous technical debt that elite engineers could disentangle Doing so will not be recognised nor appreciated by management.
      • redisman 7y ago
        It will build morale in the team of developers on that project but from my experience management/product people will just give you a blank stare. Like so you spent a month doing... nothing?
        • BurningFrog 7y ago
          The better way to do it is to refactor code as you go. I probably spend 1/3 of my day fixing old problematic code piece by piece. That one month project could probably be split in to 5 smaller but still meaningful ones.
          • Ididntdothis 7y ago
            “The better way to do it is to refactor code as you go. “ Agreed. It should be part of the normal workflow and not much talked about.
    • Ididntdothis 7y ago
      Management doesn’t see it that way. They want new features and won’t pay a lot of money for somebody to refactor code that “works”. Heck, even other devs don’t see technical debt as problem. It’s more of a political problem, less technical.
      • BurningFrog 7y ago
        That may be true of your management, but far from all.
        • Ididntdothis 7y ago
          Almost nothing people say is true for all. What said is true for a substantial number of companies though.
          • BurningFrog 7y ago
            Possible. I don't work at those places though. There are better companies, both to work for and in business performance, and you can find them! I mean this as a message of hope, not a quibble!
      • imhoguy 7y ago
        So they need to "see" it. They need to see business metrics of cleanup work. Show them e.g. AWS usage cost savings report/powerpoint in their language and you will gain a respect.
    • downerending 7y ago
      That pretty much describes my career trajectory. I'm too "old" to be hired for a lot of jobs, but it turns out that there are niches involving cleaning up the messes that youngsters make. :-)
      • BurningFrog 7y ago
        I've seriously considered becoming a "Code Janitor" consultant. I can clean up any mess better than most, and I actually enjoy it. To me refactoring is the design process of modern development. First you write the working code, and then yo design it. Except most people don't bother with the design part, and get dragged down by their atrophied systems.
        • downerending 7y ago
          The best work I've done has sort of iterated between design and coding, with minor and major swings between. They say that complex systems that work invariably evolve from simple systems that work, and I believe it.
    • gfs78 7y ago
      But in most cases they don´t care, hide, or are in a position to understand.
• pacala 7y ago
  Managers control the purse strings. ICs don't. There will never be equal status, and it starts with other ICs that won't lift a finger unless it pleases someone with a fat purse. You can leverage IC star power a little, but it won't get you too far without a purse.
  • Ididntdothis 7y ago
    Very true. Whoever owns the cost center number has the power.
• binarytox1n 7y ago
  The problem with growth as an IC is that one person only has so many hours in a day. The only real way to multiply your impact is to transition from using your own hours to produce work towards directing the hours others use to produce work. Simple math shows that your own productivity scales only up to 24 hrs/day while you can easily direct a team of 4 towards 32 hours a day of productivity and actually get some sleep.
  • geofft 7y ago
    I don't know if that requires being a people manager, specifically. You can also scale your work by being able to work alongside other people to help them maximize their impact - you don't necessarily need to work above them, choose their work, direct their performance reviews, etc. If you do it right, this also scales well. If you can help a hundred people do their work 10% more productively, that is also more effective than helping four people do their work 50% more productively. Most tech companies that have separate engineering-IC and engineering-management ladders try to keep roughly similar expectations at each level about scope/breadth of impact, it's just that for engineering management, it's "how many people do you transitively manage," and for the IC ladder, it's not as obvious. I think this article does address that by pointing out that the design management career track generally expects you to manage both increasing numbers of people and increasing amounts of work, and those don't need to be the same thing: > Overlapping responsibilities between IC and managers is the most prominent issue I’ve observed, but it’s an easy one to resolve by looking at where the line is drawn between people and product on the team. (This sort of reminds me of a similar problem in academia: there are three separate skillsets, doing research, leading researchers/scaling a research lab, and instructing students, that tend to be conflated into one ladder. They don't need to be.)
  • BurningFrog 7y ago
    You can also pair program. No better way to spread your skills to the whole team.
  • bcrosby95 7y ago
    This just isn't true. A friend of mine is an IC and regularly ends up making original tools that solve his problems that everyone else at his company ends up adopting. The company recognizes this and awards him in kind. He makes around 1 million in regular salary. He has way more impact than any individual manager. If you want to have a huge impact at your company as an IC, solve the higher level problems that both you and your fellow developers are having.
• ssivark 7y ago
  I find the whole concept strange. Why are technically skilled folks boxed into being “individual” contributors? There are many ways (hats) in which technical skill can be leveraged to help other people or teams: the person who can troubleshoot surprises with relentless digging (beaver), the person who provides technical feedback to colleague (reviewer), the person who has a broad understanding and can quickly get someone up to speed in a new area or suggest exactly what to look for (consultant), the person who understands the system well enough to onboard a new member quickly (teacher), finding new directions for the org (researcher), etc. All of those are multipliers on the performance of people and teams, and don't befit the “individual” moniker. Working on complex problems requires collaborative effort, which can be immensely gratifying not just intellectually but also emotionally (humans are social beings). It is strange to see a warped restriction of the concept of collaboration down to each “individual contributor” doing what they’re assigned, and ignoring the other “hats”. That formulation never allows/imagines a chance for the whole to be better than the sum of its parts.
  • dpeck 7y ago
    because thats the meaning that we've assigned to the phrase "individual contributor", its as simple as that. If you don't have people reporting to you for you to direct in accomplishing the goals of the organization you're an individual contributor, if you do have them you're a manager.
    • deleted 7y ago
      [deleted]
  • hugey010 7y ago
    I'd argue the best individual contributors don't have the skills to be the best mentors or managers. These skills can be learned only by sacrificing IC value, maybe just temporarily. It seems this industry is getting better at realizing IC skills may be prerequisite for any successful mentoring or managing. The breadth of knowledge is only getting bigger, so if you aren't an expert in some area, what have you been doing, and if you are, why aren't you sharing it.
  • 7y ago
• archeantus 7y ago
  Value is all about impact and companies are incentivized to reward and promote impact. It’s valuable to a company to have a really great IC, it’s even more valuable to have a manager that can grow their team into really great ICs - presumably like the manager was at one point. If you are an amazing IC, but can’t/won’t help others grow to that level, you are only so valuable to the company - hence the IC ceiling.
  • redisman 7y ago
    ICs reach a local maximum at some point. Most companies aren't solving problems that are hard enough to warrant executive-level equivalent engineering roles (except organizational ie. management of said engineers).
• irq11 7y ago
  There’s nobody making you choose to stop being an IC. If you want (and you stay up-to-date with the latest trends) you can continue doing it indefinitely. You just can’t do that and also demand that you be paid the salary of someone who is leading a team. You are paid to produce value. If you continue to focus on producing value as an individual, you have to reasonably expect that your compensation will eventually reach a limit.
  • hawaiianbrah 7y ago
    Microsoft pays employees based on level. My manager does make more than I do, but that’s because they’re a higher level, not because they’re a manager.
    • irq11 7y ago
      Yes, at perhaps five of the world’s most elite software companies, they have pay tiers that theoretically scale with experience. Setting aside the fact that most companies don’t have this, here’s a protip: count the number of engineers at each tier. People don’t get automatically promoted to l7 just because they spent years grunting at l6. It scales with impact, and opportunities for impact as an IC are fewer and farther between than for managers.
    • ganstyles 7y ago
      Facebook is the same. Transition to management, make the same pay per level. It's less about moving for money and more about moving to what skillset you prefer to use, which I really like.
      • tehlike 7y ago
        Ish. There is a ceiling to an ic. Sr dr ic level(distinguished) is probably it, while an em can go up to svp level. Let's not kid ourselves, the ladders are never equal, and a senior ic level doesnt translate well to another company. After l7 and above, the skillset is only mostly recognized within the company.
  • heisenbit 7y ago
• ptero 7y ago
  If one wants more responsibility, one has to move to leadership. This is true in almost every company and work type, not just in software development. There is a flip side to this, as some (many? most?) excellent ICs either become poor managers, or hate the job of dealing with humans, or (frequently) both. This is well known and many companies actually want and support top ICs who want to stay ICs with significant freedom to choose projects, generous (time, travel and $$) conference budgets and other perks. Thus at least some ICs do not go anywhere after they peak (hopefully plateau), which can be a good place to be. But sooner or later they will likely be working under one of their team members whom they did not think much about (who may just be better with people than with technology). This is not a reason to lose any sleep; just something to keep in mind. My 2c.
  • Denzel 7y ago
    Responsibility vs. accountability. If one wants more accountability, then you must move to management. Responsibility can and should scale with IC levels. What’s the difference? Think about when a project fails. “Bad things” happen for the person accountable, whereas the person responsible can move on to the next project. The buck stops at the accountable individual not the responsible one. In practice, every project has a manager that’s accountable and a lead that’s responsible. As ICs move up the ladder, they’re able to lead larger and larger projects and offer expertise and guidance across multiple projects. Think: providing feedback, from hard-fought past experience, on a design doc that’ll save a team 3 months worth of effort; architecture review, etc. Essentially ensuring and instilling engineering excellence across the organization. One thing to note, moving up into a senior engineering role may mean you’ll be coding or designing less. And that’s to be expected. Senior engineers understand that coding/designing is one portion of a larger picture that includes communication, eliciting buyin, documentation, architecture, software quality attributes, and many more responsibilities. In theory, this provides equal management and IC tracks that are fulfilling to all. In practice, very few companies work this way, but there are some out there. And when you find them, you won’t want to leave because it’s such a pleasant experience.
    • SpicyLemonZest 7y ago
• TomVDB 7y ago
  They keep on doing what they love. At some point, I simply cut and pasted the paragraphs of my performance self-reviews and actions for growth from one year to the next and told my manager: “WYSIWYG, you know what you can expect from me, you know I’ll learn anything that’s needed for the job, and more. What more needs to be said?” And that was the end of self reviews and we all lived happily ever after.
  • pmiller2 7y ago
    You seem to assume someone has to "love" what they do to be effective. I'm a senior engineer, and I don't hate what I do, but I wouldn't be doing it at all if I were financially independent. I'd be doing something I love instead.
    • TomVDB 7y ago
      Not assuming, just anecdotally telling what works for me.
• slavapestov 7y ago
  There are many ways to be an IC. You could just write code all day with minimal interaction with the rest of the team. But you can also mentor your teammates or be a technical lead for a component or entire project, even without becoming a manager with direct reports. In general I don’t think there is anything wrong with “peaking” at a point in your career where you feel fulfilled without feeling pressured to always take on more responsibility and stress. If you want to lead projects or manage people, go ahead. If you just want to write code, that’s fine too. Of course depending on the company your compensation might top out after a certain point, which you may or may not be happy with. But at least in the bigger FAANG-type companies, you can go pretty far as a “tech lead” style of IC, without directly managing people.
  • redisman 7y ago
    > In general I don’t think there is anything wrong with “peaking” at a point in your career where you feel fulfilled without feeling pressured to always take on more responsibility and stress. So true. Especially after having a kid, I'm dreading any further promotions above the usual Senior. I'm happy at the level I am for the last 5 years and don't see why I would suddenly want to spend more hours in meetings and be held responsible for more things?
• grogenaut 7y ago
  Many of you are thinking about this wrong. In places that allow senior non-manager ICs, those ICs are determining what to do. The managers are figuring out who and when to do it, the ICs are going to figure out the details, tech ordering, research, etc. Usually the way it works is I'll identify a large scale problem, work to quantify it, cost it out, work to find the manager who is most appropriate for it. Work with that management chain to further quantify cost and benefit of fixing the problem. We'll get high level resourcing and prioritization for the work. I'll get going on deeper research, role needs, design docs and v0 implementation. Manager will get going on hiring. At some point I'll swap from driving everything to doing, and just lob prioritized tasks to the managers. Essentially I'm working as a Product Manager and IC coder at this point, eg I'm saying what we should be doing (PM) and doing the work. However at this point the manager is actually setting sprint task level priorities for me. So weirdly the work goes PM (me) -> SDM (mgr) -> IC (Me). At this point the SDM will usually have hired some other devs or a PM and we just fit them into the flow. At a certain point I'm really just a Lead on the team while we groom up a permanent lead. Or if it's a longer project I'll stay in the Lead role for a year. The manager, PM and I are all working together. I don't have to manage anyone but I do a ton of mentoring and product work and communication. They asked me a while back if I wanted to manage people (manager came from where everyone here seems to be coming from). But when we discussed it they didn't want to lose 30% of my time to management duties. A highly effective manager will be able to delegate large parts of their perceived responsibility to others, which is how they get to 100% productivity. Same can happen for managers. Some call it managing up.
  • thechao 7y ago
    Since I do the same process described here (at a FAANG), I’d like to elaborate on one more thing: responsibility. Upper management trusts me to do a good job along the entire pipeline, particularly at the hand-off to the maintenance/independent-development phase. Not every company actually defines a role like this (mine doesn’t), but it is a role every healthy large-scale company needs.
    • grogenaut 7y ago
      Very good call-out. Trust is inherent here. Amazon would call it earns trust and ownership. The role there is Principal Engineer (or really senior sde3).
• ereyes01 7y ago
  I think this phenomenon is evidence of the value ceiling of IC work. What is the point of diminishing returns on paying an IC more money to do what they already do well vs hiring an additional younger and less expensive person to do the same thing, though not as well? Of course, an experienced IC can transition to mentorship, and different companies value this differently, but that may have a value ceiling as well. Personally, I don't think it's necessarily a bad thing when IC's who max out their value writing code transition to other things. I agree not everyone makes the transition successfully, but it's a great opportunity for personal growth, and the potential for upside is high, since an organization can gain a leader with very nuanced and deep insights into product + market.
  • rightbyte 7y ago
    This is not my experience. It might depend on the field. Unless there is a "peak IC" doing stuff development stagnate and no matter how much time or resources is put into something the great results never comes. Things turn out good, yes, but not great. It might be that I see this from an engineering perspective and that "the market" and stockholders wont notice in the short term until the brand gets a quality reputation in 10-20 years from user hearsay. Managers on the other hand seems to mostly have the duty of fighting fires and putting out fires - with the most important quality of not litting fires themselves. There is no way a great engineer working as a manager have time to deal with deep proactive technical issues where I have worked.
• _nalply 7y ago
  And what about individual contributors with a communication handicap? Where do they go once they peak?
  • downerending 7y ago
    That's a great question, and of course depends on the handicap. If it's hearing/speaking, probably a lot of jobs can be done via "chat", with little or no phone or in-person hearing required. For limited sight, we fortunately live in an era of huge monitors. Certainly being blind would suck, of course, perhaps even more than 20 years ago given the "advances" in UI.
• irrational 7y ago
  "Then, a few years into the [manager] job, they realize that they don't have the natural talent to develop other people. Not only is this a waste of their time, but chances are, they could have increased their contribution even more if they had stayed in the [developer] role - a role in which they naturally excelled. Yet if we want additional income, status or responsibility, most organizational hierarchies force us into a very different role - instead of allowing for an entire career of progression within a specific role that fits our talents." StrengthsFinder 2.0 from Gallup
• mmmBacon 7y ago
  I am a senior IC transitions to management. I think these articles leave out a very significant part of the equation and that is compensation and career mobility. Generally the management track at higher levels has more openings. If you stay in the IC track, there are going to be much fewer openings at that level with appropriate compensation. This is particularly true the more specialized your knowledge is. Moving to management track provides more opportunity at the same/similar or greater compensation. The exception to this are the FAANG companies but in my experience it’s way easier to get in through the leadership ladder than through the senior IC ladder. At least that was my experience in the 2 I’ve worked for. In one of the FAANG I worked for, I joined as a senior IC but was given a very non-senior manager and was effectively treated as a junior engineer during the 1st year.
  • pmiller2 7y ago
    More openings at higher levels? That's just at odd with how organizational structure works. For engineers, at least, you need about 1 manager per 8 ICs. Going up the ladder, you probably need about the same number per level, so: 8 managers of managers per first level manager, and so on. If you have team managers, directors, and VPs, you should need: 1 VP per 8 directors per 64 team managers. So, how are there more openings at higher levels?
    • blueboo 7y ago
      Because every year there's some turnover, so your senior IC has a shot at getting some reports. Meanwhile, the incentive for upper management to promote a senior IC to super-senior IC or fellow or whatever is slight.
    • mmmBacon 7y ago
      There are more openings for managers at higher levels with the same or higher compensation than for high ICs simply because there are fewer problems that have the scope for such a senior engineer. A FAANG I worked at might have a need in an org for a few director level ICs. These ICs in my experience are few and far between. ICs at this level make same money as management track. In my experience not many teams within an org have scope for an IC at that level Making it more difficult to transfer within the organization. Yet at the same time there are many director level managers because there are many teams and lower level managers to manage within those orgs. Additionally, a director level manager is considered somewhat generic and has an easier time moving around in the company with things that are tangential to their domain. My current company is not a FAANG but I can tell you that I see the same thing there.
• jonas21 7y ago
  The original article's title is: "Where do IC designers go once they peak?" (not sure why it was changed on HN), and it focuses mainly on the career path for design. For engineers, at least in larger tech companies, there's often a tech career ladder that runs parallel to the management ladder where you can have salary and responsibility growth as an IC without managing people. These ladders usually top out at a "distinguished engineer" or "fellow" level that's roughly equivalent to being a VP. EDIT: added clarification about company size
  • AaronM 7y ago
    Based on my experience, it doesn't seem that many companies outside of the FAANG companies have those kind of tracks. At a small company that builds a single product, what would a "fellow" actually do that is different than a senior engineer?
    • jonas21 7y ago
      You're right, the company needs to be of a certain size before this makes sense. But it's not just FAANG -- for example, IBM, Microsoft, Twitter, Lyft and many others have similar tracks.
      • scarface74 7y ago
        People are so stuck on the acronym that think of MS as less of a tech company than Netflix? Microsoft is much larger than Netflix no matter how you measure it.
        • james_s_tayler 7y ago
          So true. The reply is like "by these other huge famous companies have them too". Ok. That's great. How about the small product companies that have like 20 or 200 engineers as opposed to 2,000 or 20,000?
        • deleted 7y ago
          [deleted]
• gfs78 7y ago
  Where do they go? A-Management. B-Consulting. C-Stagnation. D-Endure a string of jobs where they are mobbed because they are seen as a threat until they retire from the industry.
  • stagger87 7y ago
    You forgot E-Continue working as an IC, satisfying their intellectual and financial needs.
  • randycupertino 7y ago
    E - Teaching? A few of my absolute best adjunct professors were retired from industry and took jobs in education because they loved the field and wanted to give back.
• eagsalazar2 7y ago
  Be careful that you are at a company or, even better, in an industry that isn't rife with ageism and where there is a clear and well defined path for more senior ICs to continue to develop an age appropriate resume (increasingly strategic contributions while remaining current with latest industry tools and practices) that will serve them well if/when they are looking for work at 55. In software this is very often not the case. A 55 year old still fluent in hot tech and a lot of strategic work as an architect, interventionist, mentor to younger devs, etc and who can demonstrate all that in their resume will probably do ok. A 55 year old who is "just" a coder will often have a rough time (vs 28 year olds getting actively recruited 5x/week). In other industries, like EE where I also worked for several years, this is much much less true. Very senior ICs are highly valued and it is common for teams to be a blend of engineers from fresh grads upto near-retirees.
  • gfs78 7y ago
    Not an easy problem to solve. And this is why, given the odds, a career in tech is probably a bad decision. To avoid ageism while being an IC you need to find a job in a niche where the domain is CS and/or ENG based (as in embedded, aerospace, or even relational database engines) and these jobs are far and in between. Beware: jobs like Facebook seem to be CS based but they aren´t (that´s why their programmer average age is 27). The CS problems they have are due to arbitrary complexity and they are short term. Companies like these are media companies.
    • smnrchrds 7y ago
      Do these jobs pay as well as typical tech jobs?
      • blueboo 7y ago
        The point being claimed is that they pay better after a certain point, say, 40.
    • scarface74 7y ago
      What’s wrong with as the parent poster said “develop[ing] an age appropriate resume (increasingly strategic contributions while remaining current with latest industry tools and practices)”? I’m 45, still an IC mostly but my next role whenever I decide to leave my current job, will probably be working for a consulting company. Currently, I am “more equal than others” and have more influence based solely on my “relationship and expert” power.
• SubuSS 7y ago
  I have been an IC for 17 years now (MS/Amzn/Snap) - let's hope I haven't peaked yet :) But over time I have seen my role change in many ways though: I started as the stereotypical IC, slinging code and did that for a long time. Almost at every level though, sooner or later I ended up with almost full ownership of whatever I was working on. That meant I kept growing in levels and I am where I am right now (Uber tech lead for all data analytics infrastructure at snap). My current role essentially takes up 10-15% time for company level arch/design reviews, 10% time on interviews, 40% time on preset meetings (scrums/team design reviews/planning/post mortems), 20% time on operations and about 15% time for coding. So pretty much all coding I do is in that tiny sliver or outside office. I am pretty much a part of all meetings my manager peers are a part of - except for their people commitments. The main differentiation I see between the IC role and managerial is that I don't have people reporting to me. I also don't have to be in ALL the status reporting meetings / managing up etc. There are definitely times I want to put my head down and get some problems solved, but it usually comes at a cost. So I find some or other engineer to task it on and watch it done most of the times. Rest of the times I don't sleep :) It is breadth heavy because snap is still a small company in terms of # of engineers. My equivalent role in AWS was a lot more on the building side (50-75% went into building stuff and rest for ops/interviews etc.) because it was a depth position. I did choose this after 13 years of depth roles, it has been quite interesting so far! The biggest advantage I bring is that I can pretty much fix anything in the system and make changes in any component, assuming the dev is not available. I also keep the full stack in my head, so serve as the initial litmus test for new proposals. I see a bit of misconceptions about pay (I do get paid in the same band as my level to next level give or take bonuses/stocks etc), ownership (My ass is very much on the line for our data quality), responsibility (my managers share the responsibility in a different way - they will get a team member on things that need done and refocus. I will jump in myself if that doesn't work) etc. I like the freedom. I do like the fact that I can be socially aloof (I am usually friendly, but my friends are outside work) and still get things done. I prefer not to worry about others personal lives (from what I see, this becomes inevitable for managers). I definitely like not having to deliver reviews (I am still a part of the process). Feel free to ask me any questions.
  • commandlinefan 7y ago
• Scalanchilis 7y ago
  It sounds like career path for designers has some similarities with software engineers. I think software engineering can potentially offer a much wider and deeper set of opportunities. Still, in practice, these growth opportunities can seem far less common than yet another senior full-stack dev position. If you want to work with scale, there's Google, Amazon, etc., but most companies don't really need to engineer for scalability and high availability. They just need to ship some CRUD features yesterday. At some point, it's worth considering whether it's worth the costs to keep pushing up in career for more interesting work, more money, more status, whatever.
• playing_colours 7y ago
  It is unfortunate that the industry seems to stick to only “coder or manager” framework. There are technical topics and decision spanning across a few teams or the whole organization: CI/CD, data pipelines, languages / frameworks, consistency, reusable components, best practices, mentoring, integrations. Can coders who are limited to a single team, without exposure to a big picture, not experienced in business communications, specialists not generalists do it? Can a director of engineering, who is busy with people management, meetings, plannings, work allocations, who can barely keep up with latest technologies, forgot when they coded last time do it properly? Do you want VP to decide what language or platform to use across the organization? It is just my opinion and some experience, but I think there is a proper set of responsibilities in many tech companies for such leadership roles without people management, like tech leads on steroids, they can be called architects, principal engineers. Roughly, 20-30 percent coding, the rest on communications, coordination, designing, mentoring, researching, solving tricky problems, with career progression in the scope: single team -> department, area -> whole organization.
• purplezooey 7y ago
  they become PMs and begin the inexorable long decline.
• plutonorm 7y ago
  And then there's me, desperate to get into management. Has hussled for 10 years to make it happen, with no luck. I'm currently sending out hundreds of CVs trying to get a business analyst role. No interest. Do you know how many engineers I've seen promoted in 15 years in the industry? 0. None. Had I done a business degree I'd be well away. I'm so old now that even doing an MBA wouldn't help me. I'm currently considering getting a super market job because the thought of going back to programming makes me feel physically ill.
• scarface74 7y ago
  Devil’s Advocate Question: What’s wrong with peaking? I’m 45. I spent 10 years in “Expert Beginner” mode and then spent 7 years moving between 3 companies and for the last 3 or 4 going back and forth between a dev lead, back to an IC to get some hand on experience in some areas I was weak at and now back to an “architect” or a Single Responsible Individual with maybe a team of dotted line reports. I make “enough” now to meet my short and long term goals and have a great work life balance. Why shouldn’t I just focus on keeping my network current, my resume up to date with in demand technologies, and within the next two or three years when I reach my ceiling, be happy with cost of living raises? I’m looking at the next level. Management doesn’t interest me. I’m really not interested in the travel requirements of consulting and we are good. I could easily see myself doing the same thing I’m doing now using whatever technologies are trending then at my current company or an equivalent. But, on the other hand. I might get bored out of my mind and move to consulting just for new challenges and the extra money would be nice but not necessary. A regular old Enterprise Developer in Atlanta can live a good life - especially with dual incomes