Roman's miles

Should you change your boss?

I'm reading now Up The Organization by Robert Townsend. This is a reprint of the 1960's edition but, oh boy, it is so relevant today! The book is to be read in a direct-access-format so you can read any chapter straightforward without reading the previous. I jumped to the appendix - "rate your boss as a leader". It echoes pretty much to my thoughts but is more specific. Try to rate your boss on each of the aspects on a scale from 0 to 10 how she is:

1. Available
2. Inclusive
3. Humorous
4. Fair
5. Decisive
6. Humble
7. Objective
8. Tough
9. Effective
10. Patient

If the total rating is below 50 - look for another job:-)

Techorati tags: career, boss, job

Never do "davka" to your boss

Davka (דוקא)  has no clear translation. "Spitefully" or "despite everything" may be the closest possible. Norman Geras struggles here to explain too. An example could be a situation when in (open and clear) disagreement with your boss you davka keep doing what you think is right. I don't think it's right (for you).

I've seen my colleagues and friends after not agreeing with the boss in an open conversation keep carrying out their own position. They don't succeed to convince the boss to change his mind and nevertheless continue pursuing their theory. By doing opposite to what the boss requires they sabotage his instructions trying to prove their own point of view. Needless to say it's dangerous.

First and foremost for your career. Very likely career advancement with your current boss will be put on hold rather soon. You'll build an aura of a stubborn and unmanageable employee that very few will want to work with. Regardless of whether you're right or not. 

Now I'm not saying you have to be a yes-sayer. Opinionated and confident people "davka" get visibility and earn positive reputation. I'm just saying that when the controversy is over you must follow the decision of your boss even if you don't agree. An option to resign (change the team, role, position, the boss) also exist. Use all your might and energy while the discussion is in progress but give up when the decision has been made.

The very last case is whistle blowing. An ethical problem or an illegal witnessed activity can be a cause to signal up the chain of command. It's a separate topic but before you whistle be sure you're ready to withstand the consequences.

Technorati tags: davka, boss, loyalty

Are you paid fair?

I'm sure this is a question each of us asks herself now and again. Notice, I didn't ask whether you're paid well but fair comparing to a) your colleagues in the company and b) the market. Sooner or later you'll find the answer and if you're underpaid then (this time rather sooner) you'll probably will find that you can't change much now (unless you consider changing job).

If the gap between your and the position's average salary is more than 15% then you're manager can't simply give a fair-fixing increase after the next performance review. If you work in a small company he follows budget restrictions and if it's a corporation - so even worse - Its Majesty HR rules the game. In big companies there are ranks and HR looks at you through the prism of policies, rules, and processes. To give a significant increase the foremost necessary step would be to lift your rank. Now the game becomes really complex - the changing rank process is more demanding than just the increasing salary step. The manager now needs to justify the rank change and he may not have a headcount for that, or you may not fit it, or you may not have worked in the company sufficiently long to make it, or a hundred of other reasons.

Why it all happened? Many possible explanations can apply. But hearing the same story again and again I'm sure that in the majority of the cases the one to blame now is yourself. The mistake you did was to accept the offer you got at that interview when the offer blinded your mind.

When you get an offer you start a game of negotiation - a poker! Who wins the game - one who made the homework better and who's cool-headed in the game. For a company (in the person of its HR) it's much simpler so it's gotten a competitive advantage on you. But the game is not lost. If they give you an offer they value you and prefer among other candidates (tip: by all means try to not reveal your salary expectations). If you play your part right you can get the most out of this situation.

By the homework I meant that you should prepare a few things:

• Figure out how much the position is worth on the market;
• Figure out how long the company has had this vacancy;
• Figure out the current pace (and rate of success) of company's hiring;
• Figure out your absolutely lowest limit, your "ideal salary" answer, and have a contingency plan - if they don't give it to you what benefits you can ask for (including out-of-plan increase in a short time interval).

You may consider to buy this information or to hire an recruiter expert in your realm. Remember - the stake here is not your annual salary but your entry point to the company. Prepare to this poker and play it right. As in any game there is a risk of loosing it but if you've reached the offer phase and made your homework right (be fair, don't be unreasonable greedy) the odds are tiny that they revoke the offer.

What are your tips on safe landing on a new job?

Related posts:

What's important for choosing a job - Stability / Stimulation / Discovery?
Your current job -"a time to kill, and a time to heal"
Three questions employee should periodically ask themselves
Evolving from a software engineer to...
Work with pros

Technorati tags: job, career, salary, negotiation

Joining the startup world - remain in "province" or move to Silicon Valley?

I've been struggling with answering this question for myself for a while and as I read on the realm  a set of options is widening instead of shrinking. The title question may seem to be obvious and drive to the immensely polar answer - Silicon Valley - but in reality the question should be re-asked differently. If you live in a big enough American city should you relocate to SV to make your startup adventure easier? By adventure I mean either creating your own startup or joining  an existing one. The former entails  rising funds, hiring people, organizing office, etc.  The latter makes you choosing the most attractive position from available options.

The question is very relevant for me - I live in Atlanta and as an option consider after completing my MBA to open a startup navigation, leaving my current job in SAP. I'm not trying to reiterate the well known reasons of why SV is the Rome of high-tech ventures explained and opposed  here, here, here, and here. Instead, I'm seeking for arguments whether it's possible to stay in Atlanta and achieve desired targets instead of locking myself in a void of opportunities.

On one hand, in the Bay Area a number of vacancies and VC groups looking for promising ventures is bigger - so there are more options. On the other hand, in Atlanta (or any other  city with sufficiently provided resources, infrastructure, and local VCs) the number of challengers is smaller hence one's candidacy may meet less competition.

I'm attending a presentation of Marc Fluery (the JBoss guy) next week where hope to ask this question but will be very interested in others' experience and findings. What are your thoughts? Does the province have its piece in the startup world or better off plan to move to the capital?

Update: Johanna Rothman helps to answer my questions.

Technorati tags: startup, VC, Silicon Valley, Atlanta

How to read fast

Let me explain the title. I didn't mean how to read more words per minute that a bunch of different techniques claim to educate. My needs were how to increase the speed of comprehension of the read material, especially of business or studying books. Let's start with an extreme but clear case. Assume that we research a topic or read a book just to widen our horizon. If it's not our first book  in the realm the odds are good that we already know something about the matter; now we can either read every single word or skim through. The former is not efficient - we may read about the concepts we already know and waste our time. The latter is risky - we can miss something important and lose the book's value. Balancing two options is the kind of the fast reading I'm referring to in this blog.   

I already brought Brad's explanation on his way to read 8(!) books a week: "(a) no TV, (b) no kids, (c) four to six hours a night of reading, and (d) the willingness / ability to skim when things are dull". So the question is how to find an optimal pace for a book to trade off speed and comprehension most efficiently. I just started practicing this method and here are few my suggestions.

• Build expectations for the book. Before starting the book make it clear for yourself why you decided to read it. What is the question you're seeking answers for and why is this book indeed. Is it a particular idea, a set of examples and case-studies, or you need deep diving to the realm. Depending on the answer you may predefine what chapters to skim through. A good example of what I mean here is a pile of the books of Geoffrey Moore. Each of them is great but you don't want to read each of them from cover to cover.
• Always read the book's introductions (all of them).   In a read-every-word mode that was the only victim of my through-skimming. When I was cover-to-covering  a book I thought I didn't need to know what the book was about - I'd know it upon completion. In optimizing the pace very valuable information can be found in introductions. We need to figure out what the authors will be telling us on the next pages (or, at least, what they promise to) and adjust our expectations (see the first item). Often authors explain the book's structure that may also help us to make up our reading plan.
• Understand the book pattern. Every author is different but even every book of an author may be different. Still each book has its structure and style which even if not explained in the introduction nevertheless can be figured out after a few chapters. We need to recognize a question the author is about to answer, possible options for the answers, analysis of the dilemma if it exists, winning answers, and examples proving them. Depending on your needs you may decide what is "dull" for your particular case and accelerate reading. To make it precis the book's structure must be known.
• Take a sample and check the pace. After you answer the above questions you can start skimming. Usually, if you're aware of the problems the authors are explaining, an introductory part of a chapter can be skipped. A few paragraphs detailing importance and complexity of the situation are good candidates to save time if you know the area. Figure out where they get to the point and propose solutions to the problems. You may skip quite a few paragraphs and find that you miss the point. Don't despair. Come back but not to the very beginning. Take a half of the way and try again. After a few iterations you'll find the pace.
• A book may vary - re-adjust the pace. Rarely I find a book that keeps the same pace, style, and tone on all the way. It may happen as you go from chapter to chapter, especially when there are many authors. The pace should be adjusted and re-tested again. 

I hope you'll find the tips useful and waiting for your feedback. The final confession is I still read fiction books in a cover-to-cover mode (or just throw them away) and I'm happy when I get a business book which reading without skimming pleases me.

Update: I'm sure you'll find uesful "How to read a business book" by Slacker Manager

Technorati tags: fast reading, books, read

Corporate startups. First findings

I've got a few comments and emails to the blog I published comparing typical and corporate startups. A special thank to Richard Jones who wrote a lengthy comment answering each of my 10 questions. Driven by the desire to understand the matter I read Corporate Entrepreneurship by Vijai Sathe which sheds some light on the problem. The book is a great guide for corporate entrepreneurship and although it looks at the situation from an enterprise's standpoint nevertheless with hundreds of references and numerous examples bears on the discussion.

So after reading the book and cumulating the emails I want to add to the comments an answer to the first question "What benefits does the corporation get from the venture or why the idea of its former employee should prevail over somebody else's who comes from outside?"

Will Herman brings three theoretically possible options: the company wants to save the employees who otherwise may go on their own and by doing something similar become a competitor, the company wants to free the employees from internal bureaucracy, the company wants to attract startup-like people that otherwise won't join a big company.

The first reason is is about the people, not the product or the project so, it seems, it falls out of the startup category described in the original blog. The second reason is very possible. Indeed, Clayton Christensen in his Innovator's dilemma brings this reason as one of the most important for spinning a division off the corporation. The third reason probably makes sense for anti-corporate folks (which I know a lot in person) but I doubt there is a star on Earth worth opening a "startup" just to accommodate her hatred of the corporate world.

The question I found a suggestion in the book was the third question in my blog. What disadvantages does the company get investing into an idea of its employees (at least in a form of an internal team)? A risk here is the rewards the group may get. Vijay is highly opposed to the idea of giving the "Silicon Valley" conditions to the new venture's folks (although he talks about creating new ventures inside the company in this case). He warns that "the perceptions of inequity hurt employee morale and collaboration within the division". So the only case when Vijay sees the "Silicon Valley" conditions possible is when 1. the group of people is clearly separated from the mothership and 2. their success or failure is perceived as solely dependent on their own (they don't use the corporate's resources).

In a case when the division isn't separated Vijay brings examples of exceptional bonus programs for the participants making the bonus conditions as challengable as it can be in a real startup. Make net profit in 4 years of X dollars and get your double salary. Increase the profit by 10% and get other 100% of bonus, 20% - other 100%. So although the financial incentives are not as rainbow as the team could get in a normal startup. looking at them together with the low risk the team takes (and high opportunity cost for them to leave the corporation and start something from scratch) it probably makes it quite comparable to the typical startups.

I don't have all the questions answered yet and lack of examples of corporate startups (in my definitions) so you're welcome to comment or bring links to other sources. Meanwhile I continue researching the topic. Thanks to all who commented.

Technorati tags: startup, corporate venture, internal startup

Company mission, division of labor, and group KPIs

The advantage of small firms is they're small, and, hence, mobile. Not only very small portion of formality is required and no overhead in staff, processes, and operations is produced, small  companies live a very coherent life. When the number of employees is below "the magic number 150" they're led by one mission, have the very same strategy, and focus on one mission.

As a company grows division of labor becomes an indispensable factor of the company structure. That implies that every big division in the company is driven by the mission it's responsible for. More loosely coupled cooperation between the divisions is a natural consequence of company growth. Developers are less exposed to customer needs, professional services - to developers, marketing to professional services, support to marketing, training to support, etc. Each of the groups expands, gets its own life inside the company, own executive leads, and the most vitally important - own KPIs.

In pursuing group KPIs it's easy to lose the coherence of "one firm - one mission".  A professional services group might be wrongly measured only by revenue they bring to the company (not by minimizing the time/efforts/money of customers to deploy the product). A training group -  by the number of courses it develops, or even worse, again by revenue it brings to the company. An R&D group - by the number of bugs (I guess nobody today measures the number of coded functions or lines of code per day). Business development group - by the pipeline it creates (not by actual money it helped the sales to harvests).

Instead,  company overarching KPIs have to be the ultimate target and prevail over any formal defiitions imposed by the division of labor. Especially for new products and not productized services it's crucial for each group to be able to deviate from the predefined KPI and be flexible to perform necessary tasks leading to the completion of the company mission. Groups must build horisontal virtual teams and set up joint KPI that can be reached only via cooperation.

Professional services group needs to have capacity to transfer knowledge to the ecosystem without causing damage to the bonus of its experts. Training group - to invest in creating free self-studying content allowing people to learn the products and pass certifications on their own (which may be viewed at first glance as cannibalization of its revenue).  Sales - to spend time in rolling feedback back to product management. Each group has to look at what needs to be done for the ultimate company goal and be free to digress from its predefined path for the sake of  higher aim.

Do you cultivate a practice of debriefing in your team?

I'm reading now "Complications - A surgeon's notes on an imperfect science" by Atul Gawande. I took this book for two reasons. One, I was thinking of overcoming my panic, almost physical disgust for medical stories told (let alone shown) in details - really, just can't stand it. And second, I think that reading about parallel worlds (professions, industries, and experiences we don't cross in our business) can be a good means for widening the horizon. I'm in the middle of the book and if the first wish doesn't seem achievable (struggling forward scary medical terminology doesn't come effortless for me) the second idea brought some outcome.

In chapter "When doctors make mistakes" Dr. Gawande talks about mistakes that inevitably happen in a doctor practice. Medicine (both, science and practice) can't become one day error-less and he brings a number of examples when the human factor plays its dramatic role in every doctor's career. What nearly every hospital has, however, is a M&M process - Morbidity and Mortality conference. That's the place where doctors openly and candidly talk about their mistakes: "[doctors] gather behind closed doors to review the mistakes, untoward events, and deaths that occurred on their watch, determine responsibility and figure out what to do differently next time".

In my group we call it a debriefing process instead of M&M but although the process exists I found a few things we can borrow from its medical incarnation. I wrote before on how to love lost deals  and this time instead of concentrating on the sales aspect want to draw some suggestions on a generic level of process improvements.

• Discuss process not people. "Go after process, not people" - is the recipe from Dr. Gawande. M&M appears as a people-less processes. A good M&M discussion has lost of passive words implicitly accentuating on the process part of the problem, not the human part. I think a fear of a personal attack and reluctance to defend oneself in such a case makes debriefing projects unwanted practices in our world. In a recently performed debriefing  by my group one of the leads of the analyzed team complained that the report wasn't balanced. He wanted the areas needed additional development were accompanied by  accomplishments of the team. He missed the point (and I doubt I succeeded to come across with all my attempts) that the mission of the debriefing is in finding what to improve in the processes and not what to reward. For the latter it should be another discussion, probably internal. Also I think that we shouldn't forget the people part of the problems and its addressing should be, apparently, done internally as well.
• Make it a permanent practice. Almost every hospital holds M&M weekly. Although we don't have the highest criticality in our projects and engagements as the hospitals do, it may be a good idea to perform debriefing sessions periodically. Making the process a known place/time for critique and improvement suggestions is an important part of the team structure. Making this practice occur periodically with results focused on the areas required improvements will diminish the reluctance I referenced before.
• Build outcomes - find problems. M&M goes to discourage both attitudes - self-doubt and denial. But if surgeons can't afford being self-doubt for our industry, I believe, it's a healthy situation. When at M&M a chairman asks what the doctor, reporting the case, would do differently "nothing" is "seldom acceptable answer". Surgeons must have a "correct" view of mistakes - recognize them and come up with a solution. For our industry I think only the denial is the foe to relentlessly attack. Neither can we always come with suggestions on how to fix a problem or make things differently next time. But problem recognition is not a less crucial part of the solution. To discuss and identify problems openly is 50% of their solutions.

I'm in the middle of the book and really enjoying it. Maybe I'll find other things we can adopt from the surgeons. Dr. Gawande tells how his profession borrowed practices from aviation and engineering to minimize mistakes. Thrilling examples in the book of how new ideas helped to reduce fatal errors in medicine excite and encourage us to look at other industries in our turn and maybe to adopt something too. If not to safe somebody's life but simply to make our code better.

Technorati tags: improvement, debriefing

Corporate startup. How is it different from the typical ones?

By corporate startups (aka internal startups) they mean ventures, spun off a corporation as completely independent organizations, or else, ventures,  established from scratch but funded mostly by a corporation and being led by the corporation's former employees . Corporate startups are  sporadically mentioned in the startup literature and the blogosphere but there is a lack of materials focused on the corporate venturing, at least from a founder's perspective.

Not pretending to shed light on the topic in this blog and to shoot "10 do's and dont's for corporate startups" I'll instead try to create 10 questions one may be willing to answer when considering seeking funding from the company she's working for.

Before moving to the questions a short preamble. Maybe my understanding is not correct but I imply by corporate startup a company with two satisfied requirements:

1. It's a new and independent (to which extent is another question) company that isn't operated by the original enterprise. Otherwise, it's not a startup but just another internal project.
2. It's led by a group of former corporate employees.  Otherwise, it's just another venture that the corporation decided to invest to and the peculiarity of the topic vanishes when nothing links the founders to the VC.

I want not to mix the corporate startup with intrapreneurship because, again, the latter lives inside the company even if its management has an additional room for maneuver.

Now the questions. I hope that VC and entrepreneur gurus will come with their ideas and knowledge and help me find answers to the questions. Beneath each question I'll give a few hypothesis that sound logical for me to check but they're also the targets for your refutation.

1. What benefits does the corporation get from the venture or why the idea of its former employee should prevail over somebody else's who comes from outside?
   
   1. Trusted team. The "founders" are easily trackable and checkable.
   2. Providing some safety conditions for the founders it can get better conditions.
   3. Its VC division is very specialized and may not be attractive for "external" founders.
2. What benefits do the founders get from the company as their investing source?
   1. Easier to sell the idea (including the team and the track of records).
   2. Easier to roll out the product through the company's resources (customer base, brand, relationships, etc).
   3. "Dispersal field" in case of failure of the venture in a form of saved conditions in the company.
3. What disadvantages does the company get investing into an idea of its employees?
   
   1. Didn't come up with anything in case when it decides to invest.
4. What disadvantages do the founders get from the company as their investing source vs. independent investors?
   1. Potentially worse conditions.
   2. Lock out of the company's competitors as potential partners.
   3. Lock out of the company's competitor's customers.
5. What target does the company pursue from the venture (which defines the venture's degree of freedom for the product) and what is the exit strategy?
   
   1. Building disruptive model (product, service, etc) to later roll it out through the corporation (in this case the model is quite predefined and few variations in the plan are possible).
   2. Effective cash-out (probably not a first priority option for a corporate VC?) But in this case it allows to change and adjust the business model on the way.
6. How the venture is managed (operations and strategy)?
   1. Totally independent from the corporation but with its presence in the board.
   2. As a daughter enterprise (I excluded this case in the above but still want to hear how realistic it is).
7. When is good timing for the founders for asking money from the enterprise? Is there any difference in the approaches from the typical startups?
   1. The more model, prototype, product is ready the better - less dilution to expect.
   2. It's a "family" business and it doesn't really matter when to ask money - as soon as the idea can win the hearts and brains of the enterprise the founders should pitch it.
8. Should there be other VC and if yes on which phases?
   1. No. The corporate locks it out completely for others to join.
   2. Yes. The founders should be advocating for retaining such an option.
9. What other conditions should founders be aware of that are relevant only for internal ventures (both positive and negative)?
10. What other questions I forgot to ask?

What do you think?

Update: First Findings

Technorati tags: startup, corporate venture, internal startup

The best of my first 92 blogs

I'm reaching the first hundred of blogs (this one is the 93d) and I want to group and re-publish links to the ones I like most. I hope you've found them interesting too.

On entrepreneurship:

• Why to become a founder?
• Business intelligence, SOA, and your grocery shop
• Falling corporate startups
• How to make your startup a "cool to be working in" company?
• Mossad, French Legion, or Taliban - what does your company look like?

On career planning

• Three questions employee should periodically ask themselves
• Work with pros
• Your current job -"a time to kill, and a time to heal"
• Are you waiting for a week-end to end or to start?
• Evolving from a software engineer to...

On managing

• How to manage Squidward in your team?
• Who is the ideal boss?
• Whom to hire for startup?
• Getting good at giving feedback
• How many of your folks will be working for you in a year?

Random ideas

• Committed or tentative?
• IT/Business - how to talk the same language?
• Three pragmatic isolations
• Resetting the targets (05)
• Email culture

Blogging with different pace during this year and making a blog not focusing on a particular topic I've somehow got a small but firm readership and I want to thank you all for that. Hope you'll continue enjoying reading my second hundred of posts too.

Branding yourself

Career building becomes an important piece when we zoom into our thoughts about the job we're doing. We are encouraged by opportunities to get promoted, to enrich the resume by new achievements, to get new appealing challenges. But sometimes people pay too much attention to this (undoubtedly important) question and look at everything through the prism of career building and rewards. This behavior, of course, has a detrimental effect on their reputation and, eventually, on the desired promotion. How to not to get to extreme and find a right balance - is the topic of this blog.

• Don't push too much. My strong believe is your success depends 99% on luck. Also I'm a strong believer that everything is managed from the heavens so - don't push too much. Do what you can to build a stainless shiny brand of you and opportunities will find you in mysterious ways.
• Build the brand of a doer. Find what can be done in the given circumstances, criticize, suggest, but always complete a bemoan's speech by concrete suggestions and plans. Execute with excellence, complete what you start, and always make a project postmortem at the end (at least for yourself)
• Act like a SVP. Found this formulation in great advice from Dumb Little Man. Climbing career ladder is not only about getting promotion and higher salaries. It's about taking higher responsibility. Don't wait to be promoted to SVP. Start acting today as a hidden one. See what can be done and act properly.
• Work for the company. A mentor of mine went further and said work for the board of the company. But the idea is the same - think what should be done to make the company successful - not only what your group is after. Be creative with suggestions but don't go too far - suggest only pragmatic and practical things that you will start doing.
• Work for the boss of your boss. That's simple - make your boss happy by making his boss happy. He's the one who can remarkably promote you and he's the one who can reward your boss for delivered results - so you'll win anyway.

Don't be frustrated if your career doesn't advance with a desire pace. Much more important thing is to build your own brand as of one who addresses the problems, plans, and delivers. Your brand (read, your reputation) is the only long-time investment you have. Don't let it to catch a stain of a carper, or one who just plans, or one who starts but doesn't complete, or one who throws dust in eyes. I've seen so many colleagues that instead of making things happen on the current position worried about the next position, yet to come. Instead of promotions they got demoted, gained a reputation of unprofessional persons, and killed any opportunities to grow in the network of the people they've worked with.

Think about delivering and completing. Become a known doer and new opportunities will find you in a surprising way.

Technorati tags: career, promotion, gtd

What/Who SalesForce enforces by Apex?

The news that SalesForce.com announced its new language Apex has been echoed in the blogosphere for last week and the idea of yet another language has gained lots of criticism. People chew over the last step of the king of the SaaS world from all possible sides: how innovative it is, how significant it is, how known and repetitive (hinting to the ABAP success), and  even how SAP reacted to the news. I didn't read everything in the net on the topic but the ones, apparently, forget to answer the question why SF had no choice but to come with such an idea and what long-term targets SF sets for its business. I'll try to share with you my bet here what I suspect SF had in mind when it made this decision. Disclaimer: This blog, as all others published here, represents only my personal opinion and has nothing to do with SAP:-)

SF started its business and has been trumping its competitors with the SaaS philosophy. The impressive achievements of 0.5M users and 400 applications (regardless what we count as an application) makes the big guys (on-premise enterprise software vendors) nervous but, at the same time, leaves them and opponents of the on-demand application a few strong arguments why the SaaS model can't be accepted by some companies (at least for some applications and markets). I think the major obstacles on the way of a SaaS provider to grow are: 1) low customizability - I would call what they offer rather configurability, 2) high TCO for a big number of users, and 3) resistance of customers to deploy their data and/or processes outside of their data centers.

To address first problem a SaaS vendor has to equip its partners by some mighty tools. Nobody started a controversy on the reason for a language. But all platform providers have eventually to lock users by something: proprietary language, custom extensions, out-of-spec improvements - there must be a catch to not to let the users easy to go. SF decided to develop its own language (I doubt it will be as complex and powerful as Java or ABAP) but that's the ultimate level you can offer the lock mechanism to build on. It's always a trade-off between high bets with high risks and low bet with low risks (in case of SF to extend or directly use any of the widely adopted languages but not to gain a strong and short leash for the users). I don't want to discuss here merits and demerits of Apex and don't think it's really important. The step SF undertook to develop, promote a new language and empower the ecosystem (concurrently building it) deserves laudable comments from a business point of view. We'll see soon how successful its adoption will be.

To resolve the last two problems (high cost of ownership for a big user base and out-of-house deployment) SF eventually will need to offer on-premise solutions. Although they build the success on the anti-in-house applications thesis the pie of in-house developed applications is huge not to dream of it. I think it will be a hybrid model of both options where a dominant role of SF will maybe remain on the hosted side. But similarly to our move with CRM on-demand and Oracle's on-demand solutions SF and other hosting vendors will have no choice but to invade our patrimony of in-house deployment and start selling their platforms with a "buy-own-and-maintain" principle. Without a powerful [enough] language even to dream about that is a sing of a disease.

To reiterate, I think SF has a very ambitious targets on scaling up their partner ecosystem and building together with them new solutions for in-house deployment. The current success of 0.5M users may vanish as these users are not locked by SF's services at all. They got them fast and easy and they can lose them with the same epithets. To build a new level of success and become a player equal to the big guys they must accommodate the needs of customers equal to the big guys' ones. Without a powerful and locking mechanism it's impossible.

Evolving from a software engineer to ... Part III. Building the path.

In the previous two blogs (Introduction and Counting options) I've started contemplating on why one may want to start looking for something else besides a new technology and what options she can consider. This time I want to share with you my thoughts on how to approach the question in a practical way. You may build great theories and visualize the future in your dream but one day you ought to start planning and executing (in a plain language - deciding what to achieve in a 5-6 year span and start pursuing the target).

I've spent last months talking to my colleagues, bosses, and a few gurus I was lucky to hear an answer from on how they perceive the problem and its solutions. Also a few bloggers (Skip, Arun, and Daniel) left quite lengthy comments to my blogs. So in this blog I'll express the thoughts of many advisors I was happy to discuss the matter.

Before we shoot the bullet points one general comment. You have to decide what to want. I know, we started from here that it's obvious that nobody would ever make this decision for your life but after many words added to the blogosphere we're still there. It's your life and your decision. A few strategies though on how to find the right decision.

• Clustering professions.  All the options from the previous blog can be split on two major groups: you work within a team (managing people if we're talking about advancing on a career ladder) or working more a solo role (like a freelancer's consulting position or any manager that doesn't manage people). They may intermix (like managing people in consulting) but the stems are still separate. That's the first attempt to decide what you want - or maybe what you don't want. If you love working with people and are a team player maybe consulting is less attractive for you than, let's say, a product manager's position.

• Balancing the skills. You may scale your skills and find ones where you're strong and others, required additional development. You can accentuate and strengthen the strong ones or tighten up the weakest. Depending on how far you've done on the career path one of the tactics may be more applicable than the other. If you're under 35 then you have more time and freedom to try and experiment than one who's in his fifties. The eventual output for the mapping the skills may make you a sound guru in a narrow area or a shallow expert in many wide areas.
• Range of the investments.  The previous point deserves a bit more attention. Don't overestimate the importance of trying other things but keep in mind the departure and destination points. If you've spent 10 years in R&D and feel like lacking experience in business development maybe it's a bad idea to seek for a full-time position as a bused guy because you'll start all over again. Your existing experience won't apply much and other folks being in the profession for some time (even the same 10 years) are in a much better shape than you. It's OK to change the profession but apparently will be a way too far step aside just to gain experience and taste it from inside.
• Time of the investments. I'm not sure this point can be described precisely with numbers but when you're 25 or 45 your options vary. I'd suggest that by 35 you have to possess clear understanding on what you want if you haven't reached yet some significant toll gates. If you're in the mid of thirties you probably should more widely experiment with the options.

We're completing the series on the same point. Make a decision! It's again the same advice. Your life - your turn. Think about it a lot, read all you can, listen to all you respect, consult with anybody whose opinion makes sense for you, try to find a mentor (it can be much simpler than you think), make a two week disconnect-from-all vacation and make up your mind. You still can make a mistake but it's much better than going with the stream and do nothing. Experiment, change, and try again but manage it as the most critical project in your life.

"Life has no rehearsals, only performances"

Technorati tags: career, shift, change

Evolving from a software engineer to ... Part II. Counting options.

I the previous blog I wrote what questions and concerns came to my mind when I was lost in thoughts about future career plans, appealing positions, and challenging professional adventures. In this blog I'll try to list some options I've found beyond the pure coding positions. I count here what directions we can trace when coding is not enough. Confession: I don't say that such a phase is in a higher level on professional evolution but when it's happened (for a variety of reasons) you can't analyze how you "sank" into a situation when coding is boring, instead you're looking for  options to get further. For those who want to remain in the coding area and go the path I mentioned in the last blog (developer-architect-CTO) I hope every position on the right to his current is known. So the only uncertainty for beginning developers can hide behind a question  what a CTO does. These folks I point to a great blog on that by Skip.

Back to the list of options for others who's thinking of leaving the comfort zone of coding. The list is far from being complete, of course, but without a list it's impossible to prioritize, exclude, and project. So let's start (worth or reminding: we're off the purely technical thread here already).

• Project manager - a guy who manages. Shocked? Well, he manages a project (not people, or a budget, or a product). Checks that resources that given him in charge are sufficient, alerts higher management to shortages of the former ones or sliding on the schedule, removes roadblocks on the team's way, leads, motivates, cares about, and controls the team.
  
  Challenges: regardless of the project or the team size projects (in the software industry) rather fail than succeed. Planning and successfully compelling a project on time is not an easy task.
  
  Advantages: marching in step with project success and complexity one can gain and polish organizational and managerial skills. It's a management position and a bright experience may spring-board a good project manager to next levels on the career ladder.
  
  Disadvantages: the duties are confined by management only (no professional growth),  the subject of managing is projects (and hence project's resources, not people that have their own boss), often an always-under-pressure working mode.

• Product manager/Product definition*. Obviously, somebody who manages a product. The best description of the duties and requirements I've seen is written by Ken Norton. The range of duties and responsibilities may vary depending on company size and structure but this time your baby is a product (not people or a program). Regardless of the company size the position implies high responsibility and influence.
  
  *In my experience product definition team members were subordinates of a product (or solution) manager. I'd say product definition team's member is a journeyman of his product manager. Usually they did more focused work for the product manager where relationships between them were akin ones between developers and a team lead in R&D.
  
  Challenges: More than enough. The product is your baby and you define its fate. For all goods and bads happening with the product you're the address for praises and complains. You'll have to know and believe what the product should be and steer it through attacks of marketing, sales, investors, disappointed customers, happy customers, programmers, and so on.
  
  Advantages: A highly influential position with concrete, tangible results. A mixture of skills  and knowledge required to take such a position and being grown during the job is extensive indeed: business sight, planning, researching, strategic vision, still very technically-minded orientation, negotiation skills, leadership.
  
  Disadvantages: Since the role is very influential it comes with lots of responsibility and hence potentially stressful. For "generals" willing to command all the branches of army (read: marketing, sales, operations, R&D, etc.) a product manager may look too "shallow" . For these guys the only way is one level up - to the CEO.

• Consulting. You work for a company that "sells" you to teams either developing custom projects or customizing and configuring integration and application solutions. Typically involves customer interactions and traveling.
  
  Challenges. Even though you work for the company you have to be competitive to cope with the tasks. At the same time you're a solder of the army conquering billable hours (although there are some exceptions) of the client and you'll be lacking time for studying and preparation.
  
  Advantages: Shifting from development to consulting is like changing profession. You'll get exposure to customers, most likely will get many opportunities to grow soft skills, and, of course, you're supposed to earn much more money.
  
  Disadvantages: Risk to be outdated with the knowledge, possibly exorbitant travels, if technically speaking the topic is not challenging you may miss your development time very soon.

• Independent consultant/freelancer. Quite similar to the last one but not fully. Independent positions always get paid better and various risks involved with the independence are higher too. The shift from an in-staff position to a freelancer always leaves what you're doing for living the same - otherwise who will pay you for something where you're not an expert?
  
  Challenges: Be on the edge - whatever you're paid for today may not bring the same income tomorrow. Now it's up to you to invest in new things and take care of your learning plan. Customer relationships may be another challenge (depending on whether you did it in the past or not) - you have to hunt for new projects and customers.
  
  Advantages: You own you! With all ensuing consequences from here: higher income (even if not via a higher wage but absolutely via less taxes),  flexible working mode, flexible locations,  selectivity in choosing deals if you break out the mediocre zone.
  
  Disadvantages: You own you!  Sitting on bench now eats money from your pocket. Lacking time for studying new things may have a very detrimental effect in the future for new projects or high rate. Living in an always-hunting-mode can be stressful.
  

• Business development/marketing/sales. That's quite a radical shift from the R&D branch. Positions here deal with building value propositions, planning partner alliances, positioning products or services from a business perspective, and to pave the way for successful sales.
  
  Challenges. You hardly have a clue on the matter if you've been coding all your life. I deliberately put this position to the list simply to identify the business direction and meant to unite here the "fluffy" group of marketing, bizdev, and sales roles (as they look from behind a debugger) to show that this leap is possible although a very long one.
  
  Advantages.  If you hate coding that much that a role of a CEO, a CIO, or a business consultant keeps coming to your dream you should start meeting the business area from one of these roles. If your technical background overweights the lack of experience in business then you may find a path to jump on this train.
  
  Disadvantages. Even with 10 years of coding experience and taking positions of chief architects you start this way from scratch. You learn and earn your experience from level zero. Also your dreams may turn out to be illusions and from inside the business tasks can be worse than the used to seem from outside.

I tried to highlight major directions for career change. My experience doesn't allow me to claim any finality on the options but I hope the list is sufficient to brainstorm various trajectories for transcending the technical land. You're welcome to throw other destination points on the map and in the next blog I'll write about building a route minimizing risks.

Update: Building the path is the third blog in the series.

Technorati tags: career, shift, change

Evolving from a software engineer to ...

Our biggest experiment in life is our life itself - "life has no rehearsals, only performances". A huge part of it is our career. Non necessarily in terms of climbing a career ladder and reaching boss positions but rather as the longest project of ours, where a rollback operation may be very expensive.

Ten years ago when I started my career my future plans were very clear and precise. I knew that from a software engineer I could become one day a developer, and then an architect. To climb the highest position of an architect with all likelihood I had to become a team leader - that was (is) a standard practice and a relatively common way to get more interesting job, more responsibility, and usually more money. That was a career path for a techie. At a pinnacle of one's desire there could be a position of CTO. That was all.

In this primitive evolution path a question on what to do next (what position to wish, what skills to obtain, what new things to learn) wasn't quite a question. Moving around in the world of engineers was akin to driving a trolleybus: your have some place for maneuver on a line (let alone a huge number of lines) but only as soon as the poles allow. Questions start if one thinks of mixing in business or managerial ingredients to the career. Then the driving turns into driving a bike, or a track, or even a F1 bolide - you gain much more diversity in your routes but it comes with a risk to get not where you hoped to. I admit that this analogy sounds silly and didn't mean to claim that the pure technology world is way too simple comparing to its business parallel. I meant to say that if you get off the technology track then the variety of options for your career is such infinite that this fact demands from you more thinking, planning (both long- and short-terms), and more caution; it also comes with more risks and less known.

I've got off the solely technology track about two years ago when I joined SAP ans shifted from software development (actually a code-generating group) to a group dealing with anything but coding. I feel like I've changed the profession and to go forward I need to answer a few questions:

• what do I want to do now (near-term view)?
• what can I dream of doing in 3-5 years (mid-term)?
• what do I leave for myself to think about in 10 years from now (long-term)?

I wrote about similar questions some time ago but looking at them through the prism of transitioning from a tetchier to a business guy/manger I see other questions very relevant too:

• how can I shift to a new position without starting from scratch and without loosing my previous experience?
• how should I invest in new skills/experience so that if I change my mind the investments will be still valuable?
• how to climb the career pick in a more pragmatic and less harmful way?

I'll be sharing my thoughts on the topic in coming blogs and will try to answer the questions as I perceive them now. I must confess that I have no answers yet. I rather will contemplate different options weighting positive and negative aspects and invite you to participate in the discussion.

Update: Counting options is the second blog in the series.

Update: Building the path is the third blog in the series.

Technorati tags: career, shift, change

Why and how to love lost deals?

You lost a deal. That happens. The more you try the more lost deals (in absolute numbers) you may have. It doesn't matter whether the lost is to a competitor or a prospect decided simply to freeze the deal - you didn't get a sale. How do you react to it on a practical level? Do you see it as an unfortunate even or as an opportunity to learn? Are you waiting for loses or afraid of them?

Lost deals are inevitable and they're only the symptoms of a disease that can fall out of the blue. You have if not to love them but at least be ready for them. A few ideas on how to organize a lab of studying infections on early stages of diseases.

• Don't let emotions prevail pragmatism. When a deal is lost squeeze all productive information out of this sad fact. Naturally, human  beings rush to forget sad stories and sales folks are not an exception. But from a pragmatic standpoint it's a huge opportunity to see what's going wrong.  Talk to the prospect or offer an option to leave feedback. Find out motives and reasons of the lost. Whether you do it in personal meetings or online have a system in place to collect and later analyze the data. Will Hermann has a distinct blog on how to make a lost analysis in direct sales.
• Found a system to research the collected data. Be ready not just emotionally to collect the data but technically too. Have a system with questionnaires, guidelines on how to collect interviews, metrics to measure, aggregate, and analyze the information. Measure not for the sake of numbers but seeking for answers - adjust the system as the company's experience grows, add/clarify the questions to better address reasons, incentives, and circumstances of lost and won deals.
• Collect win data too. Try to minimize questions you should guess to answer. The more complete and accurate your data from the fields the better.  If you know why you lose don't you deserve to know why you win? Besides this merely practical factor there is a bonus here - collecting information about won deals is a much more attractive task.
• Measure everything. It's not actually about lost deals or a practice in the sales department. The sales folks have an obvious advantage over a group professional services,  R&D, marketing, operations, or any other. The advantage is it's clear what to measure when a patient is death (read - a deal is lost). Although lost deals happen in consulting too they're less natural and typically a real failure. Hence you should research and analyze the situation in other departments on much earlier phases by still conducting interviews with various groups crossing with the analyzed group. Any repetitive activity can be measured, recorded, and monitored.
• Assign a lost manager. When you sell as planned, studying lost deals is a kind of a side activity: it's always great to check on what to polish to sell more. But if the situation is worse than expected finding trends and tendencies is not enough. You should get an analysis with concrete recommendations, and probably a resolution. Here a lost deal manager with enough authority and power to change the situation should be assigned. Of course, it's applicable not to sales but to all the groups we mentioned above.

Interesting how rare management sees "lost analysis" an activity worth to invest time, resources, and money. But when a clear picture is desperately needed it's usually too late to come up with metrics to measure, systems to track, and experience and knowledge to analyze.

Kiko's death, Web2.0, and product strategy

Many have written an account already on why Kiko's train didn't fly - outsider's views were presented widely and two posts of Kiko employees (by Justin Kan and Richard White) added to the debriefing picture.

The huge interest Kiko's collected while being alive and quite the same, if not bigger, at its funeral procession is partly explained by big names among its fathers/founders (Y Combinator, 37Signals) and by the fact that Kiko was one of the first babies of Generation-W2.0 (bootstrapping, Ruby on Rails, Ajax, blog-based PR).

Reading the posts and the comments as a user still seeking for a good public calendar here is my impression on its failure and suggestions on how I think I'd overcome them.

• The strategy of Web2.0 "release early, release often" can't be taken so literally. The guys shot all their powder too fast and too early when the product hadn't gain yet maturity and had been in a state when it couldn't make a "wow" effect. People that saw it instantly figured out lacking features and didn't want to come back later and check again. The idea of releasing early is to amass feedback from real users so the compromise between releasing to hear feedback and not scaring our new users is to do it in small groups of selected users (early adopters and evangelists).
  
• All mentioned the mantra "stay focused" and the product wasn't designed (or at least declared) as one pursuing clear market niche (offer an alternative to Outlook in small ventures, a calendar for private events, a calendar for mobile users, a calendar with integrated services). When the product gets to its 10th release you can combine and merge but the very first couple of releases have to be absolutely focused.
• As a consequence of the first two the lack of clear understanding of demand from the users. The guys said they changed the focus and replaced lots of planned features with the new ones (delaying release by two months). If you know what your users want it's harder to miss the expectations. Propose a limited number of features you can implement in following releases (as part of "release notes" of every release, including the very first) and let the users prioritize them. This exercise can work only with the group of evangelists selected very carefully and representing the yet to come masses (see the first item).
• Google didn't kill Kiko: "One of our biggest traffic days was when Google Calendar was released because we were mentioned in all the new stories as one of their top competitors" - Rick says. I wonder how many new users they got at these days, not how many clicks. He continues "30Boxes came out of nowhere" along with "Screenshots of Google calendar were leaked and posted all over the Internet". So GCal is not the only killer (maybe not a calculated) but 30Boxes (both calendars still seriously lack of features allowing me to consider switching from Outlook). It seems Kiko got into a direct competition with another running application and an application-ghost from a strong brand. Strategy and niche is all about a product. Technology, publicity, nice UI can't win the battle (especially if you don't know upfront who the competitors are). A strong trump plan can work only if  supported by a plan-B scenario.
• Execution on the plan didn't shine. Justin tells terrible stories about wasted months and too convenient (in an opposite meaning to productive) environment. No comments, execution is the mission of the boss.

It was a bright example of a not yet successful startup. Probably it's another prove that the old good common sense overweights any modern approaches and nothing may be taken for granted.

The team did their first shot and openly and honestly shared with us their experience. A failure is not to fail, it's not to try after a failure. Koko team, I wish you all the best with the ebay project, your future ventures and waiting to hearing from you soon.

Technorati tags: kiko, startup, web20

How many of your folks will be working for you in a year?

David Maister links to a very interesting article of Rachel Beanland where she lists 10 thought that a newly-hired grad had in mind about the job. As many on David's site pointed out in the comments I agree too that the topic is not about a generation's view or a view of less experiences employee. It's quite relevant for all of us - simply for people staying at the start of their career it's more dynamic and swift. Let me bring here the 10 thoughts along with my brief comments on how it relates to the hi-tech world.

1. The grad you just hired didn't have a hard time finding a job.
   I don't know the PR world but today for a programmer seeking a job the questions are  Where and What and How Much instead of If. Very relevant for the hi-tech realm and the relevancy grows along with the experience.
2. They know they're underpaid, and they won't put up with it longer than they have to.
   Maybe more aloud for newbies but definitely exists for mature people and definitely in hi-tech (where changing job once in 3-4 years is a kind of a norm). As a boss, keep your people paid well.
3. It's not taking them long to grow bored.
   I guess it's more relevant in the world of software and applicable for all ages and all levels of experience. A great boss must address this task as one of the foremost if she wants to retain the employee and make him excited and creative.
4. Even when they're happy, they're looking for another job.
   Probably this one dims with ages or experience. But seeking from good to better is human nature so the boss again should care and worry about making the employee not looking outside.
   
5. Their bosses aren't their mentors.
   That's universal. As I said, the ideal boss must know the balance between coaching and mentoring and what else can make one wanting to stop looking outside if not a desire to remain with the best boss?
   
6. Getting thrown into the work force is turning them into experienced pros before their time.
   In hi-tech they become quite experts even before earning a degree and finding first job. All they need to get a jump in salary is the formal stage or experience. The boss (just pragmatic, not even the ideal) should to take this step proactively and make review better sooner than later. The younger the employee the sooner think about that.
   
7. Some don't feel their universities prepared them for  the blending of public relations and marketing in the workplace.
   Hard to compare. In hi-tech practical experience means a lot and it barely strengthens the above reasons.
8. They're looking to find a balance between work and their personal lives.
   Here I doubt it's so similar. Yong geeks tend to spend all free time with computers anyway so I guess we have one threat less:-)
   
9. Many of them would love to become independent practitioners or start their own firms one day.
   Not sure that the independent is the key word in our realm. Even if an employee dreams about opening his own company one day it may help his boss to address #3 and offer new challenges that may enrich the employee's horizon and prepare him for future ventures.
10. They think they’ll stay in the communications profession, but not necessarily in public relations. 
    We probably have an analogy to this item with a comparison of startups and big corporations. Rather I would merge this item with #9.

As Rachel outlines, it's naturally for PR young pros to look outside and the 10 reasons are very real. I found it's concurring with the hi-tech world but am sur