Better or Worse Management

Better...

There is an admitted difference in style to successfully managing employees who do things you understand and who do things you don't. Nearly all of my managers have not understood much about what I do. This does not seem to have greatly impacted whether they were successful and whether I was as well.



When I came on board a federal contract we were in the middle of a datacenter move. I and another senior engineer were under the network manager, who was under the IT manager. He in turn reported to the president of our contracting company who had was filling in for the program manager. On the day of the move my colleague was at the new coop site directing the receiving of servers and racks and putting them in place when that same president showed up. My colleague told me the man rolled up his sleeves, looked him straight in the eye and asked what he needed him to do. Outstanding.

The same leader would often sit in management meetings with the engineers. If I or the other senior engineer discussed a problem, the president's invariable response was "what do you need?". We would tell him, he would deliver it, we would solve the problem. Streamlined solutions thanks to good management ensuring we had the resources and authority we needed.

I have had several poor managers, a number of mediocre ones, and only a handful of truly good ones. I measure them less how their employees feel about them (you can like a manager who is not very good at managing) and more what they accomplish and enable you to accomplish.

The best manager I had to-date was a very low-key fellow. I don't think I ever heard him raise his voice, beyond mild frustration. He was personable and likable. I was told he ran his team like a family, which is a warning sign to me of weakness. Leaders who don't take control of their team usually are taken advantage of. Instead I observed that while everyone really did seem comfortable with him, they still deferred to him and accomplished a lot. I've learned watching this exercise of "soft power". If I was late for work (and I often was given a difficult commute) I expected any day for him to take me aside to "explain company hours". He never did. If I was late for a meeting he called me a couple times to ask if I would make it and could I join by phone? A strong conviction settled on me that I really wanted to perform and earn this trust already given. My first (and only at this company) performance review was stellar, the best I have ever received. They weren't idle words: I had earned them. I still want to frame it some days. A good manager can make you want to work up to a higher level.

Another manager I had, one of my first, was solid if very hands-off. I rarely interacted with him or gave reports. He was not at all technical. He helped me present my budgets, approved purchase requests. By and large, I had enormous autonomy. I was trusted. It was a good feeling. I accomplished a lot there as well.

For hiring managers, if at all possible, if the new engineer seems motivated and capable, and the compensation requested is reasonable, set your first offer at a point above what you know he/she wants. This sends the message that the company believes he is valuable and wants him to know it. This has happened to me a number of times and consequently I started very eager to become indispensable. If you start low and the employee negotiates up this level, you lose all that benefit since the employee sees this price level as something he achieved.

To date, I have had one successful hire and two failures. By failures I don’t mean they were particularly bad people – I rather liked them. But they were not very productive. Here I bowed to the common sense of the larger group that this person was well known, well liked. Just not technical. And that is precisely what we got. No more, no less. Group dynamics are important, but you need fast, eager and ambitious learners as a minimum.

If feasible, stock your team with the right personalities and drive, fit and evolve the positions to them.

Practical hiring tests can work – at least at some levels. My first successful hire was to replace my position as I moved up. I had a number of questions to ask, but I decided to be clever and created a test of 9 questions (pick 2 from section A, 1 from sections B and C, etc.). A number of decent candidates took the test, did the required questions, and failed at least one question. Then this Middle Eastern fellow comes over, after his brother-in-law who worked nearby dropped off the resume personally. His English was passable and he was desperately insecure and nervous. He attempted every last question on the page and only got one wrong – and that only because I had mis-ordered it, where you should have solved a later question first to make this one sensible. He had my unreserved vote. I pushed for a quick hire. He needed a fair amount of training, but once he got going, he was pulling work off of my desk, as I had done with my predecessor, which suited me fine. He became my go-to guy, surpassing the other engineers. If I have the chance to hire him again at some point, he's on my short list. And I have a list.

At one position, I was assigned to help one of the older engineers on a low-priority part of my first project. He was one of the “old hands” of the group as I saw it. Working with him was the closest I got to any proper briefing, and I came to rely on him thereafter as my first stop for information. The younger engineers rarely were inclined to help nor did they explain with the same clarity or detail. Since then, I’ve come to notice a trend in my workplaces. The oldest engineers are the ones most inclined and able to pass on their knowledge while they are as often the least flashy or instantly impressive in their ability. They may make the most difference in getting the junior engineer up to speed, and they are the least likely to be sought out voluntarily. Management should arrange these pairings deliberately, rather than expect the engineers to muddle through. Many wont. Those that do will do so slowly.

Worse...

Similar to hazing, there is an unreasonable and very common belief that if I had do go through this slow and frustrating coming-up-to-speed-on-your-own process, then everyone else after me should expect the same. This is dumb, inefficient, and will strip ambitious, disciplined engineers of that critical drive to learn and produce.

At one position, I spent a lot of time essentially trying to find a way to fit in and understand how things are done. Much of this learning was self-directed. The first three months I was alone on a different floor, separated from my colleagues and rarely saw anyone. I could come in late, leave early, and unless I met my people as I walked to the building, I was sure no one cared. I was finally handed a requirement to produce documentation for configuring old devices to generate circuits to test migration away from those circuits. It felt very much like busy-work, low value occupation. With rare exceptions, and only in part, no one sat down to explain the environment, how things were done, what projects were on the radar and why they were relevant. I learned by slow observation and interpolation. I felt like a foreigner, on the outside, much of my first year. This is a cultural problem and sets the tone for how well the engineer is going to do, how engaged they will be with team, how valued they feel, and how quickly (or not) they will become productive and integral.

Once, with that lack of interest in anyone else to prepare and use this new engineer, one mid-career and seasoned engineer, gave me a single late-evening overview (I took notes). I think he pitied me because I was clearly lost. It helped a little in the coming years. He also handed me the “realistic” speech about how I  needed to set my expectations very low now that I've joined (he took pride in that he was proven right in my experiences). It was incredibly demoralizing as a new engineer. The same engineer later tasked me with deconstructing configurations written, for his project now concluding, for a particular service with which I was unfamiliar. I had no objectives or goal to immediately use this so what little I learned I forgot soon after. This was a voluntary effort by the one engineer. I can’t fault him. But this is a cultural problem for an engineering group. If you want an engineer to succeed, hire an ambitious learner, brief him/her well before any assigned work, provide lab exercises and objectives, and enable him as soon as possible to become part of the team.

When I worked for a consulting company focused on small to medium businesses, I noticed that most of the engineers disliked their respective team bosses. I also understood that most of the bosses had previously been engineers. As for my own boss, I got done with him the things that needed to be done, but he felt aloof. Always. Untouchable. Moved at his own pace, not a care in the world. The company promoted engineers to managers when a slot was available as a seniority reward or simple need to immediately fill the role. Many had been capable engineers or technicians. Machine skills, but no soft skills, no interest in their people, no ability to lead or inspire trust. When they interacted with clients, the unhappiness of the clients with them was passed onto the engineers who held the unenviable task of appeasing them. If they succeeded, the manager was in the clear. If they failed, the engineer took the blame. Unsurprisingly, customers and engineers were often unhappy. Engineering skill may earn you respect. Your people skills will earn you the trust and obedience you need to be effective. Many engineers make plain awful managers.