Being More Effective in a Technical Job

Due to some mentoring from a friendly colleague I’ve taken away a simple, but valuable lesson about managing a resource constrained technical problem within an organization.  For those of you that have become frustrated trying to solve a problem while also “managing your managers”, this may add perspective.

Background:  I’m currently tasked with delivering a high-profile, but uncertain R&D solution where, like everything else, it was needed yesterday.  It has the attention of several levels of managers with varying degrees of technical understanding and there are many indirect paths of communication within the organization.  In these scenarios, keeping communication coherent is a project itself.

As such, the frustration came in having to spend as much or more time in meetings answering questions, talking about plans, reassuring interested parties…etc than actually working to solve the problem.  I’m sure I’m not the only person that’s wanted to say, “I would have this answer for you, but I’ve been too busy talking in meetings!”  The conversation with my colleague helped me understand that the perception of how the project is going is separate than the reality.  I thought of a sort of truth-table to illustrate the point, shown below.

Perception graphic

Obviously we all want to be in Square 1, where the project is going well and managers perceive it as going well, and want to avoid Square 4, where it’s all going poorly.  So which of the other two are preferable?  This question is relevant because you may be confronted with a choice on whether you prioritize spending time on aligning communication or on solving the technical problem.

Consider the dynamics of being in each of these two squares.  Put another way, if you’re in Square 2, are you more likely to end up in Good/Good or Bad/Bad?  If the perception is bad but the project is going well, you’re likely to get intervention from managers since they see the choice as either stepping in to fix the problem or doing nothing while the project fails.  Obviously a self-interested manager would do the only thing they can, which is step in to help.  This may be a good move if the project is actually going poorly, but if the project is doing well in reality, this is likely to hurt the chances of success since presumably you are the expert on solving the problem at hand and were given the task for a good reason.  This means you’ll be spending your time trying to justify your plans or explaining why alternative plans are not as good instead of doing real, productive work.

Alternatively, in Square 3 you have real work to do on the problem but the managers trust your vision and do not intervene disruptively.  This essentially buys you time to redirect into Square 1.  In the previous case, you’re spending more and more time convincing people of your vision and fielding technical nuances, which takes away your time to actually solve the problem.  In this way the communication is very important for keeping the project on track because it has practical consequences on resource allocation.

This understanding of communication have shifted my perspective on priority.  Before, as a technically minded person, I would have said Square 2 was better because once you get traction on the problem you can sort out the communication.  I now better understand the adage “Perception is reality.”

Leave a Reply

Your email address will not be published. Required fields are marked *