As some of you already know, I’ve spent most of this week in London, UK. My first and only time in London was back in 2009, when I went there for a PHP conference (see this post, and this post).
This trip was very different. I stayed longer than the last time. I was mostly for business. I had much less time to explore the city as a tourist. So I thought I’d write it up, in case I case I need to remember some of it later.
“The Engineer/Manager Pendulum” is a great article about a career shift from engineering to management. Anybody who’s in engineering now and plans or even just wants to become a manager should read this. Anybody responsible for “promoting” engineers to managers must read this too.
1. Becoming a manager is not a promotion – it's a lateral move onto a parallel track. You're back at junior level in many key skills.
— Sarah Mei (@sarahmei) May 11, 2017
Timofey Nevolin wrote an excellent article “Eight Rules for Effective Software Production” over at Toptal.com. The whole thing is well worth a read, but here are the 8 rules to get you started:
All of these are good and true, but if I had to pick one, I’d say that rule 4 is my personal favorite. Sometimes I feel like I’ve spent a good quarter of my life in meetings, discussions, and other estimation sessions. And looking back at all of them, I have to honestly say that they all of them were a waste of time. The only useful part of an estimation session is a high-level project plan, but that can be achieved with a project planning session – much narrower goal, much more measurable, and much easier to achieve.
Jason Fried has an excellent write-up on the pros and cons of using group chat for the team communications, and some of the ways to make it better. We use HipChat in the company and while it’s vital to our operations and I can’t even begin to think how we could do what we do without it, it does have some negative side effects – exactly as James describes them.
The most valuable advice out of that long article is this one (I’ve heard it before a few times, but it’s worth repeating):
Think about it like sleep. If someone was interrupted every 15 minutes while they were trying to sleep, you wouldn’t think they’d be getting a good night’s sleep. So how can getting interrupted all day long lead to a good day’s work?
Sara Rosso shares some thoughts on what to document and share, after publishing over a 1,000,000 words while working at Automattic. Here’s the gist of it:
- If you’re the go-to person for something in your company, consider how much of it is just gatekeeper information you could document properly to help someone else learn/grow from or work on independently.
- Separate out processes and historical background from your strategic expertise. Processes and backstory are not really ‘what you know.’ It’s much better to be a person someone asks ‘why’ or ‘when’ to do something vs. the logistics of a ‘how.’ How can and should be documented for others to build off of regardless of your involvement. This should free you up to be more involved in the why, the new, and the next of your work.
- If you’re repeating yourself in private chats or (gasp!) email on a specific topic, document it. That’s also what drove me to create this blog – being able to answer someone’s question with an answer you’ve already carefully crafted for someone else is a great feeling (and a great use of your time)!
- Will someone want to know why you decided or executed something a specific way later? Share as much background as possible so colleagues are brought up to speed immediately. Share the setup & thought process you went through, where to find more information, and even the facts, ideas, or information you considered but deemed outside of scope for the particular project. My goal is to hopefully never have someone ask “where did this come from?” or “what’s your source?” or “did you consider this?” (when I had) and instead focus on enriching the discussion or challenging my ideas vs. asking me for information I should have provided in the original post.
- Gather the best, most complete, or authoritative things you’ve authored and submit them as potential onboarding materials for new team members. Challenge them to ask questions and to find something you need to document.
- If important progress is made, be sure to update your documentation, or retire in favor of something newer or more complete. We do this by linking from old posts to new ones, and all it takes is a quick comment and a link on an old post.