Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No management needed: anti-patterns in early-stage engineering teams

ablg.io

Post reply on HN
Print view View original

111–120 of 361 posts

Re: No management needed: anti-patterns in early-stage engineering teams

#111

Post by systemtest »

hxugufjfjf wrote: post #52
systemtest wrote: post #10

When I read about 996-style culture I am happy to be European. That would not work here. 40 hours per week max and most engineers prefer to not work more than 32 hours a week. So you have a good work/life balance. I currently work 4 hours a week.

How does this work though? Do you have around 4 hours worth of work you report on? Are you paid for more than 4 hours? I’m so curious when people throw completely alien statements like this out like it’s something that doesn’t even warrant explanation.

I freelance. Occasionally I get called by former clients to work on legacy systems I was lead on. And I have some support tasks for former clients.

For one company I log on once a month, I start a Renovate process which generates pull-requests for updated dependencies. Patch-versions get auto-merged after tests succeed, minor and major need approval of the current lead. Sometimes I need to manually tweak the code a bit because of API changes or to get tests to pass. I'm allowed to bill them four hours on it regardless of actual work, which is between five minutes (no manual intervention required) and two hours (need to rewrite some code).

For another company I create a report once a month for all outages and which errors frequently show up in logging. I automated this to be a five minute task and it generates a Wiki page. I review the page to see if everything is ok. I bill an hour on this.

The company is happy to not have to allocate engineer hours on maintenance so they can continue pumping out new features.

I'd say that on average I work 4 hours and bill 12 hours. This is comparable to the income of someone in employment working around 24 hours. But I do run a significant risk obviously.

Re: No management needed: anti-patterns in early-stage engineering teams

#112

Post by alephnerd »

Nextgrid wrote: post #30
alephnerd wrote: post #12

Earlier quoted context omitted.

You don't have to work at an early stage startup - in fact most people don't. But some people do wish to participate in an early stage startup, and plenty do in Europe as well. > So you have a good work/life balance. I currently work 4 hours a week. And this is why when I was a PM, we shut down our Amsterdam office and shifted it to Praha, Bucharest, and Warsaw. You won't find as many people who will complain about a…

As usual, the problem is not 996 itself but comp. You can get 996, you just have to pay for it. The reason Europeans don't want to do 996 is because the extra effort isn't fairly compensated.

That's a good callout - I have found European employers and founders to be much stingier with salaries in comparison to those I've worked with in the Bay or Israel, but I feel a lot of this is because of much more conservative investors, with boards pushing back on more "realistic" compensation.

I've been adamant about paying 75th percentile TC - I want the employees in my portfolio companies to be extremely motivated, and that requires incentivizing employees and founders correctly

Re: No management needed: anti-patterns in early-stage engineering teams

#113

Post by nebula8804 »

bob001 wrote: post #63
Herring wrote: post #54

Earlier quoted context omitted.

Again see Steve. Something can look like a good position and still rapidly deteriorate. This one wasn’t that rapid either, you had plenty of warning. I remember discussing inequality with friends in 2014, and probably knew about it since Occupy Wall Street (2011). Or earlier.

Engineers were the privileged class. They were part of the group occupy wall street wanted to bring down. Not hard to guess why they didn't want that.

Privileged is too generic of a word that does not accurately describe the cohorts. There is the capital class. Occupy was after the Capital class but im not sure if they accurately zeroed in on that. Its been too long since then.

Engineers were never part of that class. They work for a living while capital owns assets that work for them.

Engineers were part of the "Intellectual Elite" class that made good money but were super socially progressive. (Think putting BLM signs in their yards while at the same time pricing out the people they claim to help).

They ended up becoming a lot of the Elizabeth Warren cohort after being the Hillary and Obama cohorts(before it fractured into part Bernie part MAGA with the rest going to Hillary).

Extremely socially progressive but don't you dare touch economics.

Re: No management needed: anti-patterns in early-stage engineering teams

#114

Post by nebula8804 »

mothballed wrote: post #71
bob001 wrote: post #63

Earlier quoted context omitted.

Engineers were the privileged class. They were part of the group occupy wall street wanted to bring down. Not hard to guess why they didn't want that.

I would say more precisely, engineers are closer to the managerial or capital wielding class; usually the adversary of the union.

They are closer but they are not part of the class so does it really matter how close they are? Engineer still has to trade their time for wealth in the form of work. Capital class has assets that work for them.

Re: No management needed: anti-patterns in early-stage engineering teams

#115

Post by lovich »

tyre wrote: post #77
burnto wrote: post #18

> Motivation is a hired trait. The only place where managers motivate people is in management books Initial motivation is the hired trait. It’s very easy to demotivate people. The trick is to not do that.

Yeah this 100%. One of my core philosophies as a manager is that by default I should get the fuck out of the way. From there, identify the biggest issues and solve them. If you're successful hiring great people, I really don't understand the desire to micromanage them. Or do silly things that are demotivating, like 996 or trying to mislead them / market things / hide the bad stuff. Treating people like adults is that…

> Treating people like adults is that One Neat Trick that influencer bloggers don't want you to know.

In the companies below Big Tech in valuation at least, having been in the room with drunken executives speaking their real thoughts multiple times, I’ve found it’s because they don’t want to treat people like adults.

They want serfs to order around because they have some cultural value around being “the boss” and you can’t be “the boss” if you aren’t telling people what to do. The more things you tell them to do, the more of a boss you are.

It’s how you get executives crowing to you about all of these faang ideas like google’s 20% time back in the day, or engineers being able to vote with their feet and only attend meetings they found useful, but then have people on pips because they were consistently 30-60 seconds late to daily standups.

It’s not the only failure mode by far, but having leadership like that seems like a cause for companies getting hard stuck below a billion in profit

Re: No management needed: anti-patterns in early-stage engineering teams

#116

Post by OhMeadhbh »

Animats wrote: post #101

If you need motivation, maybe the organization is designed badly. It was once said of the Roman legions "The Legion is not composed of heroes. Heroes are what the Legion kills." Field Marshall the Viscount Slim, who commanded in the China-Burma-India theater in WWII, once wrote "Wars are won by the average performance of the line units." He wrote negatively on various special forces type units, preferring to use regu…

in the military we had a saying "you don't go to war with the army you want, but with the army you have." consequently, there was a lot of effort given to training and planning. the nature of most combat arms roles is such that you need most of the team operating at a decent level. i think the idea behind so much training is that if you can raise the performance of the worst performers, you might be able to improve the overall unit performance dramatically.

to put it in marketing manager speak, for many tasks in a combat arms unit, individual performance is a satisfier, not a a delighter. if one person in the unit does a bad job, the unit will fail. if everyone in a unit does an "okay" job, the unit will not fail. the outcome between the two cases is dramatic. but if you have a unit where everyone is "okay" and then expend effort to make everyone in the unit exceptional, you will not notice a concomitant increase in performance.

flipping this over to software development... you have a lot more control over whom you hire to be in your unit. but everyone has a bad week or a skills gap, so training (which could be as simple as giving people time to read up on a subject or write a few test programs) will eventually be important. like line military units, everyone needs to be hitting on all cylinders for the dev team to work in accordance with plan. investing in upskilling existing developers who are competent but underperforming may be a better strategy than uber-skilling your best developers or firing them and hoping you can replace them with someone with better ability to figure out how to be productive on the team.

as a humourous aside... at amazon my manager discovered i was prior-service, saying "Oh! You were a MARINE!? I want to manage my team like a military outfit." unfortunately, my response was "WHAT!? You want to spend 80% of your budget on training and logistics!?" that was probably not the best thing to say in that situation.

also... if we're talking about applying military metaphors to product development, it's worth it to look up the various OODA talks by John Boyd. i don't know if i agree with all of it, and it's not directly applicable. but there's enough there to justify at least reading about it. Boyd was a friend of my dad's, so i remember thinking he was crazy when i met him as a child, but again, he may have been crazy, but he was definitely an intellectual outsider who hit more than he missed.

Re: No management needed: anti-patterns in early-stage engineering teams

#117

Post by crazygringo »

bob001 wrote: post #83
crazygringo wrote: post #29

> do not adopt all the "Scrum rituals" like standups, retros, etc. wholesale, and if you do, keep them asynchronous. There is little added value to a voiced update I couldn't disagree more. I know it's an unpopular opinion, but when standups are done synchronously, everyone actually pays attention, notices blocks and helps with them. Things get surfaced and quickly addressed that simply wouldn't otherwise, which is t…

I disagree. In a company of 5-6 total engineers who are actually self-motivated and competent none of these things matter. If you need stand-ups for people to be aware of work being done then you're bandaid fixing a deeper issue. Same for retros since all of that should already be getting communicated in five other ways. If not then you've got bigger issues. Same for 1-on-1s. If the founders don't know these things o…

It has nothing to do with motivation or competence.

Teams don't just work together magically and "organically". They're made of diverse human beings, every one of us, who come from different backgrounds with different expectations about when and what to communicate and when and what not to and around what is who's responsibility when. Different levels of experience, having worked at different places with different practices, and different preferences about how to do things. This is a recipe for a hundred miscommunications and inefficiences and misunderstandings a day.

These processes exist to surface the most important things not being surfaced, and to identify and fix problems that affect the team but which nobody is understanding in full because everyone only knows their own perspective.

Again, these aren't "rituals". They're processes that are proven because they work. Including with 5-6 engineers.

Re: No management needed: anti-patterns in early-stage engineering teams

#118

Post by theturtle »

Yeah. This. In 42 years in IT, i saw way too many situations where the last thing engineers need is a "team" or "management," or even worse, an outside "team leader," which usually resulted in the engineer's work or the team's work turning directly into cowshit. "Managers" want to talk about doing a thing; engineers want to actually do the thing, and both cannot happen simultaneously.

When they see results deteriorating, "managers" think the solution is "more management," which is never, ever the solution.

Re: No management needed: anti-patterns in early-stage engineering teams

#119

Post by mattmanser »

ebiester wrote: post #105
Animats wrote: post #101

If you need motivation, maybe the organization is designed badly. It was once said of the Roman legions "The Legion is not composed of heroes. Heroes are what the Legion kills." Field Marshall the Viscount Slim, who commanded in the China-Burma-India theater in WWII, once wrote "Wars are won by the average performance of the line units." He wrote negatively on various special forces type units, preferring to use regu…

This post is talking about very small companies. At that 20+ person department, it's true. Once you have a team where the founder doesn't know everyone, the average matters a lot more. If you have 15 people, you can hire 15 people and they will be able to organically organize if you hire well. If they have a question, they know what everyone is working on. The code base is small enough that everyone can just figure i…

Hiring well is extremely hard.

Re: No management needed: anti-patterns in early-stage engineering teams

#120

Post by bob001 »

crazygringo wrote: post #117
bob001 wrote: post #83

Earlier quoted context omitted.

I disagree. In a company of 5-6 total engineers who are actually self-motivated and competent none of these things matter. If you need stand-ups for people to be aware of work being done then you're bandaid fixing a deeper issue. Same for retros since all of that should already be getting communicated in five other ways. If not then you've got bigger issues. Same for 1-on-1s. If the founders don't know these things o…

It has nothing to do with motivation or competence. Teams don't just work together magically and "organically". They're made of diverse human beings, every one of us, who come from different backgrounds with different expectations about when and what to communicate and when and what not to and around what is who's responsibility when. Different levels of experience, having worked at different places with different pr…

To me you're describing a team with mediocre communication and social skills. That's common but its not all teams.

It has everything to do with maturity, motivation and competence. The best teams I've been on didn't care about these rituals because each person bridged the gap with other people. The TLs kept an eye on everything the TL and EM kept an eye on all the people side and concerns. In a startup it'd be the founders. There was mutual trust built by those in leadership roles and issues were communicated and everyone kept an eye out for them.

> They're made of diverse human beings, every one of us, who come from different backgrounds with different expectations about when and what to communicate and when and what not to and around what is who's responsibility when.

Have a meeting, align on some norms for these things and then hold people accountable to them. It's not hard. We're all adults. You don't need constant meetings to hand hold people like little kids.

Post reply on HN