[HN Gopher] How a startup loses its spark
___________________________________________________________________
How a startup loses its spark
Author : imadj
Score : 397 points
Date : 2023-08-12 09:28 UTC (13 hours ago)
(HTM) web link (blog.johnqian.com)
(TXT) w3m dump (blog.johnqian.com)
| adaml_623 wrote:
| "And as tools (especially AI) get better, the number of users a
| small team can support increases. Founders of the future may not
| need to worry so much about these scaling pains, and work may
| become fun for everyone"
|
| Except fewer of your users will have jobs because the AI
| multiplier means smaller teams. So your addressable matter will
| shrink. So another race to the bottom?
|
| I'm sure we'll work it out right..
| thumbuddy wrote:
| If only people could think from outside themselves for two
| seconds to assess technological impacts like you just have.
| fhd2 wrote:
| Awareness barely helps, it's the tragedy of the commons. I
| can't think of a solution other than regulation. But then if
| some countries regulate and others don't, you're right back
| at the tragedy of the commons at the international level.
|
| Reminds me of the Mass Effect games, where AI is essentially
| outlawed (because they revolted against the humans of course,
| but I can picture less scifi-ish reasons in the real world).
| I'm sure they're still allowed to use pathfinding algorithms
| and such, so they probably defined a level of net negative
| (to society) AI and just regulated that. Starships for
| example are manually piloted (surely with intelligent support
| systems and basic auto pilots) IIRC.
| throwaway80492 wrote:
| Let's keep sci-fi worlds designed to make a good story out
| of serious discussion, please.
|
| Or let me raise a The Culture argument, where computers/AI
| is hyper-advanced, AIs are friends, and no regulation
| whatsoever is needed.
| fhd2 wrote:
| Fair, not the best example of regulation countering the
| tragedy of the commons, because it's just made up.
| Unfortunately, any real world examples I can think of
| (nature preservation, gun control, ...) are seemingly
| controversial.
| throwaway80492 wrote:
| What even is the specific tragedy of the commons in this
| case?
|
| I mean real, observable things, not theories.
| halkony wrote:
| Isn't the tragedy of the commons how developing
| technology consumes our attention spans?
|
| Human attention span is a finite resource (we can only do
| so much in one life), and tech startups can consume a lot
| of that for relatively little payoff. Building a
| successful startup is like solving the bitcoin hash on
| your first few cycles. The barrier for entry is low, but
| you can hit it big (and consume a lot of cheap, finite*
| power too).
|
| The payoff is worth the risk since our communication
| technology is nascent and underexplored. We have an
| abundance of time right now because of what tech has done
| for us, but the cultural and environmental costs of
| growing tech are not well understood.
|
| Use of attention span is difficult to measure right now,
| but that could change in the coming decades. That said,
| parent comment seems to use "tragedy of the commons" as a
| stand in for "human nature."
| throwaway80492 wrote:
| Let me try this exercise:
|
| Except more of your users will have jobs because the AI
| multiplier means new opportunities to provide cheaper services
| available to more businesses, new companies that weren't
| economical before will be founded, entire new markets and whole
| new professions will be created. So your addressable market
| will exponentially grow. So another bull run?
|
| I'm sure we _will_ work it out right.
| SketchySeaBeast wrote:
| Do you have an example you're thinking of?
| jeremyjh wrote:
| See the last 300 years of recorded history of technological
| progress.
| SketchySeaBeast wrote:
| AI has been around for the last 300 years of recorded
| history of technological progress? Or is every piece of
| technology guaranteed to make life easier? Did the slap
| chop markedly improve people's lives?
|
| I understand theirs optimism (and pessimism), but
| optimism in and of itself doesn't make something true.
| throwaway80492 wrote:
| I'm currently consulting for a logistics/wholesale company
| that uses AI to massively cut down on product catalog
| management and vendor/customer support costs. Their
| services are now affordable to much more vendors. It's been
| a month or so in production and they have already onboarded
| many new SMB vendors who previously didn't have the means
| to pay for their services - and thus couldn't sell nor ship
| through my client. The cost of onboarding a vendor has
| decreased 100x thanks to using AI instead of doing it
| manually and it's not limited by headcount and personal
| schedules.
|
| The products of these new vendors are now available to many
| big customers in a major city (a single one where we are
| doing a pilot), and the vendors are reporting they are
| already getting 2 times the volume of orders they used to
| get. They didn't even have the means to deliver that much
| product before - now they are able to do it because their
| logistics are handled for them by my client (economy-of-
| scale advantages) instead of them DIYing it, and they use
| the freed time to do more of their main business.
|
| The customers are super happy because now they're getting
| fresh food produce from local farmers just days after it's
| been actually produced, which increases the quality of
| their products (food in restaurants/catering, usually) and
| they are already getting significantly more positive
| reviews thanks to that, which brings them even more new
| business of higher value. And funnily enough, the products
| they are getting are cheaper than what they got before,
| even though the quality is incomparable.
|
| AI is a huge win for everybody involved:
|
| - My client is no longer forced to deal only with the
| biggest vendors.
|
| - The employees who used to do sales/onboarding,
| vendor/customer support and product catalog management are
| still doing it, only now they're handling 10 times more
| products from 3 times more vendors, and focus on special
| and more interesting cases instead of doing grunt work.
|
| - The vendors have gained more customers than they ever
| dreamed of, make more money per unit and have much cheaper
| logistics that they don't need to think about nor spend
| their time on (we're talking about guys who used to hop in
| a truck themselves to deliver their stuff).
|
| - The customers are getting much better quality for lower
| price per unit. There's also much more product categories
| they can choose from now.
|
| - It's more environmentally friendly and supports the local
| economy.
| SketchySeaBeast wrote:
| Thank you - that's a super interesting example.
| moffkalast wrote:
| It's races to the bottom all the way down.
| dangus wrote:
| > But no incentive is as good as a fat chunk of equity + the
| power to influence its value.
|
| Meanwhile your sales team colleagues get their incentives paid
| out right away, in the very next quarter, and instead of equity
| lottery tickets it's just cash.
|
| I'd like to see engineering get some of the types of cash
| incentives that sales teams get. Perhaps the only reason they
| don't is because it's too hard to come up with metrics to base
| commission on. Instead, they rely on equity awards even though
| the value of the company is often quite detached from the quality
| of the software.
|
| The fun of a startup is nice but it's probably not worth it if
| you're getting below-market compensation, crappy healthcare, long
| hours, and the IOU of an equity stake that's probably crafted by
| financiers to screw over regular employees.
| fallingknife wrote:
| It's not too hard to come up with bonus structure for
| engineers. Managers have bonuses for team targets at tech
| companies. The mistake is that those bonuses don't trickle down
| to the team. That's how it works in the oil field. There are
| bonuses for on time or early well completion. And everybody,
| even the newest roughneck, gets a cut of the bonus.
| xtremedata wrote:
| i'll chime in with a personal experience. I joined a highly
| technical startup (think C++ and CUDA) with an incredible
| engineering team. Now hire a bunch of
| strategy/business/sales/success workers, create two tiers of
| society, and ensure the engineers get thrown into the back room.
| Great way to make a startup lose spark.
|
| Here is a specific example: schedule the company holiday party
| _the night before the one major software release of the year_ so
| all the engineers are sitting at the party with heavy GPU laptops
| coding away on build issues after bug fixes.
|
| Here is another specific example: recently hired workers on the
| business side become Directors and VPs three out of undergrad
| while engineers waiting for years for promotions are not given
| any.
| hn_throwaway_99 wrote:
| I liked parts of this and disagreed with other parts.
|
| Perhaps the part I agreed with the most is "don't hire too fast".
| It's difficult for me to think of a startup (or, honestly, any
| company) that failed or experienced pains from hiring too slow,
| but I can think of tons of problems (often from personal
| experience) from hiring too fast.
|
| One piece I couldn't help roll my eyes at is the "don't use Jira"
| bit - like the sun rising in the East, bashing on Jira is the
| favorite past time of engineers. Depending on your type of
| startup, Jira may be a great tool for the job. E.g. if your
| company has lots of different workflows it needs to support, it
| can be very easy to waste a ton of time due to "dropped balls" if
| things aren't tracked well and issue ownership isn't explicitly
| clear. Of course, it's easy to waste a ton of time over-
| complicating Jira with a million unnecessary issue states, but
| IMO Jira has made it much easier for small teams to use it and be
| productive quickly (i.e. team-based projects). I'm also not
| saying Jira is the best tool to start with (my last startup
| stated with Trello and it worked well), but once you get into
| production and have a lot of operational issues to manage and
| prioritize alongside new feature development, you're likely going
| to need _some_ Jira-like tool to keep everyone aligned and
| informed.
| alexchantavy wrote:
| +1, I was also confused about the don't use Jira part - what is
| the alternative that will let dinosaur companies "operate more
| like startups"?
| l5870uoo9y wrote:
| There is an incredible important step missing: find a viable
| business model. Getting ideas and building them is "relatively"
| easy (just look at the vast open source ecosystem) for engineers
| but integrating/pairing/merging them with a business models that
| generates revenue within a limited time period is hard.
| bhouston wrote:
| Brilliant short essay that captures the maturity changes and
| challenges.
| samhuk wrote:
| I'll raise your spark for complete destruction.
|
| Here's an incomplete list that I keep around of the mechanisms
| that I've observed so far that have played a big part in the
| decline/destruction of an engineering team (and product thereof):
|
| 1. Too-technical leaders:
|
| As startup scales, there can sometimes be a mad dash to fill new
| leadership roles (e.g. VP of Eng, Arch, CTO, etc.). Super-star
| _engineers_ present at startup phase sometimes move into these
| when they are not the leadership type, causing engineering team
| to devolve into a visionless, directionless zoo.
|
| 2. Non-technical leaders:
|
| Inverse to the above - as startup scales, in desperation, new
| leadership roles are filled with _non-technical_ individuals who
| have little to no engineering experience. This causes similar
| outcome to #1 (albiet slightly different, but equally perilous).
|
| 3. Problem engineers:
|
| Small number of leaders lack a spine, conducting shallow
| interviews and let in "problem engineers" who spoil the party and
| wreak havoc. Lax hiring practices almost always are reflected
| into non-existent firing practices, leading to them lingering
| around.
|
| From experience, it only takes around ~5-10% of a team being this
| type for it to have a large negative impact, as they tend to
| derail progress, dodge responsibility, reputation farm, push
| rubbish, all that nonsense. It harms morale, and the skies turn
| grey in the office...
|
| 4. Micromanagement:
|
| Speaks for itself. Leads to red tape, demoralization, timeline
| slippage and frustration.
|
| EDIT: I'de love to hear how these foot-guns have been avoided.
| From experience it seems really challenging, as if like magic; as
| if cultivating and maintaining a good engineering team and
| culture therein is like balancing a pencil on it's nib...
| extr wrote:
| What is to be done if you find yourself in the first situation
| (too-technical leader)? I found myself there before a few
| times...reporting to someone who was no doubt a brilliant IC
| but has no concept of things like communicating vision or even
| basic project management. Would be curious to understand if
| anyone has been able to "fix" this from the IC side.
| samhuk wrote:
| I find it hard to imagine that it's possible to, in all
| likelihood, improve a too-technical leader problem from the
| individual team member position. There's only two ways
| through which that I can conceive it being solved:
|
| 1. Too-technical leader realizes they aren't fit for purpose,
| perhaps due to indicators like stress, missed targets, team
| morale, etc.
|
| 2. Higher-up leadership notices aforementioned issues and
| give them the ultimatum: leave or side-/demote to more
| technically-focused role.
| bcantrill wrote:
| That's a great taxonomy of foot-guns! As to how they can be
| avoided, I can only describe some of what has worked for us so
| far, with the caveats that we are still small (~60 employees);
| that none of this is formulaic or perfect; and that there are
| many reasons why what we have done might not work for others --
| or may not work for us as we get larger! That said, here is
| some of what has broadly worked for us:
|
| 1. Writing-intensive hiring process
|
| This is controversial for some, but I have the personal
| advantage of having previously made The Worst Hire of All Time
| -- one that forced me to accept that using resume + interviews
| as the sole (or even primary) criteria left me extraordinarily
| vulnerable to Problem Engineers. We ask candidates not just for
| a portfolio of their work (and analysis samples and so on), but
| also ask them values-based questions[0] -- the answers to which
| are astonishingly revealing. Our review of candidate materials
| constitutes the bulk of our hiring process.
|
| 2. Transparent compensation
|
| Another one that is surely controversial, but in my
| professional experience, an amazing number of anti-patterns
| arise from the scramble compensation -- and usually not for
| itself per se (that is, not for the marginal dollars), but
| rather for what it represents in terms of validation, power and
| so on. Making compensation transparent forces some measure of
| organizational health -- to say nothing for the bright light it
| shines on any institutionalized inequities.
|
| 3. Uniform compensation
|
| One that even more people will find controversial. ;) When we
| wrote our blog piece on this 2+ years ago[1], we assumed that
| it wouldn't last as long as it has -- but it honestly is more
| important to us now than ever before. Especially as we go to
| expand the team with roles that are often less well compensated
| (e.g., customer-facing roles), the fact that we explicitly
| compensate them as well as everyone else allows us to attract
| extraordinary folks to the company. We still don't know if this
| is going to last forever, but we have seen so many incredibly
| benefits from it that we have stopped burdening it with
| asterisks.
|
| 4. Very, very careful hiring
|
| We are deliberately lean. We add people to the company very
| carefully, and we have no one inside the company who is
| incentivized by the size of their team (see #3, above!). When
| we add people, we keep a sharp eye on versatility and intrinsic
| motivation. This allows us to do more with relatively fewer
| people -- helping us avoid the foot-guns you've outlined. That
| said, it is also not without side-effects: a consequence of
| this is that we are extraordinarily selective, which means we
| have many more people that want to work at Oxide than we can
| reasonably accommodate -- and it can be really, really hard to
| turn down someone who you think will likely be successful!
|
| [0] https://docs.google.com/document/d/1Xtofg-
| fMQfZoq8Y3oSAKjEgD...
|
| [1] https://oxide.computer/blog/compensation-as-a-reflection-
| of-...
| samhuk wrote:
| Hey Bryan! Liked what you have done.
|
| Big +1 for #1. A brilliant IC that has an impressive
| contribution history tells only a small fraction of the
| story. Skeletons may lay behind that green square matrix!
|
| Also big +1 for #4. It may slow growth for some start-ups,
| but I think it's always better in the long term if hiring is
| deep, versus shallow.
|
| As for compensation, those certainly are controversial. I
| believe in honesty, but your extent of it is quite...towards
| one end of the spectrum? Certainly interesting.
| bcantrill wrote:
| Ha -- "towards one end of the spectrum" is a fair (if not
| generous!) way to describe much of our approach, on many
| things. ;) And it _has_ been interesting -- with surprising
| ramifications in many areas. As a concrete example: when
| people are assessing a hire to be a true peer with respect
| to compensation -- being paid neither more nor less -- the
| level of expectation is really high, and the reviews are
| thoughtful, thorough, and candid. This is but one of
| several examples; at some point, a blog entry on our
| experience is probably called for...
| arunbahl wrote:
| I've been a big fan of Oxide's approach for a while - thank
| you for articulating and sharing the thinking behind it.
| steve76 wrote:
| [dead]
| elric wrote:
| I'll throw in _greed_ as another factor. Being ambitious is
| fine, but being greedy will wreck a startup in no time flat. Or
| in the case of my previous employers, in about 13 months ...
| samhuk wrote:
| I've always assumed that greed, particularly when it's
| egregious and endemic, would more rapidly unwind a start-up.
| My OC was more focusing on those mechanisms that tend to be
| at play at start-ups that cause them to gradually
| decline/implode.
|
| However, I totally agree with your point. Also, sorry that
| happened to you!
| liquidpele wrote:
| Don't forget: Hiring remote contractors to "speed up" things.
| Dev will slow to 50% and meetings will double as you attempt
| unsuccessfully to teach them how to code.
| gochi wrote:
| Anytime a leader sees new hires or contractors as a "speed
| boost" is when it all goes to the dump. The sooner we get
| past this idea, and start viewing new hires/contractors as
| "speed bumps" the better. Bringing anyone new into the fold
| should always be a slow process!
| tstrimple wrote:
| Depends on the scope of the change and the objectives of
| the company. This is more true in larger organizations than
| startups, but not all technical problems you're working on
| are directly linked to your value prop. I've seen good
| results in many cases where some systems are handed off to
| be managed by contractors so the FTE devs can focus their
| attention on improving the product which actually makes
| them money.
|
| What I haven't seen work is (which is what I think you're
| describing more specifically) bringing on new hires or
| contractors to a project in flight in an attempt to deliver
| it more quickly. That's where we get into Mythical Man
| Month territory.
| WanderPanda wrote:
| More general hazard: Treating engineers as fungible resources
| ricardobayes wrote:
| Absolutely. If you have a software company, literally 100%
| of your company valuation goes home after 6PM.
|
| If a key engineer leaves, you lose a _lot_ more than
| 2-300k.
|
| In opportunity cost, you lose tens of millions, possibly.
| lr4444lr wrote:
| Here's an idea I've seen work: stop assuming people over 35
| aren't a good fit for a start up. People who've been in
| leadership for a while but have the chops and in their day did
| on the ground work, and who can - given enough time and
| guidance - understand the minutest detail of a new tech stack
| or financial maneuver, command the respect of the super stars
| doing the day to day for their contribution of far seeing
| leadership.
| samhuk wrote:
| Preface: I'm not saying that this norm is necessarily right,
| rather just explaining the mechanism that I believe is at
| play here.
|
| Isn't part of the issue that early on in a start-up, everyone
| is indispensable, and often that comes with putting in extra
| hours and going the "extra mile" for the viability of the
| company?
|
| When you are over 35, 30 even, you are much more likely to
| have a spouse, children, etc., and all these command more of
| your time that the business wants to capitalize on.
|
| Personally, I've seen some real rock-star engineers both at
| 20 and at 40, however more often than not for different
| reasons. Honestly, not once have I ever learned a decent life
| lesson from engineers around my age (I'de say I'm on the
| younger side), however it's been several highly memorable
| times that an engineer on the older side has pulled me away,
| given me some real hard-hitting, incredibly valuable
| engineering and life lessons, and changed my career and
| sometimes life for the better.
|
| It's a complex world!
| aardvark179 wrote:
| > Isn't part of the issue that early on in a start-up,
| everyone is indispensable, and often that comes with
| putting in extra hours and going the "extra mile" for the
| viability of the company?
|
| There seems to be a strong culture in American companies,
| and especially in startups, of rewarding heroic efforts.
| But if I see people putting in heroic efforts to get things
| done I tend to look for ways to not need those efforts in
| the future.
|
| Good experienced engineers can help ensure that you don't
| keep having to go that extra mile to get the job done in
| the first place.
| Aurornis wrote:
| As a corollary of these people problems, I would add:
|
| 1. Not correcting problem hires fast enough.
|
| First time founders are often too hesitant to give negative
| feedback, demote a too-technical manager who should have stayed
| an IC, or remove a problem employee who isn't working out.
|
| The anecdote that comes to mind is a local startup that hired a
| C-level executive's UI designer friend into their VP of Product
| role. He was wholly incapable of doing the job but they kept
| him in the job for 2 years to "give him a chance to grow into
| it." Everyone below VP level openly talked about how the VP of
| Product was incompetent and how to work around him.
|
| The company's product initiatives ultimately failed to even get
| started and they had to pivot to entirely services based work.
| Do not stay at a startup that insists on keeping unqualified
| people in leadership positions long after everyone in the
| company has given up on them.
|
| 2. Firing the wrong people
|
| The same startup was forced to downsize, largely because their
| product plans failed to even become defined enough to start
| under the incompetent VP of Product.
|
| It was the perfect opportunity to fire the VP of Product and
| his sprawling empire of people who did very little, but they
| avoided that due to his connections to a C-level executive.
| Instead, they started cutting engineers. They focused on
| cutting engineers with the highest compensation out of a
| misguided effort to cut as few people as possible.
|
| In the process, they lost their key engineers who were holding
| things together. They sent a message to everyone that
| incompetence is tolerated if you know the right people. And
| they lost even more core engineers who quit in the months after
| those layoffs.
|
| Everyone makes hiring mistakes. It's how you respond to those
| hiring mistakes that will seal the fate of the company.
| setgree wrote:
| Yep, this very much resonates with my experiences.
|
| At the end of the day, startups are run by people, who
| generally prefer to work with their friends, avoid conflict,
| etc. There's no great mystery. The mystery is when things
| work well.
| samhuk wrote:
| Thanks for your comment. Totally empathize with your
| experiences there.
| halkony wrote:
| Ray Dalio talks about this in his book "Principles."
|
| The specific advice he offers is "hire slowly, fire quickly."
| bcantrill wrote:
| Terrible advice (from a broadly terrible book, I hasten to
| add). The reason that this is terrible advice: if you "fire
| quickly", it is because something is either grievously
| wrong (a mishire) or you are firing based on limited
| evidence. If the former, you have a hiring problem, not a
| firing problem; if the latter, you will generate a fear-
| based culture. Now, if you're running a prison, a fear-
| based culture may be exactly what you're after -- but fear
| is anathema to innovation, and if your endeavor requires
| any creativity whatsoever, you should be seeking to build
| mutual trust, not foster institutional fear.
| dmoy wrote:
| Not only that but you run into the very expensive reason
| why literally every large company has a lengthy
| documented process for firing (outside of layoffs of
| course, lol):
|
| Lawsuits
| halkony wrote:
| Could you expand on your other criticisms of the book?
| How does it conflict with your experience? I'm still
| learning.
| bcantrill wrote:
| I honestly think the book is so bad that it's not worth a
| lengthy critique, but in short:
|
| 1. Dalio doesn't understand what a "principle" is -- but
| I can understand that "Aphorisms, Cliches and Hunches" is
| a less arresting title, if much more accurate. (See [0]
| for a fuller review on this.)
|
| 2. Dalio's version of Bridgewater doesn't line up with
| the experience of others -- which I have heard from so
| many people as to completely undermine whatever he might
| say.
|
| Now, in the book's defense: I didn't get through it and
| perhaps it got suddenly palatable or interesting.
| However: I also _couldn 't_ get through it -- it was just
| that bad.
|
| [0] https://www.goodreads.com/review/show/2233988523
| halkony wrote:
| I agree that his descriptions are less "principles" and
| more like "heuristics". The overall message of the book,
| as the referenced reviewer points out, is "do what's
| sensible." As someone so young, what is sensible to me is
| not obvious, so I find value in this.
|
| What, in your opinion, defines what is sensible in
| business and leads to your frustration with Dalio's
| message? Can you give personal anecdotes?
| F-W-M wrote:
| In Germany it is very hard to fire people but there is a
| six month period in the beginning, where one can be fired
| without reason. Is it possible to gauge a new employee
| during that timeframe?
| denvrede wrote:
| I would say you can generally (from my experience >95% of
| the time) identify a bad hire in roughly a month, mostly
| in two weeks and then give yourself / them additional two
| to be very sure.
|
| We just hired for a management position a couple of month
| ago and I could tell from the very first meeting that it
| was a bad hire. I made sure with my team that I'm not
| totally wrong and then communicated my doubts to the
| C-Level. It took some time because they wanted to give
| them a real chance but just before the probation ended
| there was an evaluation meeting and the feedback was,
| without exception, negative. Took two days and they were
| gone.
|
| Of course there will be hires that can uphold their
| charade for six month but I would say that's an
| exception.
| dilyevsky wrote:
| A mishire situation is what usually this advice is about.
| Maybe if you hire only people you previously worked with
| you can bring the mishire rate way down but for majority
| that rate will probably be very high is what I commonly
| hear.
| ravenstine wrote:
| It's very old school and discounts how many problems can
| actually be corrected faster and less expensively than by
| firing ASAP.
|
| The reason "fire quickly" may be appealing advice to some
| is that solving problems takes effort without a clear
| guarantee of return, and leaders usually end up trying
| easy solutions that diffuse blame or create the illusion
| that something has changed. Then they wonder why
| productivity is not up or why employee sentiment is
| middleing.
| dasil003 wrote:
| After 25 years in the full range of IC and management
| positions, I'm convinced there's no substitute for expertise,
| maturity and judgement. I could come up with some rules of
| thumb (eg. ICs need the maximum amount of agency they are
| capable of handling), but every rule has its exception.
| Distilled wisdom is easily misinterpreted, taken out of
| context, and cargo culted by those with insufficient experience
| to apply it.
|
| I've seen how small dynamics resulting from individual
| personalities and nuances of org structure have led to massive
| dysfunction and productivity loss, even though everyone was
| well intentioned and doing their job to the best of their
| ability. I could list out hundreds of behavioral "flaws" that
| individuals exhibit, but there's no way to fix them all
| directly, good engineering can't be done by top-down edict and
| central planning. Instead, you need a critical mass of people,
| including engineers on the ground, with a good end-to-end
| understanding of the product and business so that micro-
| decisions can be suitably informed by the big picture, and the
| right concerns can be escalated for leadership attention. You
| need to be able to weigh the cost of product, design, legal,
| financial, support, security, and operations across both short
| and long-term to make the right decisions. This is only
| possible with a high degree of mutual trust and safety for
| experts to voice their opinion and find the right tradeoffs.
| It's very easy for egos and personality conflicts to come in
| the way, hence the need for maturity in leadership. Balancing a
| pencil on its nib is not a bad analogy.
| Zetice wrote:
| I think your question about avoiding these mechanisms isn't the
| right one; the real question is, how does one succeed despite
| these _inevitable_ problems?
|
| In other words, I don't think you avoid these, I think you
| understand they're coming and accept the trade off, making sure
| it's worth the issues you invite when you do have to promote
| those engineers/non-technical people, for example.
| samhuk wrote:
| I think another comment made a good point - It's all about
| rapidly determining when the hires and promotions aren't
| right.
| pojzon wrote:
| Im seen as a problem engineer even if its never my intention.
|
| Im a bit anxious and introverted and thus like to get my part
| done and focus on other things.
|
| This always results in rest of the team losing will to go far
| and beyond.
|
| I dont know what to do about it, beside aknowledging it exists.
|
| Do you say that ppl like me should simply quit and go working
| at sewege?
|
| I dont think I like that idea. So what can I do if thats just
| how I am ? I cant seem to change how others see ppl like me.
| ghaff wrote:
| >So what can I do if thats just how I am ?
|
| Most things are not written in stone. You can probably change
| even if it's not comfortable to do so. Maybe a different role
| or organization would be a better fit. But typically just
| getting your part done and moving on isn't the best fit for a
| lot of jobs and, even if you work for yourself, you probably
| even have more interactions with clients at that point.
| Tainnor wrote:
| Well, nobody has the _intention_ of being a problem engineer.
| That said, from your comment I haven 't really understood why
| you're considered (or are considering yourself) to be a
| problem engineer?
| ambicapter wrote:
| > Im a bit anxious and introverted and thus like to get my
| part done and focus on other things.
|
| > This always results in rest of the team losing will to go
| far and beyond.
|
| The logic chain here is not very clear, I'm wondering if you
| actually understand what's going on.
| ricardobayes wrote:
| You can either educate others why you see things in a certain
| way.
|
| If it's unexplainable, or the majority doesn't accept it,
| move on: change your ways or accept they are going to see you
| as such.
| samhuk wrote:
| From somebody who, perhaps sometimes can be quite full-on
| about software quality, craftsmanship, and just generally
| doing good, here's what's helped me in the past when faced
| with a company/team that has morale, skill, or other
| problems:
|
| 1. _" The extent to which you publicly complain about
| something should be proportional to the robustness of your
| solution and your confidence in it."_
|
| 2. If you think things need to be done better, lead by
| example. I've found that you will be hated for saying things
| are bad, but loved for _proving_ how things can be good (by
| example).
|
| 3. Note down your concerns (Notion is free!). Wait on them,
| then talk about them >=1 day later if you still feel like
| they are valid.
|
| 4. Ensure you have enough employable skills on the side so
| that you can jump ship if the company or your place within it
| is totally DOA.
| pojzon wrote:
| I would like to change many things I feel could be solved
| in better ways.
|
| Unfortunately Im not a rockstar engineer and stuff takes me
| more time. I care a lot about maintainability, so writing
| docs or good explanations to design decisions simply take
| time.
|
| As you can guess we often dont have that time in the
| industry thus most things look like they look.
|
| My biggest issue right now is communicating those findings.
|
| Curse of things seeming too obvious, trivial or simply
| requiring more time.
| jotato wrote:
| One thing I'll add - or maybe it expands on too technical of a
| leader - is when a brilliant outside hire is brought in to fill
| the arch/principal/whatever role.
|
| Then they start looking at the app and questioning every
| decision calling everything they don't have context on
| "technical debt"
|
| I've seen it a few times. I told a new VP of Eng he was being
| asinine because he wasn't there for the original problem,
| decision, or timeline and saying we made a bad call is just
| showing ignorance.
|
| Thankfully, He pulled me aside later to thank me and asked for
| more background on it. After hearing the whole story he agreed.
| We did the right thing.
|
| Now, that could have gone the other way. And I've seen it
| happen. When it does, it sucks.
| Aurornis wrote:
| It sounds like the VP Eng was actually a great leader if he
| could take feedback like that in stride and admit when he was
| wrong. Bad leaders would have dug in their heels and
| sidelined the person with abrasive feedback (you).
| jotato wrote:
| Absolutely. My point is that it doesn't always go that way.
| He had his faults, but he could take string feedback. If I
| recall, he said something to the effect of "not many people
| speak to me like that. I forget how helpful it is to be
| challenged"
| samhuk wrote:
| I agree with sibling comment.
|
| Also, wow, that took some courage. Personally, I deeply value
| this way of direct communication when everybody feels free to
| speak up when things go wrong, and nobody has precious egos
| they feel need protecting.
| ricardobayes wrote:
| Re: 3. "Problem engineers" are a similar problem to those users
| in a forum who don't actively break the rules but destroy the
| community.
|
| And for 4, the opposite is even worse, aka "no management". So
| when you develop something but it turns out the outcome was not
| needed or in a different way.
| endorphine wrote:
| Maybe by avoiding fast scaling, which implies avoiding VC
| money.
| re-thc wrote:
| > Maybe by avoiding fast scaling, which implies avoiding VC
| money.
|
| There are still things you can do, e.g. don't pick the offers
| in a round with the most $$$ - instead pick the 1 that will
| help you the most.
|
| Set the right expectations. Most of the time it's not the VC
| money that's the problem but the founders being consumed by
| suddenly being "rich".
| WJW wrote:
| From experience I can say that these problems can occur just
| as well in bootstrapped companies when they reach a certain
| size. It's a problem with the number of employees regardless
| of how fast the company gets there IMO.
| Aurornis wrote:
| The first startup I worked for was a slow-growth company that
| had slowly expanded over 7 years to only about 50 people. A
| dinosaur in startup terms.
|
| It still had the same problems as above. Expanding slowly
| doesn't automatically protect you from these things.
| brabel wrote:
| Are you being sarcastic? To grow to 50 people in 7 years is
| probably only for the top 5% successful startups.
| srvmshr wrote:
| Elaborating a tiny bit on #2: It is a dangerous situation when
| non-technical leadership comes up with very specific technical
| opinions - based on hearsay & evangelists on their
| Twitter/Instagram.
|
| "I saw X on his Reel telling changing everything in our
| frontend to purely Coffescript will be more durable" is a kind
| of advice which does not bode well generally
| yafbum wrote:
| Big +1 on too technical leaders. Seen this a couple times with
| brilliant engineers who, once they became in charge of 50
| different teams, appeared to try to just do the same work they
| did in one team but "scaled". Put every team in a spreadsheet
| and try to automate management through uniform metrics instead
| of focusing on managing and growing his direct reports.
|
| And another time, seen a less technical leader step in, see
| engineers around me roll their eyes a couple of times at the
| lady (with maybe a smidge of male chauvinism blended in), but
| then see her actually fire bad hires, hire star players, and
| get everyone to align their priorities so they could be
| productive. Leadership is a very different job from the kind of
| technical excellence that too often gets rewarded by promotions
| (vs raises or bonuses).
| kevin_nisbet wrote:
| Another +1, I left a startup over exactly this, all the
| managers, directors, and VP of engineering were IC engineers
| maybe 2 years prior. It was a shame, because I really enjoyed
| my role at that company in general, but ended up opting to
| leave after getting a really terrible leader.
| Mistletoe wrote:
| I've seen this in science as well. Analysts get promoted to
| managers and managing is a completely different skill set
| that involves social skills, communication, empathy- all
| people skills that they didn't need to be a good analyst.
| They were promoted because they were good at being an
| analyst- meticulous, quiet, just do their job and don't
| interact with others. Unfortunately almost none of this
| carries over to being a good manager. I wished many times
| that they just hired people with management skills from some
| field completely outside of science, a manager doesn't really
| need to know the intricacies of the work to do their job
| well.
|
| My last industry job saw the company implode from this cycle
| as everyone got pissed off and left the company. My old ex
| co-worker sent me a letter from the CEO last week saying
| layoffs were starting because revenues were down and they
| keep losing clients...
| yafbum wrote:
| > I wished many times that they just hired people with
| management skills from some field completely outside of
| science, a manager doesn't really need to know the
| intricacies of the work to do their job well.
|
| Having been there too, I feel like this is another recipe
| for disaster. Technical management needs to be able to make
| calls on escalations -- that's in fact one of their main
| jobs -- and when they don't have the depth of knowledge to
| make the call on merit, they make it on rash impulse, or
| favoritism, or (perhaps worst of all) don't make the call
| and let issues fester.
| ghaff wrote:
| That's true. It's also the case that, if you polled people
| here, you'd find no shortage of people with zero respect
| for managers without technical backgrounds.
| mattkrause wrote:
| > I've seen this in science as well.
|
| Academic science is pretty much _designed_ this way.
|
| You get a faculty job based on your brilliant work as an IC
| (i.e., first author papers) but running a research group is
| a totally different skill set---and often one people get
| very little training for.
| samhuk wrote:
| It's interesting that you have experienced both sides of the
| leadership problem space. Honestly a bit glad to hear that
| others share my experiences and that I'm not just unlucky or
| something.
|
| Also, oh my do I ever have an extremely similar experience of
| an IC-type engineer going into a leadership position and
| trying to "engineer" it: put all teams, sprints, tech
| visions, growth frameworks, etc. in huge spreadsheets. I look
| back in jest now, lessons to be learned!
| duxup wrote:
| Yeah that 5 to 10 % seems about right.
|
| I recall a teamwork study that found few if any superstar team
| players can really make any given team better, but they did
| discover that one bad apple can easily kill a team's
| productivity, happiness and etc.
|
| I once worked for a company that was really great about "no
| finger pointing" and lots of trust of employees to do the right
| thing.
|
| We acquired a small troubled company along the way, they were a
| mess with finger pointing and empty accusations. Within a year
| they had infected our entire department:(
| Tainnor wrote:
| Problem engineers are not necessarily all new hires. It could
| also be people who were there initially but fail to transition
| into a role more suitable for a growing company.
|
| A classical example, which I've seen before, is a cowboy coder
| who can be a useful asset in the very early stages, but who
| later demonstrates a total lack of teamwork ability.
|
| Such people are even worse than bad new hires because they have
| a certain clout with management who is therefore more willing
| to turn a blind eye.
| jonas21 wrote:
| This sounds like the opposite of what the author had in mind.
| The cowboy coder is the one with spark, and the need to
| "transition into a role more suitable for a growing company"
| is the problem.
| Tainnor wrote:
| Companies change, and if you can't adapt then the problem
| is you. Being able to work together with your peers and not
| alienate them is not too much of an ask.
| hliyan wrote:
| It almost feels like the "efficiencies of scale" you get from
| large organisations (e.g. specialised people for recruitment,
| people matters, quality assurance, user research etc.) are not
| really efficiencies. Perhaps it's better to grow the organisation
| by repeatedly cloning the smallest effective team you ever had,
| rather than creating a more "efficient" organisational structure.
| How those "mini-companies" communicate with each other
| efficiently -- another matter.
| srcnkcl wrote:
| k8s the company, infinitely scalable
| fnordpiglet wrote:
| The challenge is cloning teams is impossible. Teams are a
| collection of individuals. It's like saying the way to win the
| World Cup is to simply clone the best team.
|
| I think the best way to scale is to build processes that
| reinforce the traits you want in a team, and hire managers who
| understand teams are collections of unique individuals, as is
| the manager. The manager should be free to manage their people
| in a way that optimizes delivery and reduces churn. Between
| teams there should be a very high bar for quality of
| communication and delivery. The culture of the organization
| should be built around respect for each person hired and a
| relentless focus on ensuring individuals end up in teams that
| they are effective in and are therefore maximally effective as
| teams.
| flir wrote:
| > the way to win the World Cup is to simply clone the best
| team
|
| The startup that does that should absolutely be called "Boys
| from Brazil".
| fhd2 wrote:
| I think it's about more than just efficiencies of scale. You
| kinda play by different rules at a certain scale (not just
| based on employee count, also based on revenue), and suddenly
| you're subject to a lot more regulatory scrutiny. Plus, as a
| company becomes more valuable and attracts shareholders and
| managers with lower appetite for risk, a lot of money needs to
| be poured into risk management and avoidance. At a previous
| company, a competitor was blatantly breaking the law to solve
| user needs we couldn't solve without breaking it as well.
| Somehow they got away with it, presumably because they were
| tiny and (to my knowledge) unprofitable.
|
| Now, if it wasn't for all that, there's still the problem that,
| from personal experience, most employees don't invest as much
| energy as a founder would - which is perfectly understandable.
| As the founder to employee ratio gets smaller, you find
| yourself hiring three people to do a job you could do yourself,
| just to make sure it gets done reliably and timely. In a
| smaller startup, early hires are more similar to founders
| because they're close to them and stand to gain a lot if the
| company succeeds and grows. For employee #213, they sell 40
| hours of work per week and their fixed salary is all they
| really stand to get out of it.
|
| So while I like the romantic idea of having a large company
| comprised of multiple independent startups, I haven't seen that
| work and I can barely picture it work :( One can get somewhat
| close to this with the right organisational structure (e.g.
| sacrificing efficiencies of scale for team autonomy where
| feasible), but it's not even close to the same thing.
| naijaboiler wrote:
| You're correct. It doesn't work. A lot of ails are
| necessarily inherent in scaling up. Once you get to 80ish,
| you just necessarily have to change your setup
| toyg wrote:
| This is what the author suggests towards the end of the piece,
| and points out some issues with it.
| hliyan wrote:
| Yes. Maybe one can design some sort of internally budgeted
| token based economy between these internal teams (distinct
| from mere gamification). But based on past experiences, I
| worry that that will lead to unanticipated perverse
| incentives.
| VHRanger wrote:
| That's what the mobile game studio supercell did initially
| (hence the name): divide the company into a bunch of 15-25
| person indie studios.
|
| It also eventually became a monolithic org.
|
| Same with Valve and flat org structures.
|
| Once something scales enough it becomes the blob, like
| everything else.
| disgruntledphd2 wrote:
| And Supercell are probably one of the most successful mobile
| gaming companies ever.
| VHRanger wrote:
| Yeah they held off becoming a blob for a solid decade
| notacoward wrote:
| Adding people/roles can be beneficial when it _frees_ other
| people from onerous or distracting work. When it _increases_
| onerous or distracting work for everyone else, that 's a
| problem. To a large extent, the art of managing growth is
| finding ways to liberate everyone instead of handcuffing them.
| KnobbleMcKnees wrote:
| I agree and this is a practical method that I've seen work well
| in several companies I've worked for. However I think there's a
| bigger problem that contributes to the loss of "spark" that the
| author strangely didn't address at all.
|
| The fruits of labor grow ever higher. By which I mean: In the
| early days of a startup the problem space is ripe and
| plentiful, the impact you can have is outsized, and the pool of
| people with which to share it is the smallest it will ever be.
|
| As a company grows, all three of these factors are subject to
| strain. The problem space becomes sparser, outsized impacts are
| recognised further up the ever-growing hierarchy, and the pool
| of people with which you're sharing your impact becomes larger
| and recognition becomes shorter lived and more diffuse.
| alain94040 wrote:
| There is also a dynamic aspect to that: the original team who
| started the startup has battle scars, they used to take risk,
| but now they have a natural incentive to be more
| conservative, preserve the way things were done.
|
| Rands has a great article on that topic well worth reading:
| https://randsinrepose.com/archives/stables-and-volatiles/
|
| It matches my experience with startups experiencing
| challenges as they grow.
| K0balt wrote:
| This is an intriguing idea. I wonder if the paradigm has a name
| or a following?
| bombcar wrote:
| Isn't that basically what franchising is?
| K0balt wrote:
| Hmm, that is an interesting parallel. I think it misses the
| mark somehow though.
|
| Idk why people don't like the question, I'm actually
| looking for a developed model/ paradigm around this
| concept. No sense reinventing the wheel.
| hintymad wrote:
| > Talking to users is for PMs, silly!
|
| I particularly don't understand why an organization would hire a
| PM for an internal infra team. It's like hiring a PM for Go to
| design the features of Go. Funny enough, executives from Google
| love to do this kind of things. I'd thought Google's infra
| engineers would be perfectly capable of driving the features of
| their infra services.
| bryanmgreen wrote:
| I think there's an inflection point at around 40 employees where
| terminal velocity starts to slow down due to a combination of
| sheer headcount and founder exhaustion.
|
| It's something I've personally seen and have read about so many
| times. Some make it through this stage but it's extremely
| difficult because it requires a very different set of skills and
| experiences. It becomes less about grinding, which in theory is
| very simple to explain and encourage.
| jSully24 wrote:
| New ideas getting shot down for fear of cannibalizing existing
| revenue.
|
| The product that was the breakthrough is likely (somewhat)
| wonderful and loved (or at least used) by many and generates the
| bulk of your revenue. However we all know that solution that has
| gotten you this far has problems and there are many ideas to be
| able to go to the next level.
|
| But any idea that is seen to take away from the focus of that
| main revenue generator will be fought unless there is VERY strong
| leadership. Anything "new" will impact marketing budgets, Sales
| incentives and revenue goals, threaten those who are working on
| the "legacy" project, not to mention external forces who are only
| interested in the bottom line revenue and EBITDA numbers for the
| next quarter, not the next 1, 3 and 5 years.
|
| I've had this happen at 2 startups I've been through. Both had
| successful exits, but could've been more and build a much better
| future path for themselves.
|
| Now trying to avoid this in my current home.
|
| What if Apple had stopped the iPhone for fear of it
| cannibalizing* the iPod line of products revenue? *
| https://www.imd.org/research-knowledge/economics/articles/ap...
| indymike wrote:
| Startups lose their spark when they either:
|
| 1. Go from "more to gain" to "more to loose" thinking.
|
| 2. Growth slows and either ethics or vision are sacrificed.
|
| Both of these are natural, and the people will have to change. In
| most companies, eventually growth stops (at least growth driven
| by the original vision). Eventually you really do have more to
| lose than gain. The signal these transitions are happening can be
| spotted by proliferation of guardrails and process controls, and
| a cultural change towards risk aversion. The drive is to make
| everything predictable, controlled and safe. The focus is no
| longer on acceleration, and is on momentum.
| victor9000 wrote:
| The failure modes I've encountered:
|
| 1. Toxic team members who can't be fired. These people will
| reduce morale down to zero and force your best people to leave.
| In one case it was the CEOs long-time friend, and in the other
| case it was one of the technical founders. If you find yourself
| as an employee in a similar situation, then go ahead and pack
| things up because it will never get better.
|
| 2. Selling to Fortune 500s without investing in a sales team.
| Basically, we built it and they never came because B2B at this
| level is much much different than B2C. So if this is your move
| then your sales team should be bigger than your engineering team
| by at least 2x.
|
| 3. Toxic team members in recruiting positions. I once worked with
| a business partner whose recruiting strategy boiled down to
| bullying people into joining the company. After a year's time we
| had a solid 12 person engineering team while the business team
| was exactly the exact same as when we started.
|
| 4. Focusing too much on writing code and not enough on building
| relationships in your domain. When it comes time to sell, you
| will need to reach out to someone, so start nurturing
| relationships early.
| zenlf wrote:
| How do you bully people into joining a company?
| victor9000 wrote:
| By employing high-pressure sales tactics to trigger fomo in
| candidates, except it never worked. He climbed the ladder at
| a well known tech company, almost to the very top, and tried
| to use those same "skills" in a startup context.
| zenlf wrote:
| I see, thank you. You would assume that one would use
| tactics accordingly.
| amelius wrote:
| Ok, so a simple solution is to compose your larger company of a
| bunch of startups that remain to operate as such, no matter what
| the larger company does. So anything that runs on top of these
| startups acts as a customer of these startups.
| nine_zeros wrote:
| At a past company, we went from 3 promotion levels to 10. There
| is a document that outlines what engineers at each level should
| be working on, much like
| https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_pr...
|
| The goal of the company was to provide standard ways to calibrate
| engineer levels for promotions and performance management.
|
| Guess what happened: Most managers started rating engineers on
| exactly that rubric. If you miss something in the rubric, you get
| a lower rating. So engineers started following the rubric
| precisely. Which meant, every senior engineer spent more time on
| managing 2-3 junior engineers. Wrote at least 1 RFC every 6
| months. And basically checked boxes on the sheet so as to not
| miss out anything during a performance review.
|
| Nothing got delivered from the team. Morale in the team dropped.
| And nothing really mattered except the career ladder document.
|
| Engineers spent more time managing the career ladder document
| than actually delivering anything.
|
| Managers spent more time rating people than actually delivering
| anything.
|
| Features were half-assed, customers started getting frustrated.
| And clueless upper management started putting more pressure on
| engineers instead of looking at themselves and asking how they
| can improve processes.
| Zetice wrote:
| > If you find an idea that you think is both valuable to the
| company and interesting to you, you can just drop everything to
| work on it.
|
| What.
|
| How is an engineer deciding what to work on like this, even at a
| small startup?!
| ajkjk wrote:
| What do you mean? They just.. Do it? Nothing about an engineer
| precludes having good sense at other things.
| Zetice wrote:
| Nothing about an engineer includes having good sense at other
| things, either.
|
| In fact, many of the best engineers are profoundly bad at
| figuring out what to work on.
| ajkjk wrote:
| Sure fine but if the question is 'how does an engineer know
| what's good to do' the answer is, "get good". Ask
| questions, learn what's important, and think about more
| than code.
| Zetice wrote:
| That's what the non-engineers are doing though, and it's
| not work everyone should do.
|
| Engineers should do engineering things at startups
| because nobody else can.
| Terretta wrote:
| > _Is this preventable? I think not. If you look closely, all
| these problems fundamentally come from..._
|
| It is preventable.
|
| I built an ISP in mid-90s, a digital agency in late 90s, another
| digital agency and a streaming CDN (world's first VDN) in 00s, as
| well as worked as chief architect for cloud at world's largest
| hedge fund and CTO of world's second largest bank. I'm currently
| an entrepreneur again, co-founding and building a hedge fund from
| scratch.
|
| My experiences across these, particularly at the digital agencies
| (where I got to help hundreds of clients go through growth) and
| the mega bank (where I got to see how things working when small
| can also work somewhere global), tell me all the goodness from
| the initial list can be built into the operating model, with a
| couple caveats.
|
| These are hard[^1]:
|
| 1. No domain versus technology divide. If you hear "The business
| wants..." or "I need I.T. to..." it's not going to work. At a
| fintech, for instance, all teams should have both fin and tech on
| the team, owning their outcomes.
|
| 2. No command and control managerialism better suited for
| piecework than building. No project managers. No scrum-masters.
| Importantly, and apparently pure heresy: _no projects_.[^2]
|
| Instead of projects, think, what should we do better?
|
| Instead of controlling for budgets and delivery dates, control
| for focus (like priorities but mostly about saying "no" to things
| instead of "yes" to everything with stack ranking) and outcome
| value (e.g. RoI or RoE instead of hitting dates). Then you can
| manage the money as investments in teams delivering outcomes,
| instead of budgets for projects.
|
| Hitting dates well becomes easy _and fun /rewarding_ when you
| scope using focus instead of pre-defining all (probably
| imperfect) requirements and you ensure teams are equipped with
| people (will, skill), and resources (tools, space) to own
| outcomes. (If people are called resources, run away.)
|
| It is preventable, and I'm happy to talk live with anyone
| building a work management tool that is interested in our
| approach.
|
| ---
|
| [^1]: see wicked problems:
| https://en.m.wikipedia.org/wiki/Wicked_problem
|
| [^2]: You can do time-boxed work with an outcome. That could look
| a lot like a project. But the word "project" tends to bring with
| it a pile of practices that all kill the intrinsic motivation for
| building things you're proud of.
|
| It's interesting even companies as smart as Linear (the Jira
| alternative, check out their Linear method pages for a lot of
| better than usual thinking) _don 't want to even listen_ why they
| should (and could just by allowing renaming a few terms in their
| tool) support a non-project-centric view of building your company
| and enjoying doing it.
| Chris2048 wrote:
| > Instead of controlling for budgets and delivery dates,
| control for focus and outcome value. Then you can manage the
| money as investments in teams delivering outcomes, instead of
| budgets for projects.
|
| Maybe if you sell to end users. If you have clients with SLAs,
| requirements etc and legal penalties for missing them, _not_
| working to delivery dates isn 't going to work. Even in teams
| with projects, ensuring deadlines are met is still tricky.
| Terretta wrote:
| See my sibling reply on projects versus time-boxes and CI/CD
| of outcomes:
|
| https://news.ycombinator.com/item?id=37100090
|
| Telling me "it isn't going to work" is why I call this
| approach "heresy".
|
| By contrast, I've observed across every size firm from 1 to
| 150,000, it does.
| liquidpele wrote:
| So... basically preventable if you have upper management with
| some balls that can enforce actual work and call out bullshit.
| Aka a unicorn ;)
| grbsh wrote:
| Wow - I've been thinking very closely to what you describe
| here, but never completely pieced it together until I read "No
| projects". You're completely right. I find that often process
| is used as an excuse to ignore outcome ownership - even if
| things didn't work out, well at least we can say we did things
| by the book. No one is at fault, and no one needs to learn from
| it.
| flappyeagle wrote:
| What pile of practices are you trying to avoid? When I see time
| boxed work with an outcome, that's the very definition of a
| project to me. There's nothing else. I had a weekend project
| building a desk. It's timeboxed to the weekend. There's an
| outcome. What am I missing?
| Terretta wrote:
| On the contrary, "time box" means the time is fixed, the work
| achieved is variable.
|
| Projects: the project comes in "on time and under budget" or
| is "late", but the work is fixed.
|
| Time boxes: The difference is if you are targeting an RoE
| curve, you can decide when to continue investing in that or
| pivot to something else. You pick a date to re-evaluate. This
| is how VC work with startups.
|
| You also make sure have minimum viable outcome well before
| that re-eval date, and then viable increments. It's
| effectively just CI/CD for outcomes!
|
| I should mention that by running a video streaming VDN, in
| the 00s we carried the world's largest streaming events white
| labeled for other CDNs. TV deadlines are real: the Oscars, or
| the State of the Union address, are happening when they
| happen. So you can have to deliver outcomes in a time frame.
| The way to always always hit that, never miss it, is let the
| work within that outcome, the "definition of done" be the
| variable. Somewhere inside the effort is a minimum viable
| outcome. Ship that, then iterate until your date or
| additional effort is below your RoE bar.
|
| Managers love to invent deadlines to "motivate" a team, and
| everyone pretends they don't know the deadlines are nonsense.
| Actual deadlines -- if you're not working, you're dead --
| teach you a different way to work.
|
| A project tries to fix both work and date, which doesn't work
| and is rarely on time.
|
| A time box fixes the date, not the work. Iterative delivery
| always hits the date and generally works.
|
| ---
|
| Using your weekend desk example:
|
| You could want a wood inlay desk.
|
| For the "job to be done", the desk has to support you doing
| work.
|
| In this toy example, the wood inlay is a desired constraint,
| not a required constraint. Business analyst will still call
| "wood inlay" a requirement, even though that "requirement"
| might lot let you ship a viable desk within the weekend.
|
| If you do the work project style, you might work the wood
| inlay for each panel before assembling them into a desk.
|
| The problem is, until you assemble it, the desk isn't a desk,
| it can't do the job to be done. If inlay takes longer than
| you thought, because it's your first time doing it and you
| had to research and built a couple test panels to throw away,
| then when the weekend is over, you have no desk.
|
| If you do it time-box style, and if "usable desk" is the
| required constraint, you might assemble the desk first, then
| do the inlay. Or you might design the desk where panels can
| be removed and inlaid whenever. Either way, if you ran out of
| weekend, you can already use the desk, just not fully inlaid.
|
| Certainly, doing the inlay after assembly will require more
| effort.
|
| So then ask yourself, was the deadline real, or was the inlay
| requirement real?
|
| If you know in advance that desk with inlay is the absolute
| requirement, you're willing to take two weekends instead of
| one, so then the deadline wasn't real.
|
| ---
|
| What's funny about this is, within a firm, everyone would
| jump on me and say the desk and the inlay are requirements.
|
| But if you don't know how to build desks, and need a vendor
| to provide it, you suddenly become tolerant of the
| differences in soft and hard requirements.
|
| Say you have to work from home, and you want a desk with
| inlay, but can't get one in time. You will iterate instead!
|
| You'll work at a table (the minimum viable desk) immediately
| and for a while, then maybe iterate to an Ikea desk while the
| custom one is ordered and hand crafted, then iterate to your
| custom desk with inlay when it arrives, with the added
| flexibility of arranging shipping to deliver when it's most
| convenient.
|
| If we handled work among groups internally the same way we
| understand we have to handle work among groups when we can't
| control them, companies would have a lot less jank.
| flappyeagle wrote:
| I understand what you're saying. I just don't understand
| what makes it a project vs. not. Fixed-scope projects,
| fixed-time projects, projects that are fixed in time and
| you have to fight the stakeholders on in scope... these are
| all projects with different features.
|
| It sounds like you prefer to work in an env where there are
| only fixed-time, variable scope projects. I like that
| better too.
| Terretta wrote:
| For the layperson definition of project, of course you're
| right.
|
| The problem is the professional definition of project,
| which comes with project management practices and
| preconceptions.
|
| Those are generally harmful, because they try to manage
| or control both time and resources needed to deliver
| unknowns _in advance_ of an inherently discovery-based
| process that results in (re-)scoping as you learn:
|
| https://en.wikipedia.org/wiki/Project_management_triangle
|
| > _It sounds like you prefer to work in an env where
| there are only fixed-time, variable scope projects. I
| like that better too._
|
| I posit it's not just "prefer", it's reality. That _all_
| "projects" are in fact "fixed time, variable scope" in
| hindsight. In other words, "it takes as long as it takes"
| to uncover and ship a minimum viable scope for the "job
| to be done".
|
| As an entrepreneur, it's preferable to create a workplace
| that acknowledges that reality up front, and designs the
| "way of working" for it.
|
| As an engineer, it's preferable, as you note, to join
| one.
|
| ---
|
| Some more musings:
|
| The OP's post says work stops being fun. A key reason why
| is all the unfortunate beliefs, management overhead, and
| recrimination for practices trying to override reality
| and failing.
|
| Small startups don't care. The cost of 5 people being
| wrong seems irrelevant compared to charging at the
| problem and getting it done, or finding out it doesn't
| work so you can pivot. How many "Show HN" are after a
| pivot? How many "Launch HN" for that matter?
|
| Enterprises care. The cost of 500, or 5000, building the
| "wrong thing" seems unacceptable (even if less cost per
| person!), so big companies keep piling on layers of risk
| management that delay getting in touch with reality.
|
| One reason they do this is the value of the outcome isn't
| clear. Perhaps it's political, perhaps it's make-work to
| keep someone's department full sized, perhaps it's a
| failure of imagination. So they develop scar tissue about
| shipping multi-year boondoggles that deliver no value.
| The problem was, it wasn't valuable in the first place,
| and if they'd just tried it out in the small and
| iterated, they'd have learned with fewer man-hours than
| all the planning.
|
| For a great take on this, see Tom DeMarco (author of
| _Peopleware_ ) rethinking his entire stance on projects
| after 50 years(!) trying to tell people how to project-
| manage better:
|
| https://www.computer.org/csdl/magazine/so/2011/06/mso2011
| 060...
|
| He even throws in the towel on estimation with the now
| famous phrase, "All projects that finish late have this
| one thing in common: they started late."
|
| He effectively accepts reality: the needful is the
| needful, the value is the value, so if it's valuable
| you'll do what you have to do, just start already and get
| it done.
|
| What I've found is, a big enterprise can understand this.
| The CEO can hold his business leaders accountable to
| telling the value that an effort should generate, the CFO
| can "venture capital" an appropriately sized investment
| in a fixed capacity team, and the team can focus to
| deliver value -- or offer a pivot -- before they run out
| of funding and can't raise another round.
|
| If they're shipping well, and getting market traction,
| the business leader looks good, the CEO is happy, and the
| CFO can continue to invest. One neat thing with this is
| the remarkable "budget" predictability that comes with
| investing in teams instead of in projects. Control your
| capacity and focus, you'll always hit your expense
| numbers, with net higher RoE as a nice side effect. So
| not only are customers getting value early, boards and
| shareholders are impressed with "hitting the numbers".
|
| So this solves that iron triangle.
|
| By continually focusing in on shipping what brings high
| RoE, you can let "the business" pick any arbitrary amount
| of time (quarterly? annually?) to announce sets of new
| features as releases. You can keep teams steady and
| employed delivering instead of wastefully scaling up then
| laying off as if tacit knowledge loss didn't have a cost.
|
| And people can feel good about building value they can
| see as they work.
| g9yuayon wrote:
| I really like the approach of Netflix of 10 years ago when it was
| still small. They hired mature people so they could get rid of
| processes. Indeed, they actually tried to de-process everything.
| As a result, things just happened. Non-event was often mentioned
| and expected in Netflix at that time. Case in point, active-
| active regions just happened in a few months. A really easy to
| use deployment tool, Asgard, just happened. The VP of CDN at that
| time said Netflix would build its own CDN and partner with ISPs.
| Well, it just happened in merely 6 months with 12 people or so.
| Netflix said it was going to support streaming and move away from
| its monolithic Tomcat app, and it just happened. And the
| engineers there? I can't speak for others but I myself had just
| one meeting a week -- our team meeting where we just casually
| chatted with each other, to the point that the team members still
| stayed close to each other and regularly meet nowadays. I also
| learned that the managers and directors had tons of meetings to
| set the right context for the team so engineers could just go
| wild and be productive. At that time, I thought it was natural,
| but it turned out it was a really high bar.
| version_five wrote:
| Importantly, this requires mature engineers _and_ managers.
| Nothing worse (from personal experience) than working at a
| place that hires experienced engineering talent and then has a
| bunch of junior "leadership" telling them what to do. That's
| how you end up inundated with meetings and frameworks and
| blablabla. Obviously you need experienced developers to get
| stuff done without handholding, but you need managers that can
| "manage" - I say coordinate, without handholding.
| aledalgrande wrote:
| This in my experience can go up to the VP level and C suite
| too in startups _cringes at bad memories_
| g9yuayon wrote:
| Absolutely. To start with, leaders must not be afraid of
| their teams making mistakes. Copying from another comment:
| "Netflix's culture demands very strong leadership and
| probably works only when the company is small enough. From
| CEO and down, leaders in every level need to know how to set
| context for their teams, give enough freedom to their teams,
| while making sure failures are manageable and success rate
| are maximized. That is, Netflix assumed that people would
| make mistakes and fail, but the trick was to ensure that
| failures do not hinder overall success of the teams and the
| company."
|
| I'll give an example of the leadership style of Netflix.
| Jordan Zimmerman, a great engineer who created Apache
| Curator, once asked then the director of cloud platform,
| Yury, if he could open source Curator. Yury just casually
| said: okay, do it. Jordan was puzzled and asked: "don't I
| have to talk to an attorney? ". Yury smiled and asked: does
| an attorney help you write code? Jordan said no, and Yury
| concluded the conversation: then you don't have to talk to an
| attorney.
| dilyevsky wrote:
| Hah I think Yury leads the Clickhouse development now. I
| interviewed with him and he seemed like a very interesting
| guy
| esafak wrote:
| > does an attorney help you write code?
|
| That does not sound like the right question. How about:
| have we vetted our dependencies' licenses?
| andrewstuart wrote:
| Man you just harshed the vibe of this free spirited
| Netflix love-in thread.
| esafak wrote:
| Don't mind me then. I think early Netflix' management
| philosophy -- as far as I know about it from the outside
| -- was exemplary. I strongly recommend _No Rules Rules:
| Netflix and the Culture of Reinvention_.
| progman32 wrote:
| I suppose that's a tangible benefit to hiring well- you
| don't have to ask your team basic questions like these.
| Presumably the engineer well knows to check licenses.
| throw3823423 wrote:
| One of the strangest experiences in my career involves
| working for a very well known startup, which had lucked out
| into an extremely high talent pool, thanks to some key early
| hires. The problem is that while they had top engineers,
| their engineering management was no good, all taken from
| companies way bigger than them. The end result is that, as
| the layers of self-entrenching management grew, basically
| every engineer left within 3 years. They went from a results-
| oriented company, to a Jira-centric organization. Fortunately
| they had a working system and good product market fit, so the
| company could keep doing well via coasting. But the extremely
| high performance organization basically disappeared due to 4
| bad hires, which then made many bad hires from their network.
|
| Hiring extremely good engineers is hard, but hiring good
| managers is far harder. They also are much better at driving
| out the good talent tan a bad engineering hire is.
| ravenstine wrote:
| In addition to your last point, an employer may have good
| engineers and not even know it if their system discourages
| excellence. A lot of what the author mentions can cause
| good engineers to coast because merely changing a string
| can be an absolute slog of PRs, spurious feedback cycles,
| and code deciphering. Cash is king, so as long as an
| engineer gets paid and isn't totally driven insane, they'll
| stay just for the paycheck. Yet the whole time the employer
| has extra talent sitting there just being wasted.
| reaperducer wrote:
| _Hiring extremely good engineers is hard, but hiring good
| managers is far harder. They also are much better at
| driving out the good talent tan a bad engineering hire is._
|
| "People join companies. They quit managers."
| bonestamp2 wrote:
| > The end result is that, as the layers of self-entrenching
| management grew, basically every engineer left within 3
| years
|
| I'm currently in this situation. Our small company was
| bought out a couple years ago. Before, we had one meeting
| every quarter and now we have at least one meeting every
| day (if not more). The managers aren't listening when I
| tell them that engineers are leaving because there are too
| many meetings. The crazy thing is that most of the meetings
| aren't even related to what we actually work on, it's
| absolutely insane.
| slotrans wrote:
| I assume these storie-lets are true but the timeline is wrong,
| it was much more than 10 years ago. I went to an Adrian
| Cockroft talk in 2012: they had thousands of engineers and
| hundreds of services at that time, Asgard already existed and
| was in the process of being open-sourced, etc.
| g9yuayon wrote:
| I joined in 2009 and left in 2014. So the timeline was
| anywhere in between.
| wavelander wrote:
| This makes a lot of sense at deep tech places that don't sell
| to enterprises where one can put their head down and just work
| on technical challenges. A similar place like Mongo DB or the
| hardware division of NVidia comes to mind. But if you're
| supposed to iterate with any input from more than 2 people that
| isn't highly objective (technical metrics that can correlate
| well with product satisfaction), communication and diffused
| collaboration is important and necessary. That doesn't mean it
| has to suck. But the Netflix model you described isn't
| applicable everywhere and shouldn't be blindly replicated.
| gervwyk wrote:
| This. In our tiny company, Lowdefy, we try to distinguish
| when something is done as part of innovation, or as a
| deliverable or chore. The work that falls into the two
| categories are vastly different in nature, stakeholder
| expectations and outcomes. Being deliberate about what
| category of work you are busy with provides freedom to thrive
| when innovating required while introducing the structure
| needed when deadlines are on the table. Mixing the two
| results in frustration and reduces quality and output. I
| would be interested to know if this applies same to larger
| orgs?
| aledalgrande wrote:
| > I really like the approach of Netflix of 10 years ago
|
| where/when did Netflix go wrong? curious to hear from insiders
| g9yuayon wrote:
| I don't know if anything went wrong afterwards. I left in
| 2014, so I only spoke for what I saw when I was there.
| [deleted]
| silentsea90 wrote:
| Wow that's so cool but makes sense! Is it not like that there
| anymore? They still hire experienced engineers, so I wonder
| what changed? As an aside, is there any low hanging fruit /
| interesting work left to do at Netflix?
| g9yuayon wrote:
| I left Netflix years ago, so I don't know their current
| culture. Netflix's culture demands very strong leadership and
| probably works only when the company is small enough. From
| CEO and down, leaders in every level need to know how to set
| context for their teams, give enough freedom to their teams,
| while making sure failures are manageable and success rate
| are maximized. That is, Netflix assumed that people would
| make mistakes and fail, but the trick was to ensure that
| failures do not hinder overall success of the teams and the
| company.
| silentsea90 wrote:
| Sounds very cool. Were failures punished by low ratings,
| bonus? How did they incentivize taking risks?
|
| Did the focus on being a leader make you stronger? Were
| Netflix employees from then valued very highly?
| g9yuayon wrote:
| > Were failures punished by low ratings, bonus?
|
| Netflix's culture stack used to say that culture is all
| about who gets rewarded and who punished. So, yes, people
| did get punished for their failures. The key here is what
| behavior led to a failure? We have to analyze consider
| the failure and the associated human behavior together
| and see if there is a lesson or a punishable pattern -
| this is where strong leadership is needed for a just
| assessment and action.
|
| There is no rating. At that time, one either their job or
| not. There was no bonus either, as bonus contradicted to
| the no-rating system.
|
| > How did they incentivize taking risks?
|
| Taking calculated risk was also part of the culture. Good
| people actually wanted to take risks. So the incentive
| systems is to take road blocks away.
|
| > Were Netflix employees from then valued very highly?
|
| I think the success of the company and the quality of the
| employees make them marketable. Everything else is
| secondary.
| aaronblohowiak wrote:
| It was a very very special place to work for a time.
| Everything changes, though, and I will leave it to say the
| Netflix I left early this year was a completely different
| place from the one I joined almost 8 years ago.
| m3kw9 wrote:
| When companies get bigger you likely don't want to use spark to
| continue building it out
| flowerpew wrote:
| If only some guy wrote about alienation from labor. That would be
| crazy.
| handsaway wrote:
| The article even reaches the conclusion that granting more
| ownership to employees might be a solution. What an idea! You
| could make a new mode of production out of this.
| ccorcos wrote:
| Another failure mode: Not being allowed to choose who you work
| with.
|
| Early on, you joined the company knowing exactly who you get to
| work with. You were probably involved in hiring for a while too.
|
| But at some point 100+, you're put on a team with people you'd
| never met, never hired, and might not vibe with.
|
| A direct, "let's hit the ground running" attitude runs up against
| a ex-FAANG person with softer personality, prefers a "compliment
| sandwich", and wants to write a 50 page technical specification
| before getting started.
| moffkalast wrote:
| How this can be made even worse is when you have a startup
| company that in principle operates like a large company because
| it wasn't founded on equal terms by all employees as a group, but
| started by one or a handful of people that fund and hire everyone
| else.
|
| There is no skin in the game as there's no stock options nor
| revenue share (founders want to keep it all for themselves ofc)
| and you can be fired on a dime without any due process, software
| proprietary and closed source of course, so you can't use it for
| your own stuff either.
|
| Only the PM spends hours on the phone talking to users and then
| gives you a direct task to work on. The task is always max
| priority and comes in randomly so you must drop whatever you were
| doing before to immediately implement it, usually getting the
| next one before the previous one is even done, making sure that
| critical tasks inevitably get forgotten and end up at the bottom
| of the backlog, leading to catastrophic software cohesiveness.
|
| Working on something you want? Haha, right. Do what you're paid
| to do, no exceptions. Coworkers of course all remote or hybrid so
| there's no meaningful cooperation and endless Jira review
| meetings to tell everyone what to do. Daily progress reports of
| course, gotta make sure people aren't slacking.
|
| The result is 100% turnover.
| esafak wrote:
| > The result is 100% turnover.
|
| Problem solved? Just be sure to leave a note online for
| potential hires to avoid the company.
| simmschi wrote:
| Companies that grow naturally form a kind of immune system that
| fights all kinds of change. That's just the way it is.
|
| I guess the lesson to be learned is to be very careful when
| scaling up your organization. Past a certain point change becomes
| very difficult. I.e. only grow headcount above 100 when you're
| certain about product market fit.
| rm_-rf_slash wrote:
| Decent analysis, but what kind of solution is "don't use Jira"
| with no alternative suggested?
|
| Jira is a fine tool in and of itself, just don't turn it into a
| religion.
| mfwgenerics wrote:
| > Most startups needlessly accelerate their corporatization by
| copying the processes of larger companies, usually by poaching
| managers from large companies who bring their playbooks with
| them.
|
| This is painfully on point.
| fallingknife wrote:
| And no one ever stops to think "is that company doing that
| thing because it's effective, or is it something that they are
| getting away with because they are big."
| naijaboiler wrote:
| Or that big companies are just solving big problems which are
| different from yours. There nothing i hate more than just
| rote copying solutions from bigger orgs
| physicsguy wrote:
| As soon as you start dealing with large customers, these things
| become inevitable. People can't start doing whatever they like
| because it becomes riskier to do it. What might be good for that
| one customer may not be good for the big customers you actually
| need to keep to make a profitable business. Big customers always
| want to know about the roadmap.
| kijin wrote:
| That depends on what kind of large customers you're doing
| business with.
|
| If a customer is large enough, and their pockets deep enough,
| you can absolutely justify building what is good only for that
| customer, and shipping it only to that customer. Keep that
| branch separate from the general-purpose product you're selling
| to the pleebs.
| zbentley wrote:
| > hire less
|
| The value of this recommendation cannot be overstated. Put
| another way: only hire when there is no other way to solve a
| problem, and even then do so carefully. Be willing to elongate
| timelines substantially as a result of this practice; the medium-
| and long-term costs of over hiring are much worse than the cost
| of later launches.
|
| Unfortunately, the funding environment and growth expectations
| for startups often incentivize the opposite behavior.
| fidotron wrote:
| Coming from Canada (and Quebec especially) it's curious to see
| a recognition of this emerge in SV. Quebec has a problem that
| historically small enterprise funding came from sources that
| require commitment to hiring plans (i.e. in two years hire
| fifty people or you get nothing), which leads to absolute
| madness, and a unsurprising lack of successful exits.
|
| I had seriously underestimated how bad the hiring situation for
| startups in SV had become though, and a lot of people are using
| them as a bench to either recover from FAANG burnout or to put
| on a resume while training for interviews. With that dynamic a
| hiring manager is going to end up leaning towards being too
| optimistic because you can't risk not noticing the few that can
| build your company. You just need to be aggressive about
| removing those that aren't working out.
| quercusa wrote:
| > _sources that require commitment to hiring plans_
|
| Are these local/provincial development funds that need to
| show job growth?
|
| Any case where "we need to hire someone in the worst way"
| seems to deliver exactly that.
| fidotron wrote:
| Precisely. Can also apply to tax credits. Luckily since the
| tax credit war race to the bottom ran out of steam this
| nonsense has been far less prominent, but for a long time
| many of the game studios in Montreal were dependent on this
| sort of thing.
|
| I regarded many of these subsidies as killing the business
| dead before it had even started, but missed that if you can
| keep it going for two years at least the managers escape
| with some decent money.
| [deleted]
| spacecadet wrote:
| Amen, less headcount more founders! Bootstrap!
| tinyhouse wrote:
| Great points. I agree with everything but I'm not sure about the
| conclusion that work will be fun for everyone. I don't think
| there will be work for everyone. The author implies that but
| saying that with AI startups can do more with fewer people, which
| I agree. The author also recommends to hire less. Yes, there will
| be more companies but the question is how the average person will
| be able to compete. If companies don't need many people they will
| become more selective.
| quickthrower2 wrote:
| In such a world progress is made faster and companies are
| solving more meta-problems. That is why people hand crafting
| html for their local businesses is no longer a thing and that
| kind of work is almost non technical now.
| fnordpiglet wrote:
| I disagree - as someone who has started up small companies and
| worked in megacorps, including FAANG and major banks, it's
| entirely possible to build that intoxicating environment
| anywhere. It's more about having a dynamic leader who assembles
| teams into collections of individuals who know precisely why they
| are there - and are given the work they excel at and the work
| they don't the manager ensures someone who does helps them. Then
| the manager has to make sure the mission of the team is crystal
| clear in its value to the mission of the enterprise and the
| enterprises mission on earth. Finally the manager has to
| relentlessly break down barriers to production and impact.
|
| The arguments articulated are entirely false: ex. N^2
| communications. This is reductionist and absurd. No team depends
| on every team in the org. Their domain is often fairly small and
| their adjacent teams extremely finite. The exception are "core
| teams" (which have been my specialty). However a well functioning
| core team doesn't have n^2 communication overhead - they act as a
| concentrator and teams come to them - which is N. N can be large,
| in which case effective triage is crucial, but so is automation
| and self service, coherent platforms that are self documented,
| and some folks on the team that really really enjoy teaching.
|
| I've burned out though on building these teams. It's absurdly
| hard work on management. But management is _supposed_ to be
| absurdly hard work. My next gig is as a distinguished engineer at
| a late stage startup - back to the roots for a while.
| angarg12 wrote:
| I agree here. The opening statement of the article is
| simplistic and inaccurate. Sure, most big corp jobs might be
| rather dull, but you can lit that spark in the right
| circumstances.
| Throw10987 wrote:
| I am the most senior engineering IC by position and years of
| experience at my current company in a 100+ person engineering
| group. The only problems I deal with are non technical and
| organisational in nature, despite on paper being expected to
| code 30 percent of the time.
| fnordpiglet wrote:
| I'm sorry - I'd advise either making your role better or
| finding a better team. They exist.
| Aurornis wrote:
| > The arguments articulated are entirely false: ex. N^2
| communications. This is reductionist and absurd
|
| I think you're being unnecessarily harsh and reductionist of
| the article's arguments. I've experienced exactly this failure
| mode in startups.
|
| The counter-example you described is an example of properly
| managing the N^2 complexity, not an example of it not existing.
| fnordpiglet wrote:
| But it doesn't exist. For any task the number of contact
| points is almost always fairly small. Just because the
| possible N might be large most are occluded by lack of
| relevance to any specific task.
|
| I would note that the author categorically says it's not
| possible for a startup like environment to exist in a large
| company. That's what I disagree with.
| commonlisp94 wrote:
| Organizations are structured as trees as a strategy to
| combat N^2 complexity. You talk up, or down. The tradeoff
| is of course N^2 relationships still exist in reality , so
| you duplicate effort, and sometimes collide, but it's a
| good tradeoff.
| halkony wrote:
| How have you developed a sense for organizational friction?
| What observations of culture can I use to make an educated
| guess about how easy it is to do my work?
|
| I agree with your point that a large org does not guarantee
| what the author claims. The author claims that the
| organizational friction can be measured by productivity,
| but you recognize culture as the better diagnostic
| criterion. The big O metaphor does not extend well to the
| argument, as you point out.
|
| I'm looking for hard hitting interview questions so I don't
| waste my time on "soul sucking" positions.
| dventimi wrote:
| > The arguments are entirely false: ex N^2 communication. No
| team depends on every [other] team in the org.
|
| From the article:
|
| "You can't just work on whatever you want; coordinating would
| be an O(N^2) communication mess."
|
| Evidently, you're agreeing with the article. So which part is
| false then?
| fnordpiglet wrote:
| That coordinating is a quadratic mess, because no task
| requires bidirectional communicating with everyone else.
|
| I also disagree with all the other points they make about
| large companies. Not that there exists teams in large
| companies that suffer these issues, but that there exists no
| teams in large companies that don't have these issues. I
| further extended it to say startups also aren't without
| issue, and many are totally screwed up. They just don't last
| very long.
| lukaszkorecki wrote:
| > The arguments articulated are entirely false
|
| I'd would disagree - I had the exact experience that the autor
| described. But you are right on this point
|
| > it's entirely possible to build that intoxicating environment
| anywhere. It's more about having a dynamic leader who assembles
| teams into collections of individuals who know precisely why
| they are there
|
| I still think it's related to size and bad incentives. I heard
| stories of people at FAANG that said that department X is like
| a startup but Y is soul sucking boredom
| fnordpiglet wrote:
| Yes, thats correct. However the existence of X department at
| all refutes the authors premise and conclusion - and if X
| exists, it's entirely possibly for Y to become better.
|
| Specifically this is entirely false due to the existence of
| X:
|
| > Is this preventable? I think not.
|
| I> f you look closely, all these problems fundamentally come
| from:
|
| > Decreased skin in the game, which reduces team alignment
|
| > N^2 communication, which creates need for managers and
| specialization, which reduces individual agency and breadth
| of learning
|
| > Reduced risk tolerance, which slows everything down
|
| > #1 and #2 are inevitable results of having more employees.
| #3 is an inevitable result of having more users, partially
| due to government regulation.
|
| I think a large company enables Y departments to exist
| without the company imploding immediately. Survivorship bias
| ensures most startups that last longer than a short amount of
| time to appear like X, when I know there are plenty of
| dysfunctional startups (a friend tells me Ghost is a great
| example). But due to the economics of a startup they
| evaporate quickly. In a large company Y departments can limp
| along for a long time or indefinitely because Y's function
| needs to exist and the company can afford for it to suck ass
| to work there without it going out of business. However
| invariably X departments in large corporations are where the
| magic happens, where people want to work, and what moves the
| large enterprise forward.
|
| I'd also note that not everyone wants to work in a startup
| environment or are able to. Many engineers got into it for a
| good paycheck and don't have much interest in anything
| particularly dynamic or engaging. They're perfectly happy
| committing once a month and sitting in meetings. That's not
| me, but I can also see when you build an army, you can't
| build it out of special forces only.
|
| So, instead of saying X can't exist, when it clearly does, I
| think it's more useful to say you should be careful where you
| work in a large company and seek out actively the X
| departments by learning what Y departments look like and how
| to spot an X department.
| dasil003 wrote:
| > _I'd also note that not everyone wants to work in a
| startup environment or are able to. Many engineers got into
| it for a good paycheck and don't have much interest in
| anything particularly dynamic or engaging._
|
| This is an excellent point. In my experience a majority of
| people value stability and predictability in their lives.
| They would rather have someone tell them what to do within
| well-structured bounds than contend with the ambiguity
| inherent in an early stage startup, or with solving massive
| product/business/technical problems with too many
| stakeholders to fit in a room.
|
| I think the challenge is the people with the intrinsic
| motivation and stomach for the ambiguity can struggle to
| grow in large corporate environments that are full of good
| soldiers who stay in their lane. It's not uncommon for
| entry level ICs to come in with 3 or 4 layers of management
| between them and VP level, and then become pawns in middle
| management games, or stuck reporting to Peter-principle
| cases who teach them all the wrong lessons.
|
| This is why I was really glad to have worked in startups
| when I was young, to really get exposed to all the moving
| parts and fundamentals of an operating business. It's just
| much easier to learn when the big picture is more legible,
| you have the latitude to iterate faster, make more
| mistakes, and see first-hand how things scale (or don't!)
| from the ground up. These days I see too many ivy league
| grad ex-FAANG who have all kinds of ideas of best practices
| with no understanding of why things are done that way at
| the tech giants, and extremely limited ability to reason
| from first principles about what makes sense in a different
| context.
| dventimi wrote:
| Would you describe your work at large companies as
| "intoxicating"?
| fnordpiglet wrote:
| Absolutely. The most exciting work I've done that has
| literally changed our world was done at systemically
| important multinational megacorps, where we created
| environments of unfettered innovation and an assembled
| teams of amazing individuals working as a coherent team.
| I had some really great leaders early in my career that
| showed it's not only possible it's the only way to enjoy
| any role at any company no matter the size. While you
| can't clone their method to work in any environment, you
| can adapt their method to any environment with enough
| energy applied. The essential secrets are the ones I
| outlined. As an IC though it's all about finding those
| leaders among the functionaries.
|
| Likewise, most of the startups I worked at were exciting
| by not intoxicating. They were relatively banal in their
| goals (change the world through prestige makeup
| e-commerce or something), their technology modern but not
| innovative, and the teams tight but not always coherent
| like a well oiled machine.
| convolvatron wrote:
| big companies have resources that give you reach
| (channels, marketing, human talent, legal, international
| presence, longer term investments) that you can never get
| with a smaller company.
|
| being able to apply them effectively can really be really
| frustrating though. and there is always the danger that
| your two year development arc will be demolished by
| 'shifts in overall strategy' or 'belt tightening' or a
| reorg.
| lifeisstillgood wrote:
| I think the best takeaway here is - don't hire until you
| absolutely have to.
| dclowd9901 wrote:
| I think that's probably still reductive -- in some environments
| (like a couple years ago), it was very hard for companies,
| especially startups, to lure in talent.
|
| Perhaps, though, if you only hire when you need, you can be
| more competitive with pay.
| geophile wrote:
| I went through this cycle a few times. My favorite, and last
| successful startup was acquired by a gigantic international
| corporation four years in (2007), and I stuck around for another
| two years.
|
| After the product shipped, the need to support customers and
| sales definitely slowed things down. Our fantastic VP of
| Engineering became CTO, and hired a middle management moron as
| VP, and that was the end of the good times. The new VP then hired
| "team players" instead of good engineers, rewarded loyalty over
| competence, and hilarity ensued. And then we were acquired.
|
| My fun startup-like time was reduced to ONE WEEK per year -- the
| week between Christmas and New Year. The rest of the year, all
| the layers of management were present and doing what they do. But
| that one week of the year, nobody was around, so I found myself
| much freer to do what _I_ thought was important. And that wasn 't
| just self indulgence, (I mean, it was, but not only), and having
| an alpha version of a shiny new thing forced the organization to
| go along.
| Aurornis wrote:
| > Our fantastic VP of Engineering became CTO, and hired a
| middle management moron as VP
|
| Hardest lesson I learned when I got promoted to upper
| leadership positions: Hiring middle management is incredibly
| hard. The number of absolute sharks in the candidate pool is
| wild. People will show up, sense that you're new, and tell you
| everything you want to hear about how they'll solve all of your
| problems. They'll claim they've done exactly what you need at
| every prior company they've worked for. They'll flatter you and
| tell you they've been waiting for an opportunity to work or
| someone like you.
|
| Imagine the schmooze-iest IC candidate you've ever interviewed,
| but 5 times better and harder to see through. These people have
| charisma you wouldn't believe (when you're new) but they don't
| really care to do the hard work. They just want to worm their
| way into the company and then _extract_. They'll extract
| compensation for themselves, extract headcount to hire their
| friends and build an empire, extract compensation for their
| friends (who will return the favor at a future company),
| extract lucrative contracts for their contracting buddies
| (where they might even be in on the take). Years can pass
| before people realize they haven't really _done_ much despite
| producing a flurry of activity. They may have even driven away
| the good employees who got tired of their BS or were pushed out
| for identifying their incompetence.
|
| I was unlucky-lucky to watch this play out under a fast rising
| CEO at a lesser known unicorn. The number of sharks who showed
| up and charmed him after he became successful was unbelievable.
| The same thing plays out with less experienced middle managers
| who get thrust into high-budget positions at smaller companies.
| esafak wrote:
| Do you have any advice on avoiding or fixing this problem?
| geophile wrote:
| It's two problems.
|
| 1) Don't hire mediocre people. We knew this new VP was
| terrible. But the guy being promoted was impatient and
| wanted someone to take over.
|
| 2) Upper management and the board must not forget the
| reason why the company exists, and put profit ahead of the
| mission. Otherwise you end up with 1980s GM, or the Boeing
| 800 Max. Read this speech by Dave Packard, a founder of HP.
| https://sriramk.com/memos/packard.pdf. A very clear,
| concise summary of how to run a company, and how to think
| about your job. And anyone who has experienced corporate
| America can immediately see that nearly no companies are
| run this way.
| xtremedata wrote:
| >> The same thing plays out with less experienced middle
| managers who get thrust into high-budget positions at smaller
| companies.
|
| Thanks for the spot-on description. You are right, the more
| money involved, the sleazier it gets. It reminds me of the
| book:
| https://www.goodreads.com/book/show/18905630-hedgehogging
|
| A highly successful hedge fund with a highly successful group
| got one of these senior managers and they managed to spends
| hundreds of millions on crazy ideas (not my money syndrome)
| while the people who actually built the machine originally
| were sidelined.
| rlifer wrote:
| Oh my god! This is like someone in my company writing about my
| org!! We offer a game platform. We have merely a few hundred
| people in the infra org. Yet we run like a 300-thousand-people
| company. Even a god-damn internal tool owned by a fucking single
| engineer in a sub-team needs to be "aligned" with other orgs. The
| Infra org, I mean the *internal" infra org, has a PM who draws
| boxes for engineers to build and has huge influence and therefore
| power over any engineer in the org. What the author writes rings
| true in every word, except item #5: "After 3 months quietly
| toiling, you ship something.". In our org, we toil for at least 3
| quarters to ship something because everyone has to be busy to
| align.
|
| A comment below says "Go from "more to gain" to "more to
| loose[sic]" thinking.", which summarizes the mentality of my org.
| If anything, it's not "more to lose", but "everything to lose",
| which saddens me greatly.
| Dirak wrote:
| > [At larger companies...] Talking to users is for PMs, silly!
| You stick to what you're good at. At best you get a summary of
| user insights and a reasonable task priority list derived from
| it. At worst you get a confusing task list built off a mistaken
| understanding of users and the manager's selfish vision, and no
| one can explain why each task matters.
|
| Not necessarily. At the large companies I've worked at (>200
| people), a UXR will drive the interview process with users,
| starting with compiling a list of questions from engineers, then
| conducting the interview sessions with users in which engineers
| can sit in, and then disseminating the insights and setting up a
| meeting to make the insights into a actionable engineering
| projects.
|
| Working with UXRs is a dream, as they're trained to conduct
| interviews in an impartial way, leading to insights that are less
| biased and higher quality. Contrast to when I worked for startups
| and I or someone on my team would interview users, very often the
| feedback would end up contaminated because the interviewer would
| ask the wrong question, projected their biases into the
| questions, or even worse into the insights.
| esafak wrote:
| Untrained people might want to read these books:
|
| * _The Mom Test: How to talk to customers & learn if your
| business is a good idea when everyone is lying to you_
|
| * _How to Measure Anything: Finding the Value of Intangibles in
| Business_.
| andrewstuart wrote:
| OK imagine you're the founder of a fast growing startup.
|
| How do you organise the software development ?
|
| What's a great way to keep it exciting and fun and productive?
| Werewolf255 wrote:
| The article mentions Rippling as still having that 'spark', but
| they've been pretty awful the past few months. Between layoffs
| and data loss, it's looked pretty dire when I've talked to them.
| [deleted]
| simon_000666 wrote:
| Love the summary, don't agree org entropy is inevitable and also
| don't agree that equity is a silver bullet. Many times the cure
| is worse than the disease, it creates a whole bunch of behavioral
| anti-patterns e.g. people sticking around too long, politics and
| grandstanding in order to win more equity. In my experience
| profit-share provides same positive incentives without the
| downsides.
| esafak wrote:
| How? Profits are short term indicators while equity is longer
| term.
| flimsypremise wrote:
| Whenever I read something like this I roll my eyes and assume the
| person writing it is either pretty junior or the specific founder
| type who has weirdly dysfunctional expectations about why their
| employees work for them. I think a lot of this stems from the
| bizarre culture of the SF tech world, but outside that bubble
| people do not really think about their jobs in this way. I
| emphasize _job_ here. The best devs I've worked with were not
| "intoxicated" with the job. They were professionals who knew what
| they were doing, were well paid for that knowledge, and outside
| of the job they had full lives with friends and personal
| interests.
|
| This sort of narrative is type of propaganda designed to get
| young, impressionable engineers to commit more of their lives to
| their job than the salary they are paid would justify. Do not do
| this if you are a young engineer. There are a lot of bosses out
| there who will take advantage of your excitement and naivete to
| utterly destroy you personal life at the expense of the business,
| but for every one of those there are others who will have the
| normal expectation of the employer/employee relationship.
| [deleted]
| spoonfeeder006 wrote:
| I am bookmarking this comment. My first job out of college was
| a great project for the world, but also at nearly grocery store
| wages. It was a small company with literally 2-3 people. The
| CEO was an old man "with no retirement" and also "2 million
| dollars in debt"
|
| Later when I offered to defer my wages until the product was
| released (it seemed he was "running out of money"), eventually
| all the trust building tactics he had used on me over the years
| were cashed out on as I gradually became disillusioned to
| realize him paying me dirt was deliberate. He could have easily
| paid me a decent wage for that work, but ultimately I met
| nothing but resistance and breadcrumbing and stonewalling when
| trying to get a decent pay
|
| "I don't have the money to pay you" he said at one point after
| the fact when I asked to be paid what he owes me. But
| afterwards and after I had rage quit, he simply hired someone
| else to start from scratch on my 2nd project after I had told
| the other developer that one thing I saw first hand working for
| him was how corporations don't care about people
|
| Granted I wasn't the fastest developer in terms of the number
| of hours I worked, and the new person he hired seems to have
| been pretty good, definitely above my level, assuming they
| implemented all the features I did. But I was getting my work
| done just fine as far as I and the other dev could tell
| louwrentius wrote:
| Just browse /r/sysadmin and the sheer number of people with a
| Messias complex, it's just stunning.
|
| "Yeah so three of my colleagues got fired so now I'm doing the
| work of four people, but my boss won't listen to me when I say
| I'm overworked".
|
| Professional people would likely been gone before the firings,
| but if this situation would have arisen, they would have set
| boundaries and negotiate what work is and isn't done within a
| normal work week. They don't let themselves get tricked or
| fooled like this. And the fun part is that management never
| even asks to take over the work.
|
| So many people are so brainwashed they care more about a
| company that would fire them without a single thought than
| their own life, it's so insane.
| toast0 wrote:
| Depends on how everything else is going, but being one person
| doing the work of four is great if you handle it well.
|
| If you do what you can get done, and go home at a reasonable
| time, it's great. You don't have to worry about justifying
| your position, or trying to find work to do, you've got a
| bunch of stuff. You can pick from your choice of tasks, cause
| there's a ton of stuff. You don't have to bother with
| knowledge transfer, cause everyone else was fired. You can
| nope out of meetings because you've got a lot of stuff to do.
| When you leave or get fired, whatever, not your problem.
|
| No need to collaborate with other contributors becauase there
| are none. Not great if you're junior, obviously.
| [deleted]
| mattmanser wrote:
| You can find them online. Dropped out of college, became a
| "founding engineer" at a start up for 4 year, now 1 year in
| another startup.
|
| Basically, drunk the kool-aid, doesn't know what they don't
| know.
| princevegeta89 wrote:
| I convinced myself these days that companies going to a size of
| more than 30 people or so automatically unavoidably switch into
| lower gears where workflows start to pile up a lot of friction,
| and politics start creeping in from all directions, thereby
| degrading satisfaction for everyone in their jobs and losing on
| the efficiency front.
|
| Not to mention the deliverability of software gets affected
| negatively with more and more contributors to code and things
| becoming "legacy". More time gets wasted on managing tasks,
| tickets, meetings, project management, and simple things end up
| taking exponentially longer now. I feel it's basically the
| killing of fun in running a startup.
| LarsDu88 wrote:
| The book Loonshots by Safi Bahcall describes this phenomena quite
| well. There's a "phase transition" of incentives at around 150
| people that can be fatal to many organizations.
|
| The secret sauce is how a startup goes past this headcount.
| Ideally many software companies quite honestly don't need more
| than 150 people!
| yousif_123123 wrote:
| When they say "100" or "150", do they usually mean total
| company size or number of engineering+product people?
| NickC25 wrote:
| Total company size. The book argues, if I recall correctly,
| that over that size, there are too many moving parts within
| the organization to be focused on anything but preservation
| of the organization at large, rather than the product or
| service the organization offers. It's been a while since I
| read the book but it was quite a good read - highly
| recommended.
| K0balt wrote:
| This argues in favor of organizations that hold close to their
| core business and allow for the additional cost of outsourcing
| non-core functions.
| mjklin wrote:
| See Miller's "Barbarians to Bureaucrats" for a description of
| the full corporate lifecycle. Barbarian -> builder -> explorer
| -> administrator -> bureaucrat -> aristocrat.
| Terretta wrote:
| See also "Dunbar's Number":
|
| _Dunbar 's number is a suggested cognitive limit to the number
| of people with whom one can maintain stable social
| relationships--relationships in which an individual knows who
| each person is and how each person relates to every other
| person._
|
| https://en.wikipedia.org/wiki/Dunbar%27s_number
|
| The world scaled past this millenia ago. You can scale your
| company past it too.
___________________________________________________________________
(page generated 2023-08-12 23:00 UTC)