So I Hear You’re Working On A Project

Technical Marketing Person:
“How’s the turbo-encabulator demo coming along? Are you going to be demoing the inverse reactive current for the unilateral phase detractors?”
Engineer:
“Um, no … I don’t remember seeing inverse reactive current for unilateral phase detractors in the requirements document …”

Some of us have been there (hopefully you have not!) the moment when someone from marketing asks if a feature has been included in the demo spec, and it hasn’t. Even worse, the question comes at nearly the end of the project. And the first thing you think is: “How did this happen?”
An engineer or a project lead has a seemingly endless number of things to keep track of and develop when starting a new project or program. A big part of engineering is solving technical problems, but there is a whole other dimension of less technical things that you should consider.
Requirements. Requirements, requirements, requirements! Getting specifications and project details from customers and stakeholders can be a really painful and stressful part of any project – technical or not. BUT, once those requirements are documented and agreed upon (even if they evolve over time), it helps reduce situations like the one above with our turbo-encabulator.

People. They’re everywhere. You work for some of them, and perhaps some of them work for you. Either way, you are all working with each other to get to the solution to a specific problem (or a large number of problems). Communication between team members really is super important. If you’re a leader, make sure you work to identify what your team members’ strengths and weaknesses are, and suggest different tools and methods to better themselves – especially if it’s communications skills. If you are working with the team, always work on bettering yourself as an engineer and as a communicator – take classes, solicit feedback at review time, and review your previous correspondences to make sure that what you thought you communicated actually was received that way.

Resources. Although you work with people, in some cases, it’s important to look at people like they are resources. You would not, of course, pick a 110V relay for your 280V design, or use twine to attach your communications satellite wire harness to the frame. In engineering we are presented (sometimes relentlessly) with different tools to pick from when solving problems. We spend quite a bit time researching and learning those new tools to help us pick the right ones for our particular project. We should apply this same level of rigor to picking people when assigning tasks on projects. You wouldn’t put your material scientists in charge of picking what embedded software framework to use, so don’t pick people to solve problems that they aren’t good at solving. Work within your team to decide which tasks are going to be taken on by which members.

I really enjoy working in teams, and learning to better understand what my team is and isn’t good at. As an engineer, I love problem solving. And if I’m given a puzzle of different personalities, skills, abilities, and passions, I look forward to the optimization problem ahead of me at the beginning of each new project!

Want to read more about this topic? Check out this white paper I put together on the “Top 5 Embedded System Design Fails – Common Pitfalls and How to Avoid Them”.