> Need to prepare a deck for a business review? Open an issue. Want to refresh our career ladders? Open an issue. Planning an offsite? You guessed it, open an issue.
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.
> But GitHub (and most other engineering tracking tools) are meant for relatively clearly defined tasks
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.
I think the author is talking about things like OKRs and other management documents.
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.
> 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?
This doesn't make any sense to me, a manager with a technical background. I do use these tools... For their intended purpose. The implication here is there are no functions in management without a software development analog?
Ben’s continuous mantra of observability has resonated strongly with me. I have learned so much more from researching and reflecting on the indexed artifacts of others’ public discourse than from any ephemeral meeting.
Observability is highly underrated for management. The best managers I’ve had have public calendars, so we can see what they’re spending their time. Priority is pretty clear when management is spending time on something
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.
Get me in a whiteboard session, and you get responses that I've spent 15 seconds tops thinking about. Send me an email and you'll get responses that I've spent an hour or two thinking about.
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.
Synchronous is fantastic when applied appropriately.
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.
My experience is that people are very good at identifying meetings that could have been emails and terrible at identifying month long email threads that could have been a 30 minute meeting.
I push for async stand ups because they’re just such a waste of time. Look at the frigging board if you want to know what’s going on. Blockers should be brought up as soon as they occur.
> There is a reason why you don't do standups asynchronously.
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
We’ve been doing async standups and it’s been fine. The thing that really requires synchrony is if there’s a blocker which we deal with as they occur on an ad-hoc basis.
The important thing about stand-ups is that you are standing up, and not comfortable in your chair. They should probably be renamed to stand on one foots to emphasize that the point is to get them over with so you can get back to work.
That makes some sense. I think GitHub projects are bad for just about all tracking purposes except code and I find them to be rather mediocre for that. I have people that push to use them all the time because it's built in.
Async is the most inefficient bullshit ever. Something that takes 30 seconds to say takes 5 mins to write and another 10 mins to parse and that’s if there are no further questions.
Maybe an aside, and I don't necessarily disagree that async is sometimes inefficient, but it's more efficient if you bias for reading instead of writing. For example, take 15-20 minutes to write the thing, so it only takes 3-5 minutes to parse.
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.
I don't disagree with this sentiment. However, my counter point would be:
"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.
Something that takes 30 seconds to say takes 30 seconds to forget.
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
Sounds like very bad writing and/or reading skills to me - in what state are your docs, requirements, etc?
If I just stupidly write down what I would similarly babble (and must be that way, because parsing that takes double time of that?) - then at most twofold slower.. factor 10 only possible on mobile maybe. Now parse that!
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"
That was my first thought too. Engineers are famously bad at people-stuff. Not all engineers, but enough spectacular examples for me to cringe at the headline.
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.
[+] [-] jkingsbery|3 years ago|reply
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.
[+] [-] randomdata|3 years ago|reply
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.
[+] [-] indymike|3 years ago|reply
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.
[+] [-] japanman425|3 years ago|reply
[+] [-] randomdata|3 years ago|reply
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?
[+] [-] winphone1974|3 years ago|reply
[+] [-] jsejcksn|3 years ago|reply
[+] [-] ssgodderidge|3 years ago|reply
[+] [-] twawaaay|3 years ago|reply
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.
[+] [-] chrsig|3 years ago|reply
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.
[+] [-] PragmaticPulp|3 years ago|reply
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.
[+] [-] UncleMeat|3 years ago|reply
[+] [-] japanman425|3 years ago|reply
[+] [-] hw|3 years ago|reply
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
[+] [-] andreareina|3 years ago|reply
[+] [-] babyshake|3 years ago|reply
[+] [-] cramjabsyn|3 years ago|reply
This allows everyone to investigate, think, prepare questions and organize ideas/approaches.
Without that sync time is wasted explaining the basic premise
[+] [-] blowski|3 years ago|reply
[+] [-] ElijahLynn|3 years ago|reply
> Ben Balter is Chief of Staff for Security and Engineering at GitHub.
[+] [-] igetspam|3 years ago|reply
[+] [-] kerpotgh|3 years ago|reply
[+] [-] bentona|3 years ago|reply
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.
[+] [-] bojo|3 years ago|reply
"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.
[+] [-] cramjabsyn|3 years ago|reply
Writing ensures that
[+] [-] throwbadubadu|3 years ago|reply
If I just stupidly write down what I would similarly babble (and must be that way, because parsing that takes double time of that?) - then at most twofold slower.. factor 10 only possible on mobile maybe. Now parse that!
[+] [-] imwillofficial|3 years ago|reply
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.
[+] [-] disgruntledphd2|3 years ago|reply
[+] [-] DannyBee|3 years ago|reply
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"
[+] [-] lavventura|3 years ago|reply
[+] [-] lloydatkinson|3 years ago|reply
[+] [-] chiggsy|3 years ago|reply
Well, that is remarkably fortunate.
[+] [-] jiaaro|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] midiguy|3 years ago|reply
[+] [-] klyrs|3 years ago|reply
[+] [-] e2e4|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] rcgorton|3 years ago|reply
[deleted]
[+] [-] marvin_3050|3 years ago|reply
[+] [-] mateo411|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]