Strategy and Vision always get the limelight. Most junior technologists are always thinking about great ideas to solve challenging business problems. At the opposite, execution is seen as… well, just execution :-) Nobody likes to think themselves as an execution engine !
Innovation is extremely important. The mistake is to think that innovation is decoupled from execution.
They go hand-to-hand, you cannot have one without the other.
In many cases, an apparently innovative idea does not account for all the real-world constraints. You may wonder at first why people are doing it this way or that way, but then when you dig into the details you realize how hard the problem is. It’s really unfortunate to fall into that pitfall: people who really know their stuff will hear you all day speaking non-sense. You will be perceived as somebody superficial. And once you finally understand what it’s about – well, that’s often too late: your bad reputation has been built already ! Being involved in daily execution is the way to understand things deeply. You have more context to judge by yourself is your solution is right and how to fix it. Things go faster.
You may realize also that you are not solving the right problem. That's the story of the guy frustrated about something and nobody want to listen to him. Again, being involved in execution will give you a sense of what the pain points are not only for you but for the organization as a whole. A great technologist knows how to shift his focus and not stick.
If you are an architect, go back to the keyboard every once in a while to understand the pain that programmers are going through. If you work on infrastructure, always be your own consumer. Think about testing, monitoring, recovery – all their things maybe not very sexy but nonetheless necessary. The Devil, and the really interesting stuff that will challenge your mind, is often in the details. Try to value all aspects of a problem and not only where your comfort zone is.
The second thing is that innovation means risk. If you truly believe in something, you need to take responsibility and drive it to completion. If you don’t master the execution side, it’s much more likely that your innovated idea will stay on the “PowerPoint platform” and not make it into real code ! People will listen to your new ideas and will say it’s great, but making them take the risk for you is very very hard.
Further: do you really want to take the risk that somebody else spoils your great idea ? It may not get a second chance after that.
Managers value passion, because it is stronger than any degree, methodology or automation tool. It’s why, two ideas being equal, it’s likely that the one whom the supporter can also execute will be elected. If you look back, I am sure you will find examples where you had a great idea, people seem enthusiastic about it but ultimately it lead to nowhere. Now, try to think of what would have happened if you could execute on it. It’s how start-ups get their funding: VC look at the business plan, but the entrepreneur is often even more important.
In some cases, you may be lucky and find people to execute for you. Again, look back and ask yourself how well did it go ? Did you ever blame people for not implementing correctly your vision? Or implementing the wrong thing ? If you are closely involved in execution, you can address both problems. On one side, you’ll spend more time with people and have opportunities to mentor them; the more disruptive your idea is, the more you need to socialize it. As you learn about the difficulties found during implementation, you may find interesting things your overlooked in the first place and improve the vision. New ideas are often a prototype, like a gem in the rough.
There is a common pattern among junior technologists. Their heart is in innovation, and are too negligent about execution. They are thus not very reliable, and slowly put on the sideline. Not that people want to be mean with them, but it’s just the path of least resistance: managers will choose the person they think they can rely on the most, having the right projects those persons get better over time. Then get chosen for more and more complex and challenging projects and end-up making the strategic choices. An innovative guy, without the execution skills, is automatically sidelining himself.
How to break that cycle? Simple: you need to build you way up. Start by basic stuff, take a concrete problem and show that you can solve it well. Learn from that, build trust, and tackle more and more challenging things. As much as your involvement in execution is important, you need also to manage it. Too many teams are burnt-out by execution, and not enough planning. Not enough planning, means more firefighting... and no time for planning !
Get ahead of the curve. The Great Innovator knows how to keep a fine balance between digging into the details from time to time, and leave time for thinking and rallying people to his vision.
Wednesday, August 13, 2008
Thursday, August 7, 2008
Of the Importance of Stretching to Become a Great Technologist
At work, you probably have met two types of people: those you work with, and those you deal with. People you deal with are people you need to work with – but it’s really a pain. It’s like a needle in the foot. They never seem to be doing the right thing, you keep repeating them ten times the same thing and you never agree with them.
Then you’re not happy when you come at work just thinking you’ll have to deal with them. You have arguments with them, and your stupid manager just blame you for one bad sentence you said although you worked each and every night of last week.
So unfair.
So what to do ? Well, in most cases you are the one to blame - not them. I’m not saying they’re right and you are wrong, I’m saying you cannot do everything on your own and a great technologist need to put people on his side then leverage the best fromthem. It’s not about politics or kissing ass, it’s about applying your engineering skills to social interactions to make the world a better place through technology.
Here is the most important thing: you need to find pride in doing that.
Don’t think it is just boring stuff and solving technical problems is more sexy. It’s actually pretty cool: a system is a system, does not matter – to some extent – if you are dealing with java classes, pools of servers or team of people. It’s all about understanding what are the goals, the constraints and find an solution. If you’re good at fixing bugs, there is no reason you cannot become good at fixing social interactions. There is a huge amount of value there (see my other post about working as a team).
Most people fail about inspiring others because they focus on the wrong goal. They think they have to prove their proposed technical solution is right, and once others are convinced they will be forever grateful that you have shared your great wisdom with them. It works sometimes, when you are really an expert and they are novice. Both need to admit it too: the type of relationship between - let’s say – a trainee and his tutor at a photographic workshop. But more often then not, following this “share my wisdom” approach turns into an argument. You may think it is a healthy fight. First, let me tell you your manager – this guy who promotes you and gives you more responsibilities - will never think so because he has no idea of what you are talking about and he just sees two kids yelling at each others instead of doing productive work. Second, are you really sure the other party thinks that is an healthy fight too ?
If you are not sure and have more pleasure helping people than beating them up, change your perspective and stop thinking in terms of winning or loosing. Think about moving the person closer to the right solution. The great Budha said: "You cannot guide people, just show directions".
You may not succeed that particular time – but don’t worry: there will be other opportunities in the future to mentor people on coding guidelines or availability principles. It is like stretching: nobody can do a lateral split the first time. You need to be realistic about where people are starting and how far they can go. You want to go every day a little bit lower, in small incremental steps.
If something is wrong while you stretch, pain will tell you immediately and warn you before you get injured. Signals are more subtle in people interaction, you need to actively look for them. For instance if the person keeps interrupting you, he’s probably not very receptive to the quality of the argumentation you may deliver: just let him speak, and wait for another opportunity to answer. Can be a few minutes later, or another day. If they take it personally, switch to different topic: for instance speak about mistakes you made in the past, and just ask them if they think that experience would apply to their case. If people don’t ask questions and you keep talking, they are probably not very interested in what your are saying; focus on delivering your key message instead of going into the details.
Doing that monitoring, and keeping the feedback loop opened as you deliver your technical argumentation is hard: it’s like eating with your left hand while playing ping-pong (sorry: tennis table) with your right hand. Before that becomes a second nature, it’s a good idea to take notes immediately after the meeting while things are still fresh in your mind. Using a voice recorder works too! Another great idea is to monitor interactions between other people; for instance if you see this great guy who is so good at convincing people, analyze his strategy (don’t feel bad – he probably stole from somebody else himself too !!).
In some cases, you will not be able to convince somebody on a critical issue. It’s really important not to let it go, this type of behavior would create completely dysfunctioning organizations where people spend more energy trying to look good than solving business problems.
Again, think about stretching: you need to push the person as far as you can, but don’t enter the red zone. If you feel that you are not going to win, don’t continue down the same path. Switch from a mode where you try to convince to a mode where you just listen and collect information. Don’t be the only one to take the heat, try to involve more people. The Chineses call it “always leave a door opened”.
You’ll need to drive to the end, don’t take people’s time and drop the ball on it. So before you do that, make sure to choose carefully your battles: focus is as much about deciding what to do than what not to do. If that does not make it to your short list, just speak informally to whoever you feel is concerned. They may not decide to work actively on your problem that time, but at least they’ll know about it. If they hear about it a few more times, then it may make it to their own short list one day.
If this problem really bothers you and nobody seem to pay attention to it, take that as an opportunity: maybe you are the only one passionate enough about solving it, and you may get great reward in doing so.
Then you’re not happy when you come at work just thinking you’ll have to deal with them. You have arguments with them, and your stupid manager just blame you for one bad sentence you said although you worked each and every night of last week.
So unfair.
So what to do ? Well, in most cases you are the one to blame - not them. I’m not saying they’re right and you are wrong, I’m saying you cannot do everything on your own and a great technologist need to put people on his side then leverage the best fromthem. It’s not about politics or kissing ass, it’s about applying your engineering skills to social interactions to make the world a better place through technology.
Here is the most important thing: you need to find pride in doing that.
Don’t think it is just boring stuff and solving technical problems is more sexy. It’s actually pretty cool: a system is a system, does not matter – to some extent – if you are dealing with java classes, pools of servers or team of people. It’s all about understanding what are the goals, the constraints and find an solution. If you’re good at fixing bugs, there is no reason you cannot become good at fixing social interactions. There is a huge amount of value there (see my other post about working as a team).
Most people fail about inspiring others because they focus on the wrong goal. They think they have to prove their proposed technical solution is right, and once others are convinced they will be forever grateful that you have shared your great wisdom with them. It works sometimes, when you are really an expert and they are novice. Both need to admit it too: the type of relationship between - let’s say – a trainee and his tutor at a photographic workshop. But more often then not, following this “share my wisdom” approach turns into an argument. You may think it is a healthy fight. First, let me tell you your manager – this guy who promotes you and gives you more responsibilities - will never think so because he has no idea of what you are talking about and he just sees two kids yelling at each others instead of doing productive work. Second, are you really sure the other party thinks that is an healthy fight too ?
If you are not sure and have more pleasure helping people than beating them up, change your perspective and stop thinking in terms of winning or loosing. Think about moving the person closer to the right solution. The great Budha said: "You cannot guide people, just show directions".
You may not succeed that particular time – but don’t worry: there will be other opportunities in the future to mentor people on coding guidelines or availability principles. It is like stretching: nobody can do a lateral split the first time. You need to be realistic about where people are starting and how far they can go. You want to go every day a little bit lower, in small incremental steps.
If something is wrong while you stretch, pain will tell you immediately and warn you before you get injured. Signals are more subtle in people interaction, you need to actively look for them. For instance if the person keeps interrupting you, he’s probably not very receptive to the quality of the argumentation you may deliver: just let him speak, and wait for another opportunity to answer. Can be a few minutes later, or another day. If they take it personally, switch to different topic: for instance speak about mistakes you made in the past, and just ask them if they think that experience would apply to their case. If people don’t ask questions and you keep talking, they are probably not very interested in what your are saying; focus on delivering your key message instead of going into the details.
Doing that monitoring, and keeping the feedback loop opened as you deliver your technical argumentation is hard: it’s like eating with your left hand while playing ping-pong (sorry: tennis table) with your right hand. Before that becomes a second nature, it’s a good idea to take notes immediately after the meeting while things are still fresh in your mind. Using a voice recorder works too! Another great idea is to monitor interactions between other people; for instance if you see this great guy who is so good at convincing people, analyze his strategy (don’t feel bad – he probably stole from somebody else himself too !!).
In some cases, you will not be able to convince somebody on a critical issue. It’s really important not to let it go, this type of behavior would create completely dysfunctioning organizations where people spend more energy trying to look good than solving business problems.
Again, think about stretching: you need to push the person as far as you can, but don’t enter the red zone. If you feel that you are not going to win, don’t continue down the same path. Switch from a mode where you try to convince to a mode where you just listen and collect information. Don’t be the only one to take the heat, try to involve more people. The Chineses call it “always leave a door opened”.
You’ll need to drive to the end, don’t take people’s time and drop the ball on it. So before you do that, make sure to choose carefully your battles: focus is as much about deciding what to do than what not to do. If that does not make it to your short list, just speak informally to whoever you feel is concerned. They may not decide to work actively on your problem that time, but at least they’ll know about it. If they hear about it a few more times, then it may make it to their own short list one day.
If this problem really bothers you and nobody seem to pay attention to it, take that as an opportunity: maybe you are the only one passionate enough about solving it, and you may get great reward in doing so.
Wednesday, August 6, 2008
Of The Importance Of People Skills To Be a Great Technologist
Good engineers have high expectations for themselves, but also for others. They are passionate, and want everything perfect. In many cases, that make them a bit arrogant and not easy to work with. Eric Schimdt from Google calls that "techno arrogance":
http://www.msnbc.msn.com/id/10296177/site/newsweek/print/1/displaymode/1098/
The unfortunate impact is that, although they have a good potential thanks to their technical skills, they may not be the most successful over the years – falling again and again into the same trap: “I am just working with a bunch of idiots, let me see if the grass is greener elsewhere”. So all the good guys leave, less technical people are getting promoted and companies become dumber and dumber. We don't want that to happen, fight back !
Without any doubt, great technical skills are a must have.
A single bad engineer can ruin an entire development team. However if you bet everything on the technical stuff, you will be useful only for firefighting and emergency calls. Although your manager will love you to clean up the mess, a successful development organization should not spend all its time working on firefighting. Probably 10% of the work will be relevant, the rest is about developing projects. That means you will be useful for 10% of the time, provide ultimately little value to the company, and consequently not successful in your career. However, let me precise there is a market for that – exceptional people at doing firefighting can find a job. Problem is, most people don’t like doing that but do not have the people skills to do anything else.
The technical skills need to go hand-to-hand with the ability to work as a team. Great technical skills do not compensate for poor communication, at the opposite they require even better people skills to reach their full potential.
Why’s that ? Because for the simplest problems, you can just go and solve it on your own. But the really difficult problems are hard to understand, and not formalized yet. You need to take the perspective of multiple persons, abstract them out and create an elegant conceptual model. Too often technical people are so passionate about the technical stuff that they jump on it. Just like a runner who does not take the time to read the map first. Because they don’t like talking to “simple” people – afterall if these people were smart they could solve the problem by themselves – they focus on the wrong problem to solve.
The other thing which is nice with simple people, is that they require simple solutions. Ever heard about EJBs ? It almost died because it has been designed by too smart guys. The result was an overly complex platform that could barely be used by common mortals. Speaking to non-specialists gives you a “fresh view”. Makes you adopt simpler solutions, easier to maintain and change. I have been architect at eBay for 3 years. You make think you need to be an expert for that ? Well, not really. My main skill was to be able to make people speak and most of the time the solution was coming from them, I was asking the right questions but individual developers who has been dreaming about their code for weeks often know -sometimes uncounsciously - the solution inside them.
Finally, one should realize that hard problems often requires a lot of manpower to execute. A lot for me means more than 1, when one single person cannot do everything on their own. You thus need to convince others that your solution is right, and make them willing to implement it. Even if you try to force it down their throat (you can probably do that a few times before they get you fired, or - even worse - that you stay but they leave to the competitor), they need to have all the context to make the call as decisions need to be made. Ever happen to you that your great vision was not implemented correctly ? Well, you can only blame it on yourself: you did not empower people to do the right thing.
You may not be convinced by all of that. But your manager certainly is ! Believe me, they're awful (I know it bc I am one myself). If you are looking for more responsibilities, want to drive more innovative projects you need to be trusted. For most managers it is easier to evaluate somebody on his/her people skills than go deep into their technical expertise – for instance because they don’t understand anything about the technical stuff. So “looking good” is an easy way to reach your end goal. Come-on, admit you also to the dentist to get your teethes whiten? ;)
In summary, if you want to be a great technologist you have all the reasons of the world to develop your people skills along your technical expertise.
http://www.msnbc.msn.com/id/10296177/site/newsweek/print/1/displaymode/1098/
The unfortunate impact is that, although they have a good potential thanks to their technical skills, they may not be the most successful over the years – falling again and again into the same trap: “I am just working with a bunch of idiots, let me see if the grass is greener elsewhere”. So all the good guys leave, less technical people are getting promoted and companies become dumber and dumber. We don't want that to happen, fight back !
Without any doubt, great technical skills are a must have.
A single bad engineer can ruin an entire development team. However if you bet everything on the technical stuff, you will be useful only for firefighting and emergency calls. Although your manager will love you to clean up the mess, a successful development organization should not spend all its time working on firefighting. Probably 10% of the work will be relevant, the rest is about developing projects. That means you will be useful for 10% of the time, provide ultimately little value to the company, and consequently not successful in your career. However, let me precise there is a market for that – exceptional people at doing firefighting can find a job. Problem is, most people don’t like doing that but do not have the people skills to do anything else.
The technical skills need to go hand-to-hand with the ability to work as a team. Great technical skills do not compensate for poor communication, at the opposite they require even better people skills to reach their full potential.
Why’s that ? Because for the simplest problems, you can just go and solve it on your own. But the really difficult problems are hard to understand, and not formalized yet. You need to take the perspective of multiple persons, abstract them out and create an elegant conceptual model. Too often technical people are so passionate about the technical stuff that they jump on it. Just like a runner who does not take the time to read the map first. Because they don’t like talking to “simple” people – afterall if these people were smart they could solve the problem by themselves – they focus on the wrong problem to solve.
The other thing which is nice with simple people, is that they require simple solutions. Ever heard about EJBs ? It almost died because it has been designed by too smart guys. The result was an overly complex platform that could barely be used by common mortals. Speaking to non-specialists gives you a “fresh view”. Makes you adopt simpler solutions, easier to maintain and change. I have been architect at eBay for 3 years. You make think you need to be an expert for that ? Well, not really. My main skill was to be able to make people speak and most of the time the solution was coming from them, I was asking the right questions but individual developers who has been dreaming about their code for weeks often know -sometimes uncounsciously - the solution inside them.
Finally, one should realize that hard problems often requires a lot of manpower to execute. A lot for me means more than 1, when one single person cannot do everything on their own. You thus need to convince others that your solution is right, and make them willing to implement it. Even if you try to force it down their throat (you can probably do that a few times before they get you fired, or - even worse - that you stay but they leave to the competitor), they need to have all the context to make the call as decisions need to be made. Ever happen to you that your great vision was not implemented correctly ? Well, you can only blame it on yourself: you did not empower people to do the right thing.
You may not be convinced by all of that. But your manager certainly is ! Believe me, they're awful (I know it bc I am one myself). If you are looking for more responsibilities, want to drive more innovative projects you need to be trusted. For most managers it is easier to evaluate somebody on his/her people skills than go deep into their technical expertise – for instance because they don’t understand anything about the technical stuff. So “looking good” is an easy way to reach your end goal. Come-on, admit you also to the dentist to get your teethes whiten? ;)
In summary, if you want to be a great technologist you have all the reasons of the world to develop your people skills along your technical expertise.
Subscribe to:
Posts (Atom)