• Home
  • Resources
  • The Owl of Many Question: The first 90 days in a new job

The Owl of Many Questions: The first 90 days in a new job - Part 3

Yana Kane-Esrig

In the first article in this series, I discussed the reason for my interest in the topic of preparing and navigating the first 90 days in a new job. I introduced an imaginary guide: The Owl of Many Questions, a character from a children’s book. I talked about the kinds of questions I find useful to ask before starting a new job. In the second article, I considered interacting with people: one’s relationship with authority, getting help, and supplementing the Golden Rule with questions about social codes. In this third, concluding article, I will address some aspects of doing the work: understanding your first work assignment, dealing with a setback, and wrapping up your first project.


The Owl of Many Questions and the Work Assignment

When I get a work assignment, I send out my Owl of Many Questions to get a bird’s eye view of the project. Having a clear idea of who needs my output, for what purpose, and in what context, makes my day-to-day work more satisfying. It also helps me stay on track.

The foundation of a successful project is alignment between the customer and the person or team working on the project. This alignment includes having a common, clearly stated view of the goals and their priorities, the scope of the work, and the context in which the output of the project will be used. This is not a particularly surprising observation. Yogi Berra, a baseball player as famous for his quotes as for his prowess on the baseball field, said: “If you don’t know where you are going, you might wind up someplace else.” What does surprise me is that quite often an assignment gets discussed primarily in terms of how something is to be done, rather than what needs to be done and why.

There are differences between the areas of misunderstanding that are most likely when the project is done for an external customer (i. e. customer who is in a different company from the one that employs the workers) as compared to a project done for an internal customer.

Work done for an external customer is usually governed by a written contract that includes a set of requirements that the output must fulfill and a list of criteria by which the success of the project will be judged. Individual work assignments that serve such a project have these requirements as a common point of origin. What may be more difficult to obtain is information about the context of the project: why the customer is requesting it and how they plan to use the output. As a junior member of the team, you might not be offered access to the contract materials, but just assigned your piece of the work. Of course, you must use your judgement about what is appropriate in the work culture of your organization. But if it does seem acceptable to do so, then I would encourage you to express interest in and familiarize yourself with the bigger picture that your individual assignment fits into.

When work is requested by an internal customer, the requirements and the definition of success are not always written down. Instead, high-level goals may be discussed in meetings or calls. Every participant ends up remembering and interpreting these discussions in their own way. It is assumed that there is sufficient shared understanding of the context and sufficient proximity (organizational and physical) between the customer and those who will be executing the project, so that specifics will be worked out along the way. But in some cases, one or both sides are so busy with day-to-day work that they do not follow up to align on the deeper understanding of the goals and other structural elements of the project.

I think that being The Owl of Many Questions reduces the chances of “winding up someplace else” due to misunderstanding about “where you are going”.

I keep a list of questions that I ask about every new project. I call it my “preflight checklist”. In 2020 I gave a presentation at an Artificial Intelligence conference where I discussed what my “preflight checklist” consists of, and how I use it. You can see the presentation here: https://www.comcastlabsconnect.com/2020-phlai-schedule/data-science-project-intake-by-yana-kane-esrig-of-comcast .

Since I am a data scientist, my list has some components specific to a data science project. But I think that the general idea of coming up with a list of questions about a work assignment is applicable in many fields. Here are the elements of my list that are general purpose, rather than data science specific.

  • Who is my primary customer for this project?
    • The primary customer is the person (or the group of people) whose opinion is decisive in judging whether the project (or my specific part of it) succeeded or failed. Typically, the customer requests and pays for the project and plans to use the output in their own work (either directly or by giving it to someone who works for them).
    • It is possible that my work is part of such a large and complex project, that for all practical purposes I have my own customer who will judge whether I was successful in my assignment. If that is the case, I need to understand the requirements and success criteria of my own customer, as well as get a “bird’s eye view” of the project as a whole.
    • In addition to the customer, there may be multiple stakeholders and influencers. I need to differentiate my primary customer from the people who may play other influential roles.
  • What drove the customer to request this project?
    • What problem are they trying to solve?
    • Why is the project being requested now? Is it because the problem is new, or is it because the existing solutions to the problem are no longer satisfactory?
  • What does success look like from the customer’s point of view?
    • What would constitute a “minimal viable product”, i. e. a solution that is basic, but good enough? What are the objectives that are “stretch goals” that would take the solution from “good enough” to “excellent”? . What are the objectives that are merely “nice to have”?
    • There may be a couple of dimensions to the prioritization of the objectives. What is most urgent (needs to be done soonest) is not always what is most important (deserves the most attention).

I will make an aside regarding success. Early on in our careers, my husband and I came up with a phrase: “It does not have to be brilliant and right; it has to be sensible, relevant and on time”. This summed up the key differences we observed between the definitions of a successful project in academia and in a corporate work environment (other than a corporate research lab). In school, the students in “techie” courses are expected to find the “right answer” to the stated question. In working on a corporate project, being sensible and relevant means finding an efficient way to meet the key needs of the customer. The concept of the “right answer” may not be relevant, or it may be insufficient.

In academic research a premium is placed on being “brilliant”: audaciously exploring new territories and making discoveries, rather than using tried and true methods to solve familiar problems. While innovation, growth and learning are also necessary in the corporate environment, the first priority in working on a project for a customer is the timely delivery of a solution that is usable in practice. Being usable in practice may mean that the deliverable is simple enough to understand, reliable, and compatible with the customer’s existing infrastructure and operations, rather than groundbreaking. Using well-known methods is often preferable to being “on the bleeding edge”.

I will now return to my list of questions about the work assignment.

  • What related projects have been done before? In what ways should my project be similar to these predecessors? In what ways should my project be different and why?
  • What is the appropriate mechanism for keeping the customer informed and for obtaining feedback during the course of the project?
  • Are there specific dates or junctures in the project flow when formal or informal readouts are expected? I have seen situations where the workers were scrambling and stressing over the need to accommodate a request from the customer (or upper management) for a readout because they did not consider in advance when such request is likely to be made.
  • Are there any special restrictions, rules or sensitivities to keep in mind?

Ideally, I would discuss my questions with the customer and other key stakeholders. Even in cases in which some of these questions are covered by the written documents that describe the assignment, it is desirable to have an alignment conversation. And even when I am assigned a project that is quite similar to something I have already done, I aim to maintain “beginner’s mind”: to not jump to conclusions too soon, but to verify with my customer any assumptions that I may consider relevant from my prior projects.

It is not always easy for a customer to answer direct questions about their needs or to prioritize their multiple objectives. This problem is even more likely to come up when the person representing the customer’s point of view is not actually the customer, but a proxy who has second-hand knowledge of the customer’s situation. So, in preparing for these discussions, I not only draw up a list of questions, but also come up with “straw man proposals”: draft answers to these questions. The intent is not to convince my customer that these are the right assumptions, but to engage them in critiquing and improving or replacing these drafts with something better. A person who has trouble formulating what they need often finds it easier to react to a few alternative statements and to describe what each of them got right and wrong, and why. This warm-up exercise helps them come up with their own specification.

Unfortunately, it is not always realistic to expect that I will have access to the key people and that they will invest enough time and attention to address my questions. (In particular, if you are a junior person in the team, you might not be given the latitude to interact with the customer.) When it is not possible to get the desired input at the outset, I must make some assumptions and look for a way to validate and correct them as I go along. But even when I am not able to get all my questions answered, it is still useful to list them and to be clear about

a) which of them got answered (and who provided that input),
b) which I have some partial clues or guesses about (and what information this is based on), and
c) which are completely open.

I have learned that it pays to be diligent about recording what I learn about the structure of the project. In particular, it is valuable to take notes about the key meetings or calls. I usually take notes during meetings, but you should figure out what works best for you. You don’t want note taking to distract you from participating in the meeting.

I have figured out by trial and error my own system for organizing this project documentation. The goal is two-fold: to make it easy for me to share and discuss this project structure information with my customer and my colleagues, and to help me understand it in the future, when I may have forgotten some of the details of the context and the content. This attention to documenting, organizing and sharing what I learn about the goals, requirements and technical parameters of the project has several benefits. If there are serious misunderstandings and disagreements, it is more likely that they will be caught early. In my experience, if the project structure is hard to document and communicate, then it is a symptom that there is something not logical, not consistent either in my own understanding, or in the information itself (i. e. there is some contradiction or gap in how the project is defined). Another plus is that when the project customer sees respect and attention accorded to their input, they become more willing to provide additional information and respond to questions. Finally, if the project runs into trouble, having this kind of documentation helps to make the right decisions about how to fix it and can protect you from undeserved blame.

Learning about the big picture of the project you are working on, and organizing and using this information are advanced work skills. I don’t think that there is a single recipe that works for everyone. Figuring out what approach works for you and developing the discipline required to do it consistently may take a while, and may require trial and error. If you are starting your first job, you might not be able to figure it all out in your first 90 days, or even your first couple of years. So, don’t be harsh with yourself if you do not ace it in your first project. But I would suggest that you start moving in this direction early, even if at first you make small steps.


Falling on your face without breaking your nose

Sooner or later, you are likely to come up against a major, seemingly insurmountable roadblock on your planned path to completing your assignment well and on time.

In my personal experience, the key to navigating this situation in professional, interpersonal and personal terms is to retain or regain my own composure and to be prepared for dealing with the emotional reactions of other people.

I will share what helps me to move in this direction. Since people with different temperaments and levels of maturity vary widely in their responses, you may find some or all of this useful, or you may need to find a different set of tools.

The Owl of Many Questions helps me to be ready to deal with work problems by asking some questions in advance, before hitting a rough patch:

  • How do I usually react to a situation where something is going wrong with a work assignment that I am responsible for?
  • Which of my typical responses are helpful? Which are likely to make the situation worse?
  • How can I soften the impact of my own unhelpful tendencies and bolster my strengths?

My own initial emotional reaction to a setback is a combination of fear and embarrassment. Needless to say, this does not foster my best thinking. On the other hand, I have strengths I can summon: a sense of humor and analytical skills.

Early on in my career, I created a couple of simple tools for helping me deal with the wave of panic that washes over me whenever I encounter the possibility of failing in a work assignment. These tools are my own words written on two pieces of paper that I keep in my desk. I will share this content with you not because I think that it is universally applicable, but rather because it might serve as a starting point for you when figuring out how to best bring your own wisdom to yourself when you most need it.

The first tool is titled “Project Milestones”. It is a caricature of my reactions. This ironic view of my predicament enables me to switch from anxiety to amusement at myself, and to remember that I have encountered and survived my own fear before.

Project Milestones

1. Get assigned a project.
I do not know a thing about this! I must let everyone know that they have been misled to think that I can do this assignment. I will fail!
2. Start working on it.
There is so much to learn! I will not be able to plow through this in time to get any work done!
3. Material starts making sense.
This is not so bad. It’s actually fun.
4. Hit the first big snag.
I am going to fail! I will be so humiliated!
5. Get over the first snag. Face lots of work.
This is so hard! Why did I choose this profession?
6. Hit the second big snag.
Oh, well. I tried. They will not fire me for failing on just one project, will they?
7. Face more hard work.
Fantasize about getting a different job.
8. Light at the end of the tunnel.
Relief, impatience. I am sick of this project!
9. Finished.
Thank Goodness! I don’t know how I got through this. I guess, I was lucky this time.
10. Get a new project…

The second tool is a set of basic step by step instructions for getting myself out of a spiral of worry and counter-productive actions, such as going into overdrive and working to the point of stupefying exhaustion. Here they are:

  • Sit more comfortably in your chair.
  • Let your eyes rest.
  • Drink some water.
  • Get up, stretch, walk a bit.
  • Do a few breathing exercises.
  • Don’t give in to panic.
  • Describe to yourself what has happened and draft a plan

So, how does The Owl of Many Questions work on a plan? By asking herself questions, of course.

  • What is going well and what is going wrong?
  • Do I need to change something that I am doing right now? Do I know what change I need to make? (If not, the best course of action is to take a step back, rather than flail around just for the sake of “doing something”.)
  • Is it time to inform others of the problem, or is it reasonable to give a bit more time to trying to fix the situation on my own?
  • If I do need to inform people (such as my boss) that I hit a big snag, I try to come to the conversation prepared with a description of the current situation and with a list of suggestions for what to do next to fix the problem or at least reduce its impact.
    • The preparation helps to shift the focus of the conversation away from the emotional reaction (my own and that of the receiver of the bad news), and from the temptation to assign blame towards a more productive discussion about how to proceed.
    • Having written documentation of my understanding of the goals, priorities and technical specifications of the project is helpful in doing this preparation.
    • The list of suggestions does not have to be a complete and guaranteed solution. It just has to be something to get the ball rolling on figuring out a path forward.
    • As I get ready for such a conversation, I write down the key points. I also rehearse aloud (sometimes more than once) what I plan to say. I know that stress can do funny things to me. I do not want to ramble, forget an important point or blurt out something I would later regret.
  • If the problem was primarily caused by my own error, I admit that I made a mistake and take responsibility for fixing the situation. So far, my experience is that admitting my mistake causes a lot less fall-out than I picture in my anxious preparations. (I realize that there is no guarantee that this will always be the case. )
  • If the problem is caused or exacerbated by external factors, I couch my discussion in terms of what I believe needs to change, and how the person I am talking with can help with that. If the “external factors” means “actions by other people”, I try to be especially careful to speak in operational terms, and not in emotional terms. I want to avoid assigning blame and speaking ill of people around me. This is both an application of the Golden Rule (do not do to others what you don’t want to be done to you) and self-preservation. Badmouthing colleagues and “throwing them under the bus” sooner or later comes around to bite the one who does this.
  • Stress can do funny things not only to me, but to other people as well. In a couple of cases I felt a need to protect myself against being scapegoated. I was greatly helped by my notes that included the dates and the names of the participants of key discussions and summaries of what was discussed and agreed upon. I was able to use this project documentation to show that the problem was not caused by my negligence or unreasonable behavior.

In my experience, once I get over my own initial emotional reaction of intense dismay, it turns out that there is some way to overcome the roadblock that brought my work to a halt. In some cases, it is a technical solution that I find either on my own or with the help of colleagues. In other cases, it is an adjustment (made in consultation with the customer) to the timeline or the scope of the project. Depending on the circumstances, dealing with the obstacle might be interesting and satisfying, or it may be unpleasant and exhausting. Almost always, it presents an opportunity to learn. So far, the actual situations I have encountered were not as catastrophic as my imagination painted them at first sight. Being aware of this does not prevent me from having that first, intense emotional reaction. But it does help me regain my equilibrium.

Wrapping up the project

When you are nearing the completion of your first assignment, you might be offered a chance to present your project in a meeting. Most likely, you have had quite a bit of training and experience preparing presentations in your academic studies. Therefore, I will mention just a couple of points.

  • If I am given a generous time slot for my presentation (30- 60 minutes) , I get ready two versions of my talk: one that takes the full amount of time and another that fits into under 5 minutes. Meeting agendas often change in real time. It is hard to cover succinctly and clearly the key points of a longer presentation unless I prepare the executive summary in advance.
  • As I mentioned in my previous article, it is not a good idea to surprise one’s boss or key collaborators, especially in front of a customer or higher-level management. If I am preparing a presentation for a high-stakes meeting, I offer them an opportunity to review my talk in advance. This has the added advantage that I get to do a dry run and collect input that helps me improve my presentation.
  • This is a good moment to be generous with acknowledgments. I start my presentation by thanking (by name) those who helped me in my project. This has the added advantage that my audience becomes more friendly and supportive.
  • During the presentation, if there are questions that I cannot address on the spot either because I do not know the answer, or because I am not sure whether it is appropriate to reveal the information, I don’t try to bluff my way out. I have learned that it is perfectly fine to say that I need some time to figure out the answer. It is important to write down the question (not only to avoid forgetting it, but also to show the person who asked it that I take their question seriously) and to follow up afterwards.

Projects that seem to be “completely in the past” have the habit of popping up again. This happens either because of some issue with the old project that crops up after its completion, or because I get involved in a new project that is an extension of the prior work. In such a case, my “future self” is very grateful to my “past self” for help with finding and understanding the right information. So, before I leave my completed project behind, I have the Owl of Many Questions fly over it one more time.

  • Have I documented the project well enough, and have I organized this documentation clearly enough, so I can reconstruct what were the objectives, the assumptions, the data, the methodology and the results of the project months from now, when that work is no longer active in my mind?
  • What went right in this project? What do I wish I did differently? What have I learned?

Conclusion

The Owl of Many Questions has been and continues to be a helpful guide in navigating periods of uncertainty and transition. I have benefitted from her company in such situations as starting a new job, dealing with changes in my personal circumstances, or encountering the kinds of large-scale shifts and disruptions that all of us are going through right now due to the pandemic.

I hope that as you read my words, your own Owl of Many Questions perched on your shoulder and suggested questions that would lead you to adapt these notes to your goals and context, to make them useful to you. I wish you good health and good fortune.

Yana Kane-Esrig

The Owl of Many Questions: The first 90 days in a new job - Part 1

The Owl of Many Questions: The first 90 days in a new job - Part 2