Effective, fast-moving project management for small teams

Lessons on being an effective project manager while working with rapid-paced, high-impact startup teams

I’ve worked as a project manager for startups for the past four years. This period of my life has entailed incredible, intense, personal and professional growth. I‘ve balanced big successes with deep failures. My natural inclination to move fast and break things (tendencies often encouraged verbally but which are, in fact, detrimental to successful project execution) lessened to a more predictable, consistent, mature approach — all because of the real-world experiences accumulated.

This wasn't my first foray into PjMing. I cut my teeth on project management during five years of military leadership and management, which involved operating within institutional confines with minimal flexibility. In small companies and with compact teams, the institutional framework that sheltered me from failure (and also limited my successes) was no longer valid.?

Instead, startups are (relatively) an unrestrained free-for-all in which you can operate with maximum flexibility — but at high risk to yourself and the project. This allowance of flexible operation is because of a lack of standardization within the nascent company. As companies grow, we standardize processes, and constraints set in — correspondingly, project and career risk decrease.?

I hope to impart lessons learned, and best practices from my time working in those unconstrained spaces. The opportunity for growth and betterment as an individual leader is limitless, but the pain experienced due to inevitable failures is, often, hard to stomach. I hope that imparting these lessons can be helpful for project managers operating in the unregulated, free-form startup space such that their career — and individual project — success is maximized.?

Startup Project Management Considerations

The following sections elaborate on the whiteboard seen above. Each sticky note has a paragraph that extrapolates and provides context based on my experiences. I have tried to be concise while also providing specific examples while being mindful about company and individual privacy. Importantly, the lessons learned as detailed below are sourced from three different working environments. Often, the examples are compilations of experiences from all three organizations. The result is a comprehensive examination of what to do, and what not to do, across a variety of (otherwise) unique companies.?

Communication ???

Nothing is more important than the way you communicate with stakeholders, both internal (execs, project team) and external (customers, investors, interested parties). If you can nail down effective, transparent, well-honed communication, you’ll be effective at everything you do.?

First:?Be?too?open with the team. You can never be transparent enough with project members. They need to know what’s going on. Too much info is better than not enough. Use group threads, direct chats, and formal briefs to ensure your team knows programmatic and high-level technical direction updates. Don't waste their time, but ensure they have insight into programmatic inner-workings.?

That openness with team members comes with a caveat:?Internal and external talking points are different. Requirements (traditional PjMing) and features (agile) are external- or internal-facing based on their level of detail. We present issues with the most positive orientation when presenting to the customer.?

This is because?all external communication is strategic. Everything you do when working at a startup could be a make-or-break line of record. Talking with stakeholders holds significant weight for a company that’s so small it can’t stomach high-risk activities — this is because all activities with a startup are high risk, including basic functionality. Profit margins are low, activities R&D-based… if you're in hardware, costs are high. For all these reasons, everything you say needs to be uttered cautiously.?

The primary reason that communication needs to be viewed strategically is so you?don’t spook the customer. As a young PjM, you want to be very candid with your customers about project limitations. This feels honest, but in fact, can tear apart the carefully woven narrative of capabilities spun by the business development team. I learned this lesson while traveling onsite to conduct a recon of a demonstration site. The customer surprised us by requesting that our system lift an object heavier than we had designed for. This was a change in initial constraints, and I felt an obligation to be honest about our system’s limitations. In fact, my honesty just scared the hell out of them. People freaked out — called other folks adjacent to the project about our system’s “newly discovered” limitations. I had to dig myself out of the hole — both with the customer and with my leadership.?

But, knowing that you will not always be perfect with your communication, at least adhere to the golden rule:?Always be friendly with stakeholders?(AKA treat others as you want to be treated). You want a reserve of kindness built up such that when you say the wrong thing, or need to engage the customer about a tough conversation, their stance is one of acceptance, not defensiveness. I have seen many conversations go off the rails — especially in remote environments — as members talk past each other and get increasingly hostile. Those feelings of hostility stick in a customer’s mind and affect project outcomes and follow-on contracts. Be nice from the start, and you’ll have a lot more conversational room to maneuver.?

Group Buy-In???

Ensuring that the entire team is on board with the project, both in terms of macro-direction and micro-detail, is essential. Agreement is crucial at every stage of the project and at every decision-making opportunity. Startups care immensely about all personnel being given a chance to contribute their insights (helpful) and opinions (unhelpful).?

Including all team members in the decision-making process is crucial. Start from the get-go! Project definition should not be an exercise in solo planning in a vacuum. This — of all phases — is the most open. Vulnerability in the project planning phase — as with all phases — is essential to ensuring you've laid a firm foundation on which you can build a resilient project.?

While ensuring all team members are part of planning and development, you must?pay special attention to the alignment between the company leadership and the project team. Many times, I assumed that one or both groups — the executive team and the project team — were aligned in their ideas for project direction. This isn't always the case — especially for smaller projects that are open-ended and developed for many purposes to support disparate product glide paths and internal R&D initiatives. I recommend that, in the earliest days of project definition, the executive team can vocalize their ideas for where the project should go. Get perspectives from the CEO (product roadmap, board priorities), the CTO/engineering lead (technical focus areas), the COO (how does the project fit into the larger operational framework?), and any other members of the company leadership team. Once this team vocalizes their inclinations, and the project manager gets approval on the honed project direction, ensure the project team also can speak to their ideas for project direction (within the confines established by the executive team). I call these meetings Strategic Alignment and Technical Direction — they are essential first steps in project definition, preceding requirements development. Ensuring alignment across groups will pay dividends and prevent moving backward in design/development.?

In all instances — strategic alignment, technical direction, brainstorms, feedback opportunities — make it easy for people to agree. Quantify metrics by which the team will rank and prioritize requirements, project risks, feature requests, and any other sort of function that needs feedback. Make sure that brainstorms and ideation sessions are targeted and procedural. Start the meeting with a goal — and keep reiterating the goal! Don't let people derail meetings with tangents and side projects. If the feature being discussed in the first place needs feedback at all, make sure the team stays in the tracks while talking it through. If not, you won't have team buy-in — just a meeting recording of a bunch of people talking over each other and jockeying for position.?

Process Improvement ?

Processes aren’t important — until they are. You do things your way. Everyone else does things their way. Fellow operations personnel and project managers will insist that methods can’t be standardized. Common excuses include:

• Managers should have leeway to execute tasks as they see fit.
• There’s no one-size-fits-all in dynamic workspaces.
• Agile workspaces don't set things in stone — you have to retain flexibility!
• We’re growing so fast. SOPs are outdated the minute they're written.?
• As a company, we don't have time to document our efforts.?

This is all bogus, lazy, and ultimately detrimental to project success. (To be clear, I've used all ^ of those excuses) Project management is, at its core, the ordering of chaos. By allowing events and processes to remain unordered, you are falling short of a key feature that makes PjMing valuable.?

To be clear,?some processes?are?personal — aligned with preferences, not to be replicated across teams and functions. For example, the way I conduct meetings for team syncs doesn't have to be followed to a tee by other PjMs. I enjoy joking and taking the edge off seriousness at design huddles, while other PjMs are more to the point. I enjoy ending meetings 5 minutes early, while others use every minute of meeting space.?

However,?most processes and products need to be standardized?across the PjM team. Budgets, planning templates, design/dev checklists, Jira fields(epics, labels), schedules — all these products must look the same from team to team or else no one knows what to expect. As a starting point,?always document?your efforts. Document processes if they’re to be followed. Make a Confluence page — or, God forbid, a Word doc if that’s what your company uses — that specifies key parts of a project doc and how it’s formatted. If that template isn't standardized yet, it someday will be — and you will have immediate documentation to refer to.?

Ultimately,?messy projects screw the company. It may be great for job security for your project to be so nuanced and complex that no one can take it on if you leave. But the company will ultimately pay for your inability to standardize and streamline your efforts such that driving project success is minimally manual. If your budget, for example — which is a potentially complex document that houses vital project info — is unreadable by other PMs, then you've done the company a disservice by not allowing transparency regarding material and labor estimates and assumptions. If your schedule is organized in Wrike or Airtable or Asana differently than other PMS — bucket tasks by subassembly rather than work effort type, for instance — no one can jump in and drive the ship if you have a long weekend. You’re denying the team insight into your organization and ensuring that you are the single point of failure for programmatic details. Your sick day or family emergency can upend a project in times of resource constraint. That’s unfair. PMOs and ops managers should insist that basic project docs and products look the same across projects to minimize inefficiencies and maximize resilience.?

Feedback ??

Essential to growth, maturity, and excellence is the ability to regularly and effectively consume feedback regarding your performance. Coming from the Army, I thought I was good at receiving feedback. However, a major difference between large institution feedback and feedback from startups is actionability. In the Army, people were direct about feedback, but I didn’t have to do anything with the feedback. Often, you cant action reviews given in large organizations. However, startup feedback is immediately actionable. And if you don’t action feedback, you're shooting yourself in the foot… if you don’t listen to an exec’s feedback the first time, you will miss out on a vital information piece that leads to eventual promotion. You can’t let feedback slide through the cracks — people are super time-constrained and don’t have unlimited bandwidth.

Therefore, to maximize the opportunity for feedback,?create many types of opportunities for conversation. Conduct lessons learned not only at the ends of projects but at the end of efforts. Leave five minutes in every meeting for thoughts and concerns. Ensure you have open lines of communication with all team members and leaders so they feel comfortable telling you what you need to hear.?Every time you sit down with your boss, ask what you can improve on. The list goes on, but be creative and expansive.?

And at each of these venues,?hear what everyone has to say. Take notes, formally document, and take action on the words delivered both by leadership and team members. Often, you need to break apart the groups such that feedback can be unfiltered. Having the project team and the execs in one meeting is a good recipe for zero actionable takeaways from team members. But whatever the composition of the attendees, make sure people feel heard.?

Be formulaic about the way you incorporate feedback into the project. State goals at the beginnings of lessons learned meetings and best practice reviews about how feedback is assessed. Create metrics for assigning priority to feedback such that team members will feel that there is a formulaic mechanism for incorporating their suggestions. Don’t just say, “I’ll consider your input.” Rather, consider being systematic by developing a template where each piece of feedback is rated, then prioritized. For example, put a 1–5 rating on each feedback item as seen below, then choose to work on the highest score items first:

Most importantly — and I’d be remiss if I didn't talk about this:?Executive feedback trumps all other kinds of feedback. Even if they whisper it. Even if they just mention it in passing. If you don't grab onto every word they say, you'll pay the price. Startups are personality-driven organizations. Even when the?founder mentality?isn't on outrageous display, executives and directors, and VPs are very sure that their opinions are crucial. Take note and take action.?

Team Leadership ??

Though PMs manage projects, not people, a role implicit in the proper functioning of any project team is ensuring your people feel cared for and valued. PMs have a cool opportunity to be a point of reference, a crutch, or just someone to talk to for the entire project team. It’s leadership without the paperwork. You aren’t asked to write annual reviews, but you can offer coaching and peer support. Your project will thank you when your team members feel cared for.

The most important practice is to?check in on each team member individually. You can focus on their role in the project or strictly personal stuff — it doesn't matter. Just build a line of communication so they know they can come to you if there are problems. I conducted a small experiment (not particularly scientifically rigorous but appropriate for my needs) in which I evaluated how often team members came to me with issues/problems/concerns related to the project. With some team members, I had developed a relationship. With others, I had not. The latter group was significantly less likely to bring things up. (They didn't know how to use my procurement spreadsheet and never said anything- just didn't use it; They were sure they were going to bust their timebox but would never reply to my requests for an explanation; etc) Team members with whom I had a relationship and with whom I conducted regular check-ins frequently came to me with issues. They made sure I was ahead of the power curve in addressing problems and actioning solutions. Relationships pay off.

Leadership doesn't end with peer or subordinate team members.?Manage up, down, and all around. You must create relationships with your boss and their boss and your team members’ bosses to effectively manage a project wholly, especially when the effort is cross-cutting and interdepartmental. There are?lots of articles about managing up. At the root, just ensure you have relationships with all the people in your company so they prioritize you when problems arise. If they know you and like you, they’ll raise the priority of your concerns above the needs of folks they know less (and especially above those they don’t like).

Mistakes ??

You're the first person to make the company’s mistakes.?Just like the first man in the stack during infantry room-clearing operations, PMs hired on to early-stage startups are the first person to engage with any number of operational and strategic challenges. You will get blasted constantly. It's important to remember — no matter how bad you feel about your performance due to negative feedback — that the company needed to learn that lesson. If you didn't make the mistake, someone else would have later, when the stakes are higher. Knowing that, be aware that…

…your mistakes will follow you. It sucks, but it’s true. Leadership will never forget a high-viz failure. They will attach failure to you, not to the company’s shortcomings. You are the reason meetings are accidentally scheduled with customers when a certain team member can’t attend (it’s not their fault for failing to update their calendar). You are the reason that the customer is confused about project requirements and product features (it’s not the company’s fault for failing/refusing to find agreement in project outcomes). Your inability to budget properly is the reason there are $100k in project material costs not accounted for in the last month of a project (not the company’s fault for using janky budgeting spreadsheets and not having a system in place to track obligated expenditures). You must be OK with those failures following you, or you’ll fall into a pit of despair. Know that it happens to all startup managers. Nothing personal, it's just a consequence of blame-shifting that is inherent in resource-constrained organizations.

To be sure, most of the mistakes I make are 100% mine. Large and small, failures are part of the job, and mine are mostly attributable to me alone. However, startup culture is such that finger-pointing can often relegate blame away from multiple parties to a single person. In a way, the characteristic is adaptive as it indicates an intent to nip the problem in the bud. Unfortunately, colossal problems are normally the result of many factors by many actors and should be assessed as such.?

The pain of mistake-making aside, keep your sights on the fact that?you must fail in order to succeed. Failure is one of two likely outcomes that result from churning ahead toward an objective. One of my bosses frequently?attributed failures to backward or forwards movement. He praised forward failure as a sign that we were tackling hard problems. But, importantly, you can't fail too much or you won’t be trusted enough to move up. No matter how much your boss or any single person advocates for you, failures stick. If you can spin the failure as a learning opportunity for the company (or a forward failure) then you might come out on top… maybe.

Success No Matter What???

Ultimately, all that matters is that you complete the project on time, on budget, and without too much scope creep. The actual outcome of the project (AKA quality) is less important than?the three sides of the PjM triangle. Quality failures impact the technical lead and the company writ large. Scope, schedule, and budget are direct reflections of the PM. You may have a supportive boss who goes to bat for you when you blow through the budget or are over schedule, but that only lasts for so long.?

To maximize the chance for success, the most important thing you can do is to be loud about problems. If you see something wrong, bring it up. Be annoying and be frequent. Startups deal in the currency of attention — there isn't enough time in the day to hear all the issues or solve all the problems. Bandwidth constraint is part and parcel of startup leadership, and therefore, the issues need to be reiterated repeatedly by PMs. Otherwise, issues fall on deaf ears.?

Second — and related to the first point:?Don’t be afraid to look stupid about the issues you see. If the issue isn’t as crazy as you perceive, then that will surface — technical team members will vocalize points of correction. Often, I have been vocal about issues, but once leadership spent time with the issue, it was not as problematic as I thought. For example, I was often concerned that we stretched design windows to the limit. A closer inspection showed I had not understood the purpose or interrelation of that design effort with other efforts. The design effort that I was concerned about had either been completed already or was tied to another block on my Gannt chart — thus, the time constraint was being conducted in parallel with existing efforts and the schedule constraint was no longer problematic.?

Conversely, I often knew of an issue but was too scared to say something. What if the engineers think I'm stupid for thinking about the problem the way I was? What if I got terminology wrong — again? What if the executive team simply doesn't care about the problem? Should I risk aggravating my leadership for some small — though important — programmatic issues? In all cases, I would rather say something and the issue not be important than the other way around. When in doubt, ring the bell. The worst that can happen is someone tells you to stay in your lane.?

Finally, to ensure you're evaluating the project properly,?reevaluate your parameters constantly. Scope, schedule, budget, available labor— all the inputs are constantly changing at startups. Following are a few good habits to do monthly, bimonthly, or however frequently you see fit:

• Validate labor availability with department leads.
• Verify estimated material costs with purchasing and other PMs.
• Get reauthorization of the schedule’s subprojects from the technical lead.
• Validate customer expectations with business development reps.

And after each of the above events,?document the outcomes. Don’t get a head nod — unless you've recorded the meeting and can clearly see the head being nodded. Get written confirmation via email or Slack/Teams chat. Have a witness. Ensure that the authorization of each team member is recorded and referencable — this is a CYA so that when you identify issues with the budget or schedule or requirements in the future, you can point to the person who approved your input. Unfortunately, startups are largely engaged in the blame game when things go awry. Someone will be left holding the bag. Make sure it isn't you.?

Summary

I loved my time working for startups. That period was especially meaningful for me in breaking off the bureaucratic and institutional shackles ever-present in larger corporate/governmental settings. I’ve grown immensely professionally and personally. I think all PjMs should work for startups at some point in their careers — the opportunity for growth is limitless.?

However, the margin for error is narrow when working with fast-growth, resource-constrained teams. Being mindful of your actions as they relate specifically to the startup space will prove useful in avoiding detrimental occurrences that impact your career outcomes.

I hope that, in those rapid growth experiences, young professionals can be deliberate in their actions and make fewer mistakes given the elaborations in this article. If you, the reader, have any advice, additional notes, examples, or any other kind of feedback, please send them my way.