16 ms·

We need someone who has done “it” before

246 points by jger15 5y ago

jdrc 5y ago
why is hiring/firing posts so popular here? As an indie dev it's kind of annoying to me, this was supposed to be an entrepreneurial community rather than a place for managers to vent every afternoon.
- marktangotango 5y ago
  Interesting comment. Personally I would say this hasn't been entrepreneurial community for a few years now. Mainly because a lot of people figured out it's easier to go make $X00,000 at Big Tech Co. than to take on the risk of a startup. Secondly the "market place" of ideas is pretty heavily saturated nowadays (imo), seems like unicorns are becoming less common, and the domains a lot harder where there are. And when you do work at Big Co, there's a whole lot of Dilbert-esque stuff like this. Hence the prevalence of this type of material.
- eatonphil 5y ago
  YC is a startup accelerator and VC. What do you think happens to the companies that grow after completing YC? Ideally they grow and hire (and sometimes, fire) people. The HN community is way broader than just YC and their companies though.
  - jdrc 5y ago
    > is way broader than just YC With respect, i think it isn't and that the pendulum has swung too far on the other side. It is more likely that you will find purists who will attack anyone who wants to "make money on the internet" , to the point that people no longer post their projects here. E.g. it is impossible to state that you want to monetize your project via advertising and not get attacked. And yet the people who make those attacks overwhelmingly work in ads companies.
- postalrat 5y ago
  Hiring/firing is "It".
GianFabien 5y ago
My take is colored by the fact that I only engage as consultant/contractor. The key is to probe deeply before taking on an assignment. If the managers appear too clueless or fixated upon some timeline or budget, then I often decline the work. I often end up fixing / rescuing projects that have been blotched because the previous incumbent rushed into taking on the job. You simply need to ask questions until you are comfortable that the proposed role is feasible. If the client (employer) is unwilling to engage to that depth, then that too is a red flag.
- vsareto 5y ago
  Not saying you should change, but if they aren't engaged deeply, then that sounds like the freedom to do whatever and get paid for it.
  - Consultant32452 5y ago
    This is more closely aligned with the way I think. The more of a cluster I think the project will be the more I charge and the more I change the terms of my contract to get paid regardless of the outcome.
- Ensorceled 5y ago
  I've had more than one contract come back with a "you were right and the person we hired made a mess, willing to discuss this again"; I've even taken one of those contracts. My favourite is the combination of a tight timeline/budget AND an unwillingness to discuss the project in depth. Especially since they always want some kind of fixed price guarantee in those situations.
  - antod 5y ago
    The second mouse gets the cheese
  - projektfu 5y ago
    I have definitely seen: Phase 1. "Our problem is big, we hire big company" (3000+ employee firm) Phase 2. Meeting after meeting Phase 3. Lots of billable hours, more meetings. Deadline approaching. Where is the product? Phase 4. Gaslighting Phase 5. Hire small company (1-400 people) to finish the work big company couldn't. (Typical) Phase 6. Quietly kill project because if it ever had a business case it has missed its opportunity. Does this go in the other direction, where a reputable small company starts a big project and is in over its head, only to be saved by one of the big 4 consultancies?
rexreed 5y ago
Here's an additional option: maybe the person who they hired to do "it" never really knew how to do "it" in the first place, and was really good at selling themselves and overpromising and underdelvering, being really good at avoiding personal blame and making sure that any failures were attributed to the organization and not themselves personally. Basically, fakers. There are a surprising number of fakers at the C-level and VP-level who manage to hop from one organization to another, at best providing little benefit, but at worst leaving a destructive wake. Nonetheless management keeps hiring these fakers because others have done so before, and they need "it". Fakers cover their tracks by making sure to not stay at any one place too long, and hiring people below them to actually do the hard work, take over the mess (and responsibility). I wouldn't assume the people that management bring in are any more competent than management themselves. It's unfortunate but there are many serial fakers operating as COOs, CMOs, CIOs, VP Marketing, VP Product Development, VP Business Development, and a smattering of high-sounding but low authority titles such as Chief Innovation Officer, Chief "AI" Officer, and even sadly, too many Chief Data Officers. Those are the sorts of folks who tend to bring in these "playbooks" that look like they can solve the "it" problems but are all smoke and no fire.
- Foobar8568 5y ago
  Because at these levels, it's not about what you can do, but how you manage politics. From a technical point of view, most of these people are useless and a waste.
  - rexreed 5y ago
    At those levels, unfortunately, they have both budget and authority, as well as the ability to impact culture and the definition and prioritization of teams and their work. Sort of like military generals who get their ranks not by proven experience but by working the chain of command, to the great detriment of those who actually have to face the fire.
  - bonoboTP 5y ago
    Politics arises whenever people come together. It's comfortable to think that we can simply encapsulate "politics" as such, as something for the stupid people and we the enlightened rational technical people don't concern ourselves with "politics" but unfortunately one cannot simply wish it out of existence. Politics is just a label attached to human behavior. Put 3 people together and you will have "drama" (politics on the small scale). Better learn how to understand people's motivations and incentives instead of bitterly dismissing confusing human behavior as "politics".
tyingq 5y ago
This instantly reminded me of several past situations I've seen. Another common miss is that "it" isn't something the company needs at all. Or in some cases, it's not a bad idea, but there are ten other unrelated ideas the company should be addressing first.
magicink81 5y ago
Great to see Wardley Mapping used as a tool for developing situational awareness. Here's a video of Simon Wardley introducing it: https://www.youtube.com/watch?v=2IW9L1uNMCs https://www.youtube.com/watch?v=2IW9L1uNMCs And for all the details here's a book: https://www.amazon.com/Wardley-Mapping-Knowledge-Topographical-intelligence-ebook/dp/B08LTM3VFX https://www.amazon.com/Wardley-Mapping-Knowledge-Topographic... And book free online: https://medium.com/wardleymaps https://medium.com/wardleymaps
- dijit 5y ago
  His conclusion at the end is that serverless is the future. Which is interesting to me because on the one hand he might be entirely right, but to my mind it shows a deep underlying problem with this way of thinking. He even mentions during the talk that if you don't move to the way he's suggesting Google and Amazon will own everything, but I draw the opposite conclusion: If we do what he is suggests then Google and Amazon will own everything, because he's saying that we should be giving them everything. Anyway, the issue with the method he's using is that it completely ignores economic incentives. For example: If "building it yourself" costs 0.1% of what it costs to use a commodity product then that reality is not reflected at all on a Wardley Map, in fact a Wardley Map may push you towards using commodities blindly even if they do not make economic sense. Granted: this is a conclusion I came to from his talk, I have not read the 600 page book.
xnorswap 5y ago
I found the article hard to read, I wish it were written more around a concrete example than the abstract. I found it hard to track all the abstract elements in my head which ironically made it harder, not easier, for me to generalise the ideas presented.
lr4444lr 5y ago
I'm gonna share my unsolicited opinion: if you're hiring, you want someone who is ready to do "it". He may or may not have done "it" before, and may not do "it" exactly as you had planned, but he has foundational core competencies, motivation, and the cooperative responsibility taking attitude to accomplish the key parts of "it" as best as you can foresee "it". If you LITERALLY need "it" done as "it" has been done before in an exactly specifiable way, you probably should contract it out. Not hire.
- TimPC 5y ago
  Hiring for someone who has done it before is very common at the Principal and Staff Engineer level. As people get more senior in their careers there is more demand for specific skills and expertise not less. Contracting out is its own can of worms and can introduce as many problems as it solves. Exact specifiable way typically means 30 details to iron out later even when both sides mean well and those details are usually problematic.
- wofo 5y ago
  I have had the luck of working with this kind of trust from a company and it is a great experience. It can even work as a contractor. Case in point: for my current project I was hired to port a library from Rust to Java, but since the original library was not mature enough I ended up writing an independent implementation of what the original library was intended to do: a fake MySQL server that lets you handle user requests with custom logic. I had never dreamed of things unfolding that way! Learned a lot and still enjoying it.
  - wpietri 5y ago
    Could you say more about the project? I'm curious what motivated making a fake MySQL server.
    - wofo 5y ago
      They are creating a BI platform and wanted it to integrate seamlessly with other existing BI tools. If you pretend to be a MySQL server, you can integrate it with almost anything. There is a high chance we will end up open sourcing the library :)
tmstieff 5y ago
Isn't the point of having a PM to bridge the gap between leadership that knows the domain of "it" and IT who knows how to implement general business needs onto a technical solution? Of course that would require having a PM to begin with, instead of expecting your developers to become subject matter experts in your obscure domain.
- Ensorceled 5y ago
  This article could literally be talking about hiring for the PM leadership role.
  - tmstieff 5y ago
    Good point, I immediately read it and replaced "role" with programmer since it was posted on HN.
Ensorceled 5y ago
I like this article, but it assumes everybody is acting in good faith, so there is that meta issue that this article doesn't address. For example, two situations I have personally experienced several times: The person who did "it" before may not actually be able to "it"; they rode the coat tails of a person who did "it". This "not it" person will often attempt to reframe the problem as one existing in one of the other areas; either as something were they are an "it" person or as "not my problem". The response to a "things are broken" may not be Leader: “Wait, I didn’t know things were that broken” but may actually be Leader: “Wait, these things aren't broken in any way, don't touch those things.” This is not actually a criticism of the article, just if you are trying to apply the article as a leader you may have a "not it" situation or, if you are trying to apply the article as the "it" person, the problem may be the leader.
- BlargMcLarg 5y ago
  >The person who did "it" before may not actually be able to "it"; they rode the coat tails of a person who did "it". This "not it" person will often attempt to reframe the problem as one existing in one of the other areas; either as something were they are an "it" person or as "not my problem". If we're talking meta issues, my far bigger pet peeve is how the market only wants to people who can do "it" to the point anyone who can't is expected to learn through observation, which loops back to most people only riding others' coat tails. It's cute in theory but in practice, most people need to try it a few times before having a firm grasp on the matter. Then it turns out, most desired skills aren't so obscenely difficult and arcane you couldn't just throw in a decently smart person at it and figure it out, as most tools are designed to be picked up in a short time (you know, like good, widely adopted tools are supposed to be). The entire thing sets up a job market which supports "fake it till you make it".
  - Ensorceled 5y ago
    I think this definitely applies to leadership roles in product and technology. People really want someone who did it before and, usually, exactly this thing before. To the point where they hire people who did "it" and failed badly only to have them fail again because they can't do "it".
exabrial 5y ago
In general, if you're stepping into a backfill position, negotiate $10k above asking. They'll say no and you'll both end up happy.
- dijit 5y ago
  or they say yes and you feel obliged to accept. I asked for $50k above what a company offered me, thinking that we'd part on good terms; and they accepted.. So, I guess that's what I'm doing now.
  - exabrial 5y ago
    that's incredible! I suppose the lesson here is make sure you ask enough to keep you from looking over your shoulder and not being able to deal with the inevitable 'backfill blues'
perrygeo 5y ago
Company: "Here's some big problems, can you help?" Senior Dev: "Yes!" C: "How would you recommend proceeding?" D: "I've studied the problem and my professional recommendation is to implement X, migrate away from Y and refactor Z." C: "Oh, that seems like too much work and would disrupt the teams already working on Y and Z. Let's do it this way instead (points to Confluence page written by an intern last summer)" D: "..." C: "So you're not able to help us after all?"
- dvtrn 5y ago
  This hits too close to home, even as a staff engineer.
- renewiltord 5y ago
  An average L7 at Amazon will see that "limit disruption to Y and Z" is simply a constraint to the engineering problem and make it work. That's sort of what makes someone at that level - the ability to detect the cost for moving different constraints and being able to demonstrate the technorganizational advantage from doing it. Combine that with the ability to get grassroots implementer support and you have a pretty able leader. Everything is just constraint solving in the end, and the hard part is maintaining pace.
  - perrygeo 5y ago
    Of course. Implied in the senior developer's solution ("migration") is a plan to navigate those challenges - technically, politically and socially. What I tend to see is ignorant management insisting that there must be an easier way, rejecting all empirical evidence to the contrary, even going so far as to reject the concept of engineering tradeoffs entirely. It's as if the experience and accumulated wisdom of the senior ICs is valuable only insofar as it makes them slightly more productive code monkeys, merely speeding up the existing plan put in place by management without any say in said plan. Why even hire senior employees at that point?
guessbest 5y ago
I assume that this is why management is obsessed with hiring their competitors employees including developers. They want another but proven way of doing 'it'
- anon23anon 5y ago
  we recently redid authentication in our app - was told to do it exactly like Chase did theirs which I thought was an odd requirement. Come to find out the corporate executives get Chase credit cards so they were all using the Chase app and familiar with it and essentially told the products owners to build it just like the Chase and then told me/us the developers to build it exactly like the Chase app. Shaking my head. How dumb. Anyhow come to find out Chase does this weird thing were even if you press sign out in app it essentially keeps you logged in and if you're using biometrics you can effectively unlock the app and get right back in w/ Face/Touch ID. We didn't implement that but apparently this executive clicks sign out when their done using the app and still expected to get right back in so we had to rebuild that part. F my life.
  - guessbest 5y ago
    It becomes a cargo cult.
  - daok 5y ago
    Why is that dumb if they gave you exactly what they want? Regardless of their motive, that is what they want and hire you to do. I do not clearly see your point here.
nemo 5y ago
The post opens with a false dichotomy. In general my experience has been that we hired someone that management selected because they'd "done it" before (always in very different contexts), they ramped up to our project, and it worked out pretty well. I don't think it's necessarily the best selection process, but selecting for prior experience is not a very serious problem in hiring imo.
ryandrake 5y ago
Another problem is from the candidate's point of view: I've already done "It" before. I've been doing "It" for the last decade. If I move companies, I want to do "It+1" at the very least, more likely "It+2". It's not enough for me to simply do "It" again but at a different company. So many recruiters reach out with that pitch, and I simply ignore them now: "I see you have a great background doing 'It' at 'Company'. We're offering a role doing 'It' here at this company! Isn't that exciting?" No, it's not, actually. Now if you want me to manage a team of engineers doing "It", let's talk. If you want me to be Director of "It", I'll stop what I am doing and get on the phone with you in 5 minutes! But simply "Keep doing 'It' but at our company" is not even slightly motivating.
- HeyLaughingBoy 5y ago
  Part of the problem here might be that the HN population self-selects for the personality type that wants to do "at least It+1" There's a larger population out there that having mastered "It," will happily do exactly the same thing for the next 10 years.
  - daniel-cussen 5y ago
    That's very true those peeps for sure exist just not on this forum.
- padobson 5y ago
  "Keep doing 'It' but at our company" is not even slightly motivating. That's true, but what about "Keep doing 'It' but at our company for half the hours and double the salary"? Then you could take the extra time and money and work on your +1 and +2.
  - gonzo41 5y ago
    I would guess that doing the +1 and +2 is mentally and emotionally easier and more satisfying if it's during a hellish 60 hour work week than in a relaxed 10 hours you freed up by getting more pay and a 30 hour week to do something easy. Like doing programming problems is fun for a bit, but doing work that actually does something, even if it's simpler in complexity is more satisfying. IMO of course. I think the recruiters could be pitching better if they went with, do 'it' here and think about what +1 could be and when you figure what that could be, pitch it to us. This of course assumes the organization sees IT as a value multiplier and not a cost center / plumbing job.
indymike 5y ago
It's easy to hire someone who has done something before. It's hard to make sure you've got a situation where they can do the same thing.
zeroonetwothree 5y ago
I don’t really get what “it” means in the context of this article. Using some actual examples might be nice.
- anon23anon 5y ago
  see my post in the other thread
- d23 5y ago
  Not sure it matters. This whole thing could be summarized as: > Consider context when you're hiring and doing work. I don't think any number of diagrams and attempts at categorization are going to help people who can't figure that out.
- orthoxerox 5y ago
  Anything that the company hasn't done before: - scale our app to 10mil users - fix constant Oracle performance issues - build a data lake - migrate to the new HR system - reorg the IT because Price's law is destroying our bottom line - build a private cloud - design a new microservices-based e-banking app - sell the startup to a FAANG until the end of the year because it's running out of VC money
genezeta 5y ago
Another common situation I've encountered is this one: They don't really want "it". They say they want someone to do "it", they hire someone who has done "it". But then that wasn't really what they wanted done. I think I can also draw the hypothesis that the more convinced they say they want "it" and/or the bigger the "it" they ask for, the less they actually want it when the time comes.
temptemptemp111 5y ago
travisgriggs 5y ago
I see these symptoms most when the Venn intersection of “Doers” and “Deciders” grows too small. The marriage of “I have money, you have talent” is all too often one sided. If the two parties can realize it is a marriage of convenience where they can play off of each other’s strengths, then it can be mutually beneficial.
padobson 5y ago
Another one I've seen quite often is management wants "it", and then they hire someone who can do "it", but the company/product isn't nearly ready for "it". Think hiring a DBA before you have 100 total rows in your database, or hiring someone to write an AI recommendation engine before you have any users at all. The "it" person sits around feeling uncomfortable and is inevitably asked to work on something they don't really know how to do and doesn't want to learn. They usually leave before the company ever gets to the point where the relationship is useful.
- bryanrasmussen 5y ago
  The worst job I ever got hired at (about 15 years ago) wanted asp.net, C#, html, css, javascript, xslt, and SQL. It turned out the whole of the job was optimizing SQL queries because you were not allowed to touch any other part of the application because that was all handled by jealous developers in Norway. They wanted people who could do it, but they didn't actually know what it was.
- rozenmd 5y ago
  reminds me of data science 5 years ago - everyone wanted to say they hired data scientists, no one wanted to admit they didn't know where their company data was being stored
  - lysecret 5y ago
    very optimistic take, that its only 5 years ago :D Also they know where it is, in a 1000 different excels haha
- austhrow743 5y ago
  Worst case I've seen of that was a pilot hired to fly a private jet mostly being used as an unrelated to aircraft general maintenance man because there were no clients for the recently purchased private jet. Was incredibly uncomfortable needing something done and knowing I'd be told to get him to do it. His unhappiness with his position was palpable.
ilaksh 5y ago
They touched on something in the article but it deserves more emphasis. The most difficult and critical part of software development is requirements engineering. I will includes requirements negotiation as part of that. Something that I have always had to fight against is the tendency to take business stakeholders at their word when they say they have a specific set of requirements or deadline. Project success often hinges upon modifying or rejecting supposed requirements given unambiguously. The hardest part of this is that business analysts or executives prescribing requirements often have more seniority or political power in an organization than the software engineer. They also don't really know what requirements engineering is or that it is something the _software engineer_ _has_ to do. It's necessary to understand the details of business problems and then do some level of analysis of how to address them with technology. The majority of projects have done about 50-90% of the necessary depth of business analysis and that is what they present to the programmer as a supposedly complete description. But pushing a little harder on those details it's often possible to find process descriptions scrambled, missing important information, and processes that really aren't required. Once the engineer truly understands the business, they can think in depth about ways to use technology to deliver value. They can come up with design outlines for the software and think about how to break things up into different iterations. What is worthwhile in terms of programming effort versus business value. They cannot do that without having drilled down into details. It's quite common for an important detail to be omitted in discussions initially, which dramatically increase the programming difficulty or changes the approach. That's why it's so important to always be digging to uncover real requirements (and especially at the start). Getting all of that resolved requires not only strong communication skills but also favorable political outcomes. If the project management isn't good, they can interfere or fail to provide support during the requirements phases and therefore kill any possibility of success from the start. But regardless of how good the managers, requirements need to be negotiated and agreed upon which is another challenge. Beyond all of that, programming really is hard. If it wasn't, it would not be programming. It would be copy and paste or configuring existing software. The premise is that you have unique problems that have not been solved yet. So you need expertise but also strong problem solving skills. Which all the while you may be dealing with all the people issues at the same time.
- anon23anon 5y ago
mbg721 5y ago
"I used to be With It. But now what I'm With isn't It, and what's It seems weird and scary to me. It'll happen to you!"
- evilantnie 5y ago
  They changed what It was!
photochemsyn 5y ago
Solution: replace company leaders (who sound like they come from the financial sector, as they don't understand 'it', other than that others have made money off 'it') with engineers.
- orthoxerox 5y ago
  Hey, remember Xerox PARC?
Ozzie_osman 5y ago
The other challenge with hiring someone who has done "it", is they may not want to do it again, especially in startup contexts. "Find me someone who has scaled the infrastructure of a fintech startup from Y to Z". Some people may enjoy the same challenge again, but lots may want some variation (eg different company stage, different industry, different scale).
- gkop 5y ago
  Speaking personally, I can’t do It again, if It represents an apex accomplishment of mine. My apex accomplishments, I was able to do, only because of a special confluence of factors, never to be repeated. Fortunately, this forces me to seek new apex accomplishments, which keeps things interesting and growthful.
georgeecollins 5y ago
This reminds me of one of my first consulting gigs, where someone asked me if I could do "it" where "it" was something I had done before a couple times. Sure, I said. But then I get to the company, spend a few days and see enough to know "it" wasn't the problem at all. A bunch of other things were keeping "it" from happening and they didn't want to change those things. Thank goodness I was consulting and could bow out.
- drewcoo 5y ago
  I've seen this several times. Management wants to do "it" but isn't sure how to get there. They hire an expert, who determines that management is actually the thing keeping "it" from happening. [cue sad trombone]
  - andrekandre 5y ago
    > management is actually the thing keeping "it" from happening. in the end, its almost always this isn't it...
duxup 5y ago
I haven't been writing code professionally really long but one thing I notice is "It" ... even the same "It" can be dramatically different wherever you go and not everyone seems to be entirely aware of that or able to adapt. You get folks who maybe have worked a few places, or a lot of places that all operate with the same bureaucracy / processes and they seem unaware that it could possibly be different anywhere else. Some folks I know work at a very large corp. Their development cycle is very heavy with processes, albeit seems very reasonable / works for them. Folks writing up what some feature should do for 100 different possibles, folks reviewing it in some way ... on and on. Maybe someone finally writes code and everyone reviews it. Testing, testing, testing. I'm not judging it, it's just ... a lot. I work at a place with 3 devs, and only one other really does what I do. I get a vague idea of a feature requested, I talk to the customer, I go write it. Show some folks, maybe I change things, maybe not. I roll it out. Done. Feature is out there in production, live, sometimes in just a few hours (and I watch our error reporting system to see if it blows up or not). It's a completely different mindset / process. I've worked with folks who worked at very large corp and they weren't doing anything differently than I do, but in my more informal / not a lot of review environment they struggle. They're good, they're not bad, they just are so used to so many eyeballs / not used to talking to customers (and distilling what they say) / they're used to so much confirmation that they freeze up in a way. They can do "It" it's just "It" in a new context is hard. Granted I might struggle in a more formal environment, I don't know I haven't tried it. But the same "It" is not the same "It" everywhere.
- pixl97 5y ago
  Is 'it' a process or is 'it' a goal, guess that's a question many people should ask.
  - duxup 5y ago
    I do get that vibe at times from some folks, unfortunately. They’re more interested in process, rando points, etc.
mad_vill 5y ago
What about companies that sell you on "If you come on, you will do it", and then you get there and it turns out you won't be doing "it" at all?
nateburke 5y ago
This article circles around the most common situation where "wanting to hire a person who has done 'it' before but it's hard to find that person" arises: hiring for startup leadership. Acme Startup needs to hire its first "HEAD of X" to steer X decisions because Acme Co's current leadership has failed in making those decisions and it has harmed growth. Why are they hiring? 1. Acme Co's current leadership has failed to develop its existing talent to the point where an ambitious existing employee can leverage their detailed knowledge of the business to make a solid bid to do "It". 2. Acme Co's current leadership has developed its talent pool well, but can't promote to the sr mgmt team because it would be weird to have one person in their 20s in sr mgmt with everyone else > 40. 3. Acme Co's current leadership has deep cultural and functional flaws and the new hire isn't really what is advertised. e.g. investors are trying out a new CEO. Or there is no real product mgmt happening because the founder/ceo/coo/etc are "product people" and don't want to give up that control but have no time to do it, so they hire a "head of data" so that product decisions can be more data-based... Now let me just draw a picture with some circles and lines to make all of this seem more abstract than it is.
swader999 5y ago
The trick with this approach is for the company to actually know what "It" is.
dbg31415 5y ago
Hiring right now is really broken. Companies: "We want someone who has done IT before!" Perspective Hires: "I've done IT, I can do IT again!" Also Companies: "Oh, so you've done IT? You seem over-qualified..." Workers at the Company: "We should NOT be doing IT, IT is so five-years-ago!"
btbuildem 5y ago
> Or they understand it, but can’t explain it. If they can't explain it, chances are they don't actually understand it.
namanyayg 5y ago
The article mentions that you can copy & paste or mix & match playbooks. But, does anyone know where can someone get the reference playbooks to mix and match..?
y-c-o-m-b 5y ago
You can help alleviate some of this by being completely open and honest on your reasons for leaving a company (and it doesn't just have to be when you're leaving, btw). I know far too many people that are somewhat timid in their exit interviews and simply state "I found a better offer" when really they're frustrated with how "it" is accomplished in their environment. Anytime I resign, I'm brutally honest. Some jackass being nitpicking during code-reviews? That might seem minor, sure, but it's annoying enough to add to that unhappiness threshold which drives people to quit. I make sure it's known as a contributing reason for leaving. If an organization doesn't pick up on these patterns that push people to leave because folks are too shy to share them, we get poor working environments and hiring patterns that are never fixed. It's easy to assign all the blame on these organizations and managers, but we have some options to help from the individual side as well.
- woeirua 5y ago
  I'm going to be blunt. Unless you are a rockstar that is irreplaceable in the organization, no one is going to give two shits about what you say in an exit interview. Your management isn't totally blind or naive. They know whats going on, but there are always reasons as to why they can't or won't act to change the situation. Typically, its because their manager is unresponsive or unwilling to change. Once you understand that nothing you can say or do in an exit interview will matter at all, then it makes sense to be as non-confrontational as possible in order to preserve any references you might have at that company. Prioritize your own career and well-being over any corporation.
  - y-c-o-m-b 5y ago
    Disagree. That may have been true in the past, but it hasn't been the case for the past few years where employers bleed talent rapidly and are in dire need of anyone even remotely competent. I assure you, they are looking at exit interview data and it absolutely matters. A "rockstar" employee (I really hate that term, but I get what you mean) was a luxury many companies no longer have; now they're desperate to just keep the ship afloat with your average team. It's especially important to the many small businesses that have less than 100 employees - like my last employer - where individual resignations on a week-to-week basis is having huge impacts to deliverables. Even at the FAANG I'm currently at, it's very much an important data point. EDIT: FWIW I've had zero issues with "references" with my past employers. All of them are open to me returning as well, so this idea of burning bridges by being honest in exit interviews seems mistaken.
Animats 5y ago
"No one wants to have a “rare problem”. But everyone wants to have a rare opportunity." Which is why there are so many webcrap startups. They don't have to solve any hard new problems. Just combine existing technologies to do something new. "Facebook for cats". (I once watched someone pitch that at a VC conference.) I've been watching this happen in the metaverse space. Large 3D worlds full of user-created content with high graphics quality and good responsiveness are an unsolved problem. You can have any 3 on that list now. All four, not yet. Serious people at Epic and Roblox are working on it and making progress. Over at Facebook/Meta, they've tried three times and blown through US$10 billion failing at it. The NFT crowd thought they could sell land in virtual worlds they haven't built yet, then throw something together and profit. Most of them either have crappy worlds that look like games from the 1990s (Decentraland, Cryptovoxels), have missed their roadmap deadlines for shipping a product, or just took the money and ran. The US Securities and Exchange Commission catches about two of the last category each month, and is starting to investigate some in the second category. (If you sell an NFT for something that exists, that's usually OK. If you sell an NFT for something that doesn't exist yet, that's a speculative investment and public offering of a security.)
awinter-py 5y ago
I think author meant this as a random example but 'basic meeting hygiene and employee onboarding' fix so many problems on teams
renewiltord 5y ago
The problem with hiring someone who has past experience at "it" is the Peter Principle + Market for Lemons + Market Dead Sea Effect. - Peter Principle : Everyone is hired to the level of their incompetence. Consequently, the pool of people who had this job before is full of people who couldn't get promoted from it - Market for Lemons: It is hard to tell whether someone has succeeded at "it". Consequently, you pay at average for those who suck at it and those who rule at it, but those who rule at it won't take the average pay. - Market Dead Sea Effect: Everyone who is good at this role isn't in consideration because they're excelling at it and are going to get promoted to the next level. Those who are average at it are available and going to stay. Those who suck at it are very available and always interviewing but otherwise have the same history. Personally, my heuristic is always whether we can detect an individual whose recent motion is upwards towards this role, i.e. optimize for f(x, ∆x) not just f(x). I'm hoping that high ∆x means the person is unlikely to end at a specific x.
dboshardy 5y ago
Tangential to this point, but I've seen firsthand in a limited capacity but also heard of this from other devs, but there seem to be a decent number of devs who go from job to job doing the same thing over and over again. An example I've seen: a junior dev learns Springboot at a job, then goes from job to job converting their microservices to Springboot. When that project is complete (can take 1 to 2 years in some cases), they get bored or change jobs for a bump in pay and do the same thing again. As they do this a few times, they become a specialist in that field and they start self-selecting to only doing that one thing over and over and over again. Is this widespread? Anyone else noticed this phenomenon?
- humbleMouse 5y ago
justinlloyd 5y ago
My career gas been a little odd. I earn less than some, but more than most. But I don't ever really feel like I've worked a day in my life. I get paid ${ridiculous_sum_of_monies} to play with cool toys. I find interesting problems people have, and then I sign up for that. Some days are more difficult than others, but I am not interested building yet another "it." I am always looking for the "it+1" or "it+that" or "it*n" or "it/time" or "it=>(return null)" I think I am more tactical in my approach to my career, rather than strategic. I don't really have an end goal. I am not looking to maximize income or climb to the top. I see people racing ahead of me every day, younger people chasing up the corporate ladder to earn millions or get that VP role at BigMegaCorp. And they are so successful. And I know that isn't in my mental makeup to want that. I made a comment on another thread about "I will stop work the day that I die" and someone else pointed out that was the saddest thing they ever read. For me, it isn't. Because I don't define "work" as toiling away on a souless project without meaning, or building yet another CRUD app (doing "it"), or not finding meaning in my work. I play. Every day. And I'm happy. And when someone tries to get me to do something that is more like "bullshit jobs", I'll tolerate it for a while if it is "we need to do this to ship." I am willing to do whatever it takes to make the project a success, and if that means I have to push a broom about for a while, cleaning up dust, I will. But if my role becomes permanently that, and we've shipped, or we keep delaying our ship date and the bullshit goes on too long, I wander off to find something else to play with. I do what I do out of love for my work, but not out of love for my job or love for a company. I'd do the kind of work I do for free, even if I wasn't getting paid. But I still want to get paid for my production. I think I have an incredibly privileged position and I realise that probably 90% of software engineers, if they are honest with themselves, probably are doing absolutely meaningless work that nobody wants.
- armagon 5y ago
  Sounds amazing. Can you offer some insights in how other people might apply your approach? Are you a contractor? How can you tell if someone is offering a job of the sort you want, and how do you convince the gatekeepers you can do the work well?
  - justinlloyd 5y ago
jpswade 5y ago
We had these people come in at a company I worked at, the problem I found was “it” at this small to medium business was very different to “it” they had experienced at a large enterprise. It usually took 6 months for them to understand the domain and the problems we needed to address, by which point they didn’t know how to execute because they didn’t have that experience.
dejj 5y ago
"But how many years of walnut do you have?" —If carpenters were hired like programmers. http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650... https://news.ycombinator.com/item?id=7819413 https://news.ycombinator.com/item?id=7819413 https://news.ycombinator.com/item?id=9017027 https://news.ycombinator.com/item?id=9017027
majormajor 5y ago
> Or, the new hire identifies the complexity in the situation, maps it to their speciality, but proposes a way forward that doesn’t match expectations. Leader: “Wait, I didn’t know things were that broken” or “this isn’t actually what we hired you to fix!” > Tension mounts, and that approach inevitably fails as well. I've run into this in a consulting capacity before. They wanted to address just one sticking point using a specific technology, I looked at it, saw a bunch of other potential pitfalls they would hit, brought them up, and it quickly became apparent we were talking across each other. They decided to just use a different technology, in their case, probably the right call for the immediate use case, but it did limit some future options. Not sure how things went long-term there, around if it was the right call for them ultimately or not, because once they were using a different technology they didn't have a need to keep talking to me about the first one. So when talking about full time positions, I bring that up in the interview process. "Oh, you want to use X, let's talk more about why?" If it seems like a bad fit where what they actually need isn't what I'd be excited about working on, I'm less interested, hopefully they take that feedback and find someone who's a better fit. If they seem stuck on "but we just want to use X, can't you do that" then I know it's a bad fit culture-wise.
jet_32951 5y ago
Met this phenomenon today. The interviewer could not elucidate what 'it' was except with buzzwords that have been overworked into meaninglessness.

246 points by jger15 5y ago

jdrc 5y ago

why is hiring/firing posts so popular here? As an indie dev it's kind of annoying to me, this was supposed to be an entrepreneurial community rather than a place for managers to vent every afternoon.

marktangotango 5y ago
Interesting comment. Personally I would say this hasn't been entrepreneurial community for a few years now. Mainly because a lot of people figured out it's easier to go make $X00,000 at Big Tech Co. than to take on the risk of a startup. Secondly the "market place" of ideas is pretty heavily saturated nowadays (imo), seems like unicorns are becoming less common, and the domains a lot harder where there are. And when you do work at Big Co, there's a whole lot of Dilbert-esque stuff like this. Hence the prevalence of this type of material.
eatonphil 5y ago
YC is a startup accelerator and VC. What do you think happens to the companies that grow after completing YC? Ideally they grow and hire (and sometimes, fire) people. The HN community is way broader than just YC and their companies though.
- jdrc 5y ago
  > is way broader than just YC With respect, i think it isn't and that the pendulum has swung too far on the other side. It is more likely that you will find purists who will attack anyone who wants to "make money on the internet" , to the point that people no longer post their projects here. E.g. it is impossible to state that you want to monetize your project via advertising and not get attacked. And yet the people who make those attacks overwhelmingly work in ads companies.
postalrat 5y ago
Hiring/firing is "It".

GianFabien 5y ago

My take is colored by the fact that I only engage as consultant/contractor. The key is to probe deeply before taking on an assignment. If the managers appear too clueless or fixated upon some timeline or budget, then I often decline the work. I often end up fixing / rescuing projects that have been blotched because the previous incumbent rushed into taking on the job. You simply need to ask questions until you are comfortable that the proposed role is feasible. If the client (employer) is unwilling to engage to that depth, then that too is a red flag.

vsareto 5y ago
Not saying you should change, but if they aren't engaged deeply, then that sounds like the freedom to do whatever and get paid for it.
- Consultant32452 5y ago
  This is more closely aligned with the way I think. The more of a cluster I think the project will be the more I charge and the more I change the terms of my contract to get paid regardless of the outcome.
Ensorceled 5y ago
I've had more than one contract come back with a "you were right and the person we hired made a mess, willing to discuss this again"; I've even taken one of those contracts. My favourite is the combination of a tight timeline/budget AND an unwillingness to discuss the project in depth. Especially since they always want some kind of fixed price guarantee in those situations.
- antod 5y ago
  The second mouse gets the cheese
- projektfu 5y ago
  I have definitely seen: Phase 1. "Our problem is big, we hire big company" (3000+ employee firm) Phase 2. Meeting after meeting Phase 3. Lots of billable hours, more meetings. Deadline approaching. Where is the product? Phase 4. Gaslighting Phase 5. Hire small company (1-400 people) to finish the work big company couldn't. (Typical) Phase 6. Quietly kill project because if it ever had a business case it has missed its opportunity. Does this go in the other direction, where a reputable small company starts a big project and is in over its head, only to be saved by one of the big 4 consultancies?

rexreed 5y ago

Here's an additional option: maybe the person who they hired to do "it" never really knew how to do "it" in the first place, and was really good at selling themselves and overpromising and underdelvering, being really good at avoiding personal blame and making sure that any failures were attributed to the organization and not themselves personally. Basically, fakers. There are a surprising number of fakers at the C-level and VP-level who manage to hop from one organization to another, at best providing little benefit, but at worst leaving a destructive wake. Nonetheless management keeps hiring these fakers because others have done so before, and they need "it". Fakers cover their tracks by making sure to not stay at any one place too long, and hiring people below them to actually do the hard work, take over the mess (and responsibility). I wouldn't assume the people that management bring in are any more competent than management themselves. It's unfortunate but there are many serial fakers operating as COOs, CMOs, CIOs, VP Marketing, VP Product Development, VP Business Development, and a smattering of high-sounding but low authority titles such as Chief Innovation Officer, Chief "AI" Officer, and even sadly, too many Chief Data Officers. Those are the sorts of folks who tend to bring in these "playbooks" that look like they can solve the "it" problems but are all smoke and no fire.

Foobar8568 5y ago
Because at these levels, it's not about what you can do, but how you manage politics. From a technical point of view, most of these people are useless and a waste.
- rexreed 5y ago
  At those levels, unfortunately, they have both budget and authority, as well as the ability to impact culture and the definition and prioritization of teams and their work. Sort of like military generals who get their ranks not by proven experience but by working the chain of command, to the great detriment of those who actually have to face the fire.
- bonoboTP 5y ago
  Politics arises whenever people come together. It's comfortable to think that we can simply encapsulate "politics" as such, as something for the stupid people and we the enlightened rational technical people don't concern ourselves with "politics" but unfortunately one cannot simply wish it out of existence. Politics is just a label attached to human behavior. Put 3 people together and you will have "drama" (politics on the small scale). Better learn how to understand people's motivations and incentives instead of bitterly dismissing confusing human behavior as "politics".

tyingq 5y ago

This instantly reminded me of several past situations I've seen. Another common miss is that "it" isn't something the company needs at all. Or in some cases, it's not a bad idea, but there are ten other unrelated ideas the company should be addressing first.

magicink81 5y ago

Great to see Wardley Mapping used as a tool for developing situational awareness. Here's a video of Simon Wardley introducing it: https://www.youtube.com/watch?v=2IW9L1uNMCs https://www.youtube.com/watch?v=2IW9L1uNMCs And for all the details here's a book: https://www.amazon.com/Wardley-Mapping-Knowledge-Topographical-intelligence-ebook/dp/B08LTM3VFX https://www.amazon.com/Wardley-Mapping-Knowledge-Topographic... And book free online: https://medium.com/wardleymaps https://medium.com/wardleymaps

dijit 5y ago
His conclusion at the end is that serverless is the future. Which is interesting to me because on the one hand he might be entirely right, but to my mind it shows a deep underlying problem with this way of thinking. He even mentions during the talk that if you don't move to the way he's suggesting Google and Amazon will own everything, but I draw the opposite conclusion: If we do what he is suggests then Google and Amazon will own everything, because he's saying that we should be giving them everything. Anyway, the issue with the method he's using is that it completely ignores economic incentives. For example: If "building it yourself" costs 0.1% of what it costs to use a commodity product then that reality is not reflected at all on a Wardley Map, in fact a Wardley Map may push you towards using commodities blindly even if they do not make economic sense. Granted: this is a conclusion I came to from his talk, I have not read the 600 page book.

xnorswap 5y ago

I found the article hard to read, I wish it were written more around a concrete example than the abstract. I found it hard to track all the abstract elements in my head which ironically made it harder, not easier, for me to generalise the ideas presented.

lr4444lr 5y ago

I'm gonna share my unsolicited opinion: if you're hiring, you want someone who is ready to do "it". He may or may not have done "it" before, and may not do "it" exactly as you had planned, but he has foundational core competencies, motivation, and the cooperative responsibility taking attitude to accomplish the key parts of "it" as best as you can foresee "it". If you LITERALLY need "it" done as "it" has been done before in an exactly specifiable way, you probably should contract it out. Not hire.

TimPC 5y ago
Hiring for someone who has done it before is very common at the Principal and Staff Engineer level. As people get more senior in their careers there is more demand for specific skills and expertise not less. Contracting out is its own can of worms and can introduce as many problems as it solves. Exact specifiable way typically means 30 details to iron out later even when both sides mean well and those details are usually problematic.
wofo 5y ago
I have had the luck of working with this kind of trust from a company and it is a great experience. It can even work as a contractor. Case in point: for my current project I was hired to port a library from Rust to Java, but since the original library was not mature enough I ended up writing an independent implementation of what the original library was intended to do: a fake MySQL server that lets you handle user requests with custom logic. I had never dreamed of things unfolding that way! Learned a lot and still enjoying it.
- wpietri 5y ago
  Could you say more about the project? I'm curious what motivated making a fake MySQL server.
  - wofo 5y ago
    They are creating a BI platform and wanted it to integrate seamlessly with other existing BI tools. If you pretend to be a MySQL server, you can integrate it with almost anything. There is a high chance we will end up open sourcing the library :)

tmstieff 5y ago

Isn't the point of having a PM to bridge the gap between leadership that knows the domain of "it" and IT who knows how to implement general business needs onto a technical solution? Of course that would require having a PM to begin with, instead of expecting your developers to become subject matter experts in your obscure domain.

Ensorceled 5y ago
This article could literally be talking about hiring for the PM leadership role.
- tmstieff 5y ago
  Good point, I immediately read it and replaced "role" with programmer since it was posted on HN.

Ensorceled 5y ago

I like this article, but it assumes everybody is acting in good faith, so there is that meta issue that this article doesn't address. For example, two situations I have personally experienced several times: The person who did "it" before may not actually be able to "it"; they rode the coat tails of a person who did "it". This "not it" person will often attempt to reframe the problem as one existing in one of the other areas; either as something were they are an "it" person or as "not my problem". The response to a "things are broken" may not be Leader: “Wait, I didn’t know things were that broken” but may actually be Leader: “Wait, these things aren't broken in any way, don't touch those things.” This is not actually a criticism of the article, just if you are trying to apply the article as a leader you may have a "not it" situation or, if you are trying to apply the article as the "it" person, the problem may be the leader.

BlargMcLarg 5y ago
>The person who did "it" before may not actually be able to "it"; they rode the coat tails of a person who did "it". This "not it" person will often attempt to reframe the problem as one existing in one of the other areas; either as something were they are an "it" person or as "not my problem". If we're talking meta issues, my far bigger pet peeve is how the market only wants to people who can do "it" to the point anyone who can't is expected to learn through observation, which loops back to most people only riding others' coat tails. It's cute in theory but in practice, most people need to try it a few times before having a firm grasp on the matter. Then it turns out, most desired skills aren't so obscenely difficult and arcane you couldn't just throw in a decently smart person at it and figure it out, as most tools are designed to be picked up in a short time (you know, like good, widely adopted tools are supposed to be). The entire thing sets up a job market which supports "fake it till you make it".
- Ensorceled 5y ago
  I think this definitely applies to leadership roles in product and technology. People really want someone who did it before and, usually, exactly this thing before. To the point where they hire people who did "it" and failed badly only to have them fail again because they can't do "it".

exabrial 5y ago

In general, if you're stepping into a backfill position, negotiate $10k above asking. They'll say no and you'll both end up happy.

dijit 5y ago
or they say yes and you feel obliged to accept. I asked for $50k above what a company offered me, thinking that we'd part on good terms; and they accepted.. So, I guess that's what I'm doing now.
- exabrial 5y ago
  that's incredible! I suppose the lesson here is make sure you ask enough to keep you from looking over your shoulder and not being able to deal with the inevitable 'backfill blues'

perrygeo 5y ago

Company: "Here's some big problems, can you help?" Senior Dev: "Yes!" C: "How would you recommend proceeding?" D: "I've studied the problem and my professional recommendation is to implement X, migrate away from Y and refactor Z." C: "Oh, that seems like too much work and would disrupt the teams already working on Y and Z. Let's do it this way instead (points to Confluence page written by an intern last summer)" D: "..." C: "So you're not able to help us after all?"

dvtrn 5y ago
This hits too close to home, even as a staff engineer.
renewiltord 5y ago
An average L7 at Amazon will see that "limit disruption to Y and Z" is simply a constraint to the engineering problem and make it work. That's sort of what makes someone at that level - the ability to detect the cost for moving different constraints and being able to demonstrate the technorganizational advantage from doing it. Combine that with the ability to get grassroots implementer support and you have a pretty able leader. Everything is just constraint solving in the end, and the hard part is maintaining pace.
- perrygeo 5y ago
  Of course. Implied in the senior developer's solution ("migration") is a plan to navigate those challenges - technically, politically and socially. What I tend to see is ignorant management insisting that there must be an easier way, rejecting all empirical evidence to the contrary, even going so far as to reject the concept of engineering tradeoffs entirely. It's as if the experience and accumulated wisdom of the senior ICs is valuable only insofar as it makes them slightly more productive code monkeys, merely speeding up the existing plan put in place by management without any say in said plan. Why even hire senior employees at that point?

guessbest 5y ago

I assume that this is why management is obsessed with hiring their competitors employees including developers. They want another but proven way of doing 'it'

anon23anon 5y ago
we recently redid authentication in our app - was told to do it exactly like Chase did theirs which I thought was an odd requirement. Come to find out the corporate executives get Chase credit cards so they were all using the Chase app and familiar with it and essentially told the products owners to build it just like the Chase and then told me/us the developers to build it exactly like the Chase app. Shaking my head. How dumb. Anyhow come to find out Chase does this weird thing were even if you press sign out in app it essentially keeps you logged in and if you're using biometrics you can effectively unlock the app and get right back in w/ Face/Touch ID. We didn't implement that but apparently this executive clicks sign out when their done using the app and still expected to get right back in so we had to rebuild that part. F my life.
- guessbest 5y ago
  It becomes a cargo cult.
- daok 5y ago
  Why is that dumb if they gave you exactly what they want? Regardless of their motive, that is what they want and hire you to do. I do not clearly see your point here.

nemo 5y ago

The post opens with a false dichotomy. In general my experience has been that we hired someone that management selected because they'd "done it" before (always in very different contexts), they ramped up to our project, and it worked out pretty well. I don't think it's necessarily the best selection process, but selecting for prior experience is not a very serious problem in hiring imo.

ryandrake 5y ago

Another problem is from the candidate's point of view: I've already done "It" before. I've been doing "It" for the last decade. If I move companies, I want to do "It+1" at the very least, more likely "It+2". It's not enough for me to simply do "It" again but at a different company. So many recruiters reach out with that pitch, and I simply ignore them now: "I see you have a great background doing 'It' at 'Company'. We're offering a role doing 'It' here at this company! Isn't that exciting?" No, it's not, actually. Now if you want me to manage a team of engineers doing "It", let's talk. If you want me to be Director of "It", I'll stop what I am doing and get on the phone with you in 5 minutes! But simply "Keep doing 'It' but at our company" is not even slightly motivating.

HeyLaughingBoy 5y ago
Part of the problem here might be that the HN population self-selects for the personality type that wants to do "at least It+1" There's a larger population out there that having mastered "It," will happily do exactly the same thing for the next 10 years.
- daniel-cussen 5y ago
  That's very true those peeps for sure exist just not on this forum.
padobson 5y ago
"Keep doing 'It' but at our company" is not even slightly motivating. That's true, but what about "Keep doing 'It' but at our company for half the hours and double the salary"? Then you could take the extra time and money and work on your +1 and +2.
- gonzo41 5y ago
  I would guess that doing the +1 and +2 is mentally and emotionally easier and more satisfying if it's during a hellish 60 hour work week than in a relaxed 10 hours you freed up by getting more pay and a 30 hour week to do something easy. Like doing programming problems is fun for a bit, but doing work that actually does something, even if it's simpler in complexity is more satisfying. IMO of course. I think the recruiters could be pitching better if they went with, do 'it' here and think about what +1 could be and when you figure what that could be, pitch it to us. This of course assumes the organization sees IT as a value multiplier and not a cost center / plumbing job.

indymike 5y ago

It's easy to hire someone who has done something before. It's hard to make sure you've got a situation where they can do the same thing.

zeroonetwothree 5y ago

I don’t really get what “it” means in the context of this article. Using some actual examples might be nice.

anon23anon 5y ago
see my post in the other thread
d23 5y ago
Not sure it matters. This whole thing could be summarized as: > Consider context when you're hiring and doing work. I don't think any number of diagrams and attempts at categorization are going to help people who can't figure that out.
orthoxerox 5y ago
Anything that the company hasn't done before: - scale our app to 10mil users - fix constant Oracle performance issues - build a data lake - migrate to the new HR system - reorg the IT because Price's law is destroying our bottom line - build a private cloud - design a new microservices-based e-banking app - sell the startup to a FAANG until the end of the year because it's running out of VC money

genezeta 5y ago

Another common situation I've encountered is this one: They don't really want "it". They say they want someone to do "it", they hire someone who has done "it". But then that wasn't really what they wanted done. I think I can also draw the hypothesis that the more convinced they say they want "it" and/or the bigger the "it" they ask for, the less they actually want it when the time comes.

temptemptemp111 5y ago

travisgriggs 5y ago

I see these symptoms most when the Venn intersection of “Doers” and “Deciders” grows too small. The marriage of “I have money, you have talent” is all too often one sided. If the two parties can realize it is a marriage of convenience where they can play off of each other’s strengths, then it can be mutually beneficial.

padobson 5y ago

Another one I've seen quite often is management wants "it", and then they hire someone who can do "it", but the company/product isn't nearly ready for "it". Think hiring a DBA before you have 100 total rows in your database, or hiring someone to write an AI recommendation engine before you have any users at all. The "it" person sits around feeling uncomfortable and is inevitably asked to work on something they don't really know how to do and doesn't want to learn. They usually leave before the company ever gets to the point where the relationship is useful.

bryanrasmussen 5y ago
The worst job I ever got hired at (about 15 years ago) wanted asp.net, C#, html, css, javascript, xslt, and SQL. It turned out the whole of the job was optimizing SQL queries because you were not allowed to touch any other part of the application because that was all handled by jealous developers in Norway. They wanted people who could do it, but they didn't actually know what it was.
rozenmd 5y ago
reminds me of data science 5 years ago - everyone wanted to say they hired data scientists, no one wanted to admit they didn't know where their company data was being stored
- lysecret 5y ago
  very optimistic take, that its only 5 years ago :D Also they know where it is, in a 1000 different excels haha
austhrow743 5y ago
Worst case I've seen of that was a pilot hired to fly a private jet mostly being used as an unrelated to aircraft general maintenance man because there were no clients for the recently purchased private jet. Was incredibly uncomfortable needing something done and knowing I'd be told to get him to do it. His unhappiness with his position was palpable.

ilaksh 5y ago

They touched on something in the article but it deserves more emphasis. The most difficult and critical part of software development is requirements engineering. I will includes requirements negotiation as part of that. Something that I have always had to fight against is the tendency to take business stakeholders at their word when they say they have a specific set of requirements or deadline. Project success often hinges upon modifying or rejecting supposed requirements given unambiguously. The hardest part of this is that business analysts or executives prescribing requirements often have more seniority or political power in an organization than the software engineer. They also don't really know what requirements engineering is or that it is something the _software engineer_ _has_ to do. It's necessary to understand the details of business problems and then do some level of analysis of how to address them with technology. The majority of projects have done about 50-90% of the necessary depth of business analysis and that is what they present to the programmer as a supposedly complete description. But pushing a little harder on those details it's often possible to find process descriptions scrambled, missing important information, and processes that really aren't required. Once the engineer truly understands the business, they can think in depth about ways to use technology to deliver value. They can come up with design outlines for the software and think about how to break things up into different iterations. What is worthwhile in terms of programming effort versus business value. They cannot do that without having drilled down into details. It's quite common for an important detail to be omitted in discussions initially, which dramatically increase the programming difficulty or changes the approach. That's why it's so important to always be digging to uncover real requirements (and especially at the start). Getting all of that resolved requires not only strong communication skills but also favorable political outcomes. If the project management isn't good, they can interfere or fail to provide support during the requirements phases and therefore kill any possibility of success from the start. But regardless of how good the managers, requirements need to be negotiated and agreed upon which is another challenge. Beyond all of that, programming really is hard. If it wasn't, it would not be programming. It would be copy and paste or configuring existing software. The premise is that you have unique problems that have not been solved yet. So you need expertise but also strong problem solving skills. Which all the while you may be dealing with all the people issues at the same time.

anon23anon 5y ago

mbg721 5y ago

"I used to be With It. But now what I'm With isn't It, and what's It seems weird and scary to me. It'll happen to you!"

evilantnie 5y ago
They changed what It was!

photochemsyn 5y ago

Solution: replace company leaders (who sound like they come from the financial sector, as they don't understand 'it', other than that others have made money off 'it') with engineers.

orthoxerox 5y ago
Hey, remember Xerox PARC?

Ozzie_osman 5y ago

The other challenge with hiring someone who has done "it", is they may not want to do it again, especially in startup contexts. "Find me someone who has scaled the infrastructure of a fintech startup from Y to Z". Some people may enjoy the same challenge again, but lots may want some variation (eg different company stage, different industry, different scale).

gkop 5y ago
Speaking personally, I can’t do It again, if It represents an apex accomplishment of mine. My apex accomplishments, I was able to do, only because of a special confluence of factors, never to be repeated. Fortunately, this forces me to seek new apex accomplishments, which keeps things interesting and growthful.

georgeecollins 5y ago

This reminds me of one of my first consulting gigs, where someone asked me if I could do "it" where "it" was something I had done before a couple times. Sure, I said. But then I get to the company, spend a few days and see enough to know "it" wasn't the problem at all. A bunch of other things were keeping "it" from happening and they didn't want to change those things. Thank goodness I was consulting and could bow out.

drewcoo 5y ago
I've seen this several times. Management wants to do "it" but isn't sure how to get there. They hire an expert, who determines that management is actually the thing keeping "it" from happening. [cue sad trombone]
- andrekandre 5y ago
  > management is actually the thing keeping "it" from happening. in the end, its almost always this isn't it...

duxup 5y ago

I haven't been writing code professionally really long but one thing I notice is "It" ... even the same "It" can be dramatically different wherever you go and not everyone seems to be entirely aware of that or able to adapt. You get folks who maybe have worked a few places, or a lot of places that all operate with the same bureaucracy / processes and they seem unaware that it could possibly be different anywhere else. Some folks I know work at a very large corp. Their development cycle is very heavy with processes, albeit seems very reasonable / works for them. Folks writing up what some feature should do for 100 different possibles, folks reviewing it in some way ... on and on. Maybe someone finally writes code and everyone reviews it. Testing, testing, testing. I'm not judging it, it's just ... a lot. I work at a place with 3 devs, and only one other really does what I do. I get a vague idea of a feature requested, I talk to the customer, I go write it. Show some folks, maybe I change things, maybe not. I roll it out. Done. Feature is out there in production, live, sometimes in just a few hours (and I watch our error reporting system to see if it blows up or not). It's a completely different mindset / process. I've worked with folks who worked at very large corp and they weren't doing anything differently than I do, but in my more informal / not a lot of review environment they struggle. They're good, they're not bad, they just are so used to so many eyeballs / not used to talking to customers (and distilling what they say) / they're used to so much confirmation that they freeze up in a way. They can do "It" it's just "It" in a new context is hard. Granted I might struggle in a more formal environment, I don't know I haven't tried it. But the same "It" is not the same "It" everywhere.

pixl97 5y ago
Is 'it' a process or is 'it' a goal, guess that's a question many people should ask.
- duxup 5y ago
  I do get that vibe at times from some folks, unfortunately. They’re more interested in process, rando points, etc.

mad_vill 5y ago

What about companies that sell you on "If you come on, you will do it", and then you get there and it turns out you won't be doing "it" at all?

nateburke 5y ago

This article circles around the most common situation where "wanting to hire a person who has done 'it' before but it's hard to find that person" arises: hiring for startup leadership. Acme Startup needs to hire its first "HEAD of X" to steer X decisions because Acme Co's current leadership has failed in making those decisions and it has harmed growth. Why are they hiring? 1. Acme Co's current leadership has failed to develop its existing talent to the point where an ambitious existing employee can leverage their detailed knowledge of the business to make a solid bid to do "It". 2. Acme Co's current leadership has developed its talent pool well, but can't promote to the sr mgmt team because it would be weird to have one person in their 20s in sr mgmt with everyone else > 40. 3. Acme Co's current leadership has deep cultural and functional flaws and the new hire isn't really what is advertised. e.g. investors are trying out a new CEO. Or there is no real product mgmt happening because the founder/ceo/coo/etc are "product people" and don't want to give up that control but have no time to do it, so they hire a "head of data" so that product decisions can be more data-based... Now let me just draw a picture with some circles and lines to make all of this seem more abstract than it is.

swader999 5y ago

The trick with this approach is for the company to actually know what "It" is.

dbg31415 5y ago

Hiring right now is really broken. Companies: "We want someone who has done IT before!" Perspective Hires: "I've done IT, I can do IT again!" Also Companies: "Oh, so you've done IT? You seem over-qualified..." Workers at the Company: "We should NOT be doing IT, IT is so five-years-ago!"

btbuildem 5y ago

> Or they understand it, but can’t explain it. If they can't explain it, chances are they don't actually understand it.

namanyayg 5y ago

The article mentions that you can copy & paste or mix & match playbooks. But, does anyone know where can someone get the reference playbooks to mix and match..?

y-c-o-m-b 5y ago

You can help alleviate some of this by being completely open and honest on your reasons for leaving a company (and it doesn't just have to be when you're leaving, btw). I know far too many people that are somewhat timid in their exit interviews and simply state "I found a better offer" when really they're frustrated with how "it" is accomplished in their environment. Anytime I resign, I'm brutally honest. Some jackass being nitpicking during code-reviews? That might seem minor, sure, but it's annoying enough to add to that unhappiness threshold which drives people to quit. I make sure it's known as a contributing reason for leaving. If an organization doesn't pick up on these patterns that push people to leave because folks are too shy to share them, we get poor working environments and hiring patterns that are never fixed. It's easy to assign all the blame on these organizations and managers, but we have some options to help from the individual side as well.

woeirua 5y ago
I'm going to be blunt. Unless you are a rockstar that is irreplaceable in the organization, no one is going to give two shits about what you say in an exit interview. Your management isn't totally blind or naive. They know whats going on, but there are always reasons as to why they can't or won't act to change the situation. Typically, its because their manager is unresponsive or unwilling to change. Once you understand that nothing you can say or do in an exit interview will matter at all, then it makes sense to be as non-confrontational as possible in order to preserve any references you might have at that company. Prioritize your own career and well-being over any corporation.
- y-c-o-m-b 5y ago
  Disagree. That may have been true in the past, but it hasn't been the case for the past few years where employers bleed talent rapidly and are in dire need of anyone even remotely competent. I assure you, they are looking at exit interview data and it absolutely matters. A "rockstar" employee (I really hate that term, but I get what you mean) was a luxury many companies no longer have; now they're desperate to just keep the ship afloat with your average team. It's especially important to the many small businesses that have less than 100 employees - like my last employer - where individual resignations on a week-to-week basis is having huge impacts to deliverables. Even at the FAANG I'm currently at, it's very much an important data point. EDIT: FWIW I've had zero issues with "references" with my past employers. All of them are open to me returning as well, so this idea of burning bridges by being honest in exit interviews seems mistaken.

Animats 5y ago

"No one wants to have a “rare problem”. But everyone wants to have a rare opportunity." Which is why there are so many webcrap startups. They don't have to solve any hard new problems. Just combine existing technologies to do something new. "Facebook for cats". (I once watched someone pitch that at a VC conference.) I've been watching this happen in the metaverse space. Large 3D worlds full of user-created content with high graphics quality and good responsiveness are an unsolved problem. You can have any 3 on that list now. All four, not yet. Serious people at Epic and Roblox are working on it and making progress. Over at Facebook/Meta, they've tried three times and blown through US$10 billion failing at it. The NFT crowd thought they could sell land in virtual worlds they haven't built yet, then throw something together and profit. Most of them either have crappy worlds that look like games from the 1990s (Decentraland, Cryptovoxels), have missed their roadmap deadlines for shipping a product, or just took the money and ran. The US Securities and Exchange Commission catches about two of the last category each month, and is starting to investigate some in the second category. (If you sell an NFT for something that exists, that's usually OK. If you sell an NFT for something that doesn't exist yet, that's a speculative investment and public offering of a security.)

awinter-py 5y ago

I think author meant this as a random example but 'basic meeting hygiene and employee onboarding' fix so many problems on teams

renewiltord 5y ago

The problem with hiring someone who has past experience at "it" is the Peter Principle + Market for Lemons + Market Dead Sea Effect. - Peter Principle : Everyone is hired to the level of their incompetence. Consequently, the pool of people who had this job before is full of people who couldn't get promoted from it - Market for Lemons: It is hard to tell whether someone has succeeded at "it". Consequently, you pay at average for those who suck at it and those who rule at it, but those who rule at it won't take the average pay. - Market Dead Sea Effect: Everyone who is good at this role isn't in consideration because they're excelling at it and are going to get promoted to the next level. Those who are average at it are available and going to stay. Those who suck at it are very available and always interviewing but otherwise have the same history. Personally, my heuristic is always whether we can detect an individual whose recent motion is upwards towards this role, i.e. optimize for f(x, ∆x) not just f(x). I'm hoping that high ∆x means the person is unlikely to end at a specific x.

dboshardy 5y ago

Tangential to this point, but I've seen firsthand in a limited capacity but also heard of this from other devs, but there seem to be a decent number of devs who go from job to job doing the same thing over and over again. An example I've seen: a junior dev learns Springboot at a job, then goes from job to job converting their microservices to Springboot. When that project is complete (can take 1 to 2 years in some cases), they get bored or change jobs for a bump in pay and do the same thing again. As they do this a few times, they become a specialist in that field and they start self-selecting to only doing that one thing over and over and over again. Is this widespread? Anyone else noticed this phenomenon?

humbleMouse 5y ago

justinlloyd 5y ago

My career gas been a little odd. I earn less than some, but more than most. But I don't ever really feel like I've worked a day in my life. I get paid ${ridiculous_sum_of_monies} to play with cool toys. I find interesting problems people have, and then I sign up for that. Some days are more difficult than others, but I am not interested building yet another "it." I am always looking for the "it+1" or "it+that" or "it*n" or "it/time" or "it=>(return null)" I think I am more tactical in my approach to my career, rather than strategic. I don't really have an end goal. I am not looking to maximize income or climb to the top. I see people racing ahead of me every day, younger people chasing up the corporate ladder to earn millions or get that VP role at BigMegaCorp. And they are so successful. And I know that isn't in my mental makeup to want that. I made a comment on another thread about "I will stop work the day that I die" and someone else pointed out that was the saddest thing they ever read. For me, it isn't. Because I don't define "work" as toiling away on a souless project without meaning, or building yet another CRUD app (doing "it"), or not finding meaning in my work. I play. Every day. And I'm happy. And when someone tries to get me to do something that is more like "bullshit jobs", I'll tolerate it for a while if it is "we need to do this to ship." I am willing to do whatever it takes to make the project a success, and if that means I have to push a broom about for a while, cleaning up dust, I will. But if my role becomes permanently that, and we've shipped, or we keep delaying our ship date and the bullshit goes on too long, I wander off to find something else to play with. I do what I do out of love for my work, but not out of love for my job or love for a company. I'd do the kind of work I do for free, even if I wasn't getting paid. But I still want to get paid for my production. I think I have an incredibly privileged position and I realise that probably 90% of software engineers, if they are honest with themselves, probably are doing absolutely meaningless work that nobody wants.

armagon 5y ago
Sounds amazing. Can you offer some insights in how other people might apply your approach? Are you a contractor? How can you tell if someone is offering a job of the sort you want, and how do you convince the gatekeepers you can do the work well?
- justinlloyd 5y ago

jpswade 5y ago

We had these people come in at a company I worked at, the problem I found was “it” at this small to medium business was very different to “it” they had experienced at a large enterprise. It usually took 6 months for them to understand the domain and the problems we needed to address, by which point they didn’t know how to execute because they didn’t have that experience.

dejj 5y ago

"But how many years of walnut do you have?" —If carpenters were hired like programmers. http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa6506e2f35eaac http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650... https://news.ycombinator.com/item?id=7819413 https://news.ycombinator.com/item?id=7819413 https://news.ycombinator.com/item?id=9017027 https://news.ycombinator.com/item?id=9017027

majormajor 5y ago

> Or, the new hire identifies the complexity in the situation, maps it to their speciality, but proposes a way forward that doesn’t match expectations. Leader: “Wait, I didn’t know things were that broken” or “this isn’t actually what we hired you to fix!” > Tension mounts, and that approach inevitably fails as well. I've run into this in a consulting capacity before. They wanted to address just one sticking point using a specific technology, I looked at it, saw a bunch of other potential pitfalls they would hit, brought them up, and it quickly became apparent we were talking across each other. They decided to just use a different technology, in their case, probably the right call for the immediate use case, but it did limit some future options. Not sure how things went long-term there, around if it was the right call for them ultimately or not, because once they were using a different technology they didn't have a need to keep talking to me about the first one. So when talking about full time positions, I bring that up in the interview process. "Oh, you want to use X, let's talk more about why?" If it seems like a bad fit where what they actually need isn't what I'd be excited about working on, I'm less interested, hopefully they take that feedback and find someone who's a better fit. If they seem stuck on "but we just want to use X, can't you do that" then I know it's a bad fit culture-wise.

jet_32951 5y ago

Met this phenomenon today. The interviewer could not elucidate what 'it' was except with buzzwords that have been overworked into meaninglessness.