Batman and Robin

 

Why do tech companies have delegators?

It’s weird, isn’t it? I wish I had a clue.

First of all, who is a delegator? To understand it, one has to read this classical joke -

A pig and a chicken are walking down a road. The chicken looks at the pig and says, “Hey, why don’t we open a restaurant?” The pig looks back at the chicken and says, “Good idea, what do you want to call it?” The chicken thinks about it and says, “Why don’t we call it ‘Ham and Eggs’?” “I don’t think so,” says the pig, “I’d be committed, but you’d only be involved.”

Get it? I’m sure you do.

Delegators are the kind of people whose only job is to be involved from the sidelines. They are not the ones who do design, development, testing or manage projects. Well, may be, sometimes they manage projects but all they do is just check the tasks from the list and report status off of it. I’ve been part of companies where even the task list was created by the developers themselves and all they did was ask whether it was done or not.

So, what the hell is my problem?

Well, my only problem is that I see an increasing trend in the software industry(especially India) to have delegators take prominent positions, big offices and sometimes be the drivers of the tech. strategy - All when they have little clue about how to really go about building good software. How can one really build a good strategy when they are divorced from software eco system? Why should they get quiet working conditions(read: offices) when they are not the ones getting actual work done? Why should engineers report to people who don’t have many technical bones in their body?

Tech companies where techies are not part of the core group. Huh! Yeah, beats me too.

But, I get it as well. They are generally the people who can be good with processes, can manage P&L, can drive resourcing and recruiting for large scale projects. Thus, a genuine need for software companies to recruit such kind of people. And, to be honest, one can’t run a successful tech business especially software services business without them. Thus, the right kind of people add tremendous value in running a good software organization.

But, why the hell have them be at the driver seat? Shouldn’t they be just guiding the experienced technologists about the patterns of financial success for running software business? I just wish tech companies had the “two in a box” approach – Technologists as the drivers and the business aides as their side kicks like Batman and Robin.

Yeah, we just like to wear better suits and drive fancy cars :)

Saying Sorry

You screwed up.

You are cognizant of it.

So, what’s the problem saying sorry? Simple, plain old fashioned Sorry.

“I’m really sorry that I screwed up. I will do my best to fix it.”

Some of the engineers, managers and business leaders I’ve come across hardly know this word.  They shy away from it. It’s either not there in their vernacular or it is a tongue twister for them.

Aah, I exaggerate. We know that’s not the case.

Actually, most of the people either genuinely don’t realize that they have screwed up or feel bit awkward saying that. They think they might look weak and vulnerable if they were to apologize or it could be that a honest admission of mistake would somehow cast a shadow on their superiority/path to success.

In almost negligible cases, some people are probably built not to ever accept their mistakes. They always have an excuse, someone or some situation to be blamed – somehow they can never make a mistake. Period. In my experience, there is a high correlation between these kind of individuals and them taking undue credit of someone else’s hard work/ideas. They would always make themselves look good no matter if someone else has done the hard work.

On the contrary, I believe it speaks volumes about the maturity and emotional fortitude of a person who is not afraid to admit the mistake and apologize. Saying sorry from the heart gives you another chance to rectify the mistake and helps re-build the trust. It just goes to show that you are cognizant that you let someone down, even inadvertently, but are ready to be given another chance to fix your mistake i.e. you are an objective person - well aware of capabilities, what is expected of you and how are you doing against those expectations?

My question to those who can’t say sorry is “how does one even grow if one doesn’t admit mistakes and is willing to learn from them?”

Photo By: ExtraLife

On Hiring People

He walked.

I sold our startup’s value proposition honestly but unfortunately it didn’t work. He agreed and was excited at first at first but I guess got scared away by my honest admission of risks involved in joining a startup. I guess I sold the risks far more than the merits. But, what was I really supposed to do?

It is tough to hire smart talented people for startups and keep them motivated but the situation becomes far more involved when one is hiring from one’s own network. How do you bring in an engineer whom you have worked with for years without telling them the risks in detail? Isn’t it imperative that they know both the sides and take an informed decision? How does one really show the bright side while sharing these kind of risks in detail?

I failed.

I wish I knew the answers. I wish I knew the magical words so that everyone was ready to take a chance to build what we aspire. I wish I had read Tarun Upadhyay’s advise. On the other hand, I also wish if everyone could see that huge success or colossal failure is just a game of probability and the actual fun is really in building a company itself. I’m not trying to evangelize that reward is in taking a risk itself but sometimes one has to take chances, unleash the adventurer and see if the rainbow actually exists on the other side.

Should you move on?

In the current economic gloom, it's probably preposterous to even broach the subject of leaving a job  but I was wondering if there was a methodical system to decide if the time had come to switch jobs.

All of us have an inbuilt compass that decides whether the time has come to look for opportunities outside the realm of the current company. It could be for various reasons - lack of role definition, lack of challenging opportunities, unsatisfactory work conditions/compensation or a manager that we just don't get along with etc.

Apart from the "gut system", is there an objective way to decide to look outside? It turns out there is. One can figure out the answer if was one was to earnestly answer the below 12 questions -

1. Do I know what is expected of me at work?
2. Do  I have the materials and equipment I need to do my work right?
3. At work, do I have the opportunity to do what I do best everyday?
4. In the last seven days, have I received recognition or praise for good work?
5. Does my supervisor, or someone at work, seem to care about me as a person?
6. Is there someone at work who encourages my development?
7. At work, do my opinions seem to count?
8. Does the mission/purpose of my company make me feel like my work is important?
9. Are my co-workers committed to doing quality work?
10. Do I have a best friend at work?
11. In the last six months, have I talked with someone about my progress?
12. At work, have I had opportunities to learn and grow?

I wish I had come up with these questions but I just happen to stumble upon them while reading "First, break all the rules" by Marcus Buckingham and Curt Coffman.

The questionnaire is put in such an articulate and simple manner that it helps you bring out the truth out of the closet regarding whether you belong in a specific place, are in a position to contribute and grow professionally. You immediately know the path you have to take if the answers are predominantly towards "Disagree" or "Strongly Disagree". By the way, they suggest that all the questions should be answered on the scale of "Strongly Disagree", "Disagree", "Neutral", "Agree" and "Strongly Agree".

To digress a little, the book was about the fact that individuals leave managers and not organizations. I'm sure you can clearly see that all the areas in the questionnaire can be directly addressed by an individual's manager thus I'm not surprised about their findings. After reading the book, I'm thoroughly convinced that individuals leave because of their managers. I hate to admit but I've had some smart individuals leave when they were reporting to me and now I can clearly see their reasons. I could pass the buck on to the organizational operative context but at the end of day I didn't do enough to realize their potential.

I hope this questionnaire helps everyone who have started to feel iffy about their current position but don't know what should they really do.

Analysis Paralysis

 

You know what is worse than taking a bad decision? Yes, you guessed it, not taking one. I've come across some very intelligent individuals who just couldn't make a decision and vacillated between alternatives, even when they did make a decision.

The thing which baffles me the most is that some of them are highly experienced, worldly wise and extremely intelligent individuals. I could spend hours with them talking about anything and everything under the sun and would come out of the discussion learning new things. But, I'm not sure what happens the moment they have to make a decision. They would either tend to consult lot of people before making a decision lest they might hurt someone's feelings/pride or would have their mental tectonic plates gyrate passionately on both the sides.

Something just takes over the cerebral faculties and clouds their judgement. Sometimes, these individuals take so much time that the issue becomes irrelevant. On second thoughts, it might not be such a bad thing at all as the issue does get solved :)  I'm not sure if it is the case of not feeling empowered enough, fear of failure, over cautiousness, or a mere passion for over analysis but they need to tell themselves that they are in a leadership position because someone thought they deserved it(most of the times, they truly are deserving) and they ought to get things going.

The thing that might work in these cases is constant follow up regarding the pending decision after a resolution deadline has been setup. I know it could be hard and there is a chance that you might offend your peer or senior by the regular follow-ups but I've seen it work sometimes.

What are some of the strategies/suggestions you would recommend to tackle this behaviour?

 

Related Post

In State Of Denial

The Future of Management

 

Have you ever felt that modern management practices in mid to large size organizations sometimes fall short on fostering creativity? Do you feel that your organization is not doing enough to harness the talent of all its employees? Is innovation localized to a select group in your company and you think the management is not doing enough to make innovation systemic? Have you ever had a nagging feeling why HR practices try to bring consistency and homogeneity in a heterogeneous environment?  Do you think the employees are smart enough to manage themselves and organizations don’t need deep rooted hierarchies to watch over them? Do you think your organization is not nimble enough to adapt to the changing business environment?

Well, the book is for you if you answered in affirmative for any of the above. It is a very insightful book, which is divided in four sections - Why Management Innovation Matters, Management Innovation in Action, Imagining the Future of Management and Building the Future of Management.  

The book starts with outlining the reasons why should we adopt new set of management principles and how current management practices are not suitable enough for the new knowledge economy. The second section outlines examples of companies which have adopted the new innovative management styles and are extremely successful - Whole Foods, W.L. Gore and Google. The third section outlines the need to first understand why we believe what we believe and then embrace new principles that foster innovation within an organization. The last section shares certain lessons to become a management innovator.

It's a book which would inspire you to challenge certain norms within your organization. I really enjoyed reading the book.

Why Technology Startups fail?

 

I was having coffee yesterday with one of the founders of my company and somehow the discussion came around to technology startups. Why do so many of them fail? He said they fail because most of them don't have a strategy for acquiring customers. The idea could be brilliant but it is bound to fail or struggle if the startup doesn't know the go-to market strategy, how would they have the customers buy their products, and the cost of acquisition of these customers. Simple. Insightful. Profound.

The thing which can kill a startup is the cost of customer acquisition. A startup could be raking in millions of dollars but not be making a single penny in profits because of the high cost of acquiring and servicing customers. In the formative months/years, the startups  don't mind paying more to acquire customers when compared to customers average spending on their site as it is all about growth and about getting the market to know of their product. But, it has to be backed up by a sound startegy of bringing these costs down over a period of years so that they can start making profits.

Thus, invest in creating a go-to market startegy so that you can understand the potential and limitations of your idea.

In State Of Denial

I was ruminating over the perils for a business entity and figured the thing that can hurt an entity the most is having its management in the state of denial about its health. Heck, this could be true for everything around us - our projects, professional growth, personal relationships etc. Most of us run our businesses/groups with a perception that it is succeeding until we discover that we have landed over on the dark side. It's interesting to see that most of us make believe that it was an overnight phenomenon and it was never meant to happen whereas the reality is that tectonic plates of adversity had started gathering momentum long ago.

Have you ever driven in India? If not, well, first lie in the prostrate position and thank your stars that destiny has chosen you as the lucky one. Well, it's an absolute pandemonium! There are no rules on the road, people cut you off, they are always driving at your tail and the worst, they don't hesitate to unleash an honking avalanche and bury you under the cacophonic sound if you were not to give them way. Crazy, isn’t it? They say one can drive anywhere in the world if one has driven in India. Don't believe me? Wanna try it out? Yeah, I didn't think so :)

Now, the interesting part - One has to look at everyone's animated expression every time there is a fender bender (BTW, which happens every few seconds). People are ALWAYS shocked that they got into such an accident. Well, was it not expected in these driving conditions? One should be thanking the heavenly forces that it didn't happen few days back. But, they don't. Why? They are in the perpetual state of denial about the horrid driving conditions.

In both the above scenarios, there is a state of denial which leads to unpleasant ramifications. The logical choice is to look within and seek bold new initiatives which can challenge the status quo. But, the sad part is that sometimes we are too late in discovering the disconcerting facts about the health of our environment. By that time, the playing field has already changed and one has to work diligently to be part of the race again. Thus, the idea is to observe the business context intently and be nimble enough to make proactive changes.

Thus, always periodically review the progress against the plan, be inquisitive about the plans of your competitors, invest in innovation and nimble enough to adapt to the changing environments.

Related Post

The Most Important Management Skill

The Most Important Management Skill

Listening. Period. It has to be by far the most important trait that any manager needs to have. By the way, I'm not only talking about listening as in hearing but also interpreting their vernacular through their expression of speech and body language. We sometimes forget that verbal expressing is just one miniscule part of the overall communication and a major part has to do with the body language, posture, and facial expressions through which a person expresses their thought process.

I'm not sure why some of us are not good at it but the reality is we most of the times are caught up in our web of thoughts or already have preconceived notions about the individual conveying the message. Thus, we tune out somewhere in the middle of the message and don't give a fair chance to that specific message. It could be in a hurry to end the conversation because of some prejudice against that person/topic or our mind has already come up with some smart retort.

I wonder how one could manage effectively with a listening impediment. My sense is that one can't. A manager's job is, well, to manage the team. In my field, the success of the project is also governed by the cohesiveness of the team i.e. the social engineering aspect of it. Also, how motivated and aligned every team member is towards the success of the project?

Wouldn't someone with listening impediment miss the core issues team members are grappling with? As a manager, one has to weed out all the team issues to make sure the team is aligned with one thing only - success of the project. And, one can only really do it if someone can listen, understand, judge and respond effectively.

Related Post

Managers are from Mars, Developers are from Venus

Infinite choices i.e. The Long Tail

What an insightful book! I just finished reading it cover to cover in a day! It enlightened and helped me see the great success stories of our digital age with a new perspective. I always knew the technical reasons behind the successes of eBay, Amazon, iTunes, Rhapsody and the likes of them but never in a way Chris explained it in this book.

It would help one understand the explosion and successes of the new internet businesses and the reasons behind them. It compares the online business with the traditional retail business and explains their edge because of the following forces -

• Current abundance and affordability of the tools of production.
• The dramatic reduction in the cost of distribution in this digital age.
• The prevelance of search filters to connect the suppliers and the actual consumers.

Take for an example, Why Wikipedia is more successful(or, will be) when compared to MS Encarta and Birtannica or how Rhapsody/iTunes are more popular when compared to the traditional retail stores for music like Tower Records. 

I'm sanguine that the pattern of Long Tail is ubiquitous in the modern times and I could even relate it with our own business model. I work for an Outsourced Product Development company,GlobalLogic, and I think we fit in the Long Tail of our market segment. Furthermore, there is a Long Tail within our own revenue model - majority of our revenue is driven by minorty of our partners i.e. The 80/20 rule.

I just feel that it could have been written a tad well as lot of examples have been repeated in the book. I think it could be have been wrapped in 150-170 odd pages rather than its current size of 226 pages. Nonetheless, a must read!

Agile Crazile

Blasphemy! You would say.It might be, especially when the whole software world treats agile methodologies as a panacea to all its problems. I have to admit that I've been in a perpetual state of skepticism about the benefits of agility and the fact of the matter is that I haven't found any valid reason to move out of my comfort zone of skepticism.

I think it tries hard to solve the problem of showing the ROI faster to the client but in the process ends up creating an even  bigger problem -- Chaos. Chaos has ensued in almost all the engagements that we have executed using agile methodology. Some of it definitely comes from our lack of understanding of the agile practices but most of it comes from the way the methodology evangelizes the projects to be executed. IMHO, agility has got benefits but it hasn't matured yet(again, could either be lack of our understanding or dearth of good case studies). Most of the material out there has been written by very gifted writers which ends up seducing everybody to espouse it but I think most of it is bit pedantic and lacks pragmatism. Furthermore, almost all of it has been written by comparing it with the wooly mammoth of Waterfall -- Waterfall is bad thus Agile is good, hence proved. Whoa!

What leads to this chaos? The culprit, more or less, in all the engagements has been the flux in requirements and the monstrosity involved in managing frequent iterations. I believe the whole notion of succinct user story is somewhat misleading. It doesn't give good enough idea to think about the design holistically and provide enough opportunity to put hooks in place so that the system can evolve over a period of time. Think of products like Operating Systems, Office based applications, your favorite IDE, Amazon.com, eBay, iTunes etc. -- do you really honestly believe that the engineers of these systems would have just gotten user stories, planned them in iterations, did few design spikes, few whiteboard sessions, created "just enough" documentation, planned enough for the first few months and starting churning out code without putting emphasis on rock solid design and what the future holds. Well, I don't think so.

I don't think one can adopt the agile philosophy to create systems which target millions of users. I believe all the lofty notions of brief user stories, design evolution and "design is code" can be put on a decorative mantle in these cases. While constructing such systems, wouldn't you want to detail out the vision of the system? Wouldn't you want to create detailed use cases from the perspectives of all the users? Wouldn't you want to take your time to design? Wouldn't you want to get submerged in creating comprehensive documentation to convey the thought process to the army of developers rather than doing the "just enough" documentation which can lead to ambiguity? I think the cost of refactoring the design and code and deploying them again is astronomical in this context thus it's better to follow a thorough approach rather than an agile one.

The other thing which contributes to the crazility is frequent releases. Somehow, the development team always gets bogged down by fixing the critical bugs from the previous iteration's feedback loop. One would think that the choice comes down to working on new set of requirements or bugs from the previous cycle but that generally isn't the case. Why? The thing is the development team has to roll out the agreed upon user stories and the customer also expects the team to fix the bugs thus the team dynamics goes out for a spin. It seems to me they get tied in a vicious cycle where they are always constantly refactoring the design and code to accommodate the new set of changes. It is like a dog chasing its tail.

The problem worsens when one doesn't have strong program management in place which can't push back and educate the customer about its fallout on the team dynamics. Ultimately the developer team has to work longer hours at work. This defeats one of the core objectives of agile which mandate the developers work only 40 hours week in regular iteration followed by a sprint towards the roll out of the product.

Don't get me wrong, I absolutely love the idea of frequent iterations as it provides real value to the customers as they get to be part of the growth of their software but detest it for its repercussions on team dynamics. I love it as it gives the customer an opportunity to provide early feedback to the team but abhor how the development team has to work long hours to incorporate that feedback. I think the core of both the above problems is that agile methodology believes there would be enough time to build the software the right way but the fact of the matter is that software is always conceived by a strong time bound market need and, the software would gather dust if it was to miss that timeline. In my experience, I've not once seen a piece of software being constructed without a time bound market need.

I believe most of the agile practices are best suited for a very ideal software construction setting where the developer works in tandem with the customer and both of them somehow magically agree on all timelines and what features have to be constructed. I think that kind of framework would let developers easily manage the flux in requirements and incorporate the changes from the feedback loop without any added pressure.

Nonetheless, as I said in the beginning, I'm a skeptic, but still working passionately towards to become a believer as there are lot of merits in following agility. Thus, I'm currently reading two of the famous works on Agile which have been recommended to me by people I respect a lot --

1. Agile Principles, Patterns, and Practices in C# by Robert C. Martin

2. Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results by David Anderson

I would love to hear any thoughts on how to execute projects on agile methodology, especially some good case studies of executing large scale enterprise projects.

Got Thoughts?

PS - Thanks to my friend Rajeev Singh for coming up with a very creative name for the problems we are facing on daily basis i.e. Crazy + Agile = Crazile

Managers are from Mars, Developers are from Venus

Really?

It turns out to be true. If you don’t trust me, please check it out in your team, in the team next to your cubicle, in your company or at a local theatre near you.

Be warned that this has been written from a perspective of a developer thus certain language might be unsuitable for managers especially newly conceived managers – This gibberish has been rated MMG. Thus, Manager of Managers Guidance might be required while reading it.

What really makes us different? Don’t our hearts beat in similar fashion, don’t we go through the similar rhythms of life, doesn’t the thought of a chilled Corona with lime on a sunny afternoon evoke a similar response from us, don’t we perceive reality the same way (ya kiddin’ me?), and don’t we communicate and express our thought process alike (you really pushin’ it now)?

PS – I guess the similarity stopped at our hearts beating in similar fashion.

But, most importantly, we have the same lowest common denominator!! Managers were also developers at one point in their lives but, unfortunately, they mutate once they are beamed out of the bit world. Nonetheless, can peaceful bilateral relationships exist between Mars and Venus, Managers and Developers? Is there hope?

Short Answer, Yes.

Long Answer, Y     e      s :)

If you are a manager and think your developers are on a totally different plane, please read on.So, what kind of attributes can bring you closer to your group of developers? Here is my simple list, please feel free to add/remove or critique it all together --

Technical Competence – Show me a manager without technical competence and I will show you a manager who is not very well respected among the developers. Well, you may get lot of brownie points for being a great human being or having a charismatic personality but you won’t ever be able to be one of the guys if you don’t have a technical bone in your body. I’m not saying one has to have a degree in computer science but decent understanding about what your team does on a daily basis is definitely a must. Furthermore, how can you really act as a conduit to the success of your kick-ass developers or mouth off their accomplishments in front of your customers and senior management if you don’t understand technology? I believe this attribute also helps you to kick ass when it really comes down to marrying business needs with the technology roadmap.

Autocracy Democracy – How hard it is to get rounded decisions by taking a holistic perspective of the team? I think if you are one of the managers who micro manage things or takes decision in autocratic way then you really have to figure out a way to change yourself. There are times when autocratic decisions are required but they should be few and far between. IMHO, one only stands to gain by listening from the people who are in touch with ground reality a.k.a code a.k.a the software.

Ability to manage ambiguity – I think majority of the developers are generally much contended with creating bits and lack the overall business perspective somewhat. I think a manager would score really high on the developer’s respect-o-meter if he can bring in some level of clarity to ever changing business needs and articulate that in technical context. Yes, articulation in technical context. Not sure, how is this possible? Please look at point number 1.

Playing to their Strengths – I think one of the reasons project fail or are behind schedule is that developers don’t play according to their skills. I think one can only have a highly productive team and developers with a healthy swagger if one plays according to their strengths. In my experience, most of the managers generally have this attribute imbibed in their DNA as they are born with the natural instinct of mitigating risk. But, if you think you are not one of the lucky ones, then you would have to collaborate with your developers at a deeper level to understand what moves them. In case, you are not in a position to figure out the strengths then I would suggest following Scott Berkun’s advice of asking a developer how you can help them shine or kick-ass in the project.

Growing Talent – Playing to your team’s strength alone is not enough you really have to help them grow. I don’t mean helping them climb the corporate ladder faster but helping them realize their true potential. It means either mentoring them or helping them find the right mentor. It means helping them to take on lateral tasks which might not be part of their core skill set. I think developers are generally more productive and committed if they think they are following a well laid out plan.

Technical Competence $30
Playing to their Strengths $25
Helping your team grow $25
Ability to manage ambiguity $20
Standing up to defend the rights of your team, Priceless!

Before you go on a rant complaining about this, please bear in mind that this has been written by a New Manager On The Block who is still learning the ways of being an effective manager.