- you need aligned incentives across the board. Sales and accounts mustn’t promise what the company can’t deliver
- people need to defend their area of expertise whilst listening to what others are saying about theirs. For me this boils down to a division between technical and business focussed. Techies need to push for non-client facing technical improvements without making everyone ignore them every time they say “technical debt”, and they need to accept that sometimes you just build shit to get business through the books. Sales/accounts need to accept that sometimes the build budget is taken up with mysterious technical drives that will be worth it. When I say “must accept” I mean accept that it must happen some percentage of the time - each case still needs to be backed up by a business case.
- ultimately this needs to come from the top - founder(s) must balance these facts and drive it through the whole organisation, and in the article they didn’t
I agree with what you’re saying. However given the reputation of openclaw (and I presume many other vibe coded spaghetti monsters) I appreciate the signal “I care about quality”.
This stuff is quite new to me as I’ve been learning F#, so take this with a pinch of salt. Some of the things you’d want are:
- a function to produce a list of customers
- a function or two to retrieve the data, which would be passed into the customer list function. This allows the customer list function to be independent of the data retrieval. This is essentially functional dependency injection
- a function to take a list of customers and return a list of effects: things that should happen
- this is where I wave my hands as I’m not sure of the plumbing. But the final part is something that takes the list of effects and does something with them
With the above you have a core that is ignorant of where its inputs come from and how its effects are achieved - it’s very much a pure domain model, with the messy interfaces with the outside world kept at the edges
- you need aligned incentives across the board. Sales and accounts mustn’t promise what the company can’t deliver
- people need to defend their area of expertise whilst listening to what others are saying about theirs. For me this boils down to a division between technical and business focussed. Techies need to push for non-client facing technical improvements without making everyone ignore them every time they say “technical debt”, and they need to accept that sometimes you just build shit to get business through the books. Sales/accounts need to accept that sometimes the build budget is taken up with mysterious technical drives that will be worth it. When I say “must accept” I mean accept that it must happen some percentage of the time - each case still needs to be backed up by a business case.
- ultimately this needs to come from the top - founder(s) must balance these facts and drive it through the whole organisation, and in the article they didn’t