Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Then make sure developers are deeply aware of all the concerns you listed. A large part of why developers think they are the center of the world is because they are meticulously isolated from said world. This is exactly what the article addresses as one of the main concerns.


As a developer, I’ve noticed a pattern: devs complain about too many meetings -> devs are left alone (aka isolated) -> devs complain about being left out of decision making process/chain of comm.


It's a good observation. IME you can't be in all the meetings you need to be in to obtain alignment on complex problems in a changing environment AND be effective in writing code, very generally speaking. My most frustrating career points have been when I was a tech lead, doing a bit of both. Being more purely IC or purely managerial, it is much easier to get important work done.

Its also a grass is geener issue. Work is generally more enjoyable as an IC, you get to focus and write code. Until you end up having to build something really stupid, and you want more control over product direction. Then you end up as manager, and long for the simplicity of being able to focus and write code. At least that's how I've felt at times.


Meetings are to align people. Complaining about too many of them can be a sign of many different things, but one of the biggest is needing to align with so many people to get anything done.

If you hold the same number of meetings but stop inviting some stakeholders, those stakeholders are going to be upset. If instead you remove some meetings from the process entirely, by e.g. not requiring multiple design reviews for internal products, or by not letting platform teams force everyone else to use their software, or by letting teams spin up their own low capacity services without meeting with ops, or anything else that lowers the complexity of getting work done, then your team will be happy and the previous gatekeepers will be complaining.


I agree. And then if the same devs have reduced meetings, are included in more cross dept initiatives, and included in decision making, they end up upset that their freedom is suddenly gone. Its not even just devs this is a common thing from call center reps to the top of the broken pyramid. Everyone is the linchpin in their perceived contribution to the world.


Both of those problems can be solved to a degree with more efficient communication. Async communication channels like email and other messaging are great at not wasting peoples time while keeping everyone in the loop who needs to be, properly used. Sometimes I think phpbb style forums would work better than the usual tools. But overall I find people don't experiment enough or put enough effort into optimizing communication and it leads to this false dichotomy of either isolation or time wasting. There's a middle ground of optional participation where you communicate widely but don't force peoples attention, and that's how you can reduce meetings without reducing valuable communication. You can always put a time limit on feedback if needed, mark some things important... Just find what works!


The comment you replied to gestures at but doesn't outright say this, but I think you have a good point.

I genuinely think that many engineering managers see their most important skill as "getting engineers to do things for reasons they don't understand".


That isolation is often as much self-imposed as not. While the GP may have been a bit aggressive in his/her characterization of it, I agree with the general thrust that developers tend to be both narrowly focused on their own technical work and prone to inflation of its worth.


> prone to inflation of its worth

This issue is not limited to developers.


Of course it isn't: most individuals tend to inflate their contributions' importance. There are matters of degree, though. My experience is that developers tend to overestimate more often and by larger amounts.


My answer was intentionally phrased to mirror the absolutism of the GP. A large part of my time is spent explaining why certain process is in place or why we cannot get a license for this or that tool or why one needs to be considerate of the other crafts.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: