Early career tips

I’ve got a post in the queue that I’ve been struggling with, as it turns out to be a more complex project than I originally thought – I’ve had a few people ask why I started writing this blog, and it seemed like a fine time to tackle that. But it’s taking more time to put that into words than I originally estimated, and I don’t want to leave you without something to read for too long! (I know I get impatient with my favorite blogs, sometimes. Hopefully I’m making it into your list of favorites! #purelyselfish)

Anyhow, I read this StackOverflow blog post today, and I really enjoyed some of the tips. Not only do they point out how important 1:1s are (more important than you may think!), but they also provide some advice on how to best utilize that time. They share ‘default topics’ you can return to whenever you need inspiration, from Current Projects, to Feedback, Professional Development, and Future Opportunities.

They also point out that you should thank the other person for their time and this 1:1. They imply that the employee should thank the manager, but I believe that the manager should thank the employee as well – we wouldn’t have jobs without the other person in that relationship! And being grateful has positive effects on your mood, no matter who you are. (If you’d like more tips on developing your sense of gratitude, check out Grateful.)

Thanks for joining me today!

This book, The Making of a Manager, came up in conversation with a (non-manager) friend recently, and I thought I’d share some of our conversation, and my thoughts, here. I’m also including an Amazon Affiliates link, so if you’re curious about the book, please feel free to purchase it through me #purelyselfish 🙂

I told my friend that, “some books feel like a nearly-remembered memory, if that makes sense, so I read them more for new techniques to try than for the thrills” and my friend pointed out Zhuo’s book felt like that, and was “best read academically.” I totally agree – this is a great book for you to use to learn some techniques you can try in the office, whether you’re a manager or not. Zhuo’s tips on planning, for example, would benefit any corporate type, regardless of individual contributor or manager status. Same with her tips on earning trust.

Zhuo also gives the reader great insight into the practice of management, and what makes a good manager (or not). I like her inner voice, and how she shares the experience of executing when you don’t have all the answers, which make this book extraordinarily relatable. She uses clear, easy-to-understand language throughout. This, coupled with her easy voice, made me read through it so quickly I wanted to start again immediately after I finished (in case I missed something critical!)

I didn’t start over after I finished, but I did cycle back through the book to re-read some of the pieces that I needed the most, at that exact moment – making an impact through my team, managing my mistakes, etc.

This book feels like an approachable advisor, and having it around to refer back to makes me feel more confident in my ability to excel as a manager. It’s not a pleasure read, but it’s exceedingly pleasant to read, regardless.

A question I’ve gotten from my mentees and directs before, but haven’t written anything about (yet), goes something like, “How do you speak up in meetings? How to you interrupt? What do you even say!?”

This Harvard Business Review YouTube video came out about 2 weeks ago, but I only caught it today, and I think it has a pretty good answer to that anguished question I’ve heard so many times before. Basically, you need to have a plan for what you’ll say. There’s more to the video, though, so… Check it out!

I started this blog, thinking I have information and interests that may help early- and mid-career technologists. I’m beginning to share tips, tricks, and learnings here. I generated some of these learnings through my own hard work, with years of trial & error. I gathered other tidbits via my voracious appetite for reading and love of sharing what I read. No matter how much work I put in, though, the one key ingredient leading to blog success is reader feedback. If you find any of this article helpful, do let me know (my email’s in the footer of this page). If you’re confused, ask me about it! If you disagree with a point I make, please take a moment to enlighten me. The single thing that I can guarantee will happen if you reach out, is that I’ll listen – if you’re lucky, I may even reply directly. This blog lives and dies on your feedback, so please do share!

I’ll bet you’ve heard your manager, senior staff, and leaders share their rules of thumb for managing their calendar, or scheduling their time. One guideline I hear at AWS is that you should spend 10% of each week learning new skills, or improving those skills you use to perform your job.

You might have heard about the book Deep Work. I’m just tossing it out there, really quick, that you might want to check out. See, Cal Newport wrote the book on reducing distractibility by scheduling Deep Work, and here I am writing a blog post about a different, related concept (and, I suppose, sharing Cal’s idea with you).

The single limiting factor in your schedule is simply having enough time, which leaves you to wonder… Celeste, have you found any rules-of-thumb that we should absolutely apply to our own calendars, and our own process controls?

Yes! I have something I believe you’ll like. I generated an ‘ideal schedule’ for me. I built it through trial and error, observing my emotions and work output each time I changed how I schedule myself over the course of years. I aim for a distribution across the following buckets in a “standard work week” of 40 hours:

  • 10% – about 4 hours – learning new job-relevant functional skills or iterating upon and improving existing ones
  • 20% – 8 hours – sustaining engineering – where I address my current source(s) of technical debt, or prevent more from occurring. Take a look at the article Manual work is a bug, which I absolutely love and live by, and comment further upon, below
  • 10% – 4 hours – get moving, get away from your desk, kitchen table, wherever you’re working and eat lunch, maybe even go for a walk! If I know I won’t need to take notes, I’ve enjoyed walking meetings, where I plug in my headphones and walk to the park a few blocks away, absorbing some nature as we walk and talk
  • 50% – 20 hours – performing core work: planning sprint, documenting programs, managing feature requests, retrospecting, mentoring peers, writing code, executing tests, standing-up, emailing, coaching, pairing, meeting, creating, interviewing, debriefing, offering feedback, managing incoming tickets, managing the ticket queue, escalating problems, sketching ideas, opening tickets to others, 1:1s, and so on – these are the tasks that you prioritize relentlessly, as without completing these tasks, you’re not out-putting any work
  • 10% – the last 4 hours – this gets unavoidably lost through context switching, breaks, and other low-output effort – even so, I try and pay attention here to see if I can further reduce this bucket, over time, and with focused attention to its reduction and eventual elimination

You’ll notice these buckets add up to 100% – exactly 40 hours – like I planned it or something. While I strive for the former, ideal ratio, I understand that nothing’s perfect, either. Some weeks I work more than 40 hours, and others I work fewer. Some weeks I focus primarily on one of my core work functions (like when I write a roadmap document), while others I focus on none in particular, bouncing between tasks at great speed. Some weeks I utilize different buckets, for example when I’m attending a conference and volunteering at a booth trying to recruit new teammates. That could conceivably slot into my ‘core work’ bucket, but I don’t typically categorize work travel into my core work bucket – just a personal preference. You are welcome to categorize your own obligations however works best for you, and if you have a neat spin on the matter, I’d love to hear about the special thing that you do!

You set yourself up for success with a program by scheduling it. Hopefully the scheduling guidelines I’ve shared help you think about the problem of calendar maintenance in a new light, and empower you to own your own time!

Appendix A: Links, Tips, and Tricks

If you were in the office with me, you would already know how much I love this article, since it outlines a dead-simple framework for iterative improvement, encouraging the reader to automate nearly everything in life and work: Manual work is a bug, “The successful engineer realizes that the earlier he starts collaborating, the sooner others can contribute. Together they can create a culture of documentation that spreads throughout the team. Thus, every project is collaborative and has a “stone soup” feeling, as all are invited to bring their skills and insights. The more people who embody this culture, the more success it has.” How thrilling is that!? It’s almost like open source for your office culture. Kind of (I might be stretching the simile a bit too far there.) If you already have teammates who clearly document their code and processes, you know exactly how special they are. Make sure to keep ‘em!

I don’t have as good a reference link for my second tip, but I suggest you A/B test your own life, as well as your own calendar. An A/B test allows the intrepid scientist to compare two treatments for the same scenario and see which has the more favorable output. Say… I know that I’ll be walking to the office in the rain several days this week, but I haven’t quite mastered the art of layering like the rest of Seattle. So on Monday I plan to wear my Patagonia fleece and my hand-me-down rain slicker, and on Tuesday I plan on wearing a barn-find vest, long-sleeved light Goodwill sweater, and a water-resistant canvas coat. I can objectively say which of the two outfits is more comfortable and breathable. Once I get into the office, I will check out how wet I’ve gotten, and see how cold I am (or am not). Both days, I’ll verify the amount of rain that dropped during the walk, and note the outside temperature. This helps me understand which combination of layers is more ideal for keeping me warm and dry during my winter commute. For every test condition and whichever treatment option turns out to “feel better” or increase your output or lets you see your mistakes more easily or whatever…use that! Then, remember to iterate on these improvements, as well.

Between improving your automation and continual self-testing, (and iterating on each) you’ll find your own productivity growing rapidly.

Yes, we all know by now that networking is somehow an essential to succeed in the career world, and there are about a zillion articles on how to network, who to network with, and why networking is so important. And yet, here I am looking to add something useful to the pile. I decided to write this simply because I felt that I hadn’t found the article that I once needed, anywhere in that pile. I’m sharing three steps to networking that feel authentic to me, have provided me with some measure of success, and may or may not gel with how you manage your own personal networking process – either way, I’d love to hear from you, what do you think about my twist on the idea? Keep reading… 😀

I have three steps that I use to network. I think, like many problems that you see articles about all the time, the wealth of opportunity to discuss and break down the issue means that a lot of folks take that opportunity to add their perspective. And on the Internet, it costs hardly anything to publish an article that will illuminate the solution to everyone’s concern. Networking is one of these big, ambiguous problems that we all hear we need to do, but no one seems to know exactly how to go about it. So, here’s what I do to network. I set a goal, build an algorithm to meet the goal, and then review my progress.

First, I start with a goal in mind – I need to meet three new people at this conference because I’m recruiting for an open job req, or I want to ask for help with a specific project and I suspect there’s someone in my circle with expertise in that exact thing (but I don’t yet know who), or similar. The goal needs to be concrete for this to work – I need to meet *three* new people, for example. If I just told myself, Celeste you need to meet some people at this meetup (it’s in the name!) then sure, I could maybe force myself to meet a person but my inner introvert would start squawking and who knows if I’d say hello to anyone after all.

Now that I have a concrete goal in mind, I break it down into its component parts – I build the algorithm for success. I know that there has to be someone in my circle who uses Guice and can help me troubleshoot the Inject problem I am having. How can I get an introduction to them? I can reach out to five people I know who use Java at work, and ask them if they use Guice or know someone who does, and could they introduce me on. Five emails or Slack messages or SMSes takes oh, five minutes to draft and send, and then from there all I need to do is wait for a response. If a day or so goes by and no one has responded, or responded in the negative, I know I need to find five more people to ping. If someone gives me a name, I quickly follow up with that person – as that’s one step closer to my goal.

Throughout the process, I review my progress. It wouldn’t do to forget to follow up with a person I said I’d reach out to, or to sit at that meetup staring at my phone screen, or whatever other idea I can come up with to procrastinate on my networking goal. This ongoing review helps me to iterate if I need to come at the problem at a slightly different angle than I originally thought, and lets me sanity check if I’m being a bit too hard on myself. I sometimes have a tendency to think in very rigid terms, and I might find myself in a spot where I have an 80% solution fall into my lap but I’m so focused on the 100% that I don’t notice the pretty-good option at all – and that’s a terrible place to trap yourself, don’t do it! If I am at a meetup and I’ve met two new people, but the second person has completely entranced me with their story of a product launch gone wrong, I may acknowledge that the event’s ending with me only 2/3 of the way to my goal, but I have developed a promising potential mentorship relationship with the person who’s number 2 of 3, maybe that’s a win. (Or maybe I make sure to shake hands with someone who looks friendly on the way out!)

Review also helps me recognize when I’m done-done. Yes, I have found that Guice expert and they were willing to help me troubleshoot my error, or I have met three new people at this meetup and I can go home and change into pajamas while congratulating myself on my job well done. It feels good to complete a goal, and reviewing that as I go allows me to access a fast feedback loop. (Faster feedback is better than slower feedback, as you can iterate more quickly to success!)

So, knowing now that networking can get broken down into three steps just like any other project you might want to tackle, are you going to give it a whirl? Let me know how it works for you! I’d love to hear your thoughts (and yes, I’m looking for a fast feedback loop on this blog post, you know it!)