Should a SDM be able to code like a SDE?

It is a controversial topic: Can a SDM code? Should a SDM code? How often should a SDM code?

A bigger question is: how technical a SDM should be? Should a SDM be proficient on all the technical chops: system architecture, security engineering, data flow and operational excellence etc.?

There are two schools of thoughts we often hear:

1. A SDM should first be a good engineer. “While officers and generals may not be expected to engage in direct combat as frequently as enlisted Marines, they are still required to maintain proficiency in marksmanship and other combat skills. In fact, Marine Corps officers are required to complete the same basic training and combat training as enlisted Marines, which includes marksmanship, close combat, and other essential combat skills.”

Whoa! If we follow this standard then a SDM needs to be able to take over the keyboard from a SDE at any moment. Not all SDMs are from SDE track, we have SDMs that were Product Managers, Technical Program Managers ... These tracks are all “technical”in their own ways, just not “coding” specifically.

1. A SDM just needs to know what questions to ask. Don’t judge, don’t be biased by your own opinions, just keep your mind empty and keep asking common questions like:

“So what do you think you can do differently?”

“What else can you think of to make X better?”

“Can you figure out a better way to communicate your ideas?”

These are all good management techniques but if we push it to extremes we are basically saying SDMs could be leading a team making diapers yesterday and today they can do cloud computing equally well, as long as they know what questions to ask. They don’t need to know the answers! They don’t even need to know what answers are better.

That is rarely true.

There is a reason we are called “software development manager”, not just “manager in general”.

Being technical can mean product vision and insight, project management skills, and software engineering techniques. On top of all these technical stuff, a SDM needs to be proficient at people management, which requires technical judgment to evaluate and grow people reporting to them.

Here is the keyword, “technical judgement”. For a SDM, technical judgement is more critical than knowing all the technical details, although without sufficient details and hand on experience, having a sound technical judgement is impossible.

A SDM needs to have the technical judgement of what is good and what is bad in software engineering. They use the judgement to decide “what to do, when to do what and who should do it”. They are not necessarily into the weeds of “how things are done”, but they set up

1. Standards to judge if things are done well or not.

2. Processes to make sure things are done in the most optimal ways.

So should a SDM be “technical”? Absolutely! Should a SDM know how to code in all the components of a product, not necessarily.