Being the non-techie in the room

When I started at TandemLaunch, I came straight out of university and the closest thing I’ve ever came to an engineer was the plumber at my parent’s house. I had no idea what an FPGA was, never heard about C++ and only had a vague idea how computers work. Applying for a job at a tech start-up seemed kind of ballsy, but that’s how I am.

But I’m realizing more and more that a lot of project managers don’t have a clue what their engineers are doing (or are supposed to be doing.) The number of project managers who have a background in engineering is declining steadily – thanks to specialized degrees in project management and the flood of MBAs who think project management is “no big deal” because they took a class in it.

So how do you deal with this lack of knowledge? How do you get the engineers to respect you, even though they know much more than you about the work? Here are a couple of things that I found useful.

Be honest. Don’t pretend to know something you don’t. People with domain expertise will figure you out in a second. Pretending is never a good idea – and can destroy your credibility when you are called out on it. So just admit you don’t know. This is generally a good piece of advice – if you don’t know something, just admit it. Use your project management skills to gain credibility within your team instead.  Don’t make the fatal mistake of building a project plan in isolation of the project team that will be executing on it. Draw on your team (that’s why they’re there).

Be open. One of the things I love about the engineering team at TandemLaunch is that every single one of them is completely passionate about what they do. They just love their job. And as soon as you show interest in it and ask questions, they will love to teach you. Remember you are a part of a project team: a group of people with different skill sets working together towards a common objective.  Take the time to appreciate their contribution as much as you hope they will appreciate yours.

Learn. This is not just for your job, but for your life in general – why not learn coding? Sure, I’ll never be a software engineer, but at least I am able to understand what the engineers are talking about. The great thing is that there’s tons of free stuff out there. The standard sites are codeacademy, codeschool and udacity. There are also python classes over at kahnacademy. Which one is the best depends on what you want to do with your code. For web, JavaScript, HTML, Ruby and CSS are the ones to choose. For a more “hardware” approach (computing and the like), C/C++, Java and python. You could also look into some scripting language like perl, which is more for text/file processing. For something more UI oriented, C# and VB are the way to go.

Show your value. There are a couple of things that engineers – as a whole- are not really keen on or are not in a position to do. That’s why your role exists! So demonstrate your value here. In general, this seems to boil down to exact specifications. Nothing drives engineers crazier than ever-changing specs.

And if you want to hear this story from the other side, there’s an excellent blog post on the care and feeding of software engineers by Nicholas Zakas.

Leave a Reply