As an engineer (not a manager!) who does a lot of non-engineering tasks: this kind of misses the point. Don't get me wrong - if creating a GitHub issue helps you keep track of things, great.

But GitHub (and most other engineering tracking tools) are meant for relatively clearly defined tasks, and the input on those tasks come only from engineers. But a lot of times we deal with amorphous, poorly defined tasks that involve non-engineers. "Put it in GitHub" is solving the easy part of the problem. The hard part is identifying who are all your stakeholders, getting them onboard, and turning that task that is ill-defined into something well-defined.

I am not sure that's true. They are meant to avoid the need for status meetings by providing more realtime feedback of what is and isn't happening to other people who benefit from knowing where things are at. As long as all interested parties understand the overall intent of the ticket, to know what it being closed means, it doesn't have to be well defined.

If what you want to accomplish is so abstract that you can't even reach a shared understanding with others, they won't need to keep track of your status in the first place (what would they be keeping track of?), so that case is moot.

Managers have Google Docs, Notion, SharePoint and all kinds of other tools that do change tracking and management of these kinds of things. Long before Git was created, these solutions existed (track changes). Git does a horrible job with zipped up bags of binary, xml, json, and the show changes in most corporate document management systems are really better/easier for written word.

I recently moved to a new team that has been using Notion. I can't find any meaningful difference between it and GitHub (which, just like Notion, also uses Markdown as the way to communicate the written word), aside from GitHub making it easier to include non-written word content alongside the written word.

Maybe git in the raw is a little too raw, but what's the appeal over git + something like GitHub that includes all of the higher level features?

Practices that reduce the social status gap of managers above employees are rarely popular.

There are a lot of people out there not trying to do stuff but trying to be someone important. Those people want that separation between them and those they consider lesser.

They are not good managers. But they are legion.

Umm... as an engineer I know the ins and outs of async.

The fact is that synchronous is so much more efficient when it is practical.

You can exchange mails with the other person for 3 weeks to get details of something nailed or get the meeting room with a whiteboard for 2 hours and get out with the complete solution without wasting time typing all those emails.

Asynchronous is for when you can't get that other person/persons in the room and expect to get the thing done in reasonable time.

There is a reason why you don't do standups asynchronously.

There'll also be a written record of the exchange for future reference. The time spent writing the email isn't wasted. It's time saved putting together documentation.

An example on the async side... I worked with a couple of fantastic engineers who would come back with amazing solutions if you let them go away and think about it in depth. That worked particularly well for problems which one person could get their head around with deep focus. If you asked those two for a solution in a meeting or at a whiteboard they'd literally say "I won't answer you in real time." I've seen a lot of solid foundational infrastructure created this way.

On the sync side, I worked on a team that needed relatively senior software engineering knowledge (e.g., stream processing of many MBs/second of data before their were decent open source solutions) and PhD+ level math knowledge. The most valuable tradeoffs tended to be across the software engineering / math boundary (e.g., we could use much simpler math if we could process the data faster or process much less data if the math were a little more sophisticated). But it's very rare to find people who are experts at both. Put experts from each side who are good at interactive communication at a whiteboard and tons of value pours out in an hour or two as they leverage each other's knowledge. I saw one such discussion lead directly to 3,500 LOC in one subsystem being replaced with 500 lines of much simpler code and the math being reduced from graduate level to undergraduate level at the same time.

- have a meeting where you discuss and build a shared intuition for the problem

- tomorrow (or next week or…), have a meeting where you solve the problem

This is closer to what large data processing does:

Synchronize the data, distribute tasks to work, synchronize and compile the results.

The problem was analogous to pricing at Uber or Lyft. The product was very different - not related to transportation in any way. But trying to balance supply and demand through pricing. Supply and demand could vary wildly by the minute and pricing was per customer, so that involved adjusting ~1M prices dozens of times per day. We used control theory, game theory, time series predictions, and lots of other things to understand / control the dynamics of the market and the competition within subsets of the market. I'm convinced the onset of the pandemic would have crushed the company's revenue if this dynamic pricing was not in place. Instead, we merely needed to add some new boundaries to contain what the system was doing (boundaries that were unheard of pre-pandemic like entire sectors of the world economy closing down).

As a software engineer with a BS in Math, I did the first version of this out of intuition without knowing anything about the fields I mentioned above. I was accidentally trying to reinvent control theory without knowing it existed (knowing to do a web search for "control theory" would have helped a lot!).

As time went by and we hired some people with more applicable math knowledge, they were some combination of impressed and amused at what I'd done. And they were able to take it to the next level. Seeing this, and having become the team's manager, I started to hire people with much more advanced math and stats knowledge. Advanced stats people came last and they should have been earlier. It turned out we had shipped multiple experiments that we shouldn't have because we didn't understand that we weren't measuring what we thought we were. As the system got better and better, measuring the impact of our system on indirect market effects became the hardest part of the problem. For example, a change will favor some competitors in the market - is that positive overall? If you think there's a simple-ish answer to that question (like I did at one point), you probably aren't qualified to design / analyze these experiments. wink

Where this eventually led, before I moved on, was the realization that we didn't just need a software architecture, but also a math architecture that helped keep the mathematical dynamics sane and possible to reason about. And it required a lot of effort to help the non-math people in senior management understand this wasn't black magic, but something that needed to be reasoned through by people who understood mathematical rigor (i.e., we needed to continue hiring mathematicians). That's a tough sell given that it's really hard to understand the value of mathematical rigor when you don't have it yourself. We weren't formally proving anything, but when things get complicated, it's really important to understand exactly what assumptions are necessary and when that gets difficult, it's hard to avoid the need for people who know mathematical rigor.

Realistically, quite a lot of emails are ignored until engineer really really need to answer and then he quick writes something hard to interpret.

The common failing I see isn't with synchronous meetings. It's with arbitrarily scheduled synchronous meetings.

Scheduling a recurring meeting for a team is a fantastic way to communicate to everyone that they should wait for that recurring meeting to communicate with the team.

The least productive points in my career have been characterized by recurring meetings. Once a company gets to the point where recurring meetings drive everything, the meetings themselves become the output for a large number of people. Getting work done is secondary, so long as you have something to talk about in the meetings.

Synchronous communication applied judiciously on an as-needed basis is very effective, though. It just shouldn't be the first tool that everyone reaches for for simple problems, nor should it be forced into recurring schedules for the sake of filling up calendars.

But bosses love them as a submission/compliance ritual, a surveillance practice, and another flavor of presenteeism.

Which, indeed, is another reason why bosses love them. With less time working, more workers are needed to get an equivalent amount of work done, increasing the headcount under their watch. As a boss' worth is measured by how many people he leads, it is in his best interest to waste as much time as he can without losing his own job.

The goal is to increase return on investment by reducing the investment while preserving most of the return.

It requires that people are able to show on time, though.

The usefulness of people telling what they will be doing or what problems they are facing at the moment is that they might not know there is somebody else in the team that can help them solve this problem very quickly. Or sometimes people find they are working on same or similar thing.

I also like to think it puts a little bit of pressure on people to get something done so they can show some progress on the next standup.

I have worked on teams of chickens running around with their heads cut off before. While that is one way to try and rein them in, would you not be better served by moving away from making and instead towards engineering?

> I also like to think it puts a little bit of pressure on people to get something done so they can show some progress on the next standup.

From experience, initially it does. But soon you realize that when you're racing the clock you end up taking shortcuts (introducing bugs, making poor design decisions, not properly documenting your work, etc.) that will harm you and your team later.

Appearances aren't worth sacrificing the company over. It is far better to be seen as a poor employee than to be seen as the superhero of a failed business.

This comment will get flagged and deleted shortly. However. Have you considered not using pretentious “grammar”.

The “puts pressure on people” piece is a huge alarm bell of poor people skills.

I’d quit shortly after interacting with you… proper.

A month ago I signed up for a marathon that is in the fall. I then told my family, friends and coworkers. This puts a bit of pressure on me to get results. I did not strictly have to do this but, in my experience ,it makes it more likely I will complete my training.

See, most people need a little pressure to be successful because we are naturally lazy. And yes, this includes me.

If you want to work in an environment that puts absolutely no pressure on you, sure, do your own thing. There are places where nobody cares for results.

But ask anybody who knows anything and they will tell you these are not good places for people who want to be successful.

Too little, or too much, of either is the problem to avoid.

There are plenty of teams that do standups async. I dont need to know what everyone else is working on on a daily basis. Not to mention a 15 min recurring meeting to start the day is soul sucking, especially when you hear the words ‘I have a blocker’ and it becomes a 30 min meeting

This allows everyone to investigate, think, prepare questions and organize ideas/approaches.

Without that sync time is wasted explaining the basic premise

> Ben Balter is Chief of Staff for Security and Engineering at GitHub.

This matters because async can become more efficient than sync when it prevents you from having to repeat yourself, but you lose this efficiency if you don't invest in clear writing that is easy to parse (repeatedly) to begin with.

"What takes 30 seconds to say takes 5 hours to reverse engineer and another 10 hours to document."

There's power in recording words, especially if you consider the fact that you may not work at the same place forever and people need to come behind you with concrete context to build upon what you created. This is a difficult task without recorded history.

I think this point gets lost in these discussions in favor of the immediate meaning.

Writing ensures that

  a) it was important enough to spend time writing out
  b) the ask has been thought through and can be communicated in clear terms (and via written clarifying questions)
  c) the conversation can scale beyond half duplex in the same space and timezone
  d) there is a log of the ask, questions, responses, etc. for posterity

There is a reason PM tools exist. It’s because they bring value.

Sure you could manage a project in VIM…

But no. It’s dumb.

All of the things mentioned here in the "How" focus on a fairly small subset of the overall things in the "What", and IMHO, the platitudes expressed in the "What" are nice, but sort of miss the forest for the trees in a number of ways (and without being too mean - have been better expressed before). People are barely mentioned, but are actually the central thing you are trying to help be able to achieve their goals.

Anyway, let's ignore the "What" for a second

The "How" is reasonable for managers of smaller teams, where large amounts of time are spent in the planning, tracking, etc.

With the caveat that even there, while it can be a large time sink, teams don't succeed or fail mainly because of the tooling you use, or how effective a task master you are. Certainly teams need effective, low overhead processes to do planning/tracking/etc. But beyond that, it mostly matters what the humans want out of their managers, and nothing in that "How" covers any of that. The people in the team aren't likely to say"well, now that we use markdown, i feel so much better about my job, life and career!" How does their manager treat them? How does the manager support and grow them? How does the manager make sure they are doing valuable work, and it is seen as valued? etc That is what people are looking for, for the most part. You would be much better off with a super-empathetic manager who could make people feel valued and help them succeed, but totally sucked at process, than the opposite.

Process can be delegated and contributed to by others, it does not have to be the manager. Empathy, empowerment, etc, is ... harder to delegate.

On top of that, as you grow, the piece the "How" covers becomes less and les. If you have a 300 person org, basically nothing in the "How" would be applicable.

As you grow as a manager, and end up with larger and larger organizations, most of your time does not go to those things, nor would it make sense to. More and more of it is spent on identifying talent, growing and mentoring people who have skill sets that complement yours (and delegating to them), and building and driving the right set of cultural values in an organization. Things like that. Most people would likely consider their VP watching over their project board as micro-management of the nth degree (to the degree it helps people feel like their work is visible and cared about by leadership, there are better ways)

There is always some amount of work on process/planning/etc, some amount of work on aligning people/resolving escalations/whatever, but honestly, a good goal is to try to make yourself obsolete through growing and helping the organization become capable of driving the outcomes it needs, without you being there (and all the things it involves to get to that point).

None of this means you shouldn't be trying to find ways to be open, transparent, and clear about the things you do.

But the "How" here is only going to take you a small part of the way if your career is manager.

There, if you are starting out and trying to learn to be a good manager, there are overall more coherent and complete approaches that may be more helpful.

A good recent book on this is "Engineering management for the rest of us"

Well, that is remarkably fortunate.

I think it would be positive of some mathematical or computer knowledge was used, like "don't just throw more people at the problem," "context switching cost" (and generally the whole work scheduling field).

But again "management" is not about people in most companies, but about keeping the jobs of the higher ups. It might be painful for all of us, but it is not like all managers don't know how to improve things.

I like how they include planning an offsite as something that could be done with these tools. I like to think that the plane tickets and hotel accommodations are booked through API calls run in the CI/CD pipeline. The CI/CD pipeline runs when the PR is finally merged.

Much monies could have been saved if the tickets and accommodations were booked sooner, but there was contentious discussion the style guide that happened as the result of the PR.