Stats for nerds
4recommend
7mentions
6people
2018–2026years
57% recommend43% neutral
Mentions per year
What Hacker News says
- Some of my favorite books around managing software projects and technical leadership:
My website has more book reviews on this topic: https://www.briansnotes.io/audience/tech-lead/* The Manager's Path - read the chapter on being a Tech Lead * Making Work Visible * Accelerate - I can mostly speak from the engineering side here, but my employer (100-250 employees, let's say, over the period of the pandemic) has been doing quite well with "full" remote, and if anything, we've moved from assuming we'd mostly be based out of two Canadian cities into a company with employees all over the world.
With the pandemic, we've effectively jettisoned our offices and for the most part employees seem happy with that.
Some factors: 1. We've always valued good communication between different locations and had always been tweaking how we ensure remote workers weren't ignored or that workers in a particular location felt left out of other teams. This is likely the primary factor, we already were consciously considering our remote employees even when that was relative to a particular office.
2. In 2019 our major office got flooded, and the smaller office had a similar issue happen to them a few years earlier. IT and Corporate had been forced then to be able to support 100% remote work from any location, which removed what would have been a giant transition pain otherwise.
3. Our leadership got into the concept of remote whole-heartedly. I don't entirely know their rationale, but we never really had a managerial need to see "butts in seats" because we have had distributed teams since very early in the company. There was aligned on this through every level. I think a lot of dysfunction also happens because not everyone through the levels of an organization realizes how much becoming remote means investing time in figuring out what that means for your given org or team.
4. Equipment stipends were granted. HR was tasked with finding workshops for employees about communication, mental health, etc ... the pertinent point here is that we were being explicitly guided and supported in various aspects of how to work from home effectively, _including_ communication. It wasn't left to everyone to figure out what to do on their own.
5. As part of the above initiatives on figuring out how the hell to do this, we read "Team Topologies" and other books that wound up being about how to communicate effectively as development teams. We wound up instituting a bunch of things (with input from everyone involved, although usually there was consistency) that came out of a lot of DevOps. I don't know if I can rehash it all here, but it basically was about each team setting clear processes around how communication happens within the team but also between teams.
6. We've always had little rituals for getting people to talk to each other and and know everyone in the company, even in the befor times. We have a scheduled bot that pairs people to have small 15 minute coffee chats; it was a hit when we had offices and people really love it now that everyone is remote. Part of HR's effort was running events that grouped people together in ways that facilitated getting to know other people around you (i.e. not the entire company in a zoom call, but small randomized groups with various attempts at unstructured conversations.)
In many ways, looking back over it, some combination of _always_ caring about communication is a huge part of it. It's a lot easier to just get by when you are in physical locations, but even teams working across offices shows how important conscious and disciplined communication cultures are, and that has to be adopted and tried at an organizational level. Coming from the infrastructure world I find a lot of the DevOps and SRE resources were useful here; Accelerate, Team Toplogies, Making Work Visible, etc... The remote aspect of it has logistical issues, but ultimately it's about information flow and figuring out how to develop trust between team-members and teams.
- If you liked this post, the book Making Work Visible is a great expansion on these topics. Making Work Visible: Exposing Time Theft to Optimize Work & Flow https://www.amazon.com/dp/B09L3B9YK1/ref=cm_sw_r_apan_AX66TB...
- The books on my desk are a combination of reference books and books that are good conversation-starters (I've read them already and don't need them as reference, but they're good for lending out to people, especially junior devs).
Reference:
Good for lending out:- Effective Java (good for learning the mindset of developing backward-compatible APIs in any language) - Enterprise Integration Patterns (I work on an enterprise APIs team) - Designing Data-Intensive Applications - Camel in Action- The Phoenix Project - Making Work Visible - Effective DevOps - The Pragmatic Programmer - REST in Practice - Making Work visible by Domenica Degrandis. I have switch more into it team management role (have been 17 years individual contributor) and Im trying to find good books, any advice welcome
- This is also where automated code quality checks can shine. You can say something like, if it's more than 5 or 10 lines we expect a ticket ID, otherwise we don't.
See DeGrandis’s “Making Work Visible,” the hazard of “link to a ticket if it exists” is that sometimes this causes us to treat tickets as an external process, but we absolutely want to surface tickets that track our cleanup of tech debt and any other procedural tasks that we are stuck doing.
If automated tooling sounds nice but you are at the sort of place where “there are three priority levels: hot, Red Hot, and DO IT NOW,” this can also be part of a pull request template. One extremely effective template we used at a previous job just had quick checklist and you'd check off for example “I tried this code on my dev cluster.” Caught a lot of “whoops I am moving too fast and need to slow down a bit” issues, hah!
