💎 Gems from the Soft Skills Engineering podcast 💎
"I don't want to over- or under-explain this."
It can be hard to talk about technical things in a way that makes sense to non-technical people. It is actually worth asking "Help me understand what you already know about this subject." This can help you calibrate your communication. "I don't want to over- or under-explain this" is a phrase I use a lot.
Think about "culture add" instead of "culture fit" when hiring
A replacement for "culture fit" is "culture add". The idea is, "will this person add to the culture that we want to build?" instead of focusing on "do they look and sound and act like us?" That's one of the benefits of having a well-defined culture that you strive for; now you can assess where your group is deficient and specifically hire people who fill those gaps.
Metaphor for bureaucracy as a load balancer
I think of bureaucracy as a load balancer on a web server. You could go faster if you bypassed the load balancer and went straight to the web server: it's one less network hop, it's a little less processing time, maybe you shave a few milliseconds off of every request. But, you can serve a lot more requests concurrently if you're willing to take that little overhead and have a load balancer in your web service. I think of well-designed bureaucracy as that. Well-designed bureaucracy facilitates large-scale collaboration and large-scale progress even though it reduces the optimization of individual resources or people getting things done.
Naming a project makes it memorable
Give the project a name. For whatever reason, when projects or ideas have names, they get purchase in people's minds more permanently. Instead of "that long thing that takes three paragraphs to describe that people can't remember the details of", if you give it a name, like "The Jabberwocky Project", it will stick in people's minds.
Adopting multiple technologies increases ramp-up time for learning their gotchas.
It is actually hard to be productive and effective in different technologies (e.g. web frameworks) because each has their own razorblades hiding around corners that you can walk into and get cut and not realize it. Part of the skill of using a particular technology is building a mental checklist of all the things you can do wrong in that technology. So if you use two technologies, that could result in more quality problems in your product because the developers are making mistakes that don't need to be made because they haven't learned it yet. So you have a doubling of ramp-up time for when your developers can be productive.
Effective documentation culture comes from writing *first*, not last.
Effective documentation culture comes from writing *first*, not last. It's not build a bunch of stuff and then go back and do the drudge work of writing down what you built. It's writing down what you plan to build, using that as a tool for reviewing with others whether you're on the right track, and then build it, and then (and this doesn't even happen at good documentation culture places), go back and update your documentation to match what you built.
1:1s are sometimes very helpful and otherwise not harmful.
In my mind, having a regular one-on-one scheduled with your manager is there because sometimes it will be very helpful, and the rest of the time it won't be harmful. Sometimes you'll have really important stuff to talk about, or you'll share important information or context that will change things. And the rest of the time you're just getting to know that person. You have to have that cadence and habit of talking for when there is something really important to talk about.