Work environments in software development

[suomalainen]

Fwiw, the same question and the analyses noted above apply to lawyers too. Basically, you have the “meaningful work” to “easy gig in a big machine full of bullshit” spectrum and yes, it tends to correlate to size. Know thyself and skew your interest towards appropriately sized companies and even take some interviews at “wrong” firms just to see if there’s a unique standout. Good luck!

[ducknald_don]

I found that the bigger the employer the more your political skills mattered whereas for small companies technical skills were more important. It's quite hard to hide your lack of ability when you sit opposite the boss.

Also you tend to get pigeon holed in a large organisation, you will end up with quite a narrow set of skills. This is OK until the market shifts and your narrow technical experience isn't worth much anymore. Kind of the opposite of what this forum is about.

[guitarplayer]

I find it comforting that intuitively I got it right the first time then!

[macg]

For me, the original (or more accurately, one of the originals) "agile" methodology of Extreme Programming was the best time I had. But when I did it, it was the puree concept, just the programming concepts, none of the overlay of the Project Management. But over the years XP and many other different methodologies have merged into the current "Agile" system.

I have seen it here or there, an implementation of the current Agile system stripped down to what is needed for the team, with full support (and most importantly, freedom) from the higher ups. But it's very rare, and I have only seen it in little pockets of companies, never wholly implemented across the company. Most of the time, it's a haphazard, not well formed, poor adaptation, with all the pitfalls described by others here.

The thing that is the worst for me is bad project management. That can make any job a nightmare. And I don't understand it - before there were PMs, or PM teams, I (and others) had to do our own PM to get anything done with different groups. And it's not hard - it's just a task list with dates and communication. It's not rocket science. The fact they get big money and (in my experience) >90% of them are useless blows my mind.

[Slevin]

The thing that is the worst for me is bad project management. That can make any job a nightmare. And I don't understand it - before there were PMs, or PM teams, I (and others) had to do our own PM to get anything done with different groups. And it's not hard - it's just a task list with dates and communication. It's not rocket science*. The fact they get big money and (in my experience) >90% of them are useless blows my mind.

See my pic about exponentially growing communication costs. As orgs get bigger, this becomes a more and more difficult task (as well as navigating the bureaucracy, arguing your project should get the funding, cost tracking / etc). I've seen PMs that make a good salary that are worth their salt, and ones that are utterly useless. But being the coordinated brain / documentation machine that keeps the software team working on the "correct" (for business) tasks, as well as being the bullet sponge from making all the devs solve their own coordination problems (at least up to the point they become extremely technical) very quickly becomes worth the cost. This is what a good PM should do.

Unfortunately, as keeps getting mentioned in this thread, "Average" talent and "high quality" talent are different things. Finding a good PM worth their salt from a short interview process seems ridiculously hard, and so I think this interview process fails a lot.

I actually think you should pick a "high quality" PM as one of the most important hires in a team, as a team of "high quality" engineers without the correct direction often ends up making the wrong product (from a business perspective) and gets so caught up chasing their tails (i.e. playing with serverless go because its the new cool thing or fighting about code purity or continuously nitpicking code reviews) and not wanting to support the things they already built because they are "legacy" now (I.e. not serverless go or whatever the hot thing of the moment is), that they end up obliterating companies. Working with a PM of a high / elite caliber will open your mind to how poorly most teams are run. Also, good PMs are working with customers and business people to define a product, find market fit, get people to try new things, get promises / specs / feedback out of customers / etc. A lot more things than you give them credit for that you probably don't see on the day to day.

* and I say all of this as a literal former rocket scientist

[zbigi]

And it's not hard - it's just a task list with dates and communication. It's not rocket science. The fact they get big money and (in my experience) >90% of them are useless blows my mind.

IMO it's partially about "perpetuating power" (to use terminology from the woke parlance). The official ideology of the company is that the managers have the hardest, most responsible jobs, and deserve to be paid the most. This is in the interest of the C-suite (since they want to inflate their salaries as much as they can get away with), who then apply this ideology across all management positions in company. And hence, a useless or net-negative Scrum master, since his position is seen as managment-adjacent, "obviously" needs to be making as much as or even more than the best software engineer.

A related reason is the power structure in the company. Even though ostensibly knowledge work is nothing like working in a factory, the power dynamics are largely the same - i.e. it's "us versus them", where management sees themselves as representatives of the company and owners' interest, and they see the rank and file employees as a mob that needs to be kept in the dark and manipulated for maximum company benefit. This makes being part of management more about caste loyalty than about skills (since in management you will have to do, for the sake of company's interest, some unsavory things without blinking an eye), and that loyalty is bought with inflated salary.

Having said all that, at least in Europe the market forces sometimes invert the salary situation. I.e. companies sometimes find that they can get a willing candidate for management whose loyalty can be bought for say 80k euros, whereas a qualified software engineer won't join the same team for less than 100k euros. So, you end up with managers making less than the people they manage - a common situations in the teams I worked in. It's however not the norm, it is mostly limited to areas of new hot tech, where there's just not enough experienced people yet and they can dictate their salaries. And, even in such situations, the "overpaid" employees are brought in as consultants, to make them different fro regular employees and maintain the position that rank and file people cannot make more than managers.

[conwy]

Reflecting on my most recent gigs:

1. Contract lasting 1.5 years. "Product Manager" role was embedded in the team. Was a woman and (not sure if gender plays a role here but...) she seemed fairly genuine, non-manipulative, well organised, clear communicator and I always felt safe with her about knowing about what the business needed, what the priorities were, etc. I also had a functional manager who was very distant and I almost never spoke with, but seemed to be in communication with higher-ups and able to give me updates on how I was doing. The work was great almost the whole time until it abruptly ended - apparently I had done enough work and they didn't need my skills anymore. I suspect the real reason was to cut costs (they had me transfer a lot of knowledge to other developers in the prior months) or because someone in the team didn't maybe didn't get on well with me. The company were quite generous in offering me a position in another team but I ended up going with a higher-paid role in a different firm where I would also learn new technical skills.

2. Contract lasting 1.5 years. "Delivery manager" seemed to be the main person in charge, with a somewhat distant functional manager and a "Product Manager" who was an excellent communicator and organiser but not as loud and domineering as the Delivery manager (she was a woman, whereas the Delivery manager was a man, again, I wonder if gender played a role here). The team found the Delivery manager slightly annoying and during meetings would often openly disagree with him, and make him act more humble by force of numbers. He was more authoritarian whereas the Product manager often had more influence because she was more persuasive. I often felt the Functional manager didn't appreciate my efforts, maybe because I was in a different city (working remotely). There was a very strong core of developers in HQ and they seemed to kind of exclude anyone not from their city and thus would appear to be higher performers by just jumping into initiatives before anyone else knew what was happening. The end result was that I gradually became more and more distant and pigeon-holed to just my one team. Eventually my functional manager got on a call and gave me this very solemn, long-winded "sorry have to let you go" speech - I couldn't be bothered to tell him that I already saw it coming for months. Anyway it's good because almost immediately after I got a new job where I learned a totally new skill-set, which significantly boosts my employability.

3. Contract lasting 6 months - my current gig. Delivery manager is quiet and softly spoken, but well connected to higher-ups, so has a lot of influence. Well organised but distant from the team, seems more of an introvert personality. My functional manager is almost totally absent. My main point of reference is the Architect, who kind of plays a Dev Manager role also. So he has most of the conversations with product people, designers, etc. and then documents and diagrams the solution in technical format and hands it of to us (senior developers) to implement. I appreciate this, as I prefer to just work on the technical stuff and not interact with the business. He did express a wish that I would be more involved in product (maybe wants me to take some of his job off his plate) but my contract is ending soon, so it's probably not going to happen.

My overall conclusion is that some mixture of personality, societal tropes (e.g. gender roles), who hired you, kind of business and kind of work needed and team capabilities all play a role in determining who has more power and how you work.

I consider myself fairly lucky to often be given both clear guidance and significant autonomy, but that might be because I'm fairly senior now, because I'm a contractor or just luck.

Anyway after the end of this last contract in 2 weeks I will be officially early retired and not needing work. Depending how investments perform over the year I may pick up some more work next year to fund a bit of travel, but otherwise I will no longer have to work.

[delay]

Anyway after the end of this last contract in 2 weeks I will be officially early retired and not needing work. Depending how investments perform over the year I may pick up some more work next year to fund a bit of travel, but otherwise I will no longer have to work.

Congratulations on no longer having to work!

Interesting to read about 1:1 "letting go". That sounds like a cultural difference with The Netherlands, I've seen very few of those. When a company wants to let people go it reorganizes and you lose your job with a whole batch of others. The selection of whom to let go is based on age and number of years at the company. There have been a few experiments with merit based selection but those ended in disaster. Dutch management can't part with people they meet daily so they end up retaining all their friends and enemies. The result is a group full of "dominant" DISC types.

You write like you are in a developer role? What's your area of expertise?

[liberty]

So what experience do you all have working in different work environments in software? Which was your favorite and why?

My favorite work env is working for myself, on my own projects. Then I can choose the language, framework, operating system, working hours all by myself. I went back to work for others, but quit and am now "retired" again, and will go back to working on my own projects.

The only downside is that I need to do some tasks that I'm not good at, and I don't enjoy, like sales and marketing. Maybe I will partner with someone who likes to do that part of the business.