Hacker News Reader

Comment by VyseofArcadia | Hacker News Reader

I have been a senior IC. I spent no time training in the mountains by myself. I spent all my time in meetings attempting to do system design but actually just getting bogged down in politics.

There needs to be a third track. IC (training in the mountains), EM, and IC (planning and design). A lot of orgs would call that last position a PM, but I have never worked with a PM competent enough to actually carry out that kind of work without ICs stepping up to do most of the PMing themselves.

In my experience, PMs are the corrupt bureaucrats that serve as antagonists in wuxia stories.

View on HN

The secret is — when you’re a senior IC, if you think that it’s important to spend 2 days a week coding, you’re expected to tell people to fuck off so you can spend 2 days a week coding.

Imo, the politics is the design.

Who is going to pay for what? Who's responsible for when a certain part goes wrong?

If you figure out the politics well, you've mostly constrained the system design to something straightforward

Or, you built a poorly architected piece of software that replicates your organizational structure.

It's basically a law of the Universe that your software will look like your org structure. You have to treat it as a hard engineering constraint, just like you'd treat seek latency on a spinning disk, or the speed of light between two data centers. You can't increase the speed of light, but you can still function. Treat org constraints like that.

Or, you build a well architected piece of software that replicates your organization structure if the people (director+) who are in charge of the org structure do their jobs well.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

— Melvin E. Conway

I guess the trick is to flip this by modeling your organization to the system design (i.e. create teams around the components of the system, not components around pre-existing teams). This is easier said than done, and as architecture changes one needs to adapt the organization structure...

it's not a complete solution, as 1/I've seen this cause games of musical chairs happen that essentially stall the work and 2/ creating silos make cross-cutting concerns fail to be addressed...

Hahaha. Perfect.

In many of these organizations, PMs serve to insulate the "planning and design" ICs from conversations with customers.

Not ideal either, IMO, ICs involved in planning and design should get out there and talk to customers themselves!

The most successful software project I've ever worked on, in terms of our utility to the business and our customers, as well as personal satisfaction to the team members, was one where myself and a technical PM handled "planning and design" in lock step with each other. My (former) management tried to build a template out of our success and failed, horribly, because you cannot account for the personalities that sit behind these titles/roles.

> you cannot account for the personalities that sit behind these titles/roles.

This is an important point, and should be more obvious than it is. Projects succeed or fail more as a function of individual personalities than of whatever their job titles are. Easy to forget given that people who share a job title are usually treated as interchangeable components of the machine (at least in big companies and at least in my experience).

Or Architects

In systems: Politics is as much a constraint as budget, and technical constraints.

If your manager will not accept way X. It really doesn't matter if X is optimal. You'd better find Y, or convince the manager.

Reply on news.ycombinator.com