Hacker News Reader

Comment by bcantrill | Hacker News Reader

There is stuff in here I definitely agree with (record every meeting!), but there is also tons in here that I personally disagree with (e.g., on performance management[0]). This isn't necessarily a criticism -- different problem domains likely demand different approaches and leadership styles -- just to say that I wouldn't take any of this guide as sacrosanct: if anyone reading something in here that doesn't comport with your personal experience, I would recommend deferring to your own experience.

[0] https://twitter.com/bcantrill/status/1216491216356823040

View on HN

> For example, an individual contributor software engineer s competency matrix may include a row for coding/feature output velocity. In a Level 1 to Level 5 system, the matrix would specify that for a Level 1 engineer, expectations on code velocity are X pull requests per week

I mean. No.

It really is a ridiculous metric. So ridiculous that you'd think it would never be used in reality... and yet, I have in the past actually had the CTO of a large engineering firm insist upon it.

“If you can't measure it, you can't manage it”,do you have better ideas that also work in daily operations and practical? is there a way at all to measure software engineer or no?

"If you can't measure it, you can't manage it" is absolutely terrible leadership advice. Or to phrase it another way, if you could magically transport yourself to work on any team in history, which would be and why? And how did those teams run? How did the leadership function? How did the team think of its own performance? In this regard, I feel history is a much better guide than middle management claptrap admonishing us to all kneel before the false god of Measure Everything.

I don't buy it fully either, but, I could not figure out what's a better alternative, not in theory, but in practice.

Software projects are notoriously hard to manage indeed, but it has to be managed somehow, Agile approach is a nice try, we had CMMI as well.

Even a neurosurgeon can be measured, why can't software developers, why are software engineers so special? Maybe AI programmer is the way out.

So, interesting example: how much do you know about surgery? The best surgeons care about things that are not, in fact measured -- things that amount to the quality of the craft that very much correlate to patient outcomes, but are also hard to measure. Indeed, if you really get a surgeon going, they will complain about the things that are measured -- namely, the number of surgeries that they perform. I know of more than one surgeon who has left their craft because this quantification was essentially forcing them to perform unnecessary procedures!

In general, quantification of human endeavor is fraught with peril -- even in those domains where it would seem to be entirely non-controversial like professional athletics.

The alternative to measuring everything seems obvious. Don’t measure everything.

Why not measure everything? Because measurement has a cost. And some things cost more to measure than you gain from the measurement.

I was on a team once with a product owner who insisted on absolutely everything being in jira with story point estimations. Well, that’s fine and good but one day I sat down with the designer and walked through the product. We made a list of about 30 things that needed fixing - almost all of them trivial. “This is the wrong shade of blue”. “There is too much spacing here”, etc. Well, I made a list in notepad and got going but I got in trouble for not putting it in jira. Only, it would have taken longer to write up these issues than it would have taken to fix them. To say nothing of wasting everyone’s time doing story point estimation. In this case, measuring our work would have cost significantly more than doing the work! We argued back and forth and eventually he admitted he wanted things in jira to appease upper management, who I suppose wanted to know how busy we were by looking at a number on a spreadsheet.

(He ended up writing up all my points in jira himself, guessing costs and ticking them all off as “done”. What a waste of time.)

And no, software isn’t special. Teaching isn’t measured (except maybe with a student survey at the end of the year). Science is measured in citations per lifetime, not micropapers/hr. And you don’t quantitatively measure your spouse, your friends or your enjoyment of mum’s cooking.

Measurement is a lovely tool. But don’t make a religion out of it. I heard a story from a leadership summit recently. A young CEO got up and said “But there’s no way I’d make hiring and firing decisions by gut instinct!”. A bunch of the older people there disagreed immediately, and said that’s exactly what you should do. Train your instincts then trust them to do their job.

not interested in measuring everything, neither do I believe 'measuring nothing because I'm a software developer'

Agile has its merits, abuse it is obviously wrong.

There got be something that is practical and get the job done and benefit all parties in software project management, I'm searching for answers myself.

> But there’s no way I’d make ... firing decisions by gut instinct

Well the reason it's so important to hone your gut instinct for good hiring decisions is that you absolutely should have measurements for firing decisions (at least in the US); that decision needs be defensible with data under the scrutiny of a lawsuit

You don't need a reason to fire someone in the most of the US (AFAIK). You can just say that they walked in with a red shirt and you don't like red shirts. As long as the reasoning isn't because they are in a protected class, you can pick whatever reason you want.

Firing someone "because they walked in with a red shirt" would do damage to your company's reputation, and call into question the competence of your management team.

And you can still get sued.

I mean. You can get sued for wearing a red shirt. It would probably get tossed out in ten seconds (unless the judge just wants some entertainment). But you can sue anyone for anything. You can do tens of millions of dollars to a company, get fired for it, and sue them. Nothing is stopping you.

Secondly, no one is going to give a shit why you fired someone except the person you fired (if you even told them why), and HR. In fact, most companies don’t even give managers firing authority, but if you are the owner/CEO or someone who does have that authority, it’s possible even HR doesn’t know the reason. That person is just fired.

Measuring software engineers productivity has been a meme and the butt of jokes for decades.

However, I think there are things worth measuring that do help manage success and are not intrusive.

For example, giant pull requests or pull requests that go into production with no/minimal review are likely to create problems. We use LinearB to point this sort of thing out automatically.

Code with high cognitive complexity is likely to generate bugs (and be hard to maintain). There are many other similar issues that can be automatically detected. We use SonarCloud for this.

Asking an engineer "How do you feel about work overall", "your personal well being", "career growth", "work relationships", and "impact & productivity" on a scale of horrible to outstanding once a week prior to 1:1 meetings allows each engineer to tell you their story in numbers. If you have built a culture where people trust that you care about them, you will get honest answers. This helps discuss and correct things that bother your team members, and in aggregate shows whether you have a problem with leadership and/or culture that needs to be corrected.

Those are the numbers I gather, and it takes a lot of the gut feel and guesswork out of management.

It's incredibly difficult to measure the work of a software engineer with metrics which are useful AND objective. You can have many metrics which are useful, but not objective. And you can have many metrics which are objective, but not useful (and often detrimental, like "number of merge requests" per week).

The thing is, for a junior engineer, this is not that bad of an idea. I don't think that it should be part of a formal performance process, but if you're green and aren't putting out enough PRs, it suggests you're either struggling to contribute, or putting out PRs that are far too large and need to be broken up to be easier to review & safer to deploy.

Think of it as a threshold. A high number doesn't suggest you're great. But a low number can often be a symptom of a greater problem.

I assume this suggestion only applies to big orgs where juniors can get a steady stream of small, well-scoped items to tackle.

At a lot of smaller orgs I assume it's harder to do this? Where I've worked, juniors often receive exploratory items that are lower-priority, and off the critical path, but they're expected to have reduced output, as well as asking for guidance as needed from more senior members.

Perhaps this is a failure of planning (which would have been my own failing as a lead at times), as well as management

> steady stream of small, well-scoped items to tackle

Yes. The part of the quote parent left out is

> or the ability to close Y story points per sprint

With that in mind, it makes sense and the metric is dependent on the entire org functioning well. So to the extent it does so, this is an objective, very quantifiable, metric that all junior engineers can be compared with.

That said, this is a guide for startups. So I do believe this metric is garbaj. Junior engineers will be unfairly held to task for org dysfunction.

I was just thinking the other day about one of the issues I have working in this industry. You are expected to solve some hard problems, within a couple of days, usually. If you fail to do this satisfactorily, people will wonder what you're doing; if you're smart enough. And if you can't solve those problems fast enough, the "right" way, you are let go for not "performing."

In reality, you don't run into these kinds of problems often. Usually, the problems we're solving are relatively straightforward. However, if you accidentally pick up too many of these problems in a short span of time ... you can be screwed.

I mean, if you want the # of PRs to skyrocket to an impossible to manage level, that's great advice!

What are you quoting? I don't see that sentence anywhere in parent's linked twitter thread

Personally, I would never consent to be recorded at every meeting. Further, I would be mortified asking others for their consent. And how could I, as CTO, ask without coercion?

Agreed. I would probably consent now and then but largely I find it a bit inappropriate to be recorded, especially when it's a collaborative and group think meeting.

Could you explain what you mean by "recorded"? The distance between full recording and text-only transcription (or summary) is quite large.

In order to get a text-only transcription you need to record it somehow. I can't be sure that a backup audio file isn't stored anywhere, so I believe the same applies. It means that in theory, your conversation with someone else may be shared. I don't consent to that, normally. For presentations, talks etc it's a different matter.

If you store captions produced by a party you trust (e.g., Google Meet), it could be accomplished w/o accessing audio at all. If I get it right, your concern is more about what's in the pipeline than what comes out.

You've ever seen how google captions youtube? It's completely inaccurate.

It's a policy for us, and therefore an expectation, not a request. We also make sure that this isn't a surprise: everyone comes in knowing that we do this (and indeed, many new additions to the team have taken advantage of this by listening to past meetings to come up to speed).

Know that this policy would be illegal in many jurisdictions, especially in the one I live in. Setting it up disqualifies you from being a global employer - at least in theory -, and it's also really unethical. Also workers have a right to their voice and can't be recorded by default.

Have a written record of the meetings outcomes, that's what is actually useful.

I emphatically disagree about it being "unethical" -- we view being recorded as a part of job function. I am also curious (and, frankly, skeptical) about the supposed illegality in your jurisdiction; where do you live?

This would make call centers illegal in many many places as well as calling into those call centers wouldn’t it?

Yes! Anything that required recording as part of job function would be illegal, which I highly doubt is the case -- part of why I'm interested to get to specifics here...

I don’t think you’re going to get them.

See the sibling comment.

Some specifics are in https://www.anwalt.de/rechtstipps/was-muessen-arbeitgeber-be.... This assumes you make video recordings of the meetings, then we are not only talking about the personal rights to the voice, but also to the picture. But similar rules would apply if you only take voice recordings, to my knowledge, it's just less documented.

Of course you can have jobs where the voice recording is absolutely necessary, then it can be allowed by default. Or similarly, of course an actor will be recorded in sound and picture. But that's not the case when doing a regular office job. Specifically your "it's expected from the employers" is what would absolutely make it illegal.

Edit: I actually found a source for this specific question, https://www.anwalt.de/rechtstipps/verboten-video-konferenzen....

Doing it without consent would probably be the only illegal issue you'd run into in virtually every jurisdiction on earth. Otherwise, how would movies, TV shows, or the news get filmed in your country?

We are obviously not talking about positions where recordings are normal and obviously necessary. And parent also specifically did mention that consent is required, thus not freely given, and thus not legal.

“Normal” and “necessary” are subjective and cultural. They are not set in stone or even objective.

Judges are quite used to take this into consideration.

So we are on the same page then. It’s perfectly reasonable to record all meetings at work.

Hey, spare me the bullshit. You know fully well that we are not on the same page. Recording all meetings at work by default for a regular office job is illegal and you have no chance to win the process if any employee sues in Germany. And that would be a costly loss, by the way. You might actually go to jail.

See https://www.anwalt.de/rechtstipps/verboten-video-konferenzen....

This is video calls. Maybe we are talking about different things? I was thinking an audio recording of a real life meeting in a real life office. In that case, I’d expect it to be clear meetings were being recorded and well known. If you don’t want to be recorded, register issues you want brought up in the meeting with someone else in the meeting and just don’t speak or don’t go.

In your article (English translation):

> Documentation by recording is only permissible without voluntarily declared consent if the interest in the recording outweighs the interest in the data protection of the recorded persons

This is a high bar in Germany, but certainly attainable in some situations. I suspect it is highly contextual.

Fair enough :) My work reality did not factor that possibility in.

I don't think it would change all that much. It might make it easier to justify the measure, but you would still have high bars to claim. In the end it would still be an unusual recording, which might negatively impact employees privacy and in a work context lead to conflict. As it is completely possible and way more common to just have text documentation, logs and meeting outcomes, I really am quite confident that even just a regular voice recording of meetings in a real office would not stand in court.

Also, "it's part of our process and employees have no say in it" as in parent's comment would be without any doubt not legal. Given the requirements you now saw I think we can agree on that now :)

Once in a meeting I brought up an idea. A coworker said we could have a different meeting to discuss it but the decision was going to be no. And then I said that we should not have the meeting since the decision was taken.

Said coworker went to the CTO and reported me for refusing to have meetings.

Then I thought I should record the meetings. But I decided that quitting was a much better idea.

I ended up having 2 weeks being paid for not working, so that was a nice extra.

Why record every meeting? Are you actually going to listen back to it? Waste of time and energy to me.

It settles debates about what was discussed, informs people that did not attend, increases discoverability, and promotes transparency. Especially useful in interactions with customers. It's not for your daily stand-up. To quote the inimitable "Yes, Minister" (https://www.youtube.com/watch?v=85fx0LrSMsE):

It is characteristic of all committee discussions and decisions that every member has a vivid recollection of them and that every member's recollection of them differs violently from every other member's recollection. Consequently we accept the convention that the official decisions are those and only those which have officially recorded in the minutes by the officials, from which it emerges with an elegant inevitability that any decision which has been officially reached will have been officially recorded in the minutes by the officials and any decision which is not recorded in the minutes has not been officially reached even if one or more members believe they can recollect it, so in this particular case if the decision had been officially reached it would have been officially recorded in the minutes by the officials. And it isn't so it wasn't.

So there was a laugh track behind that but honestly it seems more like good policy than comedy. If a little blunt.

Yes Minister is fantastic. I recommend the book all the time. It’s satire, but the exaggeration helps you understand real organizational dynamics.

Hmm I’m probably due for a re-read…

> It settles debates about what was discussed, informs people that did not attend, increases discoverability, and promotes transparency. Especially useful in interactions with customers.

Oh, so we're talking about “recording” as in writing down a record? Not “recording” as in “audio recording” of the meeting. Then I agree with that.

Edit: it looks like bcantrill was actually talking about audio recording [1], and then I'm much more skeptical.

[1]: https://news.ycombinator.com/item?id=37972900

In my professional ~20 year experience, throwing evidence in higher powers face that they changed their mind.. is not going to score you any points & give you a win.

Well guys you decided this at the meeting 6 months ago, that's why you aren't getting the feature you just imagined in your dream last week. Guess what, it generally doesn't matter. Stakeholders want what they want, business, customers and requirements evolve. Having "receipts" or thinking that throwing them in peoples face is somehow going to win you arguments is naive.

Having receipts is the difference between "oh I guess I didn't request that 6 months ago. but I want it now, so how much will the change order cost?" and "you're lying and trying to rip me off, you'll be hearing from my lawyers next".

This probably merits a long piece at some point, but recording every meeting has been transformative for us: it's zero time and energy (you just need someone to hit the record button!) and it gives engineers the freedom to not be in a meeting for fear of what will be done in their absence (a surprisingly common motive for attending a meeting!). As for going back through meetings: yes, we definitely do (for a variety of reasons), though the distribution is lumpy (and most meetings are likely never listened to again).

> it gives engineers the freedom to not be in a meeting for fear of what will be done in their absence

Recording the meeting won't prevent what will be done in engineers' absence, will it? Do you mean that engineers have peace of mind that they could listen to the recording and learn about everything discussed in the meeting?

Recordings are a great utility:

Having a record allows all kinds of automated followup, post analysis, etc. This level of business intelligence and actual understanding is helpful in improving organisation function and individual training long term.

Asynchronous is _a_ great next step beyond that:

Moving discussions and decisions async has been a massive improvement in the organisations I have helped. Goes against dogma and habit (with all the huge obstacles that come with it) but pays off quickly.

Discussions are more factual and evidence based.

Decisions are thought through and transparent.

Collective (and individual) memory of what has been discussed, decided, and why is much better.

Training people to be clear, succinct, transparent also help them not get bogged down in gut feeling, habit, dogma, ego, posturing, pestering, politics, etc.

And of course the immediate bonus of individually flexible scheduling and not killing efficiency by slicing everything to administration/manager-mode-time.

Manually, probably not (exceptional circumstances aside).

Recording generally means transcription and the ability to do automatic summarisation and to query action items, which _are_ useful

Also it means folks can be away or if someone didn't quite catch/understand something relevant to them they might want to rewatch some of the meeting.

As someone who recently joined a company that recorded every meeting it did since its creation: yup, this is immensely valuable.

Having access to past meetings is super useful for onboarding. You can get a picture of what everyone is working on super quickly.

totally agree

You also think that learning via youtube tutorials is quick?

I'll take the bait: no, but I think watching a livestream or a video of someone using the tool you need can be better and quicker than a tutorial, text or video.

Documentation is good, but it only gives you what the author wanted to show you. Recordings give you what they cared about, which questions they've considered and which questions they already see as settled, what problems they need help with, etc.

(But the video format isn't ideal. I'm looking into using Whisper on the meeting archive.)

Meeting minutes has been my go-to strategy in the past startups I worked at. We share them on notion, participants can edit / add, while it is also visible to other members to view. Just one notion page with subpage for different meetings.

I believe the idea for the meetings are mostly to plan for something or align the team due to changes in requirements or divergence in execution and as such they should rather discuss limited topic(s). That's why I feel meetings minutes are suffice to reach good consensus

Transcribe and summarize using an llm.

teams can do transcribe well already for me

It makes the information discoverable to people who weren't there that day, to people who will be hired in the future, and to LLMs you may want to train to make all relevant information in the company discoverable.

Having said that, some meetings don't meet these criteria. 1:1 meetings don't for sure, nor do calls centered on conflict resolution.

Just read through your twitter thread, I really appreciate this perspective and I completely agree, a manager's job includes ensuring the right circumstances to foster intrinsic motivation. I think where I might quibble is there are often circumstances where there are genuine skill gaps and, a manager acting as coach, can accelerate someones growth and performance.

Sure -- but why drag the entire organization through a perf process to accommodate those folks? Especially when they are tied to comp, performance review processes are (in my experience) about justifying decisions that have already been made rather than actually earnestly trying to improve an employee's growth: decoupling review from comp and then additionally not having a one-size-fits-all review process allows that coaching and mentoring to go where it's most needed -- and it similarly allows for positive feedback to happen much more quickly, broadly, and earnestly.

I don't think you're comparing apple to apple here.

You are talking about _forward looking_ performance. That is, how to improve performance from here.

Performance reviews in most corporations is _backward looking_, it's about ranking your past performance in the process of allocating compensation and promotions.

You propose a wonderful fw looking process, but at the end of the day, you need some bw performance assessment as well.

Would you mind posting your twitter thread here? I believe one needs an account to read any replies to a tweet, and since the tweet is in the format of a multi-post thread, it's unreadable to me. From some of the comments here, it seems like it would be quite interesting.

EDIT: found it. https://threadreaderapp.com/thread/1216491216356823040.html

> I wouldn't take any of this guide as sacrosanct

That goes without saying, doesn't it? None of this thought leader stuff should be taken literally. The book is literally an advertisement:

>> I'm also happy to discuss advising, coaching, and mentorship opportunities at the same address.

This advice should apply to any book/blog/video not just this book.

Every written text is a state of mind of the author in a point of time. Should never been taken as the only to do things.

People learn and grow, so does their advice and context.

Read to learn perspectives and ideas, not to just follow.

Reply on news.ycombinator.com