We were supposed to hear about my interview feedback writing process next, but I’ll keep that simmering on the back burner in order to get a more-timely reply out to a direct question, thus we’ll talk about getting feedback on your feedback today…

Alan, a friend who wrote to me on LinkedIn, asked how someone like me, a long-timer at Amazon, might gather feedback on confidential written interview feedback. At many mid-to-large companies, that feedback’s generally pretty well-protected in order to ensure psychological safety for the everyone on the loop, and to help ensure an un-biased hiring process overall.

“I’ll be interested if you could address how you got feedback on your review write-ups to improve them. Beyond the initial shadows of your interview how did you continue to improve your writeups?”

— Alan Hudson, Manager, Amazon Games Tech at AWS

Amazonians carefully guard interview details and our written feedback – we consider it highly protected and extremely sensitive information, right – I can see why you’d be curious about techniques to gather feedback here. It’s not easy, especially since you’re risking legal and policy matters.

One tactic I use is find out who are the “silent/other Bar Raisers” on a loop – sometimes the HM identifies themselves as a Bar Raiser, but one or more of the other interviewers also has or seeks BR certification. Because these calibrated interviewers also know all the details of the candidate’s performance on this specific loop, they straddle an improved position for criticism and improvements on your written feedback. Their unique position and knowledge allows them to speak to your work without crossing boundaries in re: candidate confidentiality and psychological safety.

Another way to gather specific, safe, policy-complaint feedback: via your BR mentor. Most people seem to limit contact with their BR mentor to their BRIT period. You know what? I still talk to my BR mentor from time to time, and I graduated as a full-fledged BR “many moons ago.” Your BR mentor also knows details of your work habits and patterns, and can also catch when you use the wrong “your/you’re” — like you do, every time you write feedback in a hurry.

You could also reach out to your BR Core or speak to your HRBP to confidentially discuss your draft written feedback, or to post-mortem the way your feedback was covered in a debrief, say if something went pretty wrong and/or you need to communicate up above your typical escalation points. It would likely seem unusual to effectively ‘just say hello’, but you could also reach out seeking a different point of view on your typical loop and the associated written feedback. I’m not sure why we don’t reach out to HR or the BR Core more frequently, but imagining it certainly gives me butterflies, so perhaps it’s simple human respect for / fear of authority that limits our access to those resources.

So, besides using your BR mentor (before or after you graduate the BRIT program), asking others on the same loop as you for thoughts and suggestions, and seeking feedback from your HRBP and BR Core, are there any other suggestions you know of, that I may have missed in this article?

… and what in the world do I do when I realize I’m not!?

I spend a fair amount of time, as a people manager, dealing with ‘fires’, everything from building a rush interview loop for a candidate with other offers, to escalating a show-stopping problem that appeared late in the working plan for a high-profile project, in the hopes that we finish something like on time (or, perhaps only kind of late…) You may have used the four quadrant model to identify a fire, in the past – fires are urgent tasks, which may or may not be important (refer to Stephen R. Covey’s The 7 Habits of Highly Effective People for more on the four quadrant model).

Fires represent one exciting part of my job, where I get an opportunity to act decisively, which appeals to me greatly; the high stakes that come with every fire keep me interested and stimulated, while letting me learn something new every day. (Learning motivates me more than most of the other verbs do.)

You may have already experienced one or more negative states in your work life, but when you have many urgent matters competing for your attention, you risk one or more of a state of overwhelm, making frequent errors and finding peer mistakes, or even your own and others’ burning out.

In order to ensure I stay on top of the ‘right things’ without simply working harder and thus overworking myself into a state of burnout, I create a rubric that helps me evaluate and prioritize among the many items jockeying for attention. For each project or deliverable, I ask myself:

  • Is this something that I / we may fix through some kind of preventative measure? If not, how do we generate a fix?
  • How do I / we measure success in this arena? We don’t want to work to produce an outcome we can’t perceive – and if we can’t measure it, we can’t perceive it.
  • What’s the expected lifespan and level of impact to deliver this control? (the ratio here should be favorable – if we work for 6 weeks to deliver a fix that will disappear in the next quarter, was it worth the effort?)
  • Number of owners or systems impacted? Who’s the customer, and how many of them are there? We generally prefer a greater impact over a lesser one, but sometimes (say in certain compliance cases) we may have to prioritize a fix for a smaller number of affected customers.
  • Number of resources impacted (e.g. groups, Teams)? There may be one owner or a single system, but there could be a much larger number of Teams, posix or ldap groups, etc. utilizing that system or reporting up through that owner. We should account for their numbers in our impact calculation, when relevant.
  • Is this a one-off or repeating request? Certain workflows repeat on a regular basis, e.g. quarterly or annually. If I know I will generate this report once a month, I am more likely to automate as much as I’m able vs. a one-off report that answers my manager’s singular inquiry.
  • Do I enjoy doing this myself (am I able to deliver on my own) or is this better delegated? You don’t want me writing your enterprise HTML or CSS, even though I’m theoretically able. However, if you want a 3 year plan or vision for our roadmap, I can whip that out no problem, and I enjoy learning about a team and our software ecosystem in order to draw a compelling vision that retains current employees and appeals to prospectives.

Once I have this data for each project or priority, I can play a kind of multi-dimensional Tetris that shuffles employees’ career goals, the business goals, and available projects and features so that we meet as many of these at a high-enough quality level, as close to on-time as we are able. For the items that I must deliver personally, I give a little extra thought and consideration to what I’m able to automate and what I’m not, and then craft a plan to deliver it – including blocking off what seems like an appropriate amount of time on my calendar to actually do the work. I monitor those stats, too, so that I can improve my estimations over time.

With the above, and with regular check-ins with stakeholders and leadership (including my direct manager) to improve my understanding of the business context & details of requirements, I know that I am pretty likely to be focusing on the right thing. I can’t always be 100% certain that I’m right, especially when I’m working mostly-autonomously. But I can be certain *enough* to get my work done, without blocking on outside input.

I love reading Ask a Manager. I just came across this relatively-recent post which expressed some thoughts I’ve had, and coached my peers through. Because this question seems common to many, I figured I would share here. “When you’re inexperienced, how can you know if something is worth complaining about or leaving a job over?” (Posted October 12, 2020).

In her response, Alison Green points out that if you’re more in-demand, more experienced, or simply unhappy, you’re more likely to (and able to comfortably) complain or leave a job over insulting and dismaying scenarios.

She mentions, “All of this points to proceeding with caution when you’re relatively new to the work world — and testing your assessment of a situation with people you respect who have more experience to draw on. It doesn’t mean that you aren’t entitled to push back on something or leave a job if you’re unhappy — that’s your prerogative at any time.”

I really like her suggestion of sanity-testing your assumptions, though. When you’re new to the working world, or just new to a particular role or position, you might think something is strange, unfortunate, or even horrifying because it’s not how you personally might do that thing. When you test that feeling of, “Is this ok or am I mistaken?” you get a lot more data than if you just react.

One thing I’ve learned from the working world is that I should never just react — I know that I can check in with my own feelings, a trusted advisor or mentor, or a family member (though — be skeptical if your family doesn’t share a career focus area with you! Technology is very different from library science is dramatically unlike truck driving…)

I always swallow my first reaction to a novel situation at work. I quickly verify how I feel and how I should be feeling, just to make sure I’m not wildly off-base. Surprise or dismay can make a small indignity feel much larger than it really is, or needs to be. I can’t tell you how enraged I’ve been over a too-large backpack hitting me in a crowded conference room, or hurt I’ve been by an offhand comment about my appearance from a coworker.

Now that I’ve been in two different careers for more than ten years, each, I can check in with myself first, and then reach out to someone else…Luckily, these days, I don’t necessarily need to check in with another person, at all, because I have these years’ worth of history that I can compare new feelings and new situations to.

Personally, I believe it’s a serious error of judgement to react before you think, in the business world. I’ve seen people rage-quit jobs, and they almost always regret doing so. Or even lower-stakes, when someone yells in front of a meeting’s audience, they don’t generally feel good about it later. If you find yourself experiencing strong emotions at work, take a breath, step away from the situation if you can, and check in with a trusted peer or a relative. If you determine that it’s appropriate to do so, respectfully complain to the person you’re emoting at, your manager, your HR business partner, or someone with power at your place of employment.

You can be the change you want to see in the world – but changing whether or not your loud boss closes his door when he’s on a call, or threatening to quit when they change the brand of coffee in the kitchenette – those aren’t good looks. Tread carefully when you feel yourself emoting in the workplace!

Hello friends, and welcome back! Continuing on with (and closing out!) my semi-intentionally serial post, the worries that I’ve gathered people experience, with any change, land into one of 3 categories:

  1. Imposter syndrome – will I do ok?
  2. Human tribal nature – will they like me?
  3. Choice economics – did I do the right thing, did I move to the right place, did I move at the right time?

The scientific framework we will apply here:

  • First, test
  • Then asses one or more fixes
  • Apply the first fix
  • Evaluate how it went
  • If more fixes needed, continue to apply and evaluate them in sequence until the benefit no longer outweighs your effort

We’ve addressed what I do about imposter syndrome in my last post, and this post I will attempt to digest how I deal with fears around being accepted by the group, and whether the recent job move or increase in responsibility was, ultimately, correct.

To address human tribal nature, we might cross a bit into relationship management or even ‘politics’. No one seems to like politics. People complain about it whenever they think they’ve been a victim of politics, and yet we often find ourselves unintentionally acting in a political manner, because it’s an easy trap to fall into. People are, ultimately, tribal creatures. We like to align ourselves with the people we like and respect, and avoid the people we don’t. Therefore this worry lends itself most easily to test. Either you find it easy to get other people to buy in to your projects, to give you the inputs you need for your deliverables, and you can just “get ‘er done”. If you find it challenging for you to work with others and perform your job duties successfully, you know that this test has failed, and you need to apply some kind of a fix …or get a different job ASAP! (Finding a new job is ultimately a type of a fix, I suppose.)

I wave my hands at this point, because I could write an entire book on improving your relationship with coworkers when you need to collaborate to succeed on your own. I’d prefer to focus on the original point of this post, where I show you how to use the framework above to quash your new-job worries. So, you’ll create a list of potential fixes, apply some kind of a fix to your issue, see if that makes it easier for you to collaborate with your coworkers, and if it doesn’t — then you iterate and try again.

As a sidebar, I’d like to point out that much like imposter syndrome, your peers worry about whether you like THEM, as well. So take a moment every day to express your interest in your peers, ask your boss how they’re doing today, spend an extra five minutes answering questions for the new person on the team, and consciously spread some of your attention around. You will find that the time you spend paying attention to, and caring about, your coworkers will pay dividends in the future. People help the people that help them. Because I’ve spent 10+ years at my company helping people without expecting a quid-pro-quo, my peers have started sending each other my name as a potential good boss to work for. I couldn’t get any more flattered and happy about the trust that people show me when they recommend a friend reach out to me for a job.

Okay, let’s address the framework for our third and final fear – did I make the right decision when I chose to take this new challenge on? That one takes time to test, and ultimately your emotions will guide you, here. Your test becomes, “does this feel right?” and requires self-awareness and attention to a rubric that each person builds for themselves. You really can’t rush this one. You can’t tie the outcome to your external veneer of success because you can, for example, get a promotion, but hate the job itself.

For me, I know I’ve made the right choice with a new job or new responsibility when I find a sense of satisfaction with my ultimate outputs. Each day, I start the day off thinking about which three things I’d like to get done, and at the end of the day I spend a moment evaluating if I did those three things, and how I feel about them. This takes less than five minutes total, at this point. I also run the same exercise for the week on Mondays and evaluate the week’s deliverables on Fridays. I used to write my To Do list down, but lately I perform the check mentally…and sometimes I forget to do a weekly analysis and that’s ok, for me, for now. My job requires constant attention to relative priority among projects, because I can easily get lost in the weeds and react to the most urgent problem, when the long-term strategic priorities forever end up sliding off my plate. We don’t want that! I won’t meet my business and personal goals if I let the important but not-urgent issues constantly go unaddressed.

So, to test whether I made the right move with my new job, ultimately I’ll just have a sense of satisfaction about the products I launch, I’ll see my team growing in their own career goals, and I’ll be proud and happy about the product and the people. Since I’ve only been at my new job for two months, it’s too early to say that I made the right choice for certain – though I can tell you, if you made the wrong one, you’ll know definitively, and pretty fast. Somewhat confusingly, my absence of negative emotions and lack of worry means that I probably made the right choice even if it’s too early to authoritatively tell.

Because it’s so hard to test this worry, it means it’s also hard to apply a fix and iterate. I’ve had friends move into a new job role and transfer out again in 30 days, which seemed rather fast to me. Talking with them about the change, though, they knew that they couldn’t work for a boss who screamed, or who used sexist/racist/*ist statements that made my friend immediately uncomfortable. My friends moved as soon as they could find another gig. I feel lucky that I’ve never landed in a role that was that bad, that quickly – but on the bright side? They saw an undeniable signal that, no, this job won’t work for them. This choice was 100% the wrong one!

Personally, I test whether I still feel satisfaction logging onto my computer every morning. I know that if I will feel pride when I finish a keystone project or can imagine that I will get a sense of satisfaction from promoting an employee, I’ve probably made the right choice. At a minimum, I know I have pointed myself in the right direction and should continue on. That kind of mindful test allows me to make minor changes in course when there’s just not much signal to go off of, so I may move a certain item up my To Do list. With that change in priority, I check in with myself and see if I feel optimistic about the future state of the world… and that’s all I can do, really.

Let me know if you apply this framework to your new job fears, and how they turn out. I think some of these worries apply themselves to testing more easily than others, as you’ve seen from my description of how I apply my framework. I find it easier to address my imposter syndrome and my human tribal worries than to address my fears around “doing the right thing”. While it’s frustrating to not really know that I’ve made the right choice in life, that seems like a pretty universal human condition, doesn’t it? I’d love to hear your thoughts.

If you’re like most people, you find a new job, or broader responsibilities in your current job, is a nerve racking experience. Change is scary. No matter what you say, or how much you embrace change, it’s a short step from, “I’m so excited!”, to “what in the world have I done?”

Real talk, on the day you accepted that offer, you flipped from one extreme to the other — at least 4 times. Even with self-care (proper hydration, exercise, adequate sleep and food), you might be spinning from excited to ‘oops!’ rapidly. Thankfully, these self-care steps are some great coping mechanisms we can all use. And beyond self care, you can test your fears. They complement each other, so you can start testing each fear, and move on to dealing with your fears via exercise, sleep, whatever, and you’ll find that using both, you’re minimizing your fears moving forward.

In my last post I discussed coaching my teammates, peers, new hires, and people at school and in earlier jobs — I found the worries they experience with changes land into one of 3 categories:

  • Imposter syndrome — will I do ok?
  • Human tribal nature — will they like me?
  • Choice economics — did I do the right thing?

And the 5-step scientific framework we’ll apply here:

  • Test
  • Assess
  • Apply
  • Evaluate
  • Repeat if needed

Let’s discuss the first fear, imposter syndrome, and how we can apply our framework to it.
Just in case you want to know more about imposter syndrome, here’s a great TED talk I’ve found helpful, and an article on HBR.

Once you’ve finished with these links, you’re may still be wondering if you’ll do well at your new job. Don’t forget! You got this job based on your history, experience, and your performance during your interview. If you’re still feeling like an imposter, you can tell yourself that you got this gig based on your interview and prior achievements, so don’t worry too much! Many people still need a little help, and this is where we can apply our framework.

To reality-test your performance, talk to your boss, ask your peers, or seek feedback from clients and customers. If you genuinely seek and ask for feedback, most people will be happy to share their thoughts. Maybe your boss tells you that that you did a thorough job researching a document, but it isn’t in the format they expected, and it’s more granular than they wanted. You need to figure out a fix.

First try asking if the current format’s ok, or if they’d prefer you re-work it. Let’s say your boss suggests you keep the current format but maybe roll it up into a less-granular summarization of the first draft. Great! You have a direction now, you can test with that. Without being pedantic, you can whip up a fix that attempts to correct for the feedback you received, and later circle back with the update. At this point, your boss is happy (or not) and you can iterate from there, or know that you completed the project to your boss’ satisfaction…and you can, in the future, remind yourself that you did a job to your boss’ requirements, and that satisfied your boss. Tell that nagging voice in your head that you’re not an imposter if you can make a satisfactory deliverable for a big project that your boss cares about.

One way to get the imposter in your mind to back off is to do your job well. Praise and gratitude both help silence the imposter, but in the long run, praise and gratitude from others do end up being external motivation. The most satisfying motivation comes from within. Remind yourself that you did a good job! And use that satisfaction to continue moving forward and achieving.

As a bonus, I’ll link two books that helped me with Imposter Syndrome personally include Sheryl Sandberg’s Lean In and Amy Cuddy’s Presence.

My next post will cover how to apply this framework to human tribal nature, and choice economics.

If you’re like me, you probably think about your job for a fair portion of each day (whether it’s a workday, or not). You may want to do well, you have a problem you’re noodling over, or your curiosity just won’t let you stop considering some aspect of, skill, or task that you’re actively learning for your job. You may even be one of the folks with both a job and a side hustle – but you find yourself regularly noodling over one or the other.

These thoughts and feeling increase in intensity when you transfer from one job, company, or role to another. This is top of mind for me because about a month ago, I switched from an operating systems team to a security team here at AWS. (Remember, my opinions are mine, not my employer’s). I tell candidates as I interview them, and I tell new-hires as they join, that every team in every company is different from any other – but there are some universal themes that I’ll cover here, in these posts.

So, since it’s top of mind, today I’ll share three new job fears that you probably worry about, too, no matter what team you find yourself on.

  1. Imposter syndrome talking – will I do ok?
  2. Human tribal nature – will they like me?
  3. Choice economics – did I do the right thing, did I move to the right place, did I move at the right time?

And in my next post, I will share my personal coping mechanism for each “flavor” of fear!

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!)