81–90 of 316 posts
I suspect that the author has never actually worked in a flat organizations, it's been my experience that flat organizations have way, way more problems than "too many managers."
Most of these, I think, relate to a single kinda-meta-problem. Managing software orgs is hard, and most orgs can't do it well. Using additional management methods, more managers, and more engineers can make the software org less efficient. Software production is weird. Efficiency of software orgs is extremely plastic. An effective 15 person team can outperform a 150 person team and this is normal. Very extreme compar…
I think there's a sweet spot that's particular to each project and collective skill set. Being in a small team and feeling anxious due being responsible for way too much stuff isn't fun as well.
What does this even mean? I've never heard of a forecast that didn't use a combination of past data and an assessment of complexity of future work to assemble the forecast.
And assessment of complexity is the heart of estimation.
Can anyone help me because my imagination is failing me here.
Granted, speaking as someone running a very small shop, mostly freelance, I really think a lot of the ennui and sense of being overwhelmed or unsatisfied can be solved by just deploying constantly. Rather than get stuck in a review cycle I try to get every incremental change online as soon as it's done and minimally tested. That can be up to six live redeployments per day, especially when a new feature is in beta. It…
It astounds me how some companies will let months of work sit in an unmerged PR and then sometimes decide they don't even want it. Not only is it a massive waste of resources, its shit for the person who built it, and also sucks if you actually do have to merge it and resolve months of merge conflicts.
Granted, speaking as someone running a very small shop, mostly freelance, I really think a lot of the ennui and sense of being overwhelmed or unsatisfied can be solved by just deploying constantly. Rather than get stuck in a review cycle I try to get every incremental change online as soon as it's done and minimally tested. That can be up to six live redeployments per day, especially when a new feature is in beta. It…
It astounds me how some companies will let months of work sit in an unmerged PR and then sometimes decide they don't even want it. Not only is it a massive waste of resources, its shit for the person who built it, and also sucks if you actually do have to merge it and resolve months of merge conflicts.
"What makes engineers sad? Their boss(engineering managers, Directors, VP’s) do not know what they face on a day to day basis and does not know how to build something, whether it is a feature or architecting something from scratch." If that's true, then it's probably mutual. Engineers typically do not realize that their manager's role is to manage people and process (which is a bit of a specialization in itself), and…
Do you think someone is qualified to manage a process they don't understand?
1) Rampant tech debt. Engineers are not empowered to fix it or their focus is on something else.
2) High barrier of entry. Most SaaS companies are bad at onboarding engineers or they simply don't care, usually because C-level staff and investors work towards sales metrics.
3) Mismanagement. Passive engineering managers who spend most of their time attending obscure meetings and expect individual contributors to chase them, maverick employees who do more harm than good, antisocial behaviour due to having no conduct expectations, etc.
My personal opinion is that nowadays SaaS engineering is akin to being a miner during some mineral rush. You can make significantly more money than the average Joe in exchange for a shorter life expectancy.
Remove anyone’s competence, relatedness, or autonomy and you will drive them away.
> Stop estimating. I have analysed every team I have been on that use estimation. Those teams have been 99% incorrect. In my experience, it does not work. If you need dates, I would recommend a more modern approach like forecasting. What's the difference between estimating and forecasting? Seems very binary as written, but at some point don't you have to look forward and make some assumptions on complexity/effort req…
If you estimate in properly calibrated 90 % intervals, you'll be correct 90 % of the time, and this is something you can verify continually.