[HN Gopher] When Everything Is Important but Nothing Is Getting ...
___________________________________________________________________
When Everything Is Important but Nothing Is Getting Done
Author : goopthink
Score : 153 points
Date : 2022-05-23 17:17 UTC (5 hours ago)
(HTM) web link (sharedphysics.com)
(TXT) w3m dump (sharedphysics.com)
| seydor wrote:
| When Everything is Grey but Nothing is Getting Read
| lbriner wrote:
| Lots of really good points in here. I have worked at various
| companies who have struggled after the initial growth. Hubris can
| take over and we feel the need to over-extend, to sit at the big-
| boys table, to court the corporates with their fat (but very
| tight) wallets.
|
| I think a common cause is simply fear. There is a lot at stake
| when you have 50+ employees. Maybe those one or two markets are
| not big enough to support what we need any more so instead of
| razor focus and discipline which helps, we try and build
| everything for everyone and a lot of it is simply wasted effort.
| We also start having teams so instead of a design decision being
| taken by the entire management (and can get shouted down), it
| just gets done because "the design team" regardless of the value
| it is actually adding or not.
|
| In extremis, we see the FANG companies who have so many
| engineering staff, we can only hypothesize about what most of
| these people even do for 40 hours per week on massive salaries.
| goopthink wrote:
| OP here -- something I didn't touch on is that this is really
| common when a company transitions from early-stage to mid
| stage. The operations of a small company and the operations of
| a mid size company (and the operations of a large company) are
| completely different. The problems start to happen there is a
| mismatch between what you are and what you think you are. If
| you implement big-company practices for a small startup, you're
| often going to be overburdening the team and losing agility.
| When you are a med/large company but operating like a small
| company, you'll see chaos and inefficiency. Part of the problem
| is that there's no clear line. Observant engineering and
| product leaders tend to have an intuition for when practices
| need to change... I think team size and revenue/contract size
| (for B2B) are good heuristics. But more often than not, it's a
| stumble through the transition and folks feel the pain before
| figuring out the solution.
| dcow wrote:
| > Part of the problem is that there's no clear line.
|
| This is what baffles/wonders me about the state of the art in
| building companies. It seems so anecdotal and ad-hoc. Case
| studies and good advice, while they exist, are from "previous
| generations" and "we do it differently" because "culture". It
| feels like society has to continuously reinvent solutions to
| managing people and projects rather than building upon proven
| and effective strategies. I guess, perhaps, I am betraying my
| own lack of knowledge of this domain. Maybe there are tried
| and true tactics and I've just never experienced them.
| Related, it really feels like there should be a sub-field of
| "sociology" set on improving the efficiency of groups of
| humans using objective methodology that yields consistent and
| reliable results...
| sumanthvepa wrote:
| > it feels like there should be a sub-field of "sociology"
| set on improving the efficiency groups of humans
|
| Yes there is. Its called organisational behaviour. Most
| b-schools have some faculty specialising in it. Cornell,I
| think, has a whole department in the school of Industrial
| and Labor Relations. They're pretty good.
| bombcar wrote:
| I wonder how much lost productivity comes from people saying
| "if only it had feature X" to salesmen to be polite instead of
| a simple "we're not interested and won't be buying".
| mason55 wrote:
| It's the difference between being a feature factory and
| having a real product strategy.
|
| If you actually have some kind of customer in mind, and you
| have ideas of problems that you're solving for them, then
| this can be valuable feedback _even if it 's a lie._ Digging
| into the feature might expose you to a new customer problem
| that weren't aware of. You can talk to other customers and
| prospects and understand if this is a problem they have as
| well. You can take that information and extrapolate it into a
| real set of use cases, think about the size of the market of
| "customers who have this problem," and decide if it's
| something that makes sense to tackle with your product. Then
| you can design features to solve the real problem.
|
| If you just have a feature factory then all you'll do is
| build the feature as the prospect specified. You'll go back,
| they'll still say no, and now you have no idea how to market
| this feature or if it would even be useful for anyone else or
| it's just built around the customer's internal process.
| goopthink wrote:
| "The Mom Test" is an _awesome_ look at that -- how bad
| questions and worse feedback leads to a lot of wasted effort.
| Highly recommend it. http://momtestbook.com/
| perlgeek wrote:
| > Be really careful with the yellows: if there is low impact, you
| might be confusing work for progress. If there is low urgency,
| you might be overestimaging the value of your work.
|
| On the flipside, if only high-urgency projects get done, you end
| up becoming a 500+ employee IT service provider without a proper
| Identity and Access Management System (IAM), without a Privileged
| Access Management system (PAM), a haphazard, ad-hoc secrets store
| and so on.
|
| That's all fine and good for a 10-person company, you can get by
| like that when you're 100, above 200 maybe it starts to get
| icky...
|
| Yes, I understand that if really nothing progresses, you have to
| prioritize ruthlessly, but you cannot keep doing only high
| urgency projects forever.
| ketzo wrote:
| No real comment other than damn, what a solid-gold piece of
| writing and advice. Felt like I was just nodding along to every
| other sentence. Awesome stuff.
|
| I particularly liked breaking down "priority" into the
| intersection of urgency and impact.
| eastbayjake wrote:
| This was a really great article and case study. The problems (and
| eventual solutions) will be familiar and unsurprising to readers
| of _The Phoenix Project_ : https://itrevolution.com/the-phoenix-
| project/
| SemanticStrengh wrote:
| hey that's called modern physics open-problems
| marktangotango wrote:
| After the MVP is found, then the real work begins in building a
| company. We all understand that if everything is a priority, then
| nothing is, but often times, business resources don't. Support
| wants bugs fixed to keep customers happy and to re-sign. Sales
| whats features to land their whales. Engineering wants to work
| off tech debt, refine, and innovate. Etc.. I've found that a
| formal "Intake" process works wonders. Engineering needs an
| advocate to take these disparate priorities and refine what, when
| and how to address. It's really that simple, and that complex.
| Finding someone to own it. Sometimes it's impossible depending on
| the Org and personalities involved.
| jrvarela56 wrote:
| Think you nailed it by breaking it up by groups of people with
| different lists.
|
| Literally every group/dept/team has a list. Someone/process has
| to arrange that into a single list for the group that builds.
| If you have more than one group that builds stuff, then more
| output lists and more complex the transformation from input
| lists to output lists.
|
| Guess this is a simplistic summary of what PMs and Eng managers
| do.
| hinkley wrote:
| > Engineering wants to work off tech debt, refine, and
| innovate.
|
| I know I'm not the only one who is backing away slowly from the
| concept of tech debt, and I'm not the only one trying to drag
| other people with me.
|
| Tech debt has turned into hippie-dippie bullshit in the minds
| of many people. It was an attempt at enlightened self interest
| by appealing to the bean counters, but if you're talking to
| bean counters you've already lost.
|
| The developers want easy things to be easy so they don't have
| to spend half their time slogging through code that does
| everything the wrong way, half their time explaining why
| everything takes so long (heading toward infinity), and half
| their time implementing new functionality. And yes that's 3/2
| which is why we have people doing 60 hour work weeks.
|
| A long time ago I saw a speaker claim that it's not tech debt,
| it's wear and tear. I don't know if I agree entirely with that
| characterization, but I definitely think that it's less wrong.
| opportune wrote:
| Tech debt is too general a term to be useful.
|
| A lot of what people call tech debt is just working code that
| they don't understand (maybe because all of the people that
| did understand it are now gone). Or it's complex, which may
| just be because it's dealing with a complex issue and
| accumulated lots of bug fixes over time. Or tech debt is just
| nitpicky design choices which may very well be not-great but
| aren't actually causing any problems. None of that is worth
| investing in beyond a fix-as-you-go, in my opinion, due to
| there usually being problems to solve with much greater
| business impact.
|
| On the other hand, you have tech debt like: a complex set of
| dependencies/services with poor interfaces that makes what
| should be simple changes very complex and risky. Something
| implemented so inefficiently that it's slow enough to impact
| UX or wastes a lot of computing resources ($$$). Or code that
| is just so, so bad that making any change is like walking in
| a minefield - and while a lot of engineers are way too quick
| to put code in this bucket, I do think it's possible (eg a
| complete ball of mud application with tons of global state,
| very poorly applied concurrency patterns, extreme lack of
| parameterization in favor of copy-paste).
|
| That said, I have often seen "tech debt" used as a
| rationalization to work on some nitpick with no business
| impact and without a clear improvement. In my opinion, this
| is partially because working on such tech debt can be very
| easy: it doesn't require understanding more complex business
| requirements, it might be very easy to test with existing
| integration tests, it has little risk to production, and it
| doesn't have task/planning dependencies with other people.
| goopthink wrote:
| OP here. We had a _lot_ of discussion about where Tech Debt
| falls on the spectrum of projects to work on. That merits its
| own post. But the gist of it is that resolving tech debt has
| value. The challenge is that most engineering organizations
| are awful at describing and communicating that value.
|
| For example: "If we refactor this code and migrate to a new
| server, we'll be able to deploy in 15 minutes instead of 6
| hours, and we'll be able to ship features faster to customers
| with lower risk. This means that we'll get back ~90h of
| engineering time per week (6 hours x 5 people x 3 teams), and
| our defect rate will go down by 50% (We see 10% of customers
| churn due to preventable defects).. Therefore, there is
| $702,000 savings in engineering efficiency (more time
| available) and would decrease churn by 10%, resulting in [X]
| more value retained."
|
| Once our engineering team started thinking about the business
| case for why tech debt should be prioritized, they started to
| make really compelling arguments for why something needed to
| be worked on, and we could evaluate it against explicit
| business/feature requests. This value rolled up into the form
| of decreasing costs or increasing revenue.
|
| Again: resolving tech debt has value, and the engineering
| _leadership_ needs to work on figuring out what that value is
| and how it stacks up against all of the other valuable work
| that the company wants to do to grow. Engineering leaders who
| don 't understand this often struggle at the executive level
| and ultimately fail the teams they represent.
| cgio wrote:
| Once the engineering team started thinking about business
| cases, they started wasting time they could be dedicating
| to engineering. I know where you come from, on a similar
| journey, but when things don't work, adding things to do is
| the worst option.
| yen223 wrote:
| The problem I think is engineering haven't figured out good
| ways to measure software productivity, and so it's very
| hard to make the kinds of estimates that we need to
| properly justify work that otherwise delivers zero
| immediate business value.
|
| (I also suspect that not all refactoring work is equal, and
| that most refactoring work don't result in any positive
| engineering or business improvements.)
| babyshake wrote:
| Easy, you just measure the lines of code added. More code
| means more productive.
| goopthink wrote:
| This is very fair! We used a few guide posts:
|
| - 1: Keep asking "why is this valuable" until you get to
| the money questions. It's often a few layers deep. Not
| being able to get at that (missing an ability to
| quantify) was in itself something that engineering
| leadership needed to work on. After all -- how can you
| prioritize between two things if you can't figure out
| what value they create?
|
| - 2: Most engineering teams know that they might be able
| to save some time by refactoring. We figured out the
| average hourly cost of engineering effort and used that
| as a multiplier for time saved by a new project's
| implementation. You can take it a step further and
| subtract the cost of working on a project from the time
| it ultimately saves you to remove "dumb" refactors that
| take longer to deliver than time they save.
|
| - 3: If you can't get to a tech debt's value, that's a
| red flag as to if it actually creates value. This was
| true for features and business requests as well. We also
| said no to features that "felt good" but ultimately
| created zero value (some redesigns included). "Rewriting
| something in a new language" because a new sr manager
| with strong preferences joined the team was a big culprit
| of these sorts of projects.
|
| - 4: We also often asked if a tech debt project needed to
| be done independently of other work, or if it could be
| included as part of a new feature that we were working
| on. An example was that one team pitched rewriting a
| microservice because it had no API. On the other side of
| the company, we had a project to get rid of that feature
| entirely and replace it with a different functionality.
| If tech debt projects were handled entirely within the
| domain of engineering, we would have spent weeks
| rewriting something _only to throw it away a month
| later_. Hence the need for bubbling tech debt up to the
| single stack rank, and thus treating tech debt projects
| the same as any other project we were working on (with
| appropriate visibility, buy-in, and evaluation of value
| /urgency).
| RugnirViking wrote:
| Reading these comments and replies has me very
| interested. I think talking about technical debts and
| ways of quantifying it is definitely worth another post.
| I'd read it!
| pgwhalen wrote:
| > A long time ago I saw a speaker claim that it's not tech
| debt, it's wear and tear.
|
| It sounds like you agree with the idea in general, but just
| don't like the current metaphor. Can you expand on what about
| this alternate metaphor fits the phenomenon better?
| dvtrn wrote:
| I've found myself holding a bit of chagrin at the term
| 'technical debt' lately as well, mostly because it feels like
| saying it, pointing to it, quantifying it, and shoving 'it'
| under people's noses and proving its there (not to mention
| the usual ceremonies of what I'd like to do about it) isn't
| doing me any favors anymore.
|
| And at that point....
|
| ....I don't know that simply calling it something else is
| going to help.
|
| _Yes I 'm a bit jaded, grab a drink, next one's on me_
| user3939382 wrote:
| My analysis is that the problem is "tech debt is bad". Just
| like real debt, there are times when you sign your name to it
| on purpose because it's a good decision. For example, early
| on in a project when the requirements are fuzzy and
| undiscovered.
|
| Like financial debt, you pay interest on tech debt, so you do
| want to strategically pay it down when the stars align, maybe
| you've recently put out some new features, and you can buy
| the political capital with customers (and by extension,
| management).
|
| Debt isn't a bad analogy but an appreciation for the nuance
| would be nice, I don't commonly see that.
| shkkmo wrote:
| Technical debt is unavoidable, but letting technical debt
| grow without managing it is a great way to kill a project.
|
| Explaining the benefits of paying down particlar pieces of
| technical debt is important, but another important piece of
| the puzzle is talking in advance with stakeholders about
| when, where and how much technical debt you want to take on
| to launch a product. When the existence of technical debt
| isn't talked about until it needs to be repaid and thus
| comes as a surprise, the conversation becomes a lot harder.
| Additionally many of the decisions about how much technical
| debt to take on to launch something can be improved by
| bringing stakeholders directly into the conversation, at
| least on a general level.
| mason55 wrote:
| This is one of the main things a good leader should be doing.
| Not just execs, but up and down the chain, one of the most
| valuable things a leader can do is get everyone pointed in the
| right direction. Make decisions about priorities, communicate
| those decisions to the team and the rest of the org, and then
| commit to getting them done. Ruthlessly prioritize and be
| willing to say no.
|
| It's not actually easy, for a number of reasons. One is
| organizational. If your boss isn't doing the same then then
| it's going to be harder for you to do it. If you're responsible
| to multiple people who don't have any common chain of command
| then it's going to be really hard. And it involves saying "no"
| and standing your ground.
| mandeepj wrote:
| To those who are interviewing these days for a leadership
| position, the article has details for answering questions related
| to managing conflicting\multiple priorities
___________________________________________________________________
(page generated 2022-05-23 23:00 UTC)