Simple Advice That Guided Me During My Job Hunt

After working remote with my last company for about 10 months since moving to California, I decided that it was time for a new challenge. Perhaps it was simply being in the Bay Area and meeting some of the most talented people I’ve ever met that inspired me. I had been with my company for about two and a half years and had been challenged in more ways than I could have imagined, but yet, I felt like I was missing out on key growth opportunities. Thus, began my job hunt. Here are three simple, but game-changing pieces of advice that guided me. 

1. Networking As A Lifestyle

For introverted individuals, like myself, the thought of networking can be terrifying. When we think of "networking," what comes to mind for many of us are random strangers, name tags, business cards, and awkward smiles at some fancy hotel bar. While this may be the scene for many networking events, I quickly learned that this was not the only way to network, nor was it the most effective way for me. During one of the night courses I took while job hunting, my instructor Stephen McCurry (Director of Product Management at Udemy), left me with a piece of advice about networking. He said, "Don't wake up in the morning and plan to network.” Instead, he insisted to think of networking as a way of life. I've always understood the value of building my professional network, but he finally hit the nail on the head. If you play sports on a league, use this opportunity to “network." If you’re in a music group or orchestra, “network." When you hit the gym, “network." These casual encounters that you’re already having are the best opportunities to connect with people because that's when people see you in your natural skin. However, don't start networking only when you're looking for a job. The strongest connections are most likely built over time, not over single events. Who would be more likely to vouch for you - your hiking buddy or a stranger you met at a happy hour? Part of it is also having a sincere interest in getting to know people, not just for the sake of finding a job, but for insight, mentorship, and friendship. I'm thankful for all the friends and connections that I made during college. Having built these relationships through those years helped make growing my network in a new city, several years later, easier. These friends ended up helping me the most during my job hunt. I found my current job because my friend from college introduced me to his friend, who kindly put in the referral for me. Thanks Howard(s)! 

2. Different Industry OR Role, not Both. 

It took me some time to figure out my career goals. I knew I wanted change, but wasn’t sure what changes I wanted. In the early stages of my job hunt as I was getting my feet wet, I sent out many resumes for various types of roles and companies. Some positions were similar to what I was currently doing for similar companies, others were for different roles and types of companies. I thought, “If I cast my net wide, I’m bound to find something I like, right?" Not exactly. I was successful in getting responses from the former, but those positions didn’t feel “right." I was seeking a dramatic change in scenery, so these initial stages were pretty discouraging. It wasn’t until I talked to my friend, Michelle Chang (HR & Operations at Sila Nanotechnologies) about hiring experiences at her company, that I decided to make a shift in my strategy. She mentioned that when looking for change, it’s extremely difficult to switch to a different industry AND a different role at the same time (especially in the Bay Area). She suggested to try pursuing one or the other, rather than both. I stopped job searching for a few days and took a step back to reevaluate. I began brainstorming about the industries and companies I wanted to pursue, separate from the roles that I was interested in. I thought, not only, about the likelihood of landing jobs for various industry and role combinations, but also how they would be aligned with my long term career aspirations. Next, I reflected on my strengths. Which was the greater strength - my experience in my role or my industry knowledge and expertise? After deciding that my greater strength was experience in my role, I came up with a new plan. I sought out companies different than my previous company that interested me, that had openings for my current role, and that had opportunities for me to evolve into new roles over time. To my pleasant surprise, I gained a lot of traction with this new strategy as the “right" emails and calls started flowing in. 

3. Best Face Forward At All Times.

During my quest, I was familiar with most of the do’s and dont's of job searching, resume writing, and interviewing. Having read every job search article that came up on my LinkedIn newsfeed, I knew I was supposed to tailor my resume to match every job description. I knew not to blast my resume at every electronic application I came across. That referrals were my best shot. That I needed to be intimately familiar with company current events and news. This list goes on and on. What was difficult about following these “rules” was deciding where to draw the line. For example, how closely should I match my resume to the job description? How many applications should I submit? How much should I know about the company in preparation for the interview? I credit my friend and mentor, Dennis Ngin (Strategy Consultant at Accenture), who would always remind me to “put your best face forward at all times” whenever I was lost on what to do next. Now, this one seems obvious, but I think it's a loaded one because prepping to put on the best face takes time and thought. It's also unique to each person. One person may require two hours to prepare for their “best face” interview, while another may need months. Whenever I was unsure about whether I had put in enough effort towards something, I started asking myself, “Is this my best face?” For me, putting on my best face meant that I had to make sure every resume and cover letter was my best response to a posting’s calling, even if it required a couple more days of preparation. It meant that I had to get my hands on every relevant piece of company information possible. It meant learning the names and backgrounds of my potential teammates, managers, and colleagues before having any type of interaction with them. With only a limited number of hours in a day, putting on my best face at every step meant that I couldn’t apply to twenty jobs. Not even ten. Using this as a guideline, I was able to concentrate on pursuing just a few companies with greater focus and more success.

I had a lot of support from my husband, friends, and family throughout this journey. It was not an easy time, so I’m thankful that I had them to lean on. If I had to leave one last piece of advice to wrap up this post, it is to stay steadfastly open and receptive. Listen, even if it's inconvenient or in disagreement. Keep all doors open because you never know what type of advice or connection could lead you to the next opportunity. 

First Holiday Season with the New Company Family

Agile for Agencies

Your agency has been using a waterfall model for years. With the rising popularity of agile methodology, your company decides to send a few team members to scrum training. Now you're excited to bring scrum to your company because you learned from an agile coach that scrum helps teams meet their deadlines, while building better product. Before you decide it's time to "go agile," here are 4 things to consider:

1) Do you have offshore team members in different time zones?

The Scrum Way: The scrum framework is based on the concept of self-managing teams and is recommended for collocated team members. 

The Problem: It's not always possible to have collocated team members, not to mention, team members in the same time zone. 

Offshore teams exist in companies not exclusive to agencies, but in small agencies, teams may be working with individual contributing contractors that are spread across the globe. Having a quick 9am meeting everyday at the office may be an inconvenience to one team member in Europe or impossible for another in Asia. Before implementing daily scrums, think about the communication tools that are needed to facilitate the new ritual. How much will the tools and equipment cost the company? How will you ensure everyone has the appropriate equipment to complement the communication tools? Will these tools or processes introduce obstacles and barriers for your team? How will these new processes make people's jobs easier? Is there anyone who does not need to participate in the daily scrum? If so, how will you ensure they stay connected to the team? If new processes create more barriers and inconveniences for team members, chances are they will not stick. 

2) How are your team members contributing in meetings?

The Scrum Way: Scrum introduces many new rituals including the daily scrums, the sprint planning meeting, the sprint review, and the sprint retrospective. The framework emphasizes more collaboration to foster shared ownership.

The Problem: If not well-planned, meetings can be counterproductive. It's not uncommon to hear engineers complain "I just want to code."

Well, this is not just agencies. Before adding these events to the calendar, consider how much time you have to prepare for these meetings. Seems like common sense, but often times project managers will ask team members to block off time for a meeting only to come to the meeting unprepared, therefore, wasting precious resource time. I've been guilty of this. If you plan on incorporating any of these meetings into your processes, think about how you would like each person to contribute in each meeting. How can you make them productive and how do you plan to keep everyone engaged? Entering every meeting with a specific goal and agenda in mind is usually the first step towards having better meetings.    

3) Are your clients asking "When can you finish?" and "How much will this cost?"

The Scrum Way: Scrum does not explicitly address how to estimate overall project costs and time. It focuses on breaking down a large project into smaller iterations, or releases. Calculating the average velocity after a few releases, the team can predict what it would take to complete the larger project. 

The Problem: Clients want to know from the beginning, the cost and timeline for a project, before they sign off your team to start on the project. 

For software companies, you may experience this with the product manager or stakeholders. For agencies, your ability to answer these questions "right," may determine whether or not the client choses you as a partner. The ability to calculate velocity after a few iterations will be valuable in validating the original estimate, but still, scrum does not address how to estimate the project from the beginning. This was one of my biggest challenges as an agency project manager because we could easily spend days coming up with a project estimate only for it to be inaccurate or to not win the bid for a project. I don't have a one-size-fits-all solution, but I would suggest starting by thinking about what the client is seeking in a partnership with your agency. Is it low-cost services? High-quality service? Long-term partnership? Strict or scrappy processes? Hard adherence to launch deadlines? What are the internal and external repercussions for missing deadlines and going over budget with this client? Do they have a high tolerance for risk? Having a good sense of this will help you determine the level of effort needed to compose an estimate and whether the client will be a good fit for your agency. 

4) How will your team support a scrum master? How will having one improve current processes?

The Scrum Way: There are no "project managers" in scrum. There is a "product owner" and "scrum master." On a high level, the product owner is in charge of the vision for the product and the scrum master serves the team by facilitating communication and activities with the team.

The Problem: This framework adds an additional person to the team, which can add overhead, thus increasing cost and time, if the role responsibilities are not clearly defined or balanced. More traditional agencies who have project managers overseeing all aspects of client projects (resources, scope, budget, schedule, risk, communication, change, etc.) might also face a challenge figuring out which scrum role is better suited for their skill set or choosing which responsibilities to "give up."  

Should you have a designated scrum master for the team? It depends on many different factors. How large are the teams and projects? How tight are deadlines and budgets? What are the current hiring and training challenges? How fast is the team iterating? What is the team's risk tolerance for scrappiness? What project management responsibilities are popular and which are not? In my agency experience, I've found it very difficult to implement a scrum master role seamlessly. Not divvying up the responsibilities between two roles meant a significant increase in new hire training costs, but the benefits often outweighed the costs. Having the extra person facilitating the development team sometimes slowed down projects, hindered client relationship building, and added overhead that caused us to burn through budgets too rapidly. This is not to say the agency should never implement this role. If anything, we were probably too busy to test out more approaches. 

Implementing agile methodologies into our processes dramatically increased our team's ability to complete projects on time and within budget, but it did not happen overnight. It took much trial-and-error, patience, and creativity to find an appropriate "Agilefall" approach. Still, as team conditions, project size, feature complexities, and client partnerships evolve, the needs of the team will continue to change. No matter what the implementation is, I believe it's important to approach process change gradually and deliberately because what works with one company, may not work with another.

I'll end this with one of my favorite scenes from one of my favorite shows. Would love to hear about your experiences "going agile!"

Passing the PMP

I took the PMP exam in 2014 and since then, I've had numerous people ask for tips and advice. It's been a while, but here it goes...

Just kidding. Well, actually no. You really do need to learn all the EVA concepts. Sorry! With all joking aside, here are my suggestions.

1) Do not rely on the PMBOK

I did not enjoy reading the PMBOK at all. Unfortunately I had already gone through 90% of the book before learning that the test was not just about studying PMBOK. I suggest only using the PMBOK for reference on the "official" knowledge areas, process groups, process inputs & outputs, and process tools & techniques. Yes, you do have to memorize all of these, but solely memorizing the names will not help you pass the exam. The reason why studying PMBOK will only get you so far is because it overloads you with information without going into detail about application. It gives you a lot of "whats" and "whens" without going into the "whys" and "hows" you'll need to understand to pass. Some books I found to be helpful were "Rita Mulcahy's PMP Exam Prep" and "Kim Heldman's PMP Study Guide - 7th Edition."

2) Use multiple resources and different types of resources

I suggest utilizing multiple learning resources. For example: Rita's book was easy to get through and understand, however, the practice questions were very easy and could give a false sense of security. Also, I found many instances where concepts were shared in some books, but not all. If you have the money and time, enrolling in classroom courses could help tremendously, especially if you're struggling with managing your time to study. Unfortunately these courses come at a high cost. If you're looking to save a couple thousand dollars, I suggest a combination of online courses, books, and flashcards. I found that it was easier to retain information after I was exposed to it in different ways (eg. watching, hearing, reading). 

3) Know all the analysis concepts and equations by heart

This includes, but is not limited to, earned value analysis, schedule network analysis (critical path), expected monetary analysis, sensitivity analysis, etc. Again, solely memorizing the equations will not help because many problems on the exam are written in a way where you can't simply plug and chug. You will need to understand how the equations are derived and may need to use multiple equations for single problems. This was a list of practice questions I used to prepare for the test: Oliver F. Lehmann Project Management Training.

4) Do it for a good reason

Lastly, people may pursue this certification for different reasons. There might be a job that only hires certified project managers. A salary increase. A change in career path. The certification requires some time and discipline, not to mention many requirements to keep up with license renewal. I do advise on having a good reason for why you want it. With the right motivations, you'll have a better shot at passing the exam.

I've had many people ask if getting the certification was worth it. For me, it was. Even though I've never had to actually calculate earned value or put together a critical path diagram in a real work situation, studying for the certification has challenged me to think in ways that I had never done before in my daily ventures as a project manager. I have heard some say that the PMI methods are not applicable. I believe it depends on the industry, the company, and the project manager's career aspirations. After all, it's up to project manager to figure out when and how to apply the appropriate tools and techniques to their process, and determine what modifications are needed. I feel that studying for this test is similar to going through any course in school. In order to pass, the student will have to master concepts that may or may not be useful to their career and future. How the student intends on using the knowledge obtained, is up to them.