19 ms·
Manage like an engineer
- jsejcksn 4y agoBen’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.
- ssgodderidge 4y agoObservability 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
- musicale 4y agoGreat idea but it violates the mushroom management rule of keeping employees in the dark and dumping on them. Knowledge is power, and power is to be held tightly. Practices that reduce the social status gap of managers above employees are rarely popular.
- igetspam 4y agoAs an engineering manager, I'm sad for you. I believe in almost full transparency with my teams. The only things I keep private are personal items and things that are not yet ready to be shared.
- Quarrelsome 4y agoI think they're being sarcastic.
- _carbyau_ 4y agoNot sarcasm to truthfully describe the motives of many managers. 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.
- chiggsy 4y agoSo... there are no tools used for managing people that are not used for managing software? Well, that is remarkably fortunate.
- jiaaro 4y agoYeah - It does seem like the author is trying to apply too many lessons learned from managing computers and software to managing people.
- eftychis 4y agoTo be fair the other approach of a lot of managers and companies is to manage people as itemized resources -- and not for the convenience. 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.
- ElijahLynn 4y agofwiw, the OP is: > Ben Balter is Chief of Staff for Security and Engineering at GitHub
- deleted 4y ago[deleted]
- marvin_3050 4y agoSounds like Jira to me
- deleted 4y ago[deleted]
- mateo411 4y agoMe too. 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.
- ElijahLynn 4y agoMaybe some examples in the OP would be useful too. e.g. An example of the offsite planning using GH Issues, Projects, screenshots.
- mateo411 4y agoThat's a more mature and level headed take than what I suggested.
- winphone1974 4y agoThis 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?
- midiguy 4y agoI prefer engineering like a manager
- indymike 4y agoI 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.
- japanman425 4y agoPerformanceTracker-March-2001-final_updated_for_2003-new(2).doc
- randomdata 4y ago> 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?
- seveibar 4y agoIt’s nice to have a structured review system. I find this is most difficult with Notion vs Github, there are a lot of conventions in Github around approval processes and sources of truth (eg CODEOWNERS, Github Flow)
- lavventura 4y agoWhy not using Org mode files instead of Markdown files?
- lloydatkinson 4y agoBecause outside of the bubble not everyone knows or wants to use emacs. Markdown is a lot more well used.
- japanman425 4y agoWtf is org mode? - 70% of people here, 100% of people outside of here.
- lloydatkinson 4y agoExactly this. HN really does exist in this weird bubble.
- lavventura 4y agoOrg Mode = `Your life in plain text`. Link: https://orgmode.org https://orgmode.org
- lavventura 4y agoYou are not required to use emacs for the org mode. Org files can be edited with any flat-text editor (e.g., Vim, Atom, or Visual Studio Code), and many have plugins that help create and manage Org files.
- lloydatkinson 4y agoAlmost all of those already fully support plain text and markdown without plugins. It's never gonna happen.
- blowski 4y agoThis is all the “administrivia” of management, and the tools you choose won’t make much difference.
- twawaaay 4y ago> Asynchronous first 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.
- japanman425 4y agoI 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.
- twawaaay 4y agoDepends on how long your standups are and how disciplined the team is. I try to keep standups under 5 minutes after which most people can get back to whatever they are doing. 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.
- randomdata 4y agoWhat kind of useful team conversation is taking place in under five minutes?
- twawaaay 4y agoNot a conversation. There is an information exchange that may also lead to a conversation. If this is the case, the conversation happens after standup proper. 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.
- kerpotgh 4y agoAsync 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.
- bentona 4y agoMaybe 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.
- kerpotgh 4y agoDefinitely, async has its place and it’s for long term documentation. Most daily things in engineering do not fall into that bucket in my experience.
- throwbadubadu 4y agoSounds 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!
- cramjabsyn 4y agoSomething 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
- 4y ago
- rcgorton 4y ago[dead]
- ElijahLynn 4y agoFWIW, the OP of the article is: > Ben Balter is Chief of Staff for Security and Engineering at GitHub.
- igetspam 4y agoThat 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.
- jkingsbery 4y ago> 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.
- randomdata 4y ago> 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.
- DannyBee 4y agoA couple things 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"
- imwillofficial 4y agoThis is the worst management idea I’ve ever heard. Ever. 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 4y agoObviously. You'd use Emacs for that.
- imwillofficial 4y agoI no shit have a coworker who does this hahahaha a straight savage.