Better or Worse Engineers

The Better...

Lead by example. Once, one of the oldest engineers in the building (a recognized expert in an obscure technology) for many weeks would come over to my distant cubicle and stay late into the evenings walking me through how it worked so I could write a tutorial. He wasn’t from my group, didn’t owe me any time, and I should have been met him whenever and wherever it was convenient for him. This was a profound example of both humility and kindness to a junior engineer. Thanks to this undeserved and unexpected help, I produced the first thing I was proud of there

Take side jobs as they come along. Take as much experience as you can get. Extra money is great (don’t forget to pay the federal taxes before year’s close). The experience, far more than that, has been invaluable. One client I spent two days per week for more than a month heading to DC evenings to teach a network administrator basic Cisco and Windows skills. It was a miserable commute and I charged way too little for the effort. But I find I really love teaching. Effective teaching forces you to be clear yourself how something works, exposing your weaknesses suddenly and rudely. Three other projects put me in a lead role guiding more junior engineers. It’s one thing to run into a problem, muddle through on instinct and fix it. It’s quite another thing, in the heat of the moment, to have to detail the right command via WebEx for others to input, explain what you’re looking for, analyze any diagnostics with them, explain the apparent problem, propose the solution, and finally why it did/did not work and next steps. Any questions that emerge, you will undoubtedly research for your after-action report. Sometimes the problems are aggravatingly simple, only slowed and compounded by your abstraction from the working environment. I've found my train of thought even reset in the delays. But get the right engineers under you and this yields an enormous sense of accomplishment when the project closes.

Every now and then the “expert” is just working one step ahead of those he leads. Still, the effort appears smooth, ends in success and everyone looks back on the long set of steps everyone took to get there. At that point you can even admit this openly and people will think it is just humility. Success counts.

Whether as a consultant or employee, when they are paying you, all efforts from that point are "we". Hopefully they treat you well, but even if not you are part of the company and as invested in the project's success as they are. That doesn't stop until your last paycheck.

The projection of competence amidst incompetence is an invaluable skill. When I took over as the acting head of an IT unit, I was suddenly the Windows server, Novell, Cisco, storage, and budget guy for my group, while knowing next to nothing about these. On top of that, my Dean (CEO) was worried about projecting weakness among other Medical schools who would like nothing better than to absorb my group into their larger structure and they could manage our services. Everyone is building their own empire. My Dean’s instructions, while I came up to speed on the technology, was to get the campus to pay for some of our network through their shared programs, get it done, and not give away the farm. I attended a number of meetings with extremely technical people where I was completely outclassed. I had to fake competence. And failing that, I had to fake confidence amidst mild incompetence. And I asked my questions, did my research, and built. And I was dogged, stubbornly stuck on details, and impatient as to timeline; in short, deliberately annoying. Within one year, I had my new network (years before anyone else) and had demonstrated our self sufficiency. Within three years I was advising other departments on what they should do. I got just about all I asked for, campus paid for (surprisingly) most of it, it was installed in record time, and I even managed to save the Medical School money (a point of pride for someone in my little Nursing School). The icing on the cake, after giving a lecture at a seminar, was when one of the Humanities engineers let slip that for years the School of Nursing's IT efforts had been the butt of jokes. No longer.

Come prepared. When I took over as acting CIO, I had my first budget to prepare. I did my best. When I came before my Dean’s Committee (CxO board), she parsed my request and immediately spotted a $20k math error in the training fund and sent me back red-faced to redo it. That never happened again. I learned early on to write out everything in exhausting detail. I once bragged to an interviewer that I wrote 30 pages to justify a $60k request to outfit a new datacenter, which he thought was nuts. To him, I was bragging about how much effort I put in for so little. For me, it was about having figured out the secret to getting things done in my space. If I needed to write a book to do my job, I did it happily. I learned how to document and prepare thoroughly. I got just about everything I ever asked for from the CxOs of my school. I once went in with a $150k limited scope capital request, all "i's" dotted, and was sent back out to figure out if and how I could use $300k. I'll never forget that feeling.

Proof-readers are awesome, and there’s always someone better. I always thought I was that strange engineer with a bit of an English background. We hired a Russian technician who had spent most of his time previously working in our research offices drafting grant proposals. I learned early on to send every proposal I wrote (and had already quadruple-checked) to him. It always came back heavily marked up. He was right 95% of the time. I swallowed my pride, made the corrections, and almost always got my plans approved.

Iron sharpens iron. Stay away from the mediocre engineers. Spend your time with the brighter stars, even if you’re the dullest one in the room.

First year on the job in a more capable engineering team, pick the lowest (competent) engineer on the totem pole and make sure you at least perform (not simply appear) better than them. When you do, repeat as necessary with the next lowest until you are at the top.

Figure out where you place on the engineering hierarchy. If you’re the most experienced and capable, get out in front, (tactfully) make recommendations that make others look good, (tactfully) fill in knowledge that the others don’t have; be a force-multiplier. Engineers are ego-driven. Good engineers will respect ability above their own egos, if grudgingly. If you’re not the most experienced and capable, figure out who is and siphon lower grade work from them in exchange for mentoring and experience. Be a force multiplier for those above as well as for those under you.

Certifications are great for keeping or getting a job. It used to be unquestioned: the value of Cisco certifications. For my part, they have proven nearly worthless when compared to on-the-job experience. I blew passed everyone in high school, but once in college I was uninterested in studying for tests while I immersed myself in the practical assignments. Others find the studying a good way to learn. I got my CCNP and CCDP to negotiate my way through a contract changeover. It worked. I later passed my CCIE RS Written when I had nothing challenging to do at work. At the least, it got me most interviews requiring a CCIE which weren’t open to me earlier (blame a CCIE shortage). My friends who have their CCIEs and many going for it will deservedly be highly paid engineers. I have the nagging feeling that the continued effort needed to get these specific certifications doesn't get me where I want to go. I don't want to be that kind of engineer, that deep in the weeds. It's not a destination. At best, it's a way point; at worst, a detour. Better to understand that.

How you look at the next up certification gives you a clue as to a changing career path. If getting that certification doesn't get you where you think you want to go, don't bother.  Time is precious. Trade it for what will pay off, rather than vague potential to payoff. Same thing for the wrong degree. It flies in the face of the common wisdom that you need to qualify yourself before you get the work. In some professions yes, but not always in engineering where learning by doing and self-research is common.

My first mentor taught me everything I knew about programming and network administration. His degree was in music and his first few years were spent in Nashville writing for Christian singers. It's amazing how many different fields of study end up preparing the mind for computer engineering.

The Worse...

In one position, it was not easy working under most of the managing engineers. Although affable, likable and approachable, one was hands-off and only reached out when he wanted updates. You could tell him the problem but wouldn’t get much more from that. Another gave only the most high-level of requirements, asked you to come up with your own timetables (even if this was your first and you had no point of reference to estimate) and thereafter resorted to "you need to figure it out” as the answer for all inquiries. It was basically working in a vacuum under him: you had no idea if you were on the right track or not. Others were worse. Then there was one engineer: crusty, pessimistic, blunt, often foul-mouthed, with a deserved reputation for not being the sort you brought to meetings where diplomacy was expected (in the event of any disagreement). I honestly didn’t trust him or like him in the beginning. I still have mixed feelings. Of all the managing engineers in this group at the time, he was the only one who could properly lead a project. He trained the junior engineers, assigned basic work to develop competency so you’d have it when he needed it. We all believed that he never asked anything he wouldn’t do himself. What he did was very thorough, with every attention to detail. And he gave actionable feedback. All you had to do was show up ready to work. And I did whenever I had the chance. When you were on his good side, he stuck up for you often (no one wanted to be on his bad side). One of those rare instances where I felt like I accomplished something there, and it was a good and welcome feeling. Before I could work on another project for him, he was transferred to another group. Terrible people skills yet he was a surprisingly solid manager. If given a choice, find the best leader (not necessarily the nicest one) and stick with him.

Not all CCIEs are created equal. To a young engineer, this is not always obvious, with a CCIE seen as your credentials to the big projects and money. My first rude awakening came when I had my CCNA and my company supported a small business. The client’s owner was not technical (that was our job). A CCIE for a DOD contractor next door sold him on migrating from his slow T1 WAN link at the main site to a wireless-bridge through to his building to use his company's much faster Metro-E link. I got a call one Thursday afternoon requesting all the passwords to the central site firewall. I responsibly asked why they were needed but the intermediary didn’t know. I can advise, but I won't refuse direct instructions from the customer. I would later spend the evening troubleshooting the sudden failure of their site-to-site VPN tunnels, only to discover that someone had wiped the entire configuration from their central firewall. I later found out the CCIE had asked my client if he had anything “special” on his firewall, to which my client naturally responded “no”. (How was he to know?) Not being versed in PIX configuration, he wiped the whole device (without examining it) and started from scratch. I worked the next morning rebuilding it and bringing up the tunnels. Once up, the owner relayed the CCIE’s assertion that I had now messed up his WAN configuration because the internet connection was bouncing periodically. Simple diagnostics revealed only packet drops, as the CCIE continued to pour on the blame for my incompetence. When I would make a change, it would disappear (the CCIE would undo it). Presently, I found myself locked out. I called my technical manager, he called the client and at the insistence of the client, I stopped all work. I got only one message from a weary owner later detailing that the wireless bridge passed through dense foliage, which caused the bounced link and would I kindly give him the new passwords so the CCIE could put everything back the way it was? Maybe he was a genius with a router, but not firewalls. Carelessness and arrogance, more him than the clueless client. A few CCIE’s I've met since seem to have that same self-assurance vastly out of proportion to their current skillset. They hang up their hat once they have that paper.

There are engineers I don’t understand. When there is a greater need there often seem to be a number of people who are better suited to fill it yet have no desire to do so. The only reason someone as unqualified as I got the work was that I was the only one willing to attempt it. So I became qualified.