One of the most popular questions new PMs ask is if they need to have engineering knowledge to be successful. The consensus tends towards development experience not being necessary but a nice to have.

You’re typically PM-ing in two main scenarios; first is you work in a mid-large organisation with some structure, and second is you’re a PM or founder working in a startup.

In a startup environment, you’re typically running lean as compared with more structured environments where you have full teams with engineering leads.

Beyond having a smaller team as a startup, you’re probably also dealing with one or both of these issues –

• If you’re bootstrapping, you probably can’t afford the same level of engineers (experience and exposure) that you had the opportunity of working with at your old mid-large organisations.
• You no longer have the benefit of a proper structure so no escalations etc. you’re the final bus stop and you have to figure out a way to get people to commit.

Being a non-technical PM and founder myself, and coming from more structured environments, I’ve learned some ways to ensure successful product delivery as a non-technical lead.

First off, I needed to come to terms with my reality shift. I was now in an environment where the entire buck stopped with me. Yes, being a PM had always meant I was responsible and accountable for my products but the difference between a lean startup environment and more structured organisations is that in structured environments, you have an engineering lead, a CIO or CTO or some combination of these, jobs and goals defined and segmented, and even in the flattest of structures, there was usually hierarchy of some kind.

Here however, it was me and my ears. So yes, I quickly learned to acclimatise.
‍

I identified the main issues I was facing, and after sampling the opinions of other founders, it was clear we had common pain points.

1. Understanding and agreeing on deliverables and timelines – you want to find the balance between getting the job done asap and being reasonable in terms of timelines but because you’re technically the CIO (not CTO) in this case, you can only estimate work with timelines your team agrees to. It puts you at the mercy of the team.
2. Managing remote teams – short of installing monitoring tools on their work tools, it’s tough to ensure you have their FULL commitment withing the agreed work hours.
3. Responsibility and Ownership – Lately, a lot of people (not just engineers) have become all about the NOW. They’re interested in accumulating as much wealth (well, cash) as possible and do not mind being mediocre at 2/3 jobs rather being great at one. I guess we have the economy to blame for this or the fact that people are just greedy and unethical.
4. Confidence and Belief in you and your startup – I’ve also realised that one of the main reasons people take on multiple jobs is because they’re worried your startup will pack up and they’ll be left stranded. This is a fair concern to be honest so it’s important to have clear and transparent conversations with people you’re engaging so they see the big picture and understand the journey.
5. General ‘wickedness’ – I quickly realised the truth in the Yoruba adage “gbogbo alangba lo danu dele, a o mo eyi ti inu n run”. This loosely translates to “all lizards lay flat, we can’t know the ones with tommy aches”. Some people are just wicked and there’s not much that can be done to change that. This is how I categorise issues IP theft and other forms of scamming or shafting.
   ‍

With years of iteration and practice, I've found some mitigating methods that have proven helpful in securing better outcomes for teams with these dynamics
‍

1. Ensuring goals and tasks are clearly defined. Leave no room for assumptions. I know it seems like this goes without saying, but you’ll be surprised how much room we leave for assumptions especially with the definition of done.
2. Clearly defined roles. No matter how lean your team is, you should have clear roles and responsibilities. Take advantage of the RACI matrix. You may have situations where the same person is responsible for multiple tasks or roles, but this should be defined. PS: This is not to be confused with clearly defined tasks. See image 1
3. Inspiring confidence and belief in the project/startup by extending ownership. Share a bit of the pie. People want to feel like they’re a part of something great and that their contributions are valued.
4. Process. Process. Process. Have clearly defined processes and stick with them. Of course, change your approach or tools if they’re not yielding the desired results but there should always be a guide to achieving the goal and it should always be adopted across the team.
5. Communication, transparency and respect. This sounds mundane but it isn’t. a lot of teams have broken down due to inadequate communication. This also ties back to ownership. Transparency allows everyone to be on the same page and you can avoid ambiguity.
6. Governance. Whether your startup is one day old or ten years old, governance is key. I’m not talking about corporate governance now. The governance we need here however is more focused on technology. You should have oversight of all technology access and tools. Redundancy is also very important. For instance, your code repository should be backed up regularly, you should have some level of redundancy for all your tools and access points. Your admin roles should be locked to trusted leads or only you etc.
7. Self-development. Yes. You’re non-tech but working with techies means you need to level up. I don’t mean you should go and enroll in a Java for Beginners course, but you should understand the basics. Do the research. Once you’ve defined the goals of your startup/project, find out what is required to go from idea to execution and beyond. Talk to people who’ve done it before. Build a network of people who understand what you’re trying to do and engage with them.
8. Get yourself a technical guardian angel. If you’ve been in the industry for a while, you probably know a few tech people you can trust. They may not be available to work on your project/startup, but they can provide guidance and help you navigate murky waters.

Good luck!