Tag: Management

Delegating vs MicroManaging

Just read a great post by Steven Sinovsky in his “Learning by Shipping” blog, which he started, just after he left MS. This is one of his few rare concise posts. He has a ton of experience and fantastic in-depth into software management, but some of his posts just run too long. I liked this one.

The problem is clearly stated in the words of a first year MBA student:

High-performing people generally want autonomy to get things done without anyone micromanaging them.  At the same time, as a midlevel manager, I’ve often had someone above me who’s holding me accountable for whatever my direct reports are working on.

I’m struggling to find the right balance between giving people their autonomy while also asking sufficient questions to get the detail I need in order to feel comfortable with how things are going. 

And Steve provides 5 tips to find the right balance between delegating vs micro-managing.

  1. Delegate the problem, don’t solve it.
  2. Share experiences, don’t instruct.
  3. Listen to progress, don’t review it.
  4. Provide feedback, don’t course correct.
  5. Communicate serendipitously, don’t impede progress.

I mostly agree with all of them. My favourites (which I try and practice as much as possible) are (2) and (5). I am a big believer in Management by Walking Around (for middle managers atleast). It is so much more productive for the manager and the team.

Maybe sometime later, I will write up something myself on what I feel one can do to find the middle ground. But for now, you can read the full article here.

Too Many Hops

Quite recently, I had been talking to a friend of mine, who was vying for a senior leadership position. After a couple of conversations with the recruiter, he was told he had taken too many hops, and hence the company was not considering him. I was thinking about this for a bit, and I thought I would share my thoughts.

I personally feel that, ‘rejecting’ based on this reason as the only reason seems pretty foolish and hasty. The least that one should do is to find out the reason for the hops, and how the hops happened.

Insecurity? Were the hops because of the candidate not feeling confident that he could do the job assigned to him? This might be a valid reason for rejecting, but then, we should also dig in into finding out how the fellow landed up that job in the first place. In the numerous interviews that I have taken, I have found that, one can easily figure this out, using some behavioural traits.

Performance. Were the hops because the candidate did not perform well? Did the interest levels dip soon after the candidate was hired? Again, think. Why was this not caught during the interview process? Again, performance measurement is subjective. It could be your perspective that he may have gotten the boot because of bad performance. But, this is a valid case of rejecting a candidate.

Burnt bridges. How did the candidate leave the previous companies? Were they amicable? Were they jumps with the management in full support? Were the jumps such that management tried ‘everything’ to retain him? Did he burn bridges? If the candidate had had personnel (not personal) issues because of which, he burnt bridges (fought with manager/team etc), then this is definitely something that should discourage you from hiring this person.

The fire brand. Is the candidate someone who has the fire burning in him to grow fast? Did he find that he has been increasing his net intellectual/management experience worth significantly by jumping from gig-to-gig once in a few years? If the candidate is someone like this, you can be sure that he would not have left the previous gigs in bad taste. He would have alternate plans, succession strategies, etc, that when he leaves, it does not leave a void. It is not necessarily a bad thing to hire this guy. Except, one should hire him recognizing that he is a fire brand, and craves growth. For a senior management position, this craving is a good thing. Stoked correctly, this fire brand can create miracles for a company.

To end, my opinion is that, too many recruiters make this mistake of judging a candidate by too-many-hops. Yes, I agree, there are some folks who have had too-many-hops because of ‘issues’, but you cannot generalize. In this current generation of companies, there are two kinds of people who race to the top – both the turtles and the hares. The turtles are the folks who have risen in the company (it took them 15 years in the same company to become the senior manager/director). The hares are the folks who gain experience and expertise in working through a variety of positions (these are the folks who have risen to a senior manager/director in 7-8 years). Think for a moment, and you can easily recall folks in both categories.

Can you beat Apple?

Jason Kottke has  a very compelling article on the few weaknesses of Apple. Very good observations I should say. On hind-sight, and on reading this list, they do seem like missing link. I list a summary below:

1. Apple doesn’t do social well on a large scale

2. Apple can’t do the cloud either

3. iTunes is getting long in the tooth.

4. The Apple software that rock (eg KeyNote) are the ones that Jobs uses. The ones that he does not care about (social, ical) etc are the ones that are not so good.

Read the full article here.

20 questions I ask myself – Vineet Nayar

Fantastic slide set from Vineet Nayar (CEO at HCL) – 20 questions he asks himself everyday. Two things I liked about this slide set:

  • The questions themselves (content is key, anyday).
  • The simplicity of the presentation. Hard hitting points yet on a plain spartan template.
Twenty Questions I ask Myselfhttp://static.slidesharecdn.com/swf/ssplayer2.swf?doc=twentyquestionsiaskmyself-100527032107-phpapp02&stripped_title=twenty-questions-i-ask-myself

View more presentations from Vineet Nayar.

Be a better engineering manager

For the sake of this article, I refer to an engineering manager as an R&D manager in the hi-tech software engineering industry. But I am sure, these are applicable to engineering managers everywhere. My experiences has been with respect to the highly challenging EDA industry, and so, the information below may potentially be biased towards this industry.

An engineering manager will need to have a few qualities and need to do some things which are absolutely essential to manage a productive high energy team.

  1. Lead technically: This leads the pack. The leadership has to be technical. An ideal engineering manager is one, who has grown up the ranks from software engineer, to tech lead, and now to engineering manager. He should know the specialization technically. When his developer explains a complex idea and is reasoning out why it would take a month for him to develop — the least he should be capable of, is to understand the idea, and realize its complexity.
  2. Be able to code: When there is crunch time, the manager should roll up his sleeves, and get to brasstacks. He should be able to fire his gvim/emacs/editor-of-choice, and be able to debug.
  3. Review code: He should be able to review code, atleast at a high level. There is no way, an engineering manager can ‘own’ his team, is, if he is atleast partially accountable to the teams deliverables. I am not saying, he should review line by line. He should be able to skim the bug-fix, or a feature algorithm, and be able to determine, if it is deviating or conforming with any pre-determined spec/discussion. Speaking of code reviews, there are two good side-effects. Firstly, the manager knows exactly what each of his team is working on, and can guage the productivity of the team, at any given point in time, first hand. Secondly, he is continually sharpening his saw (in Covey language). He keeps in touch with programming, and with the algorithms in his niche.
  4. Be an excellent communicator: He needs to be able to talk two languages. He should be as conversant to the developer/engineer, as he should be with management. This is crucial. Developers should build their trust in their manager. The manager is the conduit of communication between the engineer and management. The manager should also be able to distill the communication going downwards, and pass only information that is useful the developer downwards. Engineers almost always feel there is too much of management communication that flows down. A good manager distills this information and feeds only relevant information to the engineer.
  5. Be a good listener: As I said earlier, the developer builds trust in the manager. He expresses his anger, sorrow, angst, happiness – everything to his manager. A good manager listens and empathizes. There is reinforcement of trust here. A good manager listens carefully and remembers. Have you ever seen the pleasantly surprised look on an engineers face, when you ask him/her, how his/her mother is doing, after her surgery. How do you know ? He was ranting a couple of weeks ago, about how hospitals in Bangalore suck. You rememebered. You asked. There is nothing more rewarding than seeing that pleasant surprise on his/her face.
  6. Be good in planning: You should be able translate developer deadlines to project level estimates and vice versa.
  7. Be a good negiotiator: You will have plenty of situations when you have to bargain with your developers and quite a few situations when you would have to bargain with the management as well. Most likely, the latter.
  8. Be a good influencer: This is a big one. It is related to the previous point, but a little more subtler. When you win your negotiation, you win one, lose another. But, with being influential, you win both ways. You convince. You make sure, the other side takes a decision – the decision you want them to take.
  9. Have good meeting organizing skills: Two skills are needed for this. Have meetings only when required. Start the meeting on time, and finish it on time.
  10. Be flexible: You would need to be flexible. You cannot expect a developer to turn up for a meeting at 10AM (very early morning !). You should be ok to shuffle around meetings so that it is convenient to most people. Be flexible in cancelling meetings, if one is not needed at that time.
  11. Work with the team: Last but not the least – work with your team. Do not sit in your room and let the team do their work. Work with them. Debug with them. Discuss with them. Plan with them. This is not just good for the team. It is good for you as well. You are abreast of what the team is doing technically. It will help you plan your schedules more accurately. And you are continously sharpening your saw – broadening your knowledge.

These are some of the techniques, that could make you the star engineering manager. These are but the tip of the iceberg. The main thing is, you stand for the team. You are their conduit to management. And you are the face of the team to management.

Note1: The above list is in no particular order of importance.

Note2: The usual disclaimer: The opinions expressed in this article are solely mine, and are not of my employer, in any way.

Managing start-ups

First off, for those who claim that management is not necessary in a technical environment — I respect your opinion, but what I am going to be writing below is not going to interest you. You might as well go to slashdot, or metafilter, or coding horror, or …. (Disclaimer: The fact that I believe that management is necessary in a technical environment does not mean I do not visit the above sites – I am still a geek at <3 .)

Managing a start-up environment is different from managing a mature software business. There are several things that work in a startup but may  not work in a mature setup, and vice versa. You should notice that I have emphasized the ‘may not’. There are several companies that I know, which work in startup mode. Some of the below may work in these, if it is part of the culture of the company.

The following points are not arranged in any particular order.

  1. Avoid meetings – have discussions: It may seem like I am just calling it by a different name. It is really not so. There are several significant differences. Some of the key differences are:
    1. In a discussion, there is significantly more participation from the grass roots engineers, than in a meeting.
    2. There is no agenda. There are points of discussion. The key point is here is that, meetings are over when the agenda points are done. Discussions are over, when everyone is convinced.
    3. There is a lot of learning in a discussion. People can ask for clarifications and elaborations.There is no “lets take this discussion offline“. This is the discussion.
    4. Action items are taken by the ‘actioners’ themselves. There is more accountability this way.
  2. Avoid status meetings: Status can be covered either by discussions like the above ; or by just walking over to the cubicle of the developer. I sometimes write down the action items etc on the white board in the cube.
  3. Give more freedom to developers: They are more creative this way. They are more accountable, and they feel good about it. Developers who feel good about code they develop, just are more productive.
  4. Break stereotypes: Get wifi to the coffee room/pantry. Who says the pantry is only for relaxing. If the developers are most productive in the nights, and request for coffee/tea in the night, get it to them. Do they require dinner ordered in – order in. Do not think about, what others will think about it — or whether it has ever been implemented before. Just do it.
  5. Isolate from management: As far as possible, you the technical manager, should be the one who oversees the development. Try and avoid as much as interference from higher management. They do a very important job of bringing business to the company. Let them do it in peace. Try and avoid them giving advise/suggestions/recommendations on what should go into the product, or how easy/difficult it is to develop something. You, the technical manager, should be the conduit between the upper management.
  6. Reward rebels: There are programmers, and there are rebel programmers. These are the bearded ones, which get maximum work done between 11pm and 1am. Encourage through whatever-means-appropriate-means for them to align with the high level objectives of the company, and you have a winner here. Reward the rebel handsomely. One must understand that rebels do not consider money as the only reward. They can be rewarded with better machines, dual monitors, leaves-with-no-questions-asked.  These things will equally excite the rebel in your team. Go on, encourage the rebel in your team, and kick-back-and-watch-the-fun.
  7. Infuse energy: Have you ever walked into a start-up office (atleast one that is doing well, and that is managed well). Can you feel the energy. There are heated technical arguments in the hallway. There are ‘rebels’ having good over-ear headphones, listening to some loud music and bobbing their heads, as their hands furiously program. You can see people coding with feet up in the table. You can see someone who has just finished coding a module, get up, and throw up his hands in accomplishment, and drag a few of his mates for a coffee. Thats the energy. Encourage it. You, the technical manager should be part of this energy. Go and hi-five the guy who just finished the module. Participate in the hallway argument. Kick back and have a cuppa coffee with the so-called-junior-developers and share some history. You will not only be considered the cool guy. You will be the one who will be accredited for all the energy (and hence the productivity).
  8. Small perks are valued more: Perks such as spending a hundred dollars on a fancy expresso machine are valued much more in a start-up. It reinforces in the workforce the confidence that management is trying to make the place as much fun and comfortable for them. Fresh cut fruits in the morning is another example. Rebel coders rarely have the time to shave, leave alone, have breakfast. They will come to work, and have fruits and coffee. Do not lay your hands on these small ticket items, when management tells you to cut discretionary spending. You can save more in economizing other things. Infact, get the dev team together, make the decision together.
  9. Percolate field news to dev team ASAP: This is something that successful start-ups always do. Some of them do it partially, and get bombed for it. When I say partially, I mean, only bad news from field, in the form of bugs, and enhancement requests, trickle to the dev team. This is no good. Did sales bag another order – however small it is? Share it with the team, and celebrate. Hey the sales team celebrates it. And the dev team usually gets to know about this, and thinks – “dang! I created the feature, and I get nothing.” Percolate good news and bad news from the field down to dev team. You gain two things by doing this. You gain good-will from the team – the team thinks they are a part of the whole gig. And secondly, you get the dev team working more productively towards what the field and the customers require.
  10. Celebrate every occasion: Yes, I mean every occasion. There need not be a lavish 5 course meal. Celebrate with ice-cream. Celebrate with pakoras or samosas  (in the Indian context). A feature that has been under development for 6 months, just got done. Celebrate. And call the whole team for it – not just the 3 people on the project. A new customer. Celebrate. 1000th bug fixed. Celebrate. A developer fixes his 250th bug. Celebrate. Give him a uber-debugger award certificate for it ! It is not about the food, or about the time, or about what you are celebrating. It is about, getting the whole team together, and reinforcing the thought, that the team is doing something very cool, and the management recognizes it.
  11. Practise management-by-walking-around (MBWA): I just walk around and gather status. I just go and sit on the developer’s desk, while he lounges in his chair, and explains what he has in plan for the next week. He basks in the glory of fixing his 4 bugs last week. He tells me that he will be on leave on Tuesday. What did I just do ? That was my status meeting. I walk back to my office and note down important things in the conversation. You can get a lot of work done this way – and if you notice, the developer did not get off his chair, and he got back to work, right after you buzzed off. Wow, talk about productive meetings eh ?
  12. Aggressive targets: Set aggressive targets, but after buy-in from the developers. Push the line. Raise the bar. Tell the developer that you are raising the bar. Make him/her raise the bar. Challenge the developer.

These are some thoughts on how managing start-ups can potentially be different from managing a normal software factory. These are not rules. That is the whole point. Take these ideas. Spin them off in your context. And watch the fun unfold.

The opinions expressed in this article are solely mine, and are not of my employer, in any way.

Cisco’s curious week

HBR has a great article (I love HBR articles that get delivered to my email … small and crisp and full of information) on CISCO’s curious week – and how the giant has been playing around with Disruptive Innovation for quite some time. In a recent workshop I attended, I learnt that this is also called Paradigm Shift and it is well known that, paradigm shifts lead to leaders.

Cisco is not new to paradigm shifts. It originally started with usage of the Internet Protocol (IP). The giant has been making some pretty changes inside. Some of them as outlined in the article are:

Its purchase of linksys – an entry into the home router market. I think the Linksys routers are the best. I have one at home, and they are incredibly easy to configure.

Its purchase of WebEx seemed pretty logical to me. Networking giant + good conferencing company = Revenue.

It has also recently bought Pure Digital – which makes a popular line of flip handheld video cameras. (I have never heard of this one though!). But it is interesting to see the networking giant move into this market.

And ofcourse the biggest news of last week is CISCO trying to buy SUN, and enter the server market – directly getting face-to-face with IBM and HP and the likes.

But at a very high level, all this kinda makes sense to me.

(big router business) + (home routers) + (good video cameras for conferencing) + (good conferencing software) + (stable servers to handle the software) = Awesome $$.

The stable servers is probably a weak link in the above equation. But it is defenitely a good entry into a large revenue stream business. Here’s to CISCO, and lets hope they come out of this recession fine and dandy.

Note: I was in Silicon valley on a business visit in 2003, and going through some of the CISCO buildings near McCarthy Blvd/Tasman/Cisco way, and it was very disheartening to see some of the empty buildings (what was left of the DotComBust). But still CISCO lasted. And is surviving.

Proximity Management

I just read an excellent article on “The real secret of thouroughly terrific companies”, by Peter Bregman. Bregman recounts and explains his terrific experiences in staying at the Four Seasons Hotel Chain. He sees what he calls “Proximity Management” being practiced. The managers know about their employees. There is a lot of trust within the different properties. There is open communication. There are monthly meetings, without any agenda, and the GM (Michael Newcombe) just engages in conversation. There are such meetings with all employee groups. 

Here is one anecdote, of how open communication solved a huge problem:

During his meeting with the front desk staff, he learned they were slower than usual in checking in guests because rooms weren’t available. Then, in his meeting with housekeeping staff, someone asked if the hotel was running low on king size sheets. Most CEOs wouldn’t be interested in that question, but Michael asked why. Well, the maid answered, it’s taking us longer to turn over rooms because we have to wait for the sheets. So he kept asking questions to different employee groups until he discovered that one of the dryers was broken and waiting for a custom part. That reduced the number of available sheets. Which slowed down housekeeping. Which reduced room availability. Which delayed guests from checking in.

Read the full article at The Harvard Business Blog here.

When payslips kill motivation

Shankar Vedantam over at Washington Post has a great article on how payslips and rewards actually intrinsic motivation, and often kills creativity.

It happens all the time: Two guys in a garage come up with a cool new technology — and dream of making it big. A thousand people take time off work to campaign for a visionary politician because they feel they are doing something to change the world. A million kids hit baseballs — and wonder what it would take to become a pro.

Then the brainiacs, volunteers and Little Leaguers grow up. What they did for fun becomes . . . work. Paychecks and bonuses become the reasons to do things. Pink slips and demotions become the reasons not to do other things.

Read the full article here.

[banner and excerpt courtesy: Washingtonpost]