Hey, engineers, how many times have you been casually asked by a manager to go look at [insert whatever] project because we need it now. And how many times have those initial conversations been productive? It’s probably more likely that non-specific instructions delivered on the fly like this only lead to confusion as managers and the engineers struggle to get in sync about who wants what, when, and why.
So, after observing this game for many years, and after watching some highly skilled engineers navigate these nebulous exchanges with managers, I wrote up some tips for people to follow when they are asked to investigate some shiny new project.
During that First Meeting
Write down the project goal! Be sure you understand the problem you are being asked to solve and all constraints known at that time. Remember, though, that all the constraints won’t be known at this time so expect some ambiguity. That’s part of why you are being asked to investigate the issue.
Most important: Ask right up front about the underlying problem. In other words, a manager just directing you to go build A isn’t sufficient. You should want to know why. What’s the problem? Get that data first because you may be able to solve the issue much better by building B instead of building A. And the manager may have not even considered that.
Collect as much information as possible from this initial meeting. Ask questions. Take written notes. These notes will come in handy when the manager later dives off into the weeds, especially after talking with a few executives or customers, so you’ll need to pull him or her back on track.
Finally, don’t just say ok and walk out. Always respond that you’ll need to do some preliminary research before making any commitments and that you’ll get back to the manager in a week or two or some agreed upon time.
Starting the Investigation
Remember that you need to do work as part of your investigation. Simply reading or searching or consulting with colleagues is not enough to discover enough information to report back to the manager.
Is it possible to get a really rough prototype working? What’s missing? What’s possible? Even just trying to get something going is better than not making the attempt at all. The point is that you should invest some focused time doing work. Don’t just read up on net searches.
Start a rough task list. Think in terms of iteration. Task lists are flushed out over time as new information is discovered and as the project is scoped. You don’t need to report back with a fully formed task list or project plan because that’s impossible. But you do need to have a general idea of where you’d start if so directed.
Some questions to consider:
- Are there other teams that are directly needed to help implement this project? Are there other teams at the periphery that will be affected by the project?
- Is the project self-contained or will other parts of the system be affected?
- Will the project involve an executive announcement? You need to know how high up the chain your exposure will be.
- What’s behind the request? Is it a high profile customer under fire? Or just an executive whim?
As you work your initial investigation, document what you experience. Also, never forget the initial goal you believe you were given in the first meeting because you’ll need to confirm this in the next step. You may have to eventually change the goal based on your research and subsequent conversations, but that comes later after new agreements can be made.
Think broadly and long term. Consider technical work, documentation, communication, support, and things that could change in the future. Predicting the future is difficult, obviously, but flush out some scenarios for discussion.
Bring the results of your preliminary investigation into the next meeting so you and the manager are clear about what the original task was and what you’ve done since. This must be in writing. If you are talking about content two weeks after the first conversation without any notes whatsoever you might not be happy where things will lead.
Talk about what you experienced during your investigation. Show your prototype if you’ve done enough work to build one. Show your preliminary task list. Show whatever you have. The more you show the more you can influence the conversation. Continue to ask questions because I guarantee you things will have changed since your last meeting.
Some questions to consider:
- Who is the target audience for the project?
- What is the problem that needs to be solved? Focus this as much as possible.
- Is this an existing problem or is this a new opportunity? In other words, are you fixing something that’s broken or are you creating something entirely new?
- What deadlines are expected?
- Does this project have a specific end or are you creating an ongoing program to support a series of projects? In either case, what resources will be needed to maintain what gets delivered (code maintenance, testing, program support)?
- Who is leading the project on the technical side? Who has management responsibility? Make sure the chain of command is clear.
- What resources will be needed to implement a solution and complete the project? Be specific about people skills and infrastructure needs.
- How often are progress reports expected? What’s the format of the report?
- Do you need more time to complete the initial investigation? If so, say so and substantiate why.
- Do you have any ideas to offer based on your preliminary investigations? Other ways to approach or solve the problem? Now is the time to assert your expertise.
If everyone agrees that the project should be initiated, continue documenting the issues based on the discussions thus far. It’s important to establish a written timeline of decisions so everyone is clear how the project scope emerged. Maybe start a little wiki page to keep track of all this information so others can contribute. Then the page can grow into a project plan where work can be tracked.
Remember, investigations are iterative. You’ll meet. Investigate. Then meet again. Then investigate more. There should be many opportunities in this process to document and clarify things. Take advantage of all of them.
So, that’s it. It’s just a little guide to keep things focused during the early phases of a project when you may be given non-specific instructions that could lead to either a cool new opportunity or a lot of wasted time. You choose.