181–188 of 188 posts
I've seen that these cultures eventually converge to promoting "empire building" and less efficient but highly visible teams.
This article makes it sound like solving highly impactful problems is a needle in a haystack problem (which it sometimes is), but fails to recognize that this pattern works not because it helps you find an impactful problem, but because it helps you find a large enough set of people to vouch for this problem.
The author notes: > One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way. I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controll…
If a company is bootstrapped by a few engineers, where would the business acumen come from exactly?
I've been part of tiny startups, medium size, and large ones. I've been at state agencies and ancient private organizations.
The more people, the more corporate the culture. The more cooperate, the more the business needs & wants drive choices.
Earlier quoted context omitted.
> That's exactly what engineers are supposed to do: listen to and enable the business. This may be the case if you're a junior engineer just crunching through individual tickets, but with the lower end of software engineering being automated away where even more junior engineers have to take more product/feature ownership, I don't think "churning widgets" is the right way to think about our job anymore.
And this is why the lack of training/mentorship is having a negative effect: somebody needs to be protecting and guiding the junior engineers. They don't know they're supposed to push back and say "I'm not the person who's supposed to decide how your product works, I'm just supposed to build it" . They don't know that they need to interrogate the business and get them to commit to details. They probably don't know ho…
The author notes: > One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way. I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controll…
In BigCo. finding problem and the technical solution dwarfs in comparison to the effort and skill required to find the people who you're going to offend with your brilliance, the beneficiaries of said problems and who their reporting chain is and their incentive structures and the art of framing solutions using terms that they and their bosses understand in entirety.
The author notes: > One caveat: my experience comes mainly from working on infrastructure and developer tools at large companies, on teams where engineers have a lot of bottom-up autonomy to influence their roadmaps. In a more top-down environment, there may simply be less room to work this way. I wonder if the overall trend in tech is that engineers are experiencing less bottom-up autonomy and more top-down controll…
Companies are no different. During company growth, it's all about hiring, and giving tasks and some responsibilities to subordinates, setting up the right channels for communication etc. But at what point do company leadership actually say "You know what,that department would work better without direct instructions from us. Let's facilitate communication, act as conflict adjudicators and make company-wide 'North Star' decisions"
I think that's what OKRs are supposed to do, but I've never seen that work well (for very long anyway). It always gets up-ended somehow. Start of quarter optimism, over-promising, not spotting that someone else's stretch goal is actually your blocker. Then mid-quarter you're dealing with production emergencies, database code red and running out of time. At the end of the quarter, two of your team go off on PTO while you desperately try not to "fail your quarter", working late, and delivering shoddy work.
Does true bottom up exist at large companies? Hmmm. Some. We've all heard the legends of IBM's "build the first PC!" skunkworks. And we know about research-only departments at Xerox that led to so many modern computing inventions. But these were brief projects.
I find these days that people have the desire to get out of the way and let us work, but the tiling is in the way. I waste so much fixing time in Jira, slack, doing performance reviews, interviewing...
But as he later explains, he needs to decide on some typical app maintainence issues, which have nothing to do with his role as staff engineer.