Bridget Hudacs

1. Value Stream Mapping, especially documenting the current state, is an invaluable tool to identify key stakeholders for the project and to see the work required to create the future state. 2. Once key stakeholders are identified and the current and future states are mapped, hold a scoping meeting with all stakeholders (functional and technical). * Document the decisions related to in-scope and out-of-scope elements for the current timeline. * Identify who is responsible for the in-scope elements and the delivery timeline. * Keep the document in a centralized location where it can be referred to by all stakeholders. With those 2 tools, you can: * See who is impacted by the changes (whose feedback to incorporate); * What the agreed scope of work is (whose feedback to "ignore"/save for a later project phase).

As the Interviewee: 1. Have a list of interview questions that you tend to be asked (or Google Rev Ops Interview questions for ideas), and have examples from your work or studies that you can share as part of your response that highlight your skill and understanding of the role. 2. Get comfortable answering questions using the STAR method. It is a good framework for sharing examples so that you have clear and concise answers. 3. As you're interviewing, write down any questions that you stumbled over in an interview. Figure out what your answer will be if you're asked the same question in the future. 4. Think about your wants/needs for a future role. Develop questions to ask during the interview to determine if the role/company is right for you. Interviews are about you finding the right role as much as they are about a hiring manager filling a role. 5. Before your interview, review the job description and the company. Identify the parts of your work experience/resume that you want to summarize in 30 - 60 seconds in response to the inevitable "Tell me about your work history" question. (You don't have to summarize every job -- keep your initial response short and tactical. You can always expand if asked.) 6. Once you've done your prep work, relax. As the Interviewer: 1. Make sure that your questions are clear, especially for non-native speakers. Avoid colloquialisms. Vet the questions with colleagues to see if they understand what you're asking. 2. Have a list of questions that you ask all interviewees. You don't have to ask every question, but make sure that you have a few you ask consistently so you can truly evaluate candidates' strengths and weaknesses. 3. In concert with #2, build your questions primarily off of a job description for a role. Crafting the questions for your interview shouldn't be a night-before-the-interview endeavor. 4. Practice responses for candidate questions regarding the company, work environment and/or team. Sometimes you need to be diplomatic, but honest.

I've shared an Interview Template resource with Sharebird that provides the type of questions I use during my interview process. Regarding helpful resources, I believe that the job description for the role is the most important resource you can use when writing questions for the interview process. Without a clear understanding of the role, you set yourself and your candidates up for failure during the interview process. Then, as a hiring manager: * You can work with your Human Resources (HR), Talent Acquisition (TA) or outsourced recruiting partners to share required experience/questions that should be used for initial screening. * I've leaned on this point a lot with hiring. I focus on a few "non-negotiables" for a particular role to ensure that I speak with qualified candidates. I may provide specific questions and responses or, more frequently, qualifying questions that I would ask and the type of response I'm looking for (example: If someone can't give you an example of when they've had to tell someone "no", please don't move them forward). * You have a baseline to compare candidates against to try to minimize unconscious bias in the hiring process. (Here is a great book to help understand unconscious bias) And, as a cross-functional partner: * You can see the expectations of the role, which can help you develop questions for the candidate and ask support questions of the hiring manager. * You have a baseline to compare candidates against to try to minimize unconscious bias in the hiring process. (Here is a great book to help understand unconscious bias)

I hate to type this, but the first gauge of autonomy for a candidate is: How involved are/were their parent(s) in the process? The candidate, individually, should be scheduling interviews, asking/answering questions and making employment decisions. Personally, if I have to engage with someone's parent, then I'm not offering the person the job. I may make an offer to the parent, though (kidding!). Outside of that, I listen to how candidates respond to scenario questions and observe any noticeable response trends: * Are they constantly referring to having someone double-check their work? * When asked about independent decisions they've made, and the outcome of those decisions, do they have an example? Does that example involve cross-checking responses with a manager/supervisor? Sometimes the best way to gauge a candidate's autonomy is to structure questions that specifically speak to that issue. If I get a sense that, beyond nerves, a candidate is not exhibiting autonomy, I'll ask questions like: * What do you see as your level of authority/responsibility in a project team? * Please give me an example of a time when you went to your supervisor for help with an issue. Why you needed to escalate the issue? * Please tell me about a time when you had to adjust a stakeholder's expectations about a project. What did you do? Why? How was it received? From there, I assess how well their answers demonstrate the level of autonomy required for the role. An entry-level position will require less initial autonomy than a senior manager.

I don't have a recommendation for or against this type of detailed preparation, especially if it helps you structure verbal responses that also give a glimpse into how you think, problem solve and can be an asset to the company. But I wouldn't focus on developing unrequested collateral at the expense of having solid verbal responses. I would bring out supporting materials when they support your response to a particular question (ie if asked about what your 30-60-90 day plan would be in the role or what your organizational process is, show the prepared collateral as part of your response). Just be prepared for technical difficulties (internet bandwidth issues, screen sharing issues etc) that may impact how/if you can share these items in the interview itself. And remember, if what you prepared highlights a particular strength that you bring to the role, then you could also include it in a "thank you" email as a follow-up to your conversation.

1. Work with a sense of urgency. If a project can be completed quickly (no downstream impacts), then get it done. Those little projects build a lot of goodwill. 2. Communicate clearly and often. Perhaps that's weekly or monthly meetings to align on current/future projects. In addition to touch-base meetings, I like to use Confluence dashboards to show where a function's work is in-progress so those stakeholders have a centralized place to get simple questions answered. 3. Don't play favorites. Any stakeholder working with me or my team knows that the same cross-checks will be made for their request as with anyone else's. 4. Be a resource. Be available for questions. Give insight into the process. 5. Own your mistakes. If a deployment had unintended impacts on a function, apologize and correct it quickly. If you misquoted a timeline, acknowledge it and work with the function to get the project on track.

First, when I look at ownership, I look at “who is accountable for the success of the solution?” If there is a conflict, I ask a few questions of the group to determine ownership: 1. What is the problem we’re trying to solve? 2. Who is most directly impacted by the outcome of the decision being made? Who is the CEO going to call if the solution goes sideways? For example, when streamlining a manual process for sales, there are several problems to solve: * Identify the important information to capture in the process * Ensure automated data is captured and attributed accurately * Enforce adherence to the process * Ensure automation works as expected Each of these problems could be owned by an individual department — or by the same department. By identifying the areas of accountability - and asking for accountability - it is easier to iron out which department should be responsible for aspects of a solution, versus one area owning everything.

Whenever possible, have all stakeholders in a scoping meeting to agree on the project fundamentals: 1. What is the problem that we're trying to solve? 2. What is in-scope for developing the solution? What is out-of-scope? 3. What are timelines for delivery? 4. Who is responsible for various aspects of the project - and what are the agreed delivery dates for those elements? These elements are documented and put in a centralized place. They're referenced at every follow up meeting. And, if there are adjustments to scope, those adjustments and their impacts on timeline are addressed with the group.

* Agree on the in-scope and out-of-scope elements for the project with the key stakeholders. * Set clear responsibilities and timelines for in-scope project outcomes. * Identify dependencies so the team knows how adjustments to timeline impact the project as a whole. * Set up a regular communication cadence related to the project (ie weekly updates) to ensure that deadlines are met and expectations are managed. * Hold the team accountable for communicating and completing their areas of responsibility. Stuff happens; the only time it’s a problem is when the team doesn’t know about it to plan around it.

The only universal red flag that I experience in initial interviews is when a candidate cannot provide a concrete example for a universal experience (ie telling someone "no", managing conflicting priorities, asking someone to clarify a request). If an interviewee has been fairly general in their answers and then responds, "I can't think of one," when asked for an example of how they've handled one of these universal experiences, that's a big red flag. It indicates to me that either a) they're not going to do well in the role because they're avoidant or b) their language proficiency (if they are interviewing in a non-native language) is not strong.