If you can’t code, you have no business managing engineers

Do you run an organization with Engineers (i.e. Programmers, Developers, Hackers, Code Ninjas)? Is your title Technical Manager, Development Manager, Head of Technology, CTO, CIO, or any other sort of title that communicate “I’m in charge of technology”? If so, congrats on reaching the apogee of the tech department — Yeah career! Nerds rule!

However, are you able to answer this quick question? What is the output of the following function?

Did you get it? Great! Would you be able to write this in your programming language of choice (this was written in Scala, by the way)? Awesome! You can save your time and stop reading this article now, and perhaps go back to reading Hacker News. Note: if you are in infrastructure, hardware, or another technology area, you can use an equivalent example such as being able to create a circuit diagram, grep logs, mount a drive, setup a server, run Puppet, setup a cluster, etc.

However, if you were confused, had no clue what this function did, didn’t get the answer 120 (5 factorial), or couldn’t write something like this in any programming language, please remove the word “Technology” or “Technical” or even “Information” from your title. To be blunt, until you brush up on your skills, you just don’t deserve to be called technical anymore (or maybe you never did).

Yes, I know, you think I’m crazy. At your level/responsibilities you don’t need to know how to program or how the technology works. People do it for you. I get it. I’ve been told many times by non-technical managers who had those titles, and couldn’t figure out the simple function above, that being a “good” technology manager doesn’t require you to be technically skilled. Sorry, but I gotta call bulls–t. Only people without technical skills make that sort of weak argument. The rest embrace their technical skills to be amazing leaders.

Leading the troops

Let’s run through the a common argument and see if I can defend that being a technology manager requires actual technical expertise.

“I manage a big org, I don’t need to know the how to code or the technical details.”

“I have good people who do.”

“I lead and inspire.”

Leaders lead by example. How do you expect to “lead” or “inspire” an Engineer when you are unwilling or unable to get in the trenches with them? Do you know why George Washington’s troops loved him to the point that they would die for him? Sure, he was in charge, wore the fancy outfits, and had a cool title (General and Commander-in-Chief — awesome!), did the big picture stuff, etc, etc. But that didn’t convince his troops to boldly charge into battle. They did so because they felt he was one of them. He understood them. For example, Washington walked, ate, and lived amongst his troops when they camped at Valley Forge during the brutal winter of 1777–1778. He could have stayed in a big house with a warm fireplace, but he didn’t. He didn’t because he was still a solider, just like he had been many years ago during the French-Indian war, and was still able to be a solider.

Code something, no matter how small, and release it to production.

I’m not saying you need to be coding all day, but the test is have you ever released to production at your company? Have you experienced what your team does daily? If you must, are you still able to still get into the trenches? Code something, no matter how small, and release it to production.

Get coding again

When I worked at Goldman Sachs, my first day there a Super Senior Managing Director (un-official title: SSMD) sat me down and personally gave me an overview of the code structure. He knew how the systems worked and what it took to build them. Awesome! Know what, he had my absolute respect from that moment on. Even more importantly, a lot of his success came from being able to make the right decisions because of his deep understanding of the technology. I found out later that at Goldman every person in technology must be technical. At Google and Ladders (where I work) even Product Managers get programming questions (albeit simple ones) during their interview. Why? Because if you are going to work with Engineers, have the respect of Engineers, and truly understand Engineers, you need to be technically proficient.

ThoughtWorks furthers the idea of needing to stay technical (for a Tech Lead, but can be applied to anyone with a “Technical” title):

If you do not spend time with the code, you run the risk of invoking the “Ivory Tower Architect” anti-pattern, leading technical decisions without understanding their real implications for implementation or maintenance. This anti-pattern has numerous side effects including destroying trust with developers, increasing the development time of new features, and increasing the accidental complexity of your software systems.

Just like my previous manager (SSMD), you probably ended up being a technical leader because you love technology, and probably coding. The trick is you can’t let that part of your skill set wither away. It is easy to let your tech skills rot when your day is 90% meetings and 10% budget planning exercises. Luckily, no one is asking you to be the best Javascript developer. However, if Javascript is one of your team’s primary languages, for goodness’ sake, take a course or crack open a book or launch Atom to stay technical for the sake of your team, your company, and yourself.