One way a builder culture can fail(rachelbythebay.com)
rachelbythebay.com
One way a builder culture can fail
http://rachelbythebay.com/w/2021/12/02/build/
131 comments
>People like Rachael (who obviously love this work at their very core) are doomed to end up a jaded curmudgeon unless they 1) start their own company 2) join a tiny company. Big tech is hell. Make your money and GTFO.
Absolutely correct. This reflects perfectly with my professional career. In the early 2000s I worked at a place which started hiring "bozos" in frightening rate. They killed an internal project for CMS (I was the PM) and proceed to hire external agency for content management, because - "Nobody of our clients is willing to do this complicated technical stuff".
After a heated "debate" with the "bozos", management and CEO of the company, I quitted my well payed job. I created my own company and hired all of my team. For the next 10 years most of my ex company clients came to me by simple word of mouth marketing.
Absolutely correct. This reflects perfectly with my professional career. In the early 2000s I worked at a place which started hiring "bozos" in frightening rate. They killed an internal project for CMS (I was the PM) and proceed to hire external agency for content management, because - "Nobody of our clients is willing to do this complicated technical stuff".
After a heated "debate" with the "bozos", management and CEO of the company, I quitted my well payed job. I created my own company and hired all of my team. For the next 10 years most of my ex company clients came to me by simple word of mouth marketing.
> Yes it's absolutely infuriating watching them somehow gain the confidence of the C-level folks, obtain a lot of resources, and burn everything to the ground all while claiming plausible deniability.
Thanks for summarizing my biggest gripe with my current employer so clearly! It is going on, and all the senior all the engineers see it and there is nothing you can do to prevent it. Only make sure you stay away from whatever these bozo's fancy, as someone will have to clean up or take the blame when everything falls apart.
Anyone know an alternative GTFO? After a few years of complain/ignore/avoid if feel that is my only option.
Thanks for summarizing my biggest gripe with my current employer so clearly! It is going on, and all the senior all the engineers see it and there is nothing you can do to prevent it. Only make sure you stay away from whatever these bozo's fancy, as someone will have to clean up or take the blame when everything falls apart.
Anyone know an alternative GTFO? After a few years of complain/ignore/avoid if feel that is my only option.
Completely imaginary conversation ...
> Look Mr. C-level, I built this amazing tool. Look at the graphs it produces. It allows _the_ user to customize parameters, track new things, and basically makes unicorns excrete rainbows.
> OMG, I don't know the first thing about how computers work, but I love colorful pictures and unicorns. You are amazing. And, this is the first time you tried this stuff?
> Yes, but these jerks over there, they won't put it on the web! They say it is insecure, risks revealing confidential data to the whole world, and can be used to infiltrate the company network.
> But these are the best colorful pictures I've seen. Off with their heads!
> Look Mr. C-level, I built this amazing tool. Look at the graphs it produces. It allows _the_ user to customize parameters, track new things, and basically makes unicorns excrete rainbows.
> OMG, I don't know the first thing about how computers work, but I love colorful pictures and unicorns. You are amazing. And, this is the first time you tried this stuff?
> Yes, but these jerks over there, they won't put it on the web! They say it is insecure, risks revealing confidential data to the whole world, and can be used to infiltrate the company network.
> But these are the best colorful pictures I've seen. Off with their heads!
And now how I imagine it would go:
> Look Mr. C-level, I built this amazing tool that makes unicorns excrete rainbows. It is a PoC built in my own time cause I don't have time/money or a project.
> Wow, great! We need this, it fit right into our strategy for Digital! Just go talk to Mr. Bozo, our head of Digital Innovation Strategy Management.
> O, so you have an idea and want budget. Please write a two page memo describing how you can add value, who the internal client will be. Make sure you get steering council approval too and approval from our CISO. If you succeed I will present this to the board as something cool I am personally responsible for! O, and please ask the internal clients for funding, cause you are providing value right? They will be happy to put you in their year plan. The plans for 2022 have already been sent to the board for approval, but this can be the first thing for 2023! In the meantime I will buy an off the shelf solution with <big vendor> and pay a fortune to let them customize it so it doesn't work anymore. Before anyone realizes what a waste of money that was I'll be long gone, haha. Off to the <big vendor> sky box, they invited me to come watch the Super Bowl again.
> Look Mr. C-level, I built this amazing tool that makes unicorns excrete rainbows. It is a PoC built in my own time cause I don't have time/money or a project.
> Wow, great! We need this, it fit right into our strategy for Digital! Just go talk to Mr. Bozo, our head of Digital Innovation Strategy Management.
> O, so you have an idea and want budget. Please write a two page memo describing how you can add value, who the internal client will be. Make sure you get steering council approval too and approval from our CISO. If you succeed I will present this to the board as something cool I am personally responsible for! O, and please ask the internal clients for funding, cause you are providing value right? They will be happy to put you in their year plan. The plans for 2022 have already been sent to the board for approval, but this can be the first thing for 2023! In the meantime I will buy an off the shelf solution with <big vendor> and pay a fortune to let them customize it so it doesn't work anymore. Before anyone realizes what a waste of money that was I'll be long gone, haha. Off to the <big vendor> sky box, they invited me to come watch the Super Bowl again.
Buy the company?
> Oh, you can't because you're making 300k base + 2 years away from 800k in RSUs
I'm working in a semi big tech company and not making anywhere near that (in UK) should I cry myself to sleep ?
I'm working in a semi big tech company and not making anywhere near that (in UK) should I cry myself to sleep ?
Friendly reminder that salaries in the US are substantially bigger than in the UK/Europe.
For context, making GBP175000/year or over would put you in the 99th percentile for the UK.
Source: https://www.gov.uk/government/statistics/percentile-points-f...
For context, making GBP175000/year or over would put you in the 99th percentile for the UK.
Source: https://www.gov.uk/government/statistics/percentile-points-f...
I’m not sure I’ve ever met anyone that makes even £100,000 to be honest. I make £50k and I’m the highest paid person in my family by a long way.
Then again, I do live about 250 miles north of London, so that no doubt skews things somewhat.
Then again, I do live about 250 miles north of London, so that no doubt skews things somewhat.
In the US that really depends where you live and where you are at in your career. If you just started a year or two ago that would not be out the realm of possibility in the US, in what many affectionally call 'the fly over states'. Depending on where you live it can be a lot less or more. If you have 10+ years 100k+ US (90k UK) is not unreasonable at all. You see very large comp packages here as that is what the VC companies talk. They also usually include in the comp package things like parking, your desk, the building you work in, health insurance (usually at least 12k per year), the nice dual screen computer, any 401k contributions, RSU that has not matured yet. Basically anything to make that number seem huge. One company I worked at they were saying I had a comp package of 250k yet I took home closer to 110.
But take home base pay is usually in line with whatever area your are living in and the amount of exp you have. Everything else is bonus. That bonus is usually bandied about in interviews but sometimes never materializes.
But take home base pay is usually in line with whatever area your are living in and the amount of exp you have. Everything else is bonus. That bonus is usually bandied about in interviews but sometimes never materializes.
I'm in Missouri writing Erlang remotely making 155k USD and my situation is not unique
Yep, UK is the US for dev costs what India is to UK. I assume there are companies in the US out sourcing to a UK company that is the out source to an Indian company and the US companies have no idea.
It's re-sellers all the way down
Most engineers don’t, but many do.
I agree. The article feels weird. To me the topic is complex.
Absolutely you can do it yourself, but that is also a common pitfall. The belief that something can just be built in x amount of seconds by yourself comes with several risks. Building is easy, committing to a lifecycle is hard and managing the technical debt is an important part of the job.
I'm trying not to build a house of cards.
Absolutely you can do it yourself, but that is also a common pitfall. The belief that something can just be built in x amount of seconds by yourself comes with several risks. Building is easy, committing to a lifecycle is hard and managing the technical debt is an important part of the job.
I'm trying not to build a house of cards.
> So, um, who decides what belongs in production?
Product Owner, or just management?
On a side note: in "mature" markets a bricklayer nor an architect, nor constructor can really build anything they want without anyone looking.
Product Owner, or just management?
On a side note: in "mature" markets a bricklayer nor an architect, nor constructor can really build anything they want without anyone looking.
I'm confused why anyone would think this is about optics and not about performance.
If something Does Not Work Reliably - when it has no reasonable reason for not doing so - then it Does Not Belong In Production.
As for mature markets - useless and/or broken buildings happen all the time. Sometimes this is because a starchitect is good at making buildings that look incredible but bad at making buildings that don't have problems. (Calatrava, Frank Lloyd Wright, many more.)
Sometimes it's because the project is extractive and the goal is money at the expense of quality - or even usability. (Many housing estates and not a few McMansions.)
Both of these are different to a tech co hiring the equivalent of a minor starchitect to Make A Thing Happen, but getting something non-performant and/or impossible to maintain. The difference is that unless it's a greenfield startup Thing is likely to be easy to define and its performance should be easy to measure objectively with simple metrics like uptime, throughput, and so on.
If something Does Not Work Reliably - when it has no reasonable reason for not doing so - then it Does Not Belong In Production.
As for mature markets - useless and/or broken buildings happen all the time. Sometimes this is because a starchitect is good at making buildings that look incredible but bad at making buildings that don't have problems. (Calatrava, Frank Lloyd Wright, many more.)
Sometimes it's because the project is extractive and the goal is money at the expense of quality - or even usability. (Many housing estates and not a few McMansions.)
Both of these are different to a tech co hiring the equivalent of a minor starchitect to Make A Thing Happen, but getting something non-performant and/or impossible to maintain. The difference is that unless it's a greenfield startup Thing is likely to be easy to define and its performance should be easy to measure objectively with simple metrics like uptime, throughput, and so on.
>If something Does Not Work Reliably - when it has no reasonable reason for not doing so - then it Does Not Belong In Production.
Half of the companies would have died if they followed this -- including Twitter (which had to cron-restart Rails to get it to run for more than a day in its early years, Facebook, ...)
Half of the companies would have died if they followed this -- including Twitter (which had to cron-restart Rails to get it to run for more than a day in its early years, Facebook, ...)
They can look, but as you go up the scale of complexity, at a certain point, only the master tradesmen will have a clue whether the work is good or not.
Any high-skill industry has huge amounts of problems with this — rarely outright fraud, but lots of problems with "confidence men" pitching mediocre solutions to problems, and conning their way into running the full lifecycle of contracts based on this. Generally they'll deliver something, but it's usually something pretty mediocre that only kind of does the job. The further a thing is from a company's core competency (and thus, the likelihood that the executives have subject-matter expertise), the more likely this problem is.
People can raise objections all they want, but there's so much "poor faith" lying done in our world, that, as a boss, it's almost impossible to tell which things are libel, and which things are a desperate attempt to warn you something's wrong. Rigorous "professional bodies" like doctor's associations help immensely. These problems are at their worst in fields where things like that don't exist (such as software).
Any high-skill industry has huge amounts of problems with this — rarely outright fraud, but lots of problems with "confidence men" pitching mediocre solutions to problems, and conning their way into running the full lifecycle of contracts based on this. Generally they'll deliver something, but it's usually something pretty mediocre that only kind of does the job. The further a thing is from a company's core competency (and thus, the likelihood that the executives have subject-matter expertise), the more likely this problem is.
People can raise objections all they want, but there's so much "poor faith" lying done in our world, that, as a boss, it's almost impossible to tell which things are libel, and which things are a desperate attempt to warn you something's wrong. Rigorous "professional bodies" like doctor's associations help immensely. These problems are at their worst in fields where things like that don't exist (such as software).
Actually I thought the way it ended was the best point. You can use the interview process itself to understand if you are about to work for one of these companies, which lines up with my experience well. Leet code grind? Expect a shit show on the inside. Which is fine if you are joining for money / friends (who work there) / prestige. But quality shop that knows what they are doing? Probably gonna ask things other than leet code questions.
> So, um, who decides what belongs in production?
All the customers who leave when your product/service goes to shit because that thing actually didn't belong in production?
> ... is the crux of her point.
No, the crux of her point is that the company is now suffering. If 'X' did belong in production, the company would now be blossoming.
All the customers who leave when your product/service goes to shit because that thing actually didn't belong in production?
> ... is the crux of her point.
No, the crux of her point is that the company is now suffering. If 'X' did belong in production, the company would now be blossoming.
“Building” is fun. Projects are fun. Governance and sustainment are not fun for builders and as an organization grows, you need more than builders.
It’s kind of a universal theme in any endeavor. I work in a very different place and have similar experiences. As a founding member of a “startup” within a massive bureaucracy, we grew from 4 people to 4,000.
Remember that people are different. My wife is a finance/auditor by trade - digging through balance sheets and controls to audit stuff is awesome work for her. Conversely, some of the details of how the sausage is made when you build a growing service just seems “wrong” based on her training/profession.
It’s kind of a universal theme in any endeavor. I work in a very different place and have similar experiences. As a founding member of a “startup” within a massive bureaucracy, we grew from 4 people to 4,000.
Remember that people are different. My wife is a finance/auditor by trade - digging through balance sheets and controls to audit stuff is awesome work for her. Conversely, some of the details of how the sausage is made when you build a growing service just seems “wrong” based on her training/profession.
I think there is something important there that all people are different and have different goals/experiences/skills etc.
I would say that many companies corporate hierarchy enables/rewards people with political goals to end up in positions of power which slowly corrode the company. It also allows for "bozos" per OP language to propel up the ladder and espouse their ideas without any pragmatic experience or understanding to really solve the problems. People who present well and can play the political game but can't translate to execution.
The worst people for that are the finance people who are sometimes good at numbers, models, they think they understand everything (I.e. MBAs) and somehow accrue power. Once you company has a lot of those at the top level of leadership you are about to enter builder hell.
I would say that many companies corporate hierarchy enables/rewards people with political goals to end up in positions of power which slowly corrode the company. It also allows for "bozos" per OP language to propel up the ladder and espouse their ideas without any pragmatic experience or understanding to really solve the problems. People who present well and can play the political game but can't translate to execution.
The worst people for that are the finance people who are sometimes good at numbers, models, they think they understand everything (I.e. MBAs) and somehow accrue power. Once you company has a lot of those at the top level of leadership you are about to enter builder hell.
end up a jaded curmudgeon?
Success is not guaranteed, but that can be a well-earned element that at least greatly reduces the odds of failure when they start their own company.
Success is not guaranteed, but that can be a well-earned element that at least greatly reduces the odds of failure when they start their own company.
It seems that you have insider knowledge of the workings of Intel.
>Oh, you can't because you're making 300k base + 2 years away from 800k in RSUs? Congrats. You're part of the problem (it's not your fault).
What problem? Sounds more like a solution.
What problem? Sounds more like a solution.
She seems mad by the end.
> Just imagine what companies would look like if their hiring processes filtered out this kind of charlatan instead of looking for whether they could do some dumb coding card trick in a 45 minute interview block. I think they'd look very different, and a whole bunch of people would have to find another industry to prey upon.
I would caution against hoping for a personality test that could weed out the phonies, though. "Behavioral interviews" are strange enough already, in my opinion, even if their goal might be admirable (e.g. identify the assholes).
Anywhere there is money and prestige to be had, you can either keep things small or inevitably suffer the phonies.
> Just imagine what companies would look like if their hiring processes filtered out this kind of charlatan instead of looking for whether they could do some dumb coding card trick in a 45 minute interview block. I think they'd look very different, and a whole bunch of people would have to find another industry to prey upon.
I would caution against hoping for a personality test that could weed out the phonies, though. "Behavioral interviews" are strange enough already, in my opinion, even if their goal might be admirable (e.g. identify the assholes).
Anywhere there is money and prestige to be had, you can either keep things small or inevitably suffer the phonies.
Honestly, I don't think it's that hard. I assume we're talking about fairly senior candidates here.
"Tell me about the most complicated projects you contributed a significant part of the design, implementation to, or ideally both."
Start with the problem they aimed to solve.
Probe for how they chose the solution, and what alternatives they considered.
Get into the details of specifically what artifacts they produced, and if part of a team what role they played.
Get them to describe the solution in technical detail.
Probe into trade-offs they had to make or compromises.
Ask what aspects they found novel or innovative.
Once they finish describing the system, ask if it was successful, and how they measured it.
If they were around after launch, how did they operate it, monitor it, what unexpected challenges they encountered that they didn't foresee.
By the way, all along it doesn't matter if the domain or technology they are describing to you is totally different from your own experience. A senior+ engineer should be able to explain their domain to someone equally technical in a different domain with some competency.
Finally, since you now understand the problem space and the solution yourself, ask them "How would you scale this out to 10-100X" (by some metric).
Altogether, this is a dense 40-45 minutes extremely well spent. And it weeds out the phonies and charlatans.
Some yellow flags that individually aren't a problem but when you start seeing multiple of them turn into a red flag:
* Someone who didn't question the requirements and just accepted them from upstream.
* Someone that wrote a lot of code on the project, but didn't make any of the tough decisions.
* Someone that avoids talking about what they did, and focuses too much on "we"
* Someone who did all the initial decisions but did none of the actual implementation work.
* Someone who describes how X solved the problem, but you realize that's the only option they really considered
* Someone who left before the project finished, or immediately after.
* Someone who isn't sure if the project was a success or didn't see it their responsibility to find out.
"Tell me about the most complicated projects you contributed a significant part of the design, implementation to, or ideally both."
Start with the problem they aimed to solve.
Probe for how they chose the solution, and what alternatives they considered.
Get into the details of specifically what artifacts they produced, and if part of a team what role they played.
Get them to describe the solution in technical detail.
Probe into trade-offs they had to make or compromises.
Ask what aspects they found novel or innovative.
Once they finish describing the system, ask if it was successful, and how they measured it.
If they were around after launch, how did they operate it, monitor it, what unexpected challenges they encountered that they didn't foresee.
By the way, all along it doesn't matter if the domain or technology they are describing to you is totally different from your own experience. A senior+ engineer should be able to explain their domain to someone equally technical in a different domain with some competency.
Finally, since you now understand the problem space and the solution yourself, ask them "How would you scale this out to 10-100X" (by some metric).
Altogether, this is a dense 40-45 minutes extremely well spent. And it weeds out the phonies and charlatans.
Some yellow flags that individually aren't a problem but when you start seeing multiple of them turn into a red flag:
* Someone who didn't question the requirements and just accepted them from upstream.
* Someone that wrote a lot of code on the project, but didn't make any of the tough decisions.
* Someone that avoids talking about what they did, and focuses too much on "we"
* Someone who did all the initial decisions but did none of the actual implementation work.
* Someone who describes how X solved the problem, but you realize that's the only option they really considered
* Someone who left before the project finished, or immediately after.
* Someone who isn't sure if the project was a success or didn't see it their responsibility to find out.
“Someone that avoids talking about what they did, and focuses too much on "we"”
This is very interesting. I naturally use “we” when discussing past products and achievements. I do this in recognition of the fact that things are very rarely designed and built in true isolation. Even principal engineers socialize their designs and thinking with colleagues, making small tweaks here and there or gaining additional confidence to move forward.
“We” is absolutely not a red flag for me.
This is very interesting. I naturally use “we” when discussing past products and achievements. I do this in recognition of the fact that things are very rarely designed and built in true isolation. Even principal engineers socialize their designs and thinking with colleagues, making small tweaks here and there or gaining additional confidence to move forward.
“We” is absolutely not a red flag for me.
I agree. Maybe it's a cultural thing, but if someone talked about a big multiyear project only in terms of I, I would see that as a red flag. Either they actually did all the work themselves in isolation, but that must be because they are hard to work with, or they are taking all the credit for work done by a quite a few people in a team.
If you get asked, multiple times, how exactly you yourself contributed to the project and you continue only talking about what "we" did, it is absolutely a red flag.
> "Even principal engineers socialize their designs and thinking with colleagues, making small tweaks here and there or gaining additional confidence to move forward."
Principal engineers know that there are appropriate times to say "we did..." and appropriate times to lean heavily into saying "I specifically did..." (while crediting others for their part, of course, but as briefly as possible) and they also know which one an interview is.
"We" may not be a red flag (I appreciate a measure of humility and recognition of teamwork as well) but it must always followed up by a question about the details of what the interviewee did.
Principal engineers know that there are appropriate times to say "we did..." and appropriate times to lean heavily into saying "I specifically did..." (while crediting others for their part, of course, but as briefly as possible) and they also know which one an interview is.
"We" may not be a red flag (I appreciate a measure of humility and recognition of teamwork as well) but it must always followed up by a question about the details of what the interviewee did.
It depends on the context - but each time I've interviewed someone, the "we" is important, but the "I" is important-er. It's almost implicit that everyone works in a team to achieve big goals, but the reason I'm talking to that candidate is to hear what they did as part of that team as that's what makes a difference to the hiring.
This is one of those things that's getting lost in the intention. I've been in an interview where I used we and the interviewer was fairly blunt in asksing which things I directly did, which I collaborated on, which I reviewed, etc. It becomes clear very quickly they aren't trying to figure out if you are sociable, but to understand what you do and do not know how to do. Shifting into that mindset it becomes easy to say things like "three person team. We collaborated on x,y,z. A and B were my primary responsibilties and I think my most important contributions were blah blah".
Yeah for me as well, it's just a way of recognising teamwork. If anything I would say it's the opposite, excessive "I..me..myself" can become a red flag in some cases.
Speaking as someone who hires, "I" is a huge red flag for me — it's a dead ringer for what is (in a very soft sense), a confidence man. Someone who's aggressively and artificially trying to project an external appearance of competence. I've had multiple bad hires like this, and it's now something I really watch out for.
The worst thing with guys like this isn't that they're going to deliver less than promised, but it's that the aggressive "willingness to lie for their own benefit" bleeds into a lot of other behavior at work.
The worst thing with guys like this isn't that they're going to deliver less than promised, but it's that the aggressive "willingness to lie for their own benefit" bleeds into a lot of other behavior at work.
I prefer using “we” but early on in my career was rejected at an interview because they thought I hadn’t done anything myself - now I mix in we and “I specifically implemented/designed/etc.”
Same. As a long time team lead/manager I always take the blame when things go wrong and give credit to individuals other than myself when things go right.
Someone constantly using "I" like they worked in a vacuum, and didn't play nice with their team is a bigger red flag for me.
The important piece in the interview is can they answer in detail the rest of the questions.
Someone constantly using "I" like they worked in a vacuum, and didn't play nice with their team is a bigger red flag for me.
The important piece in the interview is can they answer in detail the rest of the questions.
I should have been clear - I start my interview by asking the candidate to focus on their experience and every time they talk about what "we" did on a project I follow up with what specifically they did.
The imposters/charlatans (and weeding them out was the context for this whole thread) find a way to avoid the question.
The imposters/charlatans (and weeding them out was the context for this whole thread) find a way to avoid the question.
>"Tell me about the most complicated projects you contributed a significant part of the design, implementation to, or ideally both."
Start with the problem they aimed to solve.
Probe for how they chose the solution, and what alternatives they considered.
Get into the details of specifically what artifacts they produced, and if part of a team what role they played.
Get them to describe the solution in technical detail.
Probe into trade-offs they had to make or compromises.
Ask what aspects they found novel or innovative.
Once they finish describing the system, ask if it was successful, and how they measured it.
If they were around after launch, how did they operate it, monitor it, what unexpected challenges they encountered that they didn't foresee.
By the way, all along it doesn't matter if the domain or technology they are describing to you is totally different from your own experience. A senior+ engineer should be able to explain their domain to someone equally technical in a different domain with some competency.
This verbatim can very well apply to many different industrial engineering efforts, regardless of whether there is software involved.
>This cannot be upvoted enough.
I agree, and I mean far beyond the message board.
Start with the problem they aimed to solve.
Probe for how they chose the solution, and what alternatives they considered.
Get into the details of specifically what artifacts they produced, and if part of a team what role they played.
Get them to describe the solution in technical detail.
Probe into trade-offs they had to make or compromises.
Ask what aspects they found novel or innovative.
Once they finish describing the system, ask if it was successful, and how they measured it.
If they were around after launch, how did they operate it, monitor it, what unexpected challenges they encountered that they didn't foresee.
By the way, all along it doesn't matter if the domain or technology they are describing to you is totally different from your own experience. A senior+ engineer should be able to explain their domain to someone equally technical in a different domain with some competency.
This verbatim can very well apply to many different industrial engineering efforts, regardless of whether there is software involved.
>This cannot be upvoted enough.
I agree, and I mean far beyond the message board.
> I naturally use “we” when discussing past products and achievements
Then you will not get recognition about what you did in the eyes of others. It is hard to trust someone who hides behind a group, because it looks like you have no confidence in yourself or what you did.
Then you will not get recognition about what you did in the eyes of others. It is hard to trust someone who hides behind a group, because it looks like you have no confidence in yourself or what you did.
Recognition and trust have never been a problem for me. Have you hired at this level before, or merely assuming? As always there is nuance, as other commenters have touched on.
I have hired and been hired at this level and I have tried both approaches, one is IME far superior to the other. Any role which requires self-confidence is one where I would screen for candidates that are comfortable with claiming achievement.
What would you say to someone who's starting their career and feels they would tick most if not all of those yellow flags?
I have to say this is an awesome thing to be reading as within a couple of months I'll be taking on my first major project at my new employer. Valuable insight to consider as I proceed.
I have to say this is an awesome thing to be reading as within a couple of months I'll be taking on my first major project at my new employer. Valuable insight to consider as I proceed.
> "What would you say to someone who's starting their career and feels they would tick most if not all of those yellow flags?"
Nothing, that's expected for a junior developer. The items on the list only become a problem when a "senior" developer does them. One of the parts of transitioning from junior to senior and beyond is learning to understand the business (or other) context you perform your craft in and shaping what you do to help the business succeed.
[EDIT] When I say "help the business succeed", that may sound like management claptrap (even if it happens to be true) so I'll also point out that even if you don't give a flying hoot about the business or its goals, you still do care about understanding whether it's succeeding and profitable/effective at its goals, lest you get blindsided by a layoff or cancellation of your project.
Nothing, that's expected for a junior developer. The items on the list only become a problem when a "senior" developer does them. One of the parts of transitioning from junior to senior and beyond is learning to understand the business (or other) context you perform your craft in and shaping what you do to help the business succeed.
[EDIT] When I say "help the business succeed", that may sound like management claptrap (even if it happens to be true) so I'll also point out that even if you don't give a flying hoot about the business or its goals, you still do care about understanding whether it's succeeding and profitable/effective at its goals, lest you get blindsided by a layoff or cancellation of your project.
Thank you for your advice. I've taken it seriously.
Cheers.
Cheers.
None of those are yellow flags if you are starting out in your career, in fact it would be totally expected!
It's only a yellow flag for a senior engineer - which in the framing of the original posting was being discussed. Someone with 7-10 years of experience, I'm imagining.
It's only a yellow flag for a senior engineer - which in the framing of the original posting was being discussed. Someone with 7-10 years of experience, I'm imagining.
As someone who just went through a dozen interviews, this line of questioning is by far my most favorite one to receive.
* Someone who left before the project finished, or immediately after.
In my experience, people leave just after the big project ships. They've been focused on a task, working hard and are usually left with "now what?". It's interesting psychology.
In my experience, people leave just after the big project ships. They've been focused on a task, working hard and are usually left with "now what?". It's interesting psychology.
In science these types of questions are part of the interview (either implicit or explicit), with maybe more added emphasis on future work and vision depending on the rank of the scientist.
This cannot be upvoted enough.
It seems like a leap from "person who wants to build X" to "charlatan".
We're not talking about some ordinary rank-and-file engineer here. The situation Rachel is talking about where the person is usually well-known among a significant fraction of their industry for their expertise in X. That level of seniority (principal level or beyond) is supposed to imply that they also know when -not- to use X and the responsibility to speak up, but sometimes either their belief in X is too strong ("When all you have is a hammer, everything looks like a nail.") or, in some cases I suspect, the monetary and career-enhancing incentives are high enough to overcome any unease they may have misapplying X. Then you get this situation where a mandate comes down for X is used where X is not really the appropriate thing to do.
> The situation Rachel is talking about where the person is well-known among a significant fraction of their industry for their expertise in X.
I don't know the specifics of Rachel's parable, if any. But by and large, the people who are most well known in industry for 'expertise in X' are the devrel / tech evangelists whose job it is to go on stage and be an expert, for one hour at a time (and perhaps a few extra hours on the show floor surrounding the conference). Well, the on-stage demos they execute only have to live as long as the lecture, and you don't have to fix bugs so much as rework the preso to avoid them. It's a long march from a proof of concept to production readiness, and I've seen one or two stories on HN about people who got burned hiring high profile devrels to lead an infra buildout.
> sometimes either their belief in X is too strong ... or, ... the monetary and career-enhancing incentives are high enough to overcome any unease they may have
One scenario I've seen play out: you hire a core maintainer for a product you depend on, but should probably be transitioning away from. The maintainer you typically don't have comparable expertise in anything else, so they might as well apply for unemployment before telling your boss you recommend against it. Which I suppose is covered in 'monetary incentives' but with tinge of regret about the whole thing, especially if hired away from some a more stable role.
I don't know the specifics of Rachel's parable, if any. But by and large, the people who are most well known in industry for 'expertise in X' are the devrel / tech evangelists whose job it is to go on stage and be an expert, for one hour at a time (and perhaps a few extra hours on the show floor surrounding the conference). Well, the on-stage demos they execute only have to live as long as the lecture, and you don't have to fix bugs so much as rework the preso to avoid them. It's a long march from a proof of concept to production readiness, and I've seen one or two stories on HN about people who got burned hiring high profile devrels to lead an infra buildout.
> sometimes either their belief in X is too strong ... or, ... the monetary and career-enhancing incentives are high enough to overcome any unease they may have
One scenario I've seen play out: you hire a core maintainer for a product you depend on, but should probably be transitioning away from. The maintainer you typically don't have comparable expertise in anything else, so they might as well apply for unemployment before telling your boss you recommend against it. Which I suppose is covered in 'monetary incentives' but with tinge of regret about the whole thing, especially if hired away from some a more stable role.
You also have those whose consulting career is fully based on being 'experts in X', being on stage doing talks on X, is the mean to sell themselves as 'experts in X', alongside writting books about how cool X happens to be no matter what.
> But by and large, the people who are most well known in industry for 'expertise in X' are the devrel / tech evangelists whose job it is to go on stage and be an expert, for one hour at a time (and perhaps a few extra hours on the show floor surrounding the conference).
When I think of "experts in X" I usually think of the people who created or maintain the thing, or who're active in the Github issues. I guess some of those people might be considered tech evangelists, but I don't think I could name a single devrel person.
When I think of "experts in X" I usually think of the people who created or maintain the thing, or who're active in the Github issues. I guess some of those people might be considered tech evangelists, but I don't think I could name a single devrel person.
One probably spent too much time debugging someone's shit mountain code base, the original author got to enjoy bog bonuses and bragging about X in conferences and getting hired by similar companies to build another X.
It doesn't have to be a malicious charlatan to pounce on value that has already been built, without them having actual consideration for future value that should be more rewarding and more sensibly worth working toward instead.
The corporate-climber-who-can't-build can often do this and nothing else, and they can sometimes even subconsciously exhibit some of the behaviors that end up with the same outcome, and it often can actually be unintentional.
The corporate-climber-who-can't-build can often do this and nothing else, and they can sometimes even subconsciously exhibit some of the behaviors that end up with the same outcome, and it often can actually be unintentional.
> I will now point out that whether X makes it to production can become disconnected from the notion of whether X actually belongs in production. In one outcome, it's brilliantly executed and things grow. But, this is about the downsides, and in that scenario, it's a stinking pile of garbage and needs to be thrown out, but it gets forced in, anyway. [emphasis added]
She's left the positive case out for the charlatan comment, they wouldn't be charlatans (in this instance at least).
She's left the positive case out for the charlatan comment, they wouldn't be charlatans (in this instance at least).
The guy building X isn't a charlatan in any case. The charlatan is the guy selling X, which is presumably the guy who hired the guy who builds it.
If you tell me to build you a system you don't need, and I do, and you insist on using it against everyone else's better judgment, how did I become a charlatan?
If you tell me to build you a system you don't need, and I do, and you insist on using it against everyone else's better judgment, how did I become a charlatan?
Because if you're the expert on X, you can either stand up and agree with everyone that building X is not the right decision, or you can smile and nod and say yea, we should totally build our own X, it's a great idea. If you say no, it won't happen.
On one side I would say that this the most authentic course of action.
But that doesn't suddenly shift all the responsibility to the expert. The power relation and degree of freedom between those who hire and those who get hired is often asymmetric. The ones who hire usually are the ones who make the decisions, so they should be held accountable for those.
Now of course if the expert does have a sufficient degree of freedom then they become complicit.
But that doesn't suddenly shift all the responsibility to the expert. The power relation and degree of freedom between those who hire and those who get hired is often asymmetric. The ones who hire usually are the ones who make the decisions, so they should be held accountable for those.
Now of course if the expert does have a sufficient degree of freedom then they become complicit.
and they loose the job they were just hired for.
because the more likely situation is that the newly hired expert on X is the only one realizing that X is wrong for this case.
because the more likely situation is that the newly hired expert on X is the only one realizing that X is wrong for this case.
If you know you were being hired for one specific task shouldn’t you have talked about the fit before you start? I would say that is reasonable.
It's not always reasonable, because in the general case you don't know until later right? You discover the issues at some point when already working. Also you're implying that there is no economic dependence which is not always the case.
The ones who lie to keep their job are the ones who get called 'charlatan'. Seems fair.
except they are most likely only being asked if they can build X (which they can) and not if X is appropriate here. so at the most they are lying by omission, but more realistically they are opting not to become a whistleblower.
> She seems mad by the end.
You'll see this sort of things a lot from Rachel's writing, but I tend to write it off as a stylistic choice. She kind of channels the BOFH [0] sometimes, I think :)
[0] https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell
You'll see this sort of things a lot from Rachel's writing, but I tend to write it off as a stylistic choice. She kind of channels the BOFH [0] sometimes, I think :)
[0] https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell
Filtering out the assholes is an accepted policy today but it didn’t just happen. Assholes were accepted and that sort of attitude wasn’t discouraged, until people started speaking up about it and others realized they probably had seen that dynamic. I see this article as a step in extending the anti-asshole policy to people who engage in this sort of behavior.
Can I tell you a perfect personality test that will always work and never fail? Absolutely not. Even the anti asshole processes don’t always work. But it seems a good thing that this sort of behavior is at least being described and reported on.
Can I tell you a perfect personality test that will always work and never fail? Absolutely not. Even the anti asshole processes don’t always work. But it seems a good thing that this sort of behavior is at least being described and reported on.
Every company that I’ve been in that had an anti asshole policy has meant that they don’t tolerate assholes at the line engineer level, since that’s reserved for management, especially director and up.
I guess it’s better, but the proof is in what the management team looks like.
I guess it’s better, but the proof is in what the management team looks like.
I love the call out at the end. I believe much of the post is a slight at Google (and much of big tech), where building complicated crap is one of the fastest ways of promotion. Rachel is completely right, "big tech" has a problem of attracting politician types, who are focused on abusing systems for their own gain. You can hardly blame them though, the company as a whole is doing the same thing.
The incentives are misaligned at pretty much every level.
The incentives are misaligned at pretty much every level.
> "big tech" has a problem of attracting politician types, who are focused on abusing systems for their own gain
Not just attracts, but selects for them as well. The interviews are set up to select people who are morally ok with doing arbitrary and pointless work (months of leetcoding at home) in order to game the system.
Not just attracts, but selects for them as well. The interviews are set up to select people who are morally ok with doing arbitrary and pointless work (months of leetcoding at home) in order to game the system.
It really is an incentive issue. People are given large amounts of money and promotions and raises are always lurking around. Performance review really incite you to promote your own work and play nice with people instead of acting like a team. It’s quite remarkable I find that companies like that still manage to be productive, but it seems to be working.
> It’s quite remarkable I find that companies like that still manage to be productive, but it seems to be working.
They work because they have a quasi-monopoly on something, not because of efficient use of employees time.
They work because they have a quasi-monopoly on something, not because of efficient use of employees time.
Just look at the recent UI mess at Microsoft, or ChromeOS vs Android vs PWA vs Flutter at Google, for actual examples of it.
Given when she was with the company, the X in the room is Google+.
Google+ actually seemed kind of good to me? Like maybe the problem with Google+ was that not that it existed but that they didn't invest enough in it.
> they didn't invest enough in it.
No, it was a good social network on paper, and they threw the whole company behind it. The issue was that it was meant to be a drop-in replacement for existing social networks. Except it didn't really solve any new customer issues, just solved the google issue of google not having a social space.
No, it was a good social network on paper, and they threw the whole company behind it. The issue was that it was meant to be a drop-in replacement for existing social networks. Except it didn't really solve any new customer issues, just solved the google issue of google not having a social space.
I'd argue that they invested way too much into Google+ actually. They tried forcing it on everyone, almost killing the YouTube community in the process, and people started fighting back.
Facebook didn't gain its users overnight and without a good amount of manipulation and tricks on their part, but they were smart enough to not make it feel as aggressive or directed as Google did with Google+
Facebook didn't gain its users overnight and without a good amount of manipulation and tricks on their part, but they were smart enough to not make it feel as aggressive or directed as Google did with Google+
G+ had a Real Name Policy, apparently for no reason other than copying Facebook. And then because every Google product had to have G+, Google effectively banned anonymity/pseudonymity everywhere. It was so dumb and heavy-handed. For me that was the end of using Google products.
G+ had a real names policy because Google's other social network, Orkut, did not, and Google had observed that the average Orkut use had chosen an anonymizing handle. They wanted to do something different with Google+, because the handles in Orkut made it very hard to find people you already knew in real life.
Personal opinion, they went about it entirely the wrong way. Facebook does technically have a real name policy, but they got the ecosystem of people using their real name that they have not by strenuously enforcing that policy, but by incentivizing people through the design of the product to use their real name. If memory serves, I got my Facebook account via a link that had been auto-emailed to my college email address, and that link pre-filled in my real name in the account setup process.
Personal opinion, they went about it entirely the wrong way. Facebook does technically have a real name policy, but they got the ecosystem of people using their real name that they have not by strenuously enforcing that policy, but by incentivizing people through the design of the product to use their real name. If memory serves, I got my Facebook account via a link that had been auto-emailed to my college email address, and that link pre-filled in my real name in the account setup process.
[deleted]
I will say that avoiding "builder culture" probably saved my job. I joined a company that had migrated from an open source identity management solution to a homegrown one and it had ran perfectly well in production for many years but was getting creaky and didn't offer the features that were needed for a SaaS offering. VPs gave me the option of determining whether we migrated to an identity vendor or built our own. I've contributed code to popular OIDC implementations on GitHub, I've written code in widely used open source JWT libraries and I felt extremely comfortable working in that space so my inclination was towards building.
The problem was to staff a quality engineering team was going to cost 5x the yearly price of the most expensive service and hiring other people in that space was proving to be very difficult and we didn't have time to take a year to build it and then start migration
In the end I chose to go with a vendor and a smaller team to support a migration. We migrated in less than 6 months and a year later we ended up getting contacted by law enforcement about some activity that was happening our system. The auditing system on the vendors side allowed us to quickly diagnose what exactly had happened and let us give data to folks who needed it.
Had that been our homegrown system, it would've been 100% an unmitigated disaster that took days to unravel. Had we decided to build it ourselves, there's no way we could've hit production as quickly as we did.
The problem was to staff a quality engineering team was going to cost 5x the yearly price of the most expensive service and hiring other people in that space was proving to be very difficult and we didn't have time to take a year to build it and then start migration
In the end I chose to go with a vendor and a smaller team to support a migration. We migrated in less than 6 months and a year later we ended up getting contacted by law enforcement about some activity that was happening our system. The auditing system on the vendors side allowed us to quickly diagnose what exactly had happened and let us give data to folks who needed it.
Had that been our homegrown system, it would've been 100% an unmitigated disaster that took days to unravel. Had we decided to build it ourselves, there's no way we could've hit production as quickly as we did.
One unwritten trade off that's in addition, not a knock on your stance just an observation, is that teams that build one quality product can often build another. To some extent when you choose to build you are also choosing to build a culture that knows how to build. So you have to think about not just the next thing you need, but the five things after that. I've worked at companies that bought literally everything, and what I found is the engineers there knew a lot about how to plugin to these various systems, but when they needed to build something complex together they weren't able to do so very well, or at all. Which might be fine, but you should head in that direction with intention.
It really depends on how well the offering matches the need. My personal experience is that outsourcing core bits where vendors don't match exactly the needs ends up causing more overhead that if we had written the service ourselves.
I don’t know. I’ve been in the position of being an “X-builder” (I’m a dyed-in-the-wool compiler engineer), and I’ve been through something like what she describes, and nothing about the decisions involved seemed as obvious (or as malicious/egotistical) as she makes it sound.
Like, maybe I don’t quite want to build an X, but other engineers and managers have their own reasons why we should, and after we discuss/argue for a little while, I decide that, OK, fine, I don’t entirely agree but I’m willing to concede that maybe I’m wrong and give it a shot.
The thing we end up building is OK, but not stellar. We have an outage or two but they’re minor and not an ongoing headache. We have a few wins but it’s not the runaway success we hoped. Maybe we should have gone with Y instead of building our own X? Would it have been better that way? Am I a charlatan? I don’t know.
Like, maybe I don’t quite want to build an X, but other engineers and managers have their own reasons why we should, and after we discuss/argue for a little while, I decide that, OK, fine, I don’t entirely agree but I’m willing to concede that maybe I’m wrong and give it a shot.
The thing we end up building is OK, but not stellar. We have an outage or two but they’re minor and not an ongoing headache. We have a few wins but it’s not the runaway success we hoped. Maybe we should have gone with Y instead of building our own X? Would it have been better that way? Am I a charlatan? I don’t know.
These two remarks don't line up...
They're a builder, all right, as long as you want them to build X. Perhaps they have been building X at some other company, and now your company has hired them to come and do that same job over here instead.
Just imagine what companies would look like if their hiring processes filtered out this kind of charlatan
The company specifically filtered them in to build the X product they're renowned for building at other companies. The hiring process is working perfectly if the company decides they want X, hires a famous X builder, and that person then builds X in their role.
I think the point Rachel is alluding to is that the person should have realised X is inappropriate and said so, but if your world is X then it can be hard to see the broader picture. We've all tried to leverage the tools we know best to do jobs they're not perfect for rather than start from zero with something more appropriate, especially when there's a looming deadline or a lot of pressure from higher ups. To call someone a charlatan for doing that seems grossly unfair.
They're a builder, all right, as long as you want them to build X. Perhaps they have been building X at some other company, and now your company has hired them to come and do that same job over here instead.
Just imagine what companies would look like if their hiring processes filtered out this kind of charlatan
The company specifically filtered them in to build the X product they're renowned for building at other companies. The hiring process is working perfectly if the company decides they want X, hires a famous X builder, and that person then builds X in their role.
I think the point Rachel is alluding to is that the person should have realised X is inappropriate and said so, but if your world is X then it can be hard to see the broader picture. We've all tried to leverage the tools we know best to do jobs they're not perfect for rather than start from zero with something more appropriate, especially when there's a looming deadline or a lot of pressure from higher ups. To call someone a charlatan for doing that seems grossly unfair.
I think she is not specifically talking about the exact same person here. She specifies people putting themselves over the success of the team later in the text, right in front of the charlatan statement.
The x builder can have this affect, on the one end of the spectrum what you describes happens, on the other end of the spectrum charlatanerie happens.
The x builder can have this affect, on the one end of the spectrum what you describes happens, on the other end of the spectrum charlatanerie happens.
An engineer is expected to speak up when told to construct X out of Y when Y is not good enough for it. He is personally responsible for the lives at stake. A software engineer is not expected to speak up when told to build X out of Y but to push through no matter what.
> the person should have realised X is inappropriate and said so, but if your world is X then it can be hard to see the broader picture.
Also, for political reasons, nobody else can or will question it, so there's no safety mechanism.
Also, for political reasons, nobody else can or will question it, so there's no safety mechanism.
>I've told some stories about what happens when you end up at a company that builds nothing and instead rents everything from some vendor.
This sounded interesting but I searched for her blog and I couldn't find it. Does anyone know which post this refers to?
This sounded interesting but I searched for her blog and I couldn't find it. Does anyone know which post this refers to?
Here are a couple for sure:
- https://rachelbythebay.com/w/2020/02/08/miss/
- https://rachelbythebay.com/w/2019/10/13/firewall/
- https://rachelbythebay.com/w/2020/08/17/potato/
- https://rachelbythebay.com/w/2019/11/10/scale/Thanks!
Not sure but possibly one of her books? https://rachelbythebay.com/store/
Wait, there is some disconnect here, the last paragraph does not follow at all.
To see it more easily, here is her post but with some specific, made up example instead of "X":
A chocolate factory wants to build a new dark chocolate line. They hire a very experienced industrial engineer, who just recently finished building car engine line for the Ford factory. However, once the new engineer started to work on chocolate line, they found it extremely boring and devoid of challenges. So they somehow convinced management that the chocolate factory needs to start producing car engines for their delivery trucks. This is obviously a bad idea, and many people point that, but the engineer has secured support of one of VPs, so the project goes ahead. Eventually the line is ready, new engines are produced and installed in all the new trucks. They proceed to break down frequently, the deliveries are late, customers are unhappy, and everyone is having a bad time.
Everyone is blaming engineer now and calling them "charlatan", but the engineer does not understand why: They really worked their ass off building the new engine line, working 80 hours a week to realize their dream. It was not easy -- the factory was only doing chocolate before, so switching to heavy machinery was quite a challenge! And the reason customers are unhappy is because of the management -- this project should have gotten way more resources! Then we could test more and iron out all the bugs instead of having to go to production too early.
Rachel's final paragraph puts the blame squarely on the engineer, with wishes that "hiring processes filtered out this kind of charlatan" and "whole bunch of people would have to find another industry to prey upon", but that engineer is not a charlatan -- they have a legitimate technical talent, and they used it to build real stuff. No hiring process can filter them out -- they will pass a technical interview and take-home test, they have great communication skills, they have a github page with open source code, and they can talk passionately about their past successful projects.
Instead, I'd put most of the blame on the management. In a large company, it is inevitable that someone will work on stuff that is useless or could harm the main product. Maybe because engineers lack perspective, or they overestimate themselves, or they just don't care about company's goals and want to do what they find fun. The company should have some mechanisms to prevent this -- maybe management should listen to feedback from engineers, or there should be technical committee, or at least people should not be rewarded when they ship a broken product. If the company has no such mechanisms, it will have problems as described in the blog.
To see it more easily, here is her post but with some specific, made up example instead of "X":
A chocolate factory wants to build a new dark chocolate line. They hire a very experienced industrial engineer, who just recently finished building car engine line for the Ford factory. However, once the new engineer started to work on chocolate line, they found it extremely boring and devoid of challenges. So they somehow convinced management that the chocolate factory needs to start producing car engines for their delivery trucks. This is obviously a bad idea, and many people point that, but the engineer has secured support of one of VPs, so the project goes ahead. Eventually the line is ready, new engines are produced and installed in all the new trucks. They proceed to break down frequently, the deliveries are late, customers are unhappy, and everyone is having a bad time.
Everyone is blaming engineer now and calling them "charlatan", but the engineer does not understand why: They really worked their ass off building the new engine line, working 80 hours a week to realize their dream. It was not easy -- the factory was only doing chocolate before, so switching to heavy machinery was quite a challenge! And the reason customers are unhappy is because of the management -- this project should have gotten way more resources! Then we could test more and iron out all the bugs instead of having to go to production too early.
Rachel's final paragraph puts the blame squarely on the engineer, with wishes that "hiring processes filtered out this kind of charlatan" and "whole bunch of people would have to find another industry to prey upon", but that engineer is not a charlatan -- they have a legitimate technical talent, and they used it to build real stuff. No hiring process can filter them out -- they will pass a technical interview and take-home test, they have great communication skills, they have a github page with open source code, and they can talk passionately about their past successful projects.
Instead, I'd put most of the blame on the management. In a large company, it is inevitable that someone will work on stuff that is useless or could harm the main product. Maybe because engineers lack perspective, or they overestimate themselves, or they just don't care about company's goals and want to do what they find fun. The company should have some mechanisms to prevent this -- maybe management should listen to feedback from engineers, or there should be technical committee, or at least people should not be rewarded when they ship a broken product. If the company has no such mechanisms, it will have problems as described in the blog.
That's a very reductive and limiting view of what an engineer does. Someone that accepts requirements, and outputs artifacts.
A senior/staff/principal engineer should be aware of the customer needs they are working to solve, and focused on the problem. Their engineering skills are a tool to fixing it, not itself the result.
In your example, * The industrial engineer should have asked "Do you need me to build car engine machinery?" And if they said no, pursued a different job.
* Once on the job, if management said "let's start building car engines", he should have said "Why, how does this help our customers?"
Actually, in your example: > However, once the new engineer started to work on chocolate line, they found it extremely boring and devoid of challenges. So they somehow convinced management that the chocolate factory needs to start producing car engines for their delivery trucks.
That's borderline unethical. If you're bored and devoid of challenges. Change your job, don't ruin your company.
You place the blame on managers and say "maybe management should listen to feedback from engineers", but that's exactly what happened in your scenario, and was the root cause of the problem! The manager listened to a poorly motivated, mis-incentivized, yet strangely persuasive engineer.
The problem was that neither the managers nor the engineer actually thought about the customers, or listened to them. Incidentally, maybe they would have found out that the customers actually really like the chocolate but it always get delivered too late warm and melted, and so actually investing in building bespoke engines for their trucks would have been correct in that situation. But it has to start from the customer, not the prior skills of the engineer.
Fix the process, and maybe neither the managers nor the engineer need to be fired.
A senior/staff/principal engineer should be aware of the customer needs they are working to solve, and focused on the problem. Their engineering skills are a tool to fixing it, not itself the result.
In your example, * The industrial engineer should have asked "Do you need me to build car engine machinery?" And if they said no, pursued a different job.
* Once on the job, if management said "let's start building car engines", he should have said "Why, how does this help our customers?"
Actually, in your example: > However, once the new engineer started to work on chocolate line, they found it extremely boring and devoid of challenges. So they somehow convinced management that the chocolate factory needs to start producing car engines for their delivery trucks.
That's borderline unethical. If you're bored and devoid of challenges. Change your job, don't ruin your company.
You place the blame on managers and say "maybe management should listen to feedback from engineers", but that's exactly what happened in your scenario, and was the root cause of the problem! The manager listened to a poorly motivated, mis-incentivized, yet strangely persuasive engineer.
The problem was that neither the managers nor the engineer actually thought about the customers, or listened to them. Incidentally, maybe they would have found out that the customers actually really like the chocolate but it always get delivered too late warm and melted, and so actually investing in building bespoke engines for their trucks would have been correct in that situation. But it has to start from the customer, not the prior skills of the engineer.
Fix the process, and maybe neither the managers nor the engineer need to be fired.
I've worked with several Java evangelists in my career ... two stand out.
One had written several books on Java and was tapped to head up a new initiative. They "noped" out very quickly, "this isn't a project suitable for java" and recommended a couple of different architectures and platforms and went back to their less prestigious role.
The other was very active in the Java community and shoe horned Java into a very inappropriate product, costing the client $$$ and never reaching the MVP stage.
You could blame management for both of those situations; but one of those companies went on to a modicum of success in an acquisition because the engineer decided NOT to turn the chocolate factory into a car factory.
One had written several books on Java and was tapped to head up a new initiative. They "noped" out very quickly, "this isn't a project suitable for java" and recommended a couple of different architectures and platforms and went back to their less prestigious role.
The other was very active in the Java community and shoe horned Java into a very inappropriate product, costing the client $$$ and never reaching the MVP stage.
You could blame management for both of those situations; but one of those companies went on to a modicum of success in an acquisition because the engineer decided NOT to turn the chocolate factory into a car factory.
But what stands out in that happy story is engineering integrity of the highest calibre. The behaviour of an engineer who (correctly) bows out for reasons of technical principle is the peak of engineering as a discipline and goes a bit beyond mere competence.
That sort of exemplary behaviour can save bad management, but doesn't excuse it.
That sort of exemplary behaviour can save bad management, but doesn't excuse it.
I’m NOT excusing bad management, I’ve been burned too many times for that. What I’m doing is NOT excusing bad engineering and blaming it strictly on bad management.
People should check out Wardley mapping. It's a good tool to have conversations in a company/group about what you are doing that is commodity and what is custom and crucially if this is a good idea or not.
( Of course, management have to be open to these conversations and this alone won't save you from the terrible politics Rachel describes. )
( Of course, management have to be open to these conversations and this alone won't save you from the terrible politics Rachel describes. )
I'm in such a situation right now. We got this new person that is known for having built a great a/b testing solution that scaled at a large top-tier company so they seemed like a great hire. Problem is we already have an ab test solution that is integrated into everything. Maybe it's not the best solution ever but it does everything we need, nobody has been complaining about it. But since we got this hire we're now having to do a large rewrite that's not really buying us anything and nobody can really question it because people are invested in that we got this great hire.
I would argue that this person is not a great hire for you then.
If they cannot contribute to something you actually need, how could them bring awesome at something else help?
Imagine a different situation - there's a fellow engineer who's also an olympic gold medalist in some sport. They may be awesome to have around. They may have cool stories. They may have connections. But unless they can harness that towards sometging that helps your mission - it really won't make them any better as an engineer.
Imagine a different situation - there's a fellow engineer who's also an olympic gold medalist in some sport. They may be awesome to have around. They may have cool stories. They may have connections. But unless they can harness that towards sometging that helps your mission - it really won't make them any better as an engineer.
I have been there, I have been part of teams that were created to do X, when it wasn't really required, just some architects thought so.
So when everything is in place, from management point of view it is easier to charge ahead than acknowledge it was a bad decision.
In the end when everything falls appart, they will either no longer be there, or find other reasons why it failed.
So when everything is in place, from management point of view it is easier to charge ahead than acknowledge it was a bad decision.
In the end when everything falls appart, they will either no longer be there, or find other reasons why it failed.
Probably Charlatan here, AMA
Our $company lacked of automation of some process and after months of wasting hours doing it manually I decided to automate that.
I had no exp with real ci/cd tools and thought our process was already crazy enough (using annoying source control tool, heavy dependency between compilation and external soft's specific versions) that we need to build our tool to manage it.
I built MVP as CLI and it worked. As time passed everybody wanted to add tons of stuff to it - like Web GUI, history, logs, managing software versions when creating binaries and even performing code analysis (because we were heavily dependent on 3rd software we needed to detect some colissions)
Overall, it saved us from doing hundreds manual, sometimes error-prone tasks per year. It allowed us to add customizations like that code analysis using compiler's API
But the other hand maybe we could just use some Jenkins or some shit and achieve similar stuff without having to invest time into it and maintain - it's combo of Visual Studio + MS Build + Team Foundation Version Control + .NET Framework, so stuff tends to make problems from time to time
I feel that despite all good things that this project brought, then we could just use existing tool and maybe achieve similar results, but I don't know for sure.
I feel like sometimes I used this project to escape boring CRUDing and used it as a learning opportunity - maybe I abused it too much?
Or maybe should I treat it as "Google's 20%"?
Our $company lacked of automation of some process and after months of wasting hours doing it manually I decided to automate that.
I had no exp with real ci/cd tools and thought our process was already crazy enough (using annoying source control tool, heavy dependency between compilation and external soft's specific versions) that we need to build our tool to manage it.
I built MVP as CLI and it worked. As time passed everybody wanted to add tons of stuff to it - like Web GUI, history, logs, managing software versions when creating binaries and even performing code analysis (because we were heavily dependent on 3rd software we needed to detect some colissions)
Overall, it saved us from doing hundreds manual, sometimes error-prone tasks per year. It allowed us to add customizations like that code analysis using compiler's API
But the other hand maybe we could just use some Jenkins or some shit and achieve similar stuff without having to invest time into it and maintain - it's combo of Visual Studio + MS Build + Team Foundation Version Control + .NET Framework, so stuff tends to make problems from time to time
I feel that despite all good things that this project brought, then we could just use existing tool and maybe achieve similar results, but I don't know for sure.
I feel like sometimes I used this project to escape boring CRUDing and used it as a learning opportunity - maybe I abused it too much?
Or maybe should I treat it as "Google's 20%"?
This is a completely different scenario and, also, a not so subtle humble brag.
You're duct taping process onto an existing product cycle.
I've experienced the 'X' factor the author is talking about and it's something like "we're moving everything to Linux because that's what I do" and then you go 18 months without a release and the release you do make is a bugfix release to the old infrastructure, your customers leave and you get bought for debt.
You're duct taping process onto an existing product cycle.
I've experienced the 'X' factor the author is talking about and it's something like "we're moving everything to Linux because that's what I do" and then you go 18 months without a release and the release you do make is a bugfix release to the old infrastructure, your customers leave and you get bought for debt.
>a not so subtle humble brag.
I'm not sure how could I rewrite it to avoid that feel, yet still include enough details to let people kinda evaluate whether it was reasonable or not
I'm not sure how could I rewrite it to avoid that feel, yet still include enough details to let people kinda evaluate whether it was reasonable or not
Maybe what you did WAS reasonable ...there is process automation where there was none before. Or did the project/company fail because you can't ship anymore?
IMHO: This is natural growth without mentorship. You build solutions beyond your level and where other people are not, and then question whether they were the right thing to do. With experience you start to learn when to build, when to buy, when to delegate, etc. Its all part of growing into a responsible leader. Answers are not always clear but my "Gonna guess cause your asking" view is that you aren't working with seasoned engineering leaders who can help guide you. Which is very common IME. Good for you for questioning and thinking about how to evaluate the decisions you made which impact others. If you find experienced leaders to guide you, you may grow faster and with less anxiety. But if you do not, continuing to find ways to improve your decision making and think about how it impacts others will set your course for growth.
Some people don't really care about all that and just build whatever keeps them interested and then move on and that's the end of their thought process. You don't seem like that, so I would guess you are not a Charlatan, whatever the correctness of your prior decision(s).
Some people don't really care about all that and just build whatever keeps them interested and then move on and that's the end of their thought process. You don't seem like that, so I would guess you are not a Charlatan, whatever the correctness of your prior decision(s).
Where the hilarity really ensues is when X gets reflected in the hiring process. If you're working in a sufficiently small industry you can sometimes tell if the builder has paid a visit without checking their LinkedIn. How would you integrate NIH X into architecture Y? Sometimes you can even tell which iteration of X the company ended up with.
"Fucker's settin' up franchises!"
"Fucker's settin' up franchises!"
I work at one such company. The amount of resources thrown into X is disturbing, and any attempts to discuss benchmarking changes so that the useleness of X can be revealed are shut down aggresively.
For those who are confused about this post it is clearly a long form sub-tweet. It is directed at a specific organisation and person but anonymised.
But..... it is totally generalisable. I have seen this happen myself. Rank-and-file team rail loaded into using Senior Person's X because Senior Person has made X rather than it being the best fir for the job.
But..... it is totally generalisable. I have seen this happen myself. Rank-and-file team rail loaded into using Senior Person's X because Senior Person has made X rather than it being the best fir for the job.
> "This is just one of the ways an unprincipled "builder culture" can backfire, particularly if you have people running the show who have no problem putting their own gains ahead of the company. They'll push all kinds of garbage if it makes them hit their goals and get a bigger bonus, a promotion, or some kind of shiny new position."
In lots of places I have worked there is a particular term that is often used to precisely describe this situation, it is called POA aka "Promotion Oriented Architecture". In POA, you deliberately add a lot of accidental complexity to come up with a fiendishly complicated solution to a relatively simple problem. In short, the complexity stems from the solution space rather than the problem space.
In lots of places I have worked there is a particular term that is often used to precisely describe this situation, it is called POA aka "Promotion Oriented Architecture". In POA, you deliberately add a lot of accidental complexity to come up with a fiendishly complicated solution to a relatively simple problem. In short, the complexity stems from the solution space rather than the problem space.
[deleted]
This is quite normal in big companies and it doesn’t just apply to building stuff, buying stuff has the same problem. Managers will propose a certain product vendor and after roll out will continue to support it, no matter the consequences. We had to use a terrible “data virtualizzation” tool for 2 years because IT “leaders” had bought into it and now would not admit their mistake.
Unfortunately this is somewhat ingrained in the sales cycle. I finally understood it at a prior company when they bought Saleforce. By the time they realized SF wasn't going to be a good fit, they were 50k in and had already signed a multi year contract. Charge obscene amounts, and offer steep discounts the earlier and longer the company is willing to contract for. It becomes a sunk cost and bonus points if the company starts developing competencies in it (negating that many people are sufficiently detached that they don't even realize its a bad fit). Its a relatively advanced skill knowing how to navigate such a scenario at the various stages.
In my limited experience, this is rarely so simple as to being able to push back on a technical decision when the reality will feel like pushing a square through a circle peg. I mean, as rightfully pointed out, if the reasons are more political than technical, pushing back can have nefarious consequences for the people involved.
Doing our jobs as engineers is about raising the alarms when needed, but, if all you get is resistance back... Assuming it's not your product, not your company and your ties to the thing are mostly technical... Then if advocate for the "not your problem" attitude and you can simply be content to let it crash and burn and show up the next day with a mop to fix it.
Dealing with incompetent management is never nice or easy, but I'd advocate that as software developers, we're quite privileged because we get paid pretty well, work is versioned in source control and most messes are physically unseen, and cleaning up is "usually" not a big deal.
Dealing with incompetent management is never nice or easy, but I'd advocate that as software developers, we're quite privileged because we get paid pretty well, work is versioned in source control and most messes are physically unseen, and cleaning up is "usually" not a big deal.
[deleted]
Regarding builders who jump between solutions to build X, I don't think the issue is ONLY the hiring process.
It’s often just a symptom of cargo culting at a managerial or even Board level. Google does X so we need to do X.
Can you tell where I can find the Xs Google does? My boss wants to know. :)
I wanted to smack someone at work for doing this (being facetious). It was truly demoralizing to watch that person go through with it too. I think I even heard one of them verbally utter ‘that’s not how real big boys do it, that’s not how the pros do it’. They said words like that out loud, absolutely shameless.
This hilarious part about it was, they never actually worked at a big company.
This hilarious part about it was, they never actually worked at a big company.
Yeah I think the same. A boat leaking from top.
This seems oddly specific ha ha
... is the crux of her point.
So, um, who decides what belongs in production?
I generally like her essays but this has a weird senseless negative tone to it.
Look... I get it. We've all come across bozos. A lot of these bozos aren't the derpy clowns we (hope? wish?) they would be. No - they're usually very confident, very aggressive, and very very goal oriented. Yes it's absolutely infuriating watching them somehow gain the confidence of the C-level folks, obtain a lot of resources, and burn everything to the ground all while claiming plausible deniability. Wishing that they'd get filtered out by the hiring process is <insert idiom of improbability>.
The real culprit is your director of engineering. That person is making terrible decisions but is so good at avoiding accountability that you place your blame on the bozo. Hot take: if your company keeps hiring bozos then your executives are doo-doo. Leave the company. Oh, you can't because you're making 300k base + 2 years away from 800k in RSUs? Congrats. You're part of the problem (it's not your fault).
The same reason why you won't leave your company is the same reason Mr. Bozo gets a crack at "innovating" at that same company.
People like Rachael (who obviously love this work at their very core) are doomed to end up a jaded curmudgeon unless they 1) start their own company 2) join a tiny company. Big tech is hell. Make your money and GTFO.