Hacker News Reader

> Getting things done is an important metric.

The older and more jaded I get, the more I realize this is just not true. The most important metric is the meetings and visibility, for a larger org.

If you just get things done, the effort won't be perceived or understood. .

If you just have meeting about what you did, they'll be forgotten the next day, because it's some complicated detail that can't be bothered with.

If you have periodic meetings of what you plan to do, and allow people to comment/participate, they'll see themselves as contributing in a small way, which helps them remember, which helps them understand the effort.

Worst, if you plan well and prevent future problems, nobody can know your good decisions. So, the optimal route seems to be, have periodic meetings that high ups can participate in, to some extent, and let "unforeseen problems" happen, so you can be in meetings with higher ups, fix the problems, and be the hero. This isn't even really my jaded opinion. In the org I'm in now, it was such as widely understood phenomenon that a special reward package, and recognition, had to be put together for people who prevented problems from happening.

As the old saying goes... if code was shipped but nobody heard it get shipped... did it really Provide Value?

>The older and more jaded I get, the more I realize this is just not true. The most important metric is the meetings and visibility, for a larger org.

Well we can divide it in 4 ways:

- the "sales engineer" (not a literal sales enginer, but one who wants to sell themself) wants to maximize visibility.

- the startup engieer wants to pitch just enough, but mostly wants to ship

- the craftman engineer (or the researcher) wants to get things done "right"

- the blue collar engineer wants to check off tickets.

Your metrics of success will vary, and some engineers are more punished in some spaces than others.you'll need different skills to navigate depending on your environment

Sadly, I can't disagree.

You are very right to call out that in a corporate environment getting things done is judged by the eye of the beholder. This, imho, makes this article even more naive because posthog is pretending they don't do that, and no organization is immune to it.

Ironically, GitHub started having lots of problems when they enbraced the holocracy, i.e. flat management. No one was in charge and no amount of "empty PRs" as I described above could mitigate the vacuum of leadership.

That this article made it past posthog's leadership means they might be having a leadership crisis.

I worked on a team that did something like that for important stuff. (We didn't bother for the relatively routine or uncontroversial changes.) Although in our case we did it in a team meeting rather than asynchronously.

It really was horrendously valuable. Many, many times someone would save a their teammate an ungodly amount of time by pointing out an easier way to do something. It was a big complex system so naturally none of us could be expected to know every nook and cranny.

I've been fighting for this approach for ten years now. I can divide organizations into two camps. One will see value in it. The other will not, and they have innumerable problems because they have to constantly refactor, have bugs, and most importantly, no one on the team has any clue of the goals or why of the code.

And PostHog does that too with [RFCs](https://posthog.com/handbook/company/communication#requests-...) when you require some sort of smart collaboration. The way I read OP's post is not about isolation, but rather about trust.

i get preplanning big picture architecture or strategy, but i CANNOT plan out the actual code i write. i'm not sure if i just develop deficient mental models of the codebase, but my process for figuring out what to build is to just sit down and build it. my process is very iterative. lots of stubbing things out and working backwards (if i need this function to return an X, it needs args A and B which means it might be better as a method for this class over here...)

the only way i could come up with a precise plan for how the code needs to change is to just build the thing.

Consider this: you could, given enough time. You probably haven't had management that gave you that time. Or demanded you take the time.

Writing things down takes a lot more time than you think. It is hard work. You get better with practice.

You would find, if you were given the time, or permitted yourself to have that time, that you would find all the skills you have accumulated up to this point would converge into that plan. There is a very exciting zen you get into writing things down and you can think about the architecture and the people and the teams involved, and it's a very different thing to create. And very satisfying.

Then you'll be a senior engineer.

> The team would need to sign off on that PR before any "work" was done. Can anyone describe that in any way other than collaboration?

That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks. And so we invented SCRUM.

scrum planning doesnt usually get too nitty gritty on implementation details in my experience if you dont want the meeting to last 4 hours.

> That sounds like an ad-hoc planning for a single issue, which you could also just do for a subset of the open issues, every, lets say, 2 weeks.

So you'd require the whole team to spend time on matters that interested only a subset, and you'd do this in a blocking way rather than asynchronously? What possible benefit would that have?

Then your team is too big. If you have more than, say, 7 people in a planning, your team is too large.

And it's never really asynchronous. It's more honest to block everyone who might have input. Planning the effort (points) also helps see if anyone thinks its more complex than it is, which can reveal issues before implementation begins..

It's not perfect, but if you're gonna do planning, just do it properly.

> And it's never really asynchronous. It's more honest to block everyone who might have input.

How? Even if you decide you need everyone to look at it, letting everyone check it off asynchronously is more respectful of people's time and concentration. Maybe occasionally there's a big difference in people's assessment and you need to have a synchronous discussion, but there's no need to pessimize the common case for the sake of the rare case.

> It's not perfect, but if you're gonna do planning, just do it properly.

What's "properly"? Doing your planning in a more difficult, time-consuming way might feel virtuous, but it's not actually beneficial.

This works really well in mechanical engineering, too. We don’t necessarily use tickets specifically, but planning out work or a design upfront with a small audience saves a lot of time and wasted effort.

On some level this is just basic project planning, which in my view is an underdeveloped skill in most modern engineering teams. In the case of the ‘empty ticket’, it’s project planning but at a lower level. Not every bit of work needs this, but many would benefit, especially when the taskee is at a more junior level.

I wholeheartedly support this approach. Nearly every major project requires a team, not an individual, and coordinating and collaborating are basic functions of getting things done.

"Without good [design] documentation every mistake, large or small, is analyzed by one man who probably made the mistake in the first place because he is the only man who understands the program area."

- Winston Royce, "Managing the development of large software systems"

That said I've also seen over-collaboration lead to a similar situation. In that case everybody ends up with their own personal model of what the plan is, based on their own interpretation of all the endless talking around in circles. Maybe there is also a design document that purports to be the source of truth, but nobody is actually paying attention to it. Possibly because all the bickering and confusion turns maintaining it into an impossible task.

So a design doc?