Give Engineering Teams Problems, not Solutions.

My oldest daughter Eire is a Real Estate Agent in North Carolina.

Yesterday she popped into my office after a long day showing houses. She waited for me to look up and said, “Hey.”

Me: “How was your day.”

Eire: “Great! I have another client that’s an engineer.”

Me: “I’m so sorry, honey…”

Eire: “It’s all good! I have A LOT of experience working with linear thinking, data craving, forever questioning, always doubting, engineers.

Me: “Ouch! what’s your trick?”

Eire: “It’s all about giving them the data so they can solve the problem themselves, and then tell them how brilliant they are…”

Me: “and by the way, you’re outta the will.”

That conversation left me a little shaky as I realized that my daughter had all the tools necessary to manipulate me at will. How long had this been going on?

The simple truth is that engineers are different, especially software engineers. Who would willingly attempt to make a living in an industry where one misplaced curly bracket can be the difference between success and failure?

Engineers, that’s who!

For those who wish to engage, motivate and inspire tech teams, this little gem of a concept is more valuable than cheese to a hungry mouse. It is the Holy Grail of tech team performance! (This is an exaggeration, of course. If you want to dive into the psyche of the developer, I would suggest Coders by Clive Thompson it is an excellent read with plenty of valuable insights).

Sometimes I am stunned to realize just how relatively new the software development industry is. In 1980, there wasn’t a single application using the “world-wide-web,” and I didn’t have a laptop or a cell phone. Even though I understand that I didn’t have those items because they didn’t exist at that time, I struggle to imagine how work got done without them!

Enough reminiscing; let’s get back to motivating engineers and tech teams. High employee churn and low employee satisfaction levels suggest that most tech organizations today haven’t “cracked the code” about retaining and attracting top tech talent.

There remains a significant gap between how most tech team employees are treated and the leadership or managerial behavior that keeps employees engaged and smiling. This behavior is an organization-killing disconnect.

Here are three suggestions that will help make your tech teams feel more engaged.

1. Accurately Define the Problem.

Problem Definition is often more challenging than it sounds. Too often, product and business teams get lost and jump directly from the pain to the technical solution. This rarely results in the optimal solution. Employ the rigor necessary to stick to the problem at hand. (This is one of the reasons I am such a big fan of the Amazon “6-Pager”)

It’s easy to conclude that the first deconstruction of the issue defines the problem. It usually does not.

The “5 Why’s” from Lean Manufacturing are an excellent tool to dig deeper into the problem. Way too often, we waste valuable resources solving the wrong issue.

I had a Lehigh professor who estimated teams’ frequency of solving the wrong issue as high as 90%. It pays to focus first on defining the problem correctly. The problem is often not obvious, and after consideration might not be a problem at all! (More on that in another article).

For your Engineering partners, it is infinitely frustrating to spend time and effort solving the wrong problem. It is even more disheartening for the individuals consuming a significant amount of mental and intellectual energy building the solution to a problem they aren’t sure will address the real issue.

It happens all the time and leads to the second suggestion.

2. Actively Solicit Input from your Tech Teams

Once you have taken the time to define the problem accurately, stop. Yes, stop, do not pass go, do not collect $200! Now is the time to pull in your best technical problem solvers.

The Product and Business teams often travel too far down the path of defining the technical solution before pulling in the tech problem solvers. I know how challenging it can be to broker a discussion evaluating options when it seems like the other side is speaking Gaelic. Technical folks seem to have perfected the art of the acronym, the buzzword, and having at least three names to describe the same thing.

But it would be best if you got past the language barrier. The benefits can be immense, as early architectural decisions can make or break a solution.

Just like it can be frustrating to work solving the wrong problem, it can be equally disappointing using sub-optimal technology. The story of Goldilocks provides a good analogy. For the best result, the combined team needs to select the optimal technical response.

There are justifiable excitement and associated engineering enthusiasm associated with using bleeding-edge tech. The challenge is keeping the team from falling over the bleeding edge and using the best technology available for the problem at hand. The “just right” selection will often be the Momma Bears porridge.

If you want to keep your tech teams engaged, stay at least up-to-date on your technology. Developers value this highly, and your top talent will often look for other situations where learning, development, and the ability to use new technology are available if they feel stagnated.

This leads us to the third suggestion.

3. Provide Space to Learn

Engineers love to learn new things.

I admit there is a certain amount of arrogance and competitive drive between technical folks. Developers will spend hours of their own time learning the newest language and the newest build tools to stay ahead of their peers.

We appreciate it when the organization provides the time and resources to learn and grow. Focusing on your tech team’s development is a great way to reduce turnover and improve team health and employee retention. There are many ways to help your tech teams grow in competencies and engagement. Providing Mentorship programs is one of the most effective. 91% of employees currently working with mentors are satisfied with their jobs.

I understand that great thinkers and problem solvers are scattered throughout the organization. Engineers don’t have a lock on those traits.

However, when the team is looking to leverage technology to solve a problem, it seems rather silly not to invite the organization’s best technical problem solvers to the party, doesn’t it?

Thanks for reading. If you want to continue the discussion, please drop a comment, reach out at Ajito.io or via chris@Ajito.io.