Became tech lead of a startup a few months ago. Even by startup standards the codebase is poor, I don't feel any pride in working with it.
Example: the dev team took three weeks to update static text in the footer of the site and even then they gave up after 80% of the pages. Updating the footer's 'reusable component' breaks some of the templates, they can't tell why, even though they've been working with the code for months. The original contractors are of course long gone and left no docs behind.
I've gotten buy-in to clean stuff up, write stuff down, and reduce technical debt. But, of course, first we have to build a new feature, which will take at least two sprints, involve the whole stack, and used as a basis for bigger features. The codebase seems full of abandoned, half-finished features, so I got buy-in for one of the devs to spend five days exploring the code and coming up with different approaches, rather than just going with the first idea in someone's head.
On day three of five, product manager asked the dev for progress - short answer was "here are some things we could do, but haven't a clue which are any good yet as the code is a mess, had to deal with a site outage on day two, I needs more time". That evening the manager junked the spike and replaced it with a "prototype", based on one of the ideas. In doing this they, the product manager, made several technical decisions on the spot, pulling rank on me, the tech lead. From this and other incidents, I'm pretty sure the "prototype" will quickly end up going live, after a quick "does this look OK to you?" test on the dev's Macbook.
I get the whole "agile startup" thing. I get the relaxed attitude to risk and the need to get something, anything, into the hands of users last week, and worry about the consequences later. I don't mind having rank pulled on me.
But this seems the worst case of "Agile means make it up as you go along, learning from our mistakes is for losers!" I've seen. I was explicitly told "we're a startup, we're not into this investigation ****". "Research" was spoken like it was a dirty word.
Old hands may spot this is a classic case of the product being poor because the processes are poor; possibly from the org culture being poor.
How can I convince the manager there's value in some planning and forethought? Or, perhaps, should I be convincing myself that this is what this agile startup "should" be like, swallow my professional self-discipline and pride, and roll with the hacking?