5 ms·

I fully agree with this, but I think it misses a key step: As the team’s manager, it’s your job to get buy-in from the executives to gradually fix the mess. Yo

I fully agree with this, but I think it misses a key step: As the team’s manager, it’s your job to get buy-in from the executives to gradually fix the mess. You don’t need to tell the team exactly how to fix it, but you gotta get buy-in for space to fix it. One approach is just to say “every Friday goes to adding tests!” (And then when there’s some reasonable test coverage, make fridays go to refactoring that are easy with the new tests, and so on). But this often fails because when Friday comes, something is on fire and management asks to please quickly squeeze this one thing in first. The only other approach I know of is to get buy in for shipping every change slightly slower, and making the code touched by that change better. Eg they want to add feature X, ok add a test for adjacent existing functionality Y, then maybe make Y a little better, just so adding X will be easier, then build X, also with tests. Enthusiastically celebrate that not only X got shipped but Y also got made better. If the team is change averse, it’s because they’re risk averse. Likely with good reason, ask for anecdotes to figure out where it comes from. They need to see that risk can be reduced and that execs can be reasonable. You need the buy-in, both from the execs and the team. Things will go slightly slower in the beginning and it’s worth it. Only you can make sell this. The metaphor of “paying off technical debt” is useful here since interest is sky high and you want to bring it under control.

more_corn 4y ago
Not the team’s manager. OP says so in the first line.
hrbf 4y ago
Before anything else, getting buy-in for any kind of major change from the execs is key. Explain the situation and the effects. Have everything in writing, complete with date and signatures. Push back hard every time this commitment gets sabotaged because something is supposedly on fire. Get a guaranteed budget for external trainings and workshops, again in writing. Then talk to the team. If you cannot get those commitments in writing, or later on get ignored multiple times: run. Your energy and sanity is better spent elsewhere. No need to fight an uphill battle alone – and for what? The company just revealed itself for what it is and you have no future there. First I’d do that, then think about the engineering part.
- vermasque 4y ago
  "Have everything in writing, complete with date and signatures" It is possible that the executives won't take it well to all of the formality here (writing and signatures). How would you convince them that this is necessary?
  - ethbr0 4y ago
    Dates and signatures are theatrical overkill. I've yet to work at a place where meeting minutes, sent out to all attendees post-meeting, aren't sufficient for the same purpose (ass covering & continued adherence to The Plan as originally agreed). I'm sure signature and date places do exist... but, I'd probably be looking for a new job if I worked at one.
  - scarab92 4y ago
    "Have everything in writing" is a bad mindset and is not going to save you. Exeutives are looking at you as the expert to deliver a good outcome. Which means making good decisions, managing expectations and keeping everyone in the loop. Generally, if it gets to the point of having to dig up who signed off on what, you've already failed. Often you won't even get the chance to dig up those emails, because delivering a bad outcome is enough for execs to write you off without even needing to hear your excuses.
    - pdimitar 4y ago
      > because delivering a bad outcome is enough for execs to write you off without even needing to hear your excuses. What makes you think they are excuses? Constantly chasing moving targets and not having even one of them agreed upon in writing is heaven for bad execs. I've seen it happen a good amount of times, my colleagues too. I don't view the "you changed requirements 20 times the last month and I can't keep up with your impossible imagined schedule" statement as an excuse.
      - jwatte 4y ago
        If the goal is to remove bad execs, then a document trail can help, although I'd suggest starting with some statistics like "over the last 3 months, we moved the goalpost 8 times, which led to an effective throughput of 4 weeks of work being done rather than the expected 12 weeks. How do you think we could improve these conditions?" Collaboration first. Keeping email threads for reference is probably plenty data enough, btw; "signatures" sounds like the wrong approach. Maybe even just summarize the direction given in a wiki document with a change log with time stamps and requesting person, which you can review once in a while, and the sheer length of it might be enough to bring the point across.
bcrosby95 4y ago
> But this often fails because when Friday comes, something is on fire and management asks to please quickly squeeze this one thing in first. There's a solution to this problem: nothing goes live on Fridays. > and making the code touched by that change better. Getting buy-in from management on this always appeared to me as weird. The alternative is a codebase that can only ever get worse over time. So you either gotta gold plate everything, which will take way longer than allowing for some after-the-fact improvement as needed, or your codebase turns into a pile of shit very quickly and your velocity grinds to a halt very quickly.
- pdimitar 4y ago
  > Getting buy-in from management on this always appeared to me as weird. The alternative is a codebase that can only ever get worse over time. Well that's just the thing: they have no notion of a "bad code base". To them that's an excuse and a negotiation leverage by the programmer to ask for more money. They judge others by themselves I guess.
  - bcrosby95 4y ago
    It just feels like an amateur hour thing. If my plumber came to me to ask if he can just dry assemble the pipes and leave them that way I'm gonna get a new plumber.
    - pdimitar 4y ago
      It's scary out there, man. A lot of people in HN judge by US companies and startups but I've only been in that bubble once for a few months and the rest of my 20 years of career has been everywhere else. And it's insanely bad in many places.
    - jgabriels 4y ago
      That’s assuming you know something about plumbing. If you don’t, you’ll just nod your head and say ok, that sounds good. The same thing is happening in these businesses. The business owners generally don’t know programming. Terms like “refactoring” mean nothing to them at best and sounds like “rewrite from scratch” at worst.
treeman79 4y ago
Do not waste time with a company that is going to collapse unless they are willing to do whatever it takes.
- noobermin 4y ago
  They are going to collapse making 20M a year, sure.
  - netb 4y ago
    Revenue is not profit

more_corn 4y ago

Not the team’s manager. OP says so in the first line.

hrbf 4y ago

Before anything else, getting buy-in for any kind of major change from the execs is key. Explain the situation and the effects. Have everything in writing, complete with date and signatures. Push back hard every time this commitment gets sabotaged because something is supposedly on fire. Get a guaranteed budget for external trainings and workshops, again in writing. Then talk to the team. If you cannot get those commitments in writing, or later on get ignored multiple times: run. Your energy and sanity is better spent elsewhere. No need to fight an uphill battle alone – and for what? The company just revealed itself for what it is and you have no future there. First I’d do that, then think about the engineering part.

vermasque 4y ago
"Have everything in writing, complete with date and signatures" It is possible that the executives won't take it well to all of the formality here (writing and signatures). How would you convince them that this is necessary?
- ethbr0 4y ago
  Dates and signatures are theatrical overkill. I've yet to work at a place where meeting minutes, sent out to all attendees post-meeting, aren't sufficient for the same purpose (ass covering & continued adherence to The Plan as originally agreed). I'm sure signature and date places do exist... but, I'd probably be looking for a new job if I worked at one.
- scarab92 4y ago
  "Have everything in writing" is a bad mindset and is not going to save you. Exeutives are looking at you as the expert to deliver a good outcome. Which means making good decisions, managing expectations and keeping everyone in the loop. Generally, if it gets to the point of having to dig up who signed off on what, you've already failed. Often you won't even get the chance to dig up those emails, because delivering a bad outcome is enough for execs to write you off without even needing to hear your excuses.
  - pdimitar 4y ago
    > because delivering a bad outcome is enough for execs to write you off without even needing to hear your excuses. What makes you think they are excuses? Constantly chasing moving targets and not having even one of them agreed upon in writing is heaven for bad execs. I've seen it happen a good amount of times, my colleagues too. I don't view the "you changed requirements 20 times the last month and I can't keep up with your impossible imagined schedule" statement as an excuse.
    - jwatte 4y ago
      If the goal is to remove bad execs, then a document trail can help, although I'd suggest starting with some statistics like "over the last 3 months, we moved the goalpost 8 times, which led to an effective throughput of 4 weeks of work being done rather than the expected 12 weeks. How do you think we could improve these conditions?" Collaboration first. Keeping email threads for reference is probably plenty data enough, btw; "signatures" sounds like the wrong approach. Maybe even just summarize the direction given in a wiki document with a change log with time stamps and requesting person, which you can review once in a while, and the sheer length of it might be enough to bring the point across.

bcrosby95 4y ago

> But this often fails because when Friday comes, something is on fire and management asks to please quickly squeeze this one thing in first. There's a solution to this problem: nothing goes live on Fridays. > and making the code touched by that change better. Getting buy-in from management on this always appeared to me as weird. The alternative is a codebase that can only ever get worse over time. So you either gotta gold plate everything, which will take way longer than allowing for some after-the-fact improvement as needed, or your codebase turns into a pile of shit very quickly and your velocity grinds to a halt very quickly.

pdimitar 4y ago
> Getting buy-in from management on this always appeared to me as weird. The alternative is a codebase that can only ever get worse over time. Well that's just the thing: they have no notion of a "bad code base". To them that's an excuse and a negotiation leverage by the programmer to ask for more money. They judge others by themselves I guess.
- bcrosby95 4y ago
  It just feels like an amateur hour thing. If my plumber came to me to ask if he can just dry assemble the pipes and leave them that way I'm gonna get a new plumber.
  - pdimitar 4y ago
    It's scary out there, man. A lot of people in HN judge by US companies and startups but I've only been in that bubble once for a few months and the rest of my 20 years of career has been everywhere else. And it's insanely bad in many places.
  - jgabriels 4y ago
    That’s assuming you know something about plumbing. If you don’t, you’ll just nod your head and say ok, that sounds good. The same thing is happening in these businesses. The business owners generally don’t know programming. Terms like “refactoring” mean nothing to them at best and sounds like “rewrite from scratch” at worst.

treeman79 4y ago

Do not waste time with a company that is going to collapse unless they are willing to do whatever it takes.

noobermin 4y ago
They are going to collapse making 20M a year, sure.
- netb 4y ago
  Revenue is not profit