Chief Mentor @ learnwithparam.com | Helping software engineers become AI powerhouses through hands-on workshops & bootcamps 🚀 | Mentoring & consulting teams to turn ideas into AI products → impact 🙌
They do matter but depends on the scale of the company.
In a early stage startup, everyone does everything to keep moving faster (hustle culture)
Once the startup scales, the maturity of the organisation will grow and it requires formal structure to avoid egos in slowing down the decision making process.
In scaleups, everyone will start to work more towards their role and align the responsibilities based on their role.
Senior DevOps Engineer with 11+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
I concur with you but believe the individual role responsibilities with the designated titles should be streamlined in an early stage itself. Restructuring it when the startup scales to a bigger team can lead to a lot of friction as members used to the hustle culture might find the whole activity very restrictive and oppose it.
What are the practical ways you've experienced to make this formalisation smoother?
Chief Mentor @ learnwithparam.com | Helping software engineers become AI powerhouses through hands-on workshops & bootcamps 🚀 | Mentoring & consulting teams to turn ideas into AI products → impact 🙌
Scaling of teams will always bring challenges but usually early stage engineers who stay longer will start to lead either as manager (engineering manager, site reliability lead) or as individual contributors(staff, principal engineers) if the company is growing.
So they will eventually end up hustling within their area or scope or projects assigned to them.
Problems start to arise if product/company growth didn’t scale as fast as the codebase complexity. Then it will be a mess that you will need specialist to clean things up and minimise tech debts but eventually you can’t hire more or promote within since you need to continue building due to budget constraints.
Every teams face different scaling challenges, I just stated one such example here.
There are companies which scaled too fast due to sudden peak in growth and eventually failed to build proper engineering culture to make it work too. They also struggle because of too many individual superstars who can’t act as a team.
Senior DevOps Engineer with 11+ years of experience. Otherwise an avid artist, reader, cinephile & football fan. Looking forward to connecting with everyone :)
Very valid points indeed. This is why formalising structures across engineering like naming conventions, Architecture Decision Records, Pull Request Formats, other applicable workflow standards are better when set and adhered early on.
A stitch in time always save nine and it's more true regarding the reduction of tech debt. Otherwise recurrences of Murphy's Law will be seen in action every now and then.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
They do matter but depends on the scale of the company.
In a early stage startup, everyone does everything to keep moving faster (hustle culture)
Once the startup scales, the maturity of the organisation will grow and it requires formal structure to avoid egos in slowing down the decision making process.
In scaleups, everyone will start to work more towards their role and align the responsibilities based on their role.
That's an interesting viewpoint, Paramanantham.
I concur with you but believe the individual role responsibilities with the designated titles should be streamlined in an early stage itself. Restructuring it when the startup scales to a bigger team can lead to a lot of friction as members used to the hustle culture might find the whole activity very restrictive and oppose it.
What are the practical ways you've experienced to make this formalisation smoother?
Scaling of teams will always bring challenges but usually early stage engineers who stay longer will start to lead either as manager (engineering manager, site reliability lead) or as individual contributors(staff, principal engineers) if the company is growing.
So they will eventually end up hustling within their area or scope or projects assigned to them.
Problems start to arise if product/company growth didn’t scale as fast as the codebase complexity. Then it will be a mess that you will need specialist to clean things up and minimise tech debts but eventually you can’t hire more or promote within since you need to continue building due to budget constraints.
Every teams face different scaling challenges, I just stated one such example here.
There are companies which scaled too fast due to sudden peak in growth and eventually failed to build proper engineering culture to make it work too. They also struggle because of too many individual superstars who can’t act as a team.
Very valid points indeed. This is why formalising structures across engineering like naming conventions, Architecture Decision Records, Pull Request Formats, other applicable workflow standards are better when set and adhered early on.
A stitch in time always save nine and it's more true regarding the reduction of tech debt. Otherwise recurrences of Murphy's Law will be seen in action every now and then.