51–60 of 85 posts
Earlier quoted context omitted.
The obvious solution is to promote them. If you don't reward loyalty don't expect loyalty.
Not everyone is great at the level above and even if they are, sometimes it is not always a good fit for them. I've had more a good few engineers ask to go backwards when they've been promoted - each for their own reasons but nearly always around the theme of being in a position of leadership / seniority.
Done this. Good question but I don't think it's the most helpful way of thinking about it. Every new recruit brings their own assumptions about how organizations / employment / etc. work and many of those assumptions won't be visible until after a while. This is especially true for managers. I found Charles Handy's thinking about four types of organisational culture very helpful and I wish I'd found it earlier in the…
The only solution I can come up with is something approximating a benevolent dictator model where the person at the top tries to remain as curious as possible about the details in their business, but is otherwise god when it comes time to make decisions. Allowing leadership to become diffuse through committees and boards of directors is where most companies go to die.
Keeping the head count small as a primary defense measure is probably the simplest thing. If you aren't comfortable with the idea of a CTO, CIO and CEO being 3 different people, then you should keep it in the low double digits. It might be better to create a wholly separate company than to grow the existing one. Outsourcing doesn't necessarily mean to another party you've never interacted with before.
[flagged]
1) ~7 people. This is when each member cannot participate in the whole context and all important decisions. "2 pizza teams", limits of the working memory. Decisions cannot be done all together anymore. This results in hierarchies forming and people worrying about their positions in them.
2) ~150 people (Dunbar's number). This is when group members cannot all know each other anymore and have meaningful relationships. Max sizes of family-based tribes, an important unit size in the army. This results in inability to observe each other's actions well, so understanding who contributes a lot vs not shifts to indirect stories. Group members start building narratives instead of demonstrating contributions directly.
We gave up on documenting the environment and just made it cloneable. Snapshot a working setup, hand it over, done. First-commit time went from ~2 weeks to a day. (fwiw I work on https://cyqle.in partly because of this)
This might not be the first to break, but it will eventually, and if corrected NOW will make things much smoother: Your documentation of processes and procedures is NOT adequate. 'everyone used to know about are getting lost' - oh good thing your documentation makes this clear, because it is obviously their fault. 'New hires take forever to ramp up' - oh good thing you have complete ramp up plan and documentation, be…
So, documentation is the solution? But do people have time to document everything?
Business. If the customer can’t feel it it doesn’t exist.
Ops. If it isn’t automated it doesn’t exist.
Product. If it isn’t documented it doesn’t exist.
Engineering. If it isn’t in code it doesn’t exist.
You have an opinion about security? Have you written a linter? Is it documented? Is it in the deployment pipeline? Do customers care?
If it’s only in your brain I don’t accept it and refer you back to the existence rules.
Earlier quoted context omitted.
So, documentation is the solution? But do people have time to document everything?
> But do people have time to document everything And to read everything. And to find it. I find documentation is often meaningless or worse -- in networks you find people documenting IP addresses on static pages like confluence pages or powerpoint presentations. That isn't important. Sure it should be in a single source of truth -- emphasis on the single -- but if isn't, it's not the end of the world. A new employee…