4 ms·
That works for things you want to DO, but is hard for things you DON'T want to do. As I mentioned in another post, as your org grows, there's going to be an in
by shados 7y ago
That works for things you want to DO, but is hard for things you DON'T want to do.
As I mentioned in another post, as your org grows, there's going to be an infinite amount of things people push, and pushing back is hard. If you have to stop and write a consensus document for every single one, you'll be doing nothing else.
- icxa 7y agoHow hard is it to say "these are the types of things we want to do. anything must look like these types of things in terms of (insert x y and z criteria: size, scale, opportunity, profitability, growth, etc) spoiler alert: it isn't hard and this is what we do at my startup that is currently experiencing hyper growth and is on multiple "unicorn" lists
- drunkpotato 7y agoAhh hahahahahahaha! Sorry. I had a more substantive comment but it drowned in ignorance and inexperience.
- stringyham 7y agoYou could have just refrained from posting.
- shados 7y agoI can't even tell if it's satire. But if it's not: I haven't see it be done easily over several hundred engineers. If you have that kind of charisma, hat off to you!
- icxa 7y agoCharisma is certainly something I have never been told I lack. Maybe we are lucky and have the right people as well.
- novok 7y agoWith things you don't want to do, you make it concise with a whitelist. Like 'we only use these 2 languages for our backend and here is why:'. If you have the authority to tell people no in the first place to make it stick, you have the ability to write that in a wiki page. You can go full FAQ mode for the miscellaneous stuff as it comes up. Documenting the why is really important, so you don't get zombie decisions self perpetuating in your org and allow for change.