Overcoming self-doubt and enabling technical leadership on projects
Over the past few months I’ve been a part of a small team enacting sweeping technical process change in an organization I’ve worked with long-term. I’ve worked closely with developers and the tech lead to establish and enforce technical and project standards. Through doing this, we’ve increased the quality of our development work, but it’s also shed light on how many gaps exist in my knowledge of the development process itself. Mitigating the mental realization that I know much less about the technical details of the development process than I thought I did is difficult at times—and can lead to self-doubt towards my role as a freelance project manager.
Right now, I work closely with small agencies and understaffed in-house teams on projects, which means I am used to playing a key role from the initial call with prospective clients or upper management, to launching the project directly with development teams. I am a designer by background, and a project manager by trade. I’ve never worked as a developer or written a significant amount of production-ready code. I’m knowledgeable enough to understand basic troubleshooting within various CMSes or in front-end work, and to speak with clients intelligently about their technical needs, but by no means am I a technical project manager.
The nature of project managers in technical environments and the self-perception of project management that arises from that is something that’s always been interesting to me because of my background. As a consulting project manager, I work with many different teams across many environments, which gives me a broader view of my project management role in a range of contexts. I work on small, specialized projects where I’m able to contribute meaningfully to basic technical needs (such as speccing out development requirements, estimating additional functionality, or contributing to technical critiques based on other similar projects). I also often work on large, complex development projects where the entire scope of the project is within my understanding, but the finer details are better planned by a technical lead or technical project manager. There is a lot of opportunity to learn and grow through my work, but also a lot of opportunity for self-doubt and unfair self-comparisons.
Throughout my career, I’ve experienced the same recurring doubts, questions, and concerns about my role and my skills as stricter and more efficient technical processes are enforced across teams. Much of this has been a product of “you don’t know what you don’t know”—when I’ve worked with teams that don’t have a strong technical review process, I haven’t been able to catch issues that would otherwise be checked within the first few steps of code reviews or technical QA by a technical lead. As I work with colleagues and other freelancers to tighten up project processes, inevitably pieces of technical knowledge that have escaped my purview or understanding will come to light. Recognizing these gaps in knowledge is a scary thing and can lead to those recurring doubts and questions about my own role within a project.
When technical leadership is needed over my project management expertise, it’s hard to find my footing and the best way to utilize my skills within the context of the project and team. It is disconcerting to get to a point on a project process where I’m no longer the expert and can’t provide expert advice—it goes against the grain of being in control of a project. But this is ok, and something I am slowly learning to adapt to. As Holly Davis reflects in her article “When Letting Go is Good”, it can be difficult to resolve the feelings of redundancy on a project when things are out of our hands as project managers. That can make it difficult to understand our roles and best fit with the team and project. It’s hard for me to find the project management sweet spot when others on a complex project are competently in control of the technical details.
Finding that higher level approach as a project manager takes time. I’m still learning to adapt and teaching myself not to feel redundant or anxious when a project is outside of my skillset. But there are a few things I’ve come to find myself relying on when I’m working on an especially technically-driven project with my team. Remembering the reason I became a project manager and acting on that reason within a project helps me find my footing more easily as I question my role and adjust to the situation at hand. I moved into project management from design work because I saw the need for better communication between teams and with clients. Now, I work on mostly remote teams, and communication is even more critical to the projects I work on. This is something I can really examine and dive into when the technical details of a project are being handled by the tech lead on my team.
When my role on a project gets handed off to a technical leader, it allows me to dig more deeply into my skills that are less process-based. I can do things like better define and shape goals for the team; communicate more frequently and deeply with key stakeholders; work more closely with teammates on specific issues on projects; and connect day-to-day workings of the project to larger, company-driven operations goals. Taking a higher-level, more strategic look at the overall project goals and managing the people and communication involved, rather than the process or data, takes a skilled project management hand. These skills can really benefit my project when my team already has the solid process and skills beneath their feet. Now that I’m “freed” of the more detailed work within a project, I’m able to elevate the level of project management, communication, and skills being showcased in the project backend.
Elevating my project management strategy on the complex, technically-driven projects I’ve described also has an added benefit: it allows me to better review and evaluate my own project skills, and measure these against the overall project successes and failures. It can be hard for me to remember that the designers and developers I work with are skilled in measurable, intellectual and creative crafts. As a project manager, my skills are less directly measurable or visual, and my project successes and failures are the result of many people, processes, and data working together to ultimately reach a project launch. When I’m able to step back from my usual role and think more deeply and critically about how I can help my team and the project goals, I focus more on connecting what I know I’m good at to the needs of a project in a more creative way. That ultimately helps shift my perception of my role when I might be feeling redundant or critical of myself. It gives me positive experience to draw on next time I’m in that position, and more concretely allows me to compare the needs I filled on the team to the overall project’s outcome.
Using technical leadership on a project as a jumping-off point for more highly skilled PM work can be extremely beneficial, both personally and for the team. It allows everyone on the team to be more focused within their own skillsets. Project and company goals can start moving to the next level in strategic thinking, rather than just strategic execution. As I continue to be a part of technical process reform and technical projects in general, I’ve learned more about how I personally view my role and success as a project manager. Working in a more skilled way has forced me to understand my strengths and weaknesses and be more honest with myself about the things I’m good at, rather than always looking at the negatives when I’m not knowledgeable about something. It also allows me to be more focused in personal development opportunities. While I still (and probably always will to a degree) experience self-doubt, I’ve also started understanding better, more proactive mechanisms to employ when I’m a part of a project that will require me to step back from my usual role and think more critically.
Do you ever experience this same self-doubt? What tools or tips do you have for managing it?
