Don’t be a developer, be an engineer

Reading this, you may be left with the feeling this is the most obvious thing in the world. But I do not think it is. At least not to most people.

Engineers build things. However…

… imagine someone building an elevator. Or a rocket having to launching itself into space. Or a bridge that has to withstand the elements. Or simply a car. However, there is no specification. The requirements are not understood. Nobody has asked if it should be fast, or secure. Or luxurious. Or go a long distance. Whether it should run or petrol, or diesel. Or electricity?

Now, ask a bunch of engineers to deliver this product. Or go through a process to procure the required components. What is the outcome? It will be up to the engineers to define right? Do you think it will be successful? Do you think the engineers will solve for the problem you had in mind? The market that you had targeted? Within the financial budget? If the answer is no, then why is that?

Could one of the issues be that the engineers do not understand which problem they are solving for? Who’s fault do you think it is? And what do you think is the result in the above example? Expectation rarely matches with reality. However, getting close is a possibility.

In Software development, many developers call themselves engineers. But they are not. There is a difference. And many of the leaders in Product and other positions setting the agenda, does not always appear to understand what being an engineer entails.

DON’T be a developer. Be an engineer. Great engineers are paid to solve difficult problems. In a meticulous manner. Building things to specifications that match requirements. Holistically.

To solve a problem, you have to understand the problem. The problem needs to be well understood and clearly defined by stakeholders. The problem statement has to be… crystal clear. To set the vision and mission. Allowing engineers to design, and build successfully. To execute.

You CAN’T FIX what you CAN’T SEE (debatable), you CAN’T BUILD something you do not understand (do not have the requirements/specifications for). And you CANNOT (provably) IMPROVE what you cannot measure. Define the problem. Make it crystal clear.

Go back to the car.. is it designed to be safe? Or quick? Or luxurious? Is a specific market segment targeted? Would you want the product to be delivered to target that market segment? To be successful in its mission? To successfully deliver towards the vision? If the answer is yes, what is that vision? What is that mission? What is the problem statement? Is it well defined? If it is not well defined, how would you expect engineers to solve it? How do you expect engineers to execute on the mission? Or deliver on the vision? Will the product you invested in, be different towards what you envisioned? If so, what do you think is the root cause? Could it be the lack of a:

• Crystal clear problem statement? (Defining the problem you are solving for)
• Vision? (Where you are going)
• Mission? (How you get there)

Every person, whatever their role, whatever their level, has bad ideas and good ideas. Accept it. Let your ego go. YOU are NOT your ideas. An attack on your ideas is not an attack on you. If you are not willing to accept feedback, you won’t learn. You won’t grow. And growth… without being uncomfortable… is difficult.

Being uncomfortable is the result of performing tasks that DO NOT already has existing neural pathways. Pathways that are created through iteration. Until it almost becomes… automation. Like learning how to walk. Or learning how to drive. Or riding a bike. Difficult. These are uncomfortable to start with. Less so… over time. After a while, you do it, almost without conscious thought right? It comes about through practice, through learning, through iterations. Rejecting the bad, refining the good. Practice makes perfect.

No-one has all the answers. So focus on executing on good ideas. And weed out the bad ideas.

So how do you weed out bad ideas? And execute on the good ones? Well…

1. Define the problem. Make it crystal clear.

2. Develop an idea that may solve to the problem. Write it down.

3. Present your written idea to relevant stakeholders. Request constructive feedback.

4. Remove the ego. Consume the feedback.

5. Take the rejection of the bad, or imperfect parts of your ideas on the chin. You are NOT your ideas.

6. iterate (Rinse and repeat).

Define the problem, set the vision, and mission. Reject bad ideas, refine good ideas. Be meticulous! Stay with the problem, until you are ready to execute meticulously. On the RIGHT problem.

Be an engineer. That build towards specification. Make sure that the people setting the agenda do the due diligence and comes to the table with a clear problem statement. What is to be built, and why it is being built…. needs to be made CRYSTAL CLEAR.

P.S. You think this is a terrible blog post? You are probably right. It is unclear, without a clear and focused alignment of title vs content. A bit of all over the place isn’t? It is the seed of a thought, written down in one session. That can be iterated upon. So that the message ultimately becomes a clear one. Remove the ego. Iterate, rinse, repeat.