#67-7/28/08: How Technical Should A Manager Be?
How Technical Should A Manager Be?
Should a technical manager be a technical expert?
Posted by Steven Cerri on Monday, July 28, 2008
Hello everyone!
There seems to be an on-going debate about how technical an engineering manager ought to be.
Some say that any manager worth his or her weight in salt has to understand the technology they’re managing well enough to actually have answers and be capable of doing some of the work themselves.
Others say that any manager worth his or her weight in salt doesn’t have to understand the technology. They just have to know how to “facilitate” the technologists who are the experts in the technology.
So who’s right? What’s the answer?
And the answer is: Neither is right? Or to put it another way: Both are wrong!
An example of the first answer is Bill Gates. It’s pretty clear that Bill Gates was up on most of the technology in Microsoft. By all accounts he was capable of doing a good deal of the technical work performed by the technologists in the company. Obviously he couldn’t because there was only one of him, but he was capable.
Because Microsoft was so successful, many come to the erroneous conclusion that Microsoft was successful because Bill Gates was at the helm. They conclude that because Microsoft was so successful and Bill was such a technologist, there must be a causal relationship here.
Not so. Bill only had this influence when Microsoft was small. The reason Microsoft became a powerhouse and was so successful was because it had a monopoly, not because Bill was a geek. The CEO of Microsoft would have had to have been a rock to drive Microsoft into the ground, at least up until recently when it finally got some competition. So Bill Gates is not a valid nor good example of how technical a manager has to be in order to be successful. The causal relationship in the success of Microsoft is not with Bill Gates but with it’s lack of competition.
If you want to read in interesting article that erroneously supports the idea that the technical Bill Gates made Microsoft successful, then read the article titled “How Hard Could It Be? Glory Days”, by Joel Spolsky. The article appears in Inc. Magazine, dated July 1, 2008.
In it, Joel talks about when he was a young Program Manager at Microsoft and had to give a presentation to Bill Gates. Joel wrote a specification and had to run the specification by Bill Gates. Joel talks glowingly about how Bill actually read his spec and how this was a testament to Bill’s technical prowess. Joel’s bottom line conclusion by the end of the article is that a good technical manager must be technically savvy. The more technically savvy the better. And as far as Joel is concerned, the Bill Gates he presented to was extremely technically savvy and therefore Bill represented the epitome of good management.
And of course, this myth persists still. People still believe that Microsoft was successful because Bill, the ultimate CEO-geek, was at the helm.
I don’t think so. This is not management. This is self-aggrandizement.
At the opposite extreme are those managers who don’t know anything about technology and therefore manage to drive their teams in the wrong direction. This usually happens when managers attempt to make decisions when they don’t have the minimal technical knowledge to make intelligent decisions.
I know plenty of managers who think that because they know management they can manage any technical team. Their position is that because they can manage, they think they can take any number of highly technical people, in any technology, and turn them into a successful, high performance team. Their fond of saying, “I don’t need to be the technical expert. I know how to manage technology and therefore I can manage any technical team. These are the managers who say that their role is to “facilitate” the team. They don’t need to know the technology because they are really only “facilitators”.
I don’t think so. This is not management. This is self-deception.
So what is the right answer? How technical should a manager of technical people be?
The answer, Einstein famously said, is, “Just enough but no more”.
Actually, when Einstein was asked how simple things should be made, he responded, “Everything should be made as simple as possible, but not one bit simpler.”
The same applies here. How technical should a technical manager be, “as technical as necessary, but not one bit more”.
So exactly how technical is “as technical as necessary?”
Technology is changing rapidly. In fact, so rapidly that few people can keep up with it for more than a decade. In fact, keeping up with technological advances for several decades is very difficult. The kids coming out of college have the latest knowledge and it’s only good for 5 to 10 years at the most, unless it basic technical and engineering knowledge they’ve been trained in.
So the technical managers’ job is not to have the latest technical knowledge. It’s not to know how to do the work that his or her direct reports are doing.
Here is the way I look at it. When I’m managing a team, my goal is to give my direct reports as much independent latitude as possible and no more. That means that each person is treated differently and each person gets a certain amount of independence, depending upon their expertise, and the situation. My goal it to keep them from failing. Put positively, my goal is to help them to be successful.
The metaphor I use is that my job is to keep them from “falling off the cliff” and yet, I want them to get close to the cliff. Getting close to the cliff means that they are pushing the boundaries of their own capabilities. It means that they are learning. But I don’t want them to fall off the cliff and fail.
Therefore, my job is to know “where the edge of the cliff is.” My job is to know when my direct reports are heading for disaster. That’s as technically savvy as I need to be. My job is to know when my direct reports are making technically sound decisions, but operationally poor ones. That means they and we are all close to falling off the edge of the cliff.
That doesn’t require that I have 100% technical knowledge. It requires that I have a combination of technical knowledge, interpersonal communication skills, and an ability to integrate facts as well as unrealized potentials. It means that I have to be able to integrate the known and the unknown in a model that can be projected into the future.
Instead of looking for managers that are technically savvy or for managers who can facilitate, we ought to be looking for managers who can integrate what they know about the technology and what they know about their team and what they know about the environment and be able to use their frontal lobes (where decisions are projected into the future) in a way that they can make sound decisions.
If you want to really understand how this is done just compare and contrast Bill Gates and Steve Jobs. Bill Gates is smart but he doesn’t project unknowns into the future well. Just notice how Microsoft delayed entry into the Internet because Bill was so technically savvy he was sure he knew what was up. In fact, a great majority of the success Microsoft has experienced has been the result of its monopoly.
Now look at Steve Jobs. Apple, with it’s small market share, has been projecting far in advance of the current state. And all with a CEO who is not a geek. Go figure!
The primary requirement for managers is not to be able to “do”, but to be able to “see’.
The technical manager must constantly ask himself or herself, “what do I need to know and understand in order to point my technical experts into the future I see?”
Ask and answer that question consistently and often and you will be just technical enough.
Be well,
Steven Cerri
“What would it be like to be as successful with people as you are with your technology?” Steven trains, coaches, and facilitates engineers and technical managers to BE the answer to that question. More information can be found at the:http://stevencerri.com/index.php/Home/index/
Copyright©2008 STCerri International and Steven Cerri. You are free to pass this information on to others and to reproduce it. If you reproduce it in whole or part please give attribution to Steven Cerri. Thank you.
Posted by Steven Cerri on 07/28 at 06:41 PM (0) Comments • (0) Trackbacks • Permalink
#66-7/21/08: On The Shoulders Of Giants!
On The Shoulders Of Giants!
Can you think your way through management?
Posted by Steven Cerri on Monday, July 21, 2008
Hello everyone!
How does science progress? On the shoulders of giants, so the saying goes.
Those of you who have taken my classes have heard me say that for the typical engineer, management is a new career. That’s my saying.
You’ve also heard that science progresses on the shoulders of the giants who have come before us. All knowledge builds on the foundations of the past. Algebra is the foundation for the calculus which is the foundation for differential equations. We must understand one level before we can understand the next. And so it goes… until things get stuck.
Yes, stuck. In fact, science doesn’t move in nice progressive steps up the ladder of knowledge. Nor does it move in chaotic fashion. Science advances in logical, incremental steps with each level using the previous level as foundation, until progress can no longer be made. And then, a completely new way of looking at the world must often emerge. If science continues to rest on the known knowledge as it’s foundation for the next step, it will ultimately fail to model the world.
Therefore, for progress to ultimately be made, science must embrace that which has never been seen before. It must embrace a totally new way of understanding the world and it must abandon, to varying degrees, that which came before.
This has happened and is happening with relativity, as one example. Einstein developed the general and special theories of relativity. That worked well enough until it didn’t. Then we got quantum mechanics and the uncertainty principle. Those theories worked well enough until they didn’t and now we are seemingly moving toward string theory as one possible alternative.
So what does this have to do with engineering, engineers, and management. Well, it’s exactly the same process. As an engineer you think you can “think” your way through management just as you “think” your way through technical challenges. But the process of management is as different from engineering as quantum mechanics is from relativity. And whatever theories, rules, processes, and strategies you use to solve the engineering issues, I can guarantee you they will not work in the arena of management.
In fact, engineering is as certain as relativity at predicting the future. Management is as uncertain as the Heisenberg uncertainty principle at predicting the future.
The question is, which way of being in the world can you live with?
Be well,
Steven Cerri
“What would it be like to be as successful with people as you are with your technology?” Steven trains, coaches, and facilitates engineers and technical managers to BE the answer to that question. More information can be found at the:http://stevencerri.com/index.php/Home/index/
Copyright©2008 STCerri International and Steven Cerri. You are free to pass this information on to others and to reproduce it. If you reproduce it in whole or part please give attribution to Steven Cerri. Thank you.
Posted by Steven Cerri on 07/21 at 09:34 PM (0) Comments • (0) Trackbacks • Permalink
#65-7/14/08: Managing Projects Half A World Away
How To Manage Projects Half-A-World Away
Can I make a contractor part of my team?
Posted by Steven Cerri on Monday, July 14, 2008
Hello everyone!
I have a coaching client who has a big challenge. He is attempting the development of a website by hiring contract website development from overseas independent contractors and companies. He is finding programmers who are technically competent. In some cases very technically competent.
He uses instant messaging (IM) and emails and in some cases phone calls to communicate with his contractors. In most cases these are one-person shops. In one case it’s a small contracting company that has perhaps 100 independent contractors available to it.
However, he is having a difficult time “managing” them. They don’t return his emails in a timely fashion. Sometimes they’ll disappear for a week without a trace. When they finally show up again on the email radar screen they’ve finished their task and it’s well done, but my client is frazzled because he was out of contact for a week and didn’t know if the project was being worked on, or if the contractor was dead, or drunk, or on vacation, or.....
So my client contacted me and said, “What do I do?” “How do I manage these people?” “They’re driving me nuts.”
I asked my client what he wanted… and it boiled down to the following items:
1. He wanted the contractors to return his phone calls, IMs, and emails in a timely fashion.
2. He wanted the contractors to behave as if they were part of his team. He wanted them to be invested int he success of the project not just behave as “hired guns”.
3. He wanted to feel comfortable by having the contractors keep him informed as to what was going on regarding their part of the project.
My gut response to these requests is the same as Matchbox 20’s Rob Thomas sings in Santana’s song, Smooth; “Forget about it.”
Well, not quite. There is a solution.
Let me pose the question succinctly: “What is the best way to manage contractors who are located overseas and are doing programming work for you or your company?”
There are several steps that must be taken simultaneously, as follows:
Expectations: Lets get really clear about expectations. My colleague wants his overseas contractors to be part of his American team. In 90% of the cases that isn’t going to happen. Separated by thousands of miles, oceans, continents, languages, cultures, values, and beliefs, the expectation that your contractor will be committed to your project as much as you are or as much as your American employees are just isn’t going to happen. So don’t expect it. Expect that it’s going to be a job for your contractors and nothing more and prepare accordingly.
Genius or Hard Worker Here is the big one: Would you rather have a brilliant genius working for you overseas who you can’t control, does really brilliant work but causes you grief because you can’t track him or her down… or would you rather have someone who does work a little slower, is not quite so brilliant but gets the job done and is willing to keep you in the loop?
My coaching client has, up until now, opted for the genius who can get things done quickly but can’t be found to hand it over until my client has pulled out his hair. Unless I absolutely have to have the genius, I’ll always opt for the less brilliant but more cooperative team player. Remember, we hire people for their expertise and fire them for lack of fit.
Project Management Next, make sure that your projects are very well “contained”. By that I mean don’t make the projects too big. Make them small enough that you can control the design and functionality.
Who Does What?Next, you, the hiring entity, must decide on the functional requirements of the software. You must decide on what you want. The contractor/programmer decides on the implementation but you decide on the requirements.
My client has been giving himself a huge amount of grief because he has not been defining the functional requirements of the software well enough before giving the project to his contractors. He has been leaving it up to the contract programmer to decide not only the implementation but also some of the requirements and the design. This has left my client out in the cold. The best approach is to clearly, with structure, forms, documents, and change processes, lay out the requirements of the software. One can even go so far as to develop dummy screen shots of how the website is supposed to look. Where are the buttons to be placed? What text should be included and where do you want it placed? How are the users to move around the pages? How are the pages to “respond” to the user’s requests.
It’s the job of the hiring firm to design to a very specific level of detail what the website is to look like and what it is to do. For sure there can be adjustments as the design gets implemented, but the hand-off from the hiring firm to the programmer should be very detailed, very clear, and very structured. The only thing the programmer should do is make the requirements “happen”. My client should design and decide, and the programmer should implement and provide feedback. Obviously there can be some “give and take” here but not nearly as much as if the programmer is located down the hall from the manager.
My client has been managing his overseas contractors too loosely. He has been managing them as if they are part of his team. They are not. They don’t want to be and he should not expect them to be.
That means that he must go through the following steps:
1. Establish a clear visual representation of what the web page(s) and system are to look like.
2. Establish a written document that explains how the various functions and operations in the web page(s) are to perform their functions.
3. Provide clear milestones with timetables, and feedback events (i.e., meetings, documents, emails, phone calls, etc.) Work this out in conjunction the the contractor BEFORE work begins.
4. Establish incentive payments along the way so that when deliverables AND communications take place as planned, payment is made; otherwise there is some appropriate penalty. Don’t make the penalty punitive of you may not get anything back.
5. Select programmers and contractors who will work with you the way you want. Find those who can do the work you want done and do it the way you want it done. Don’t sacrifice the process by assuming that it will all “come out in the wash”.
6. Finally, when you find contractors who you work well with, ask them if they know of other contractors who they would recommend. Remember the old adage, “Birds of a feather flock together.”
When people are separated by thousands of miles, different languages, different cultures, significantly different values and beliefs, it is imperative not to make assumptions that they will work the way you work. It’s challenging enough to find that in your own company office building, why would you expect it with someone halfway around the world from a completely different country.
Remember: “Keep your local direct reports close. Keep your overseas contractors even closer.”
Be well,
Steven Cerri
“What would it be like to be as successful with people as you are with your technology?” Steven trains, coaches, and facilitates engineers and technical managers to BE the answer to that question. More information can be found at the:http://stevencerri.com/index.php/Home/index/
Copyright©2008 STCerri International and Steven Cerri. You are free to pass this information on to others and to reproduce it. If you reproduce it in whole or part please give attribution to Steven Cerri. Thank you.
Posted by Steven Cerri on 07/14 at 09:52 PM (0) Comments • (0) Trackbacks • Permalink
