Endurance Learning

“Judge each day by the seeds you plant, not the harvest you reap”

Teaching your child to ride on a bicycle is very fulfilling, but can also be frustrating to both you and your child. This is a learning path with very little shortcuts. Your child can’t just nod and say “I got you”. She actually needs to get on that bike and ride. And stop. And not fall… and falling hurts… And pulling through those falls require, sometimes for the first time in your child’s adult life, to trust you that your teaching will work. That it’s ok that they fell, and that although it seems hard and painful, the outcome will be worth it. “Remeber now that it’s hard”, I told my son when teaching him to ride his bike, “remember now, and when you ride your bicycle freely and enjoy it – look back and say ‘it was worth it'”.

When facing a complex subject or a problem, a common pattern for dealing with it is called http://diplateevo.com/2013/01/forecasting-confidence-levels-with-the-bipolar-learning-graph/. Getting the basic concepts is easy (you put your hands on the handlebar, your legs on the pedals, and go…), but then you fall… and even when you are able to ride a little, it’s hard and not fun. But then – you get it. And then your confidence grows, and then you become proficient and effective (and enjoy). The problem is, if you don’t believe in the path, it’s very easy to drop just before you get to the ‘infection point’.

If you manage people, you many times act as their mentor and teacher. And sometimes it’s hard to explain why things are not adding up, and why success seem far away. And your people need to trust you that you lead them towards the right direction. When a project fails (and projects fail…), you hopefully look back and learn, aiming to improve the next time. But when a project succeeds – remind them that it was not trivial. That it succeeded because they endured through the process, and did not give up when it was hard. And now they can enjoy the ride…

Lucky Generals

“I would rather have a general who was lucky than one who was good” (Napoleon Bonaparte)

I thought of this saying, and it seemed weird to me on a few levels:
  • Luck is not something you can build on, not in life, not in business, definitely not in war… It can be with you, and it can go with someone else…
  • Isn’t it that when you’re good, luck is not a factor? Invest in your infrastructure, make sure you have alternate plans, and then ‘luck has nothing to do with it’…
  • Luck has a sense of subjectivity (how do you define a lucky person? if someone won the lottery, but also has a chronic sickness, are they lucky?). “One man’s loss is another man’s gain” and vice versa…

So after pondering about it some more, I realized that:
  • Some people believe that if they only had the right break, a little more luck, they could have been in a much better place. Maybe…
  • Many people wish for/fantasize about a Cinderella story, where all you need is for your foot to fit in the right shoe, and you’ll live happily ever after…
    • (but forget that Cinderella had difficult life until then, which didn’t stop her from believing, working hard, and also having the talent to impress a prince when the opportunity finally arrived).


  • Many successful people attribute at least part of their success to luck (external factors) while connecting their failures to themselves (internal factors). This is related (though not exactly) to Defensive Pessimism.

The Lucky Generals, the ones who understand success requires both work and luck, and understand their focus should be internal in order to recover and learn from failures, are the ones you want on board. Those people will be there at the right moment to pick up the ball and make the best out of the opportunity, which will serve both them and their surroundings best.

Engineering Managers Should Code 31% of Their Time

I think the saying shouldn’t be “Managers should code X% of their time”. That’s just a tabloid/provocative headline, and it’s about getting a higher CTR (I took it one step further, ha!)…
This is about what you base your leadership on.
Leadership can come from a lot of places:
  • You can be the most charismatic guy in the room.
  • You may have superior technical skills.
  • You can have awesome interpersonal skills and the ability to find what drives any other person.
  • You may have all the right answers and be great in prioritizing tasks.
  • Or very big balls…
In many cases, leadership is about a combination of the above (not limited to it, obviously).
What I strongly believe in, is that you can’t be a great leader and an excellent manager if there’s not a minimal amount of each ingredient.
  • If you don’t have any charisma – you’re a handicapped leader.
  • If you have no clue regarding the technology your team is using – you’re a handicapped manager.
  • If you lack interpersonal skills – you’re handicapped.
  • If you can’t say what’s right and what’s next – handicapped.
  • No guts? Handicapped…
Choose your strengths, make them stronger… but don’t ignore your weaknesses! No one wants to follow a handicapped leader (and with no followers, who will you lead?)


Goals are a good thing. You feel motivated to pursue them, you feel satisfied when you reach them.
You probably heard about SMART goals. If not, here’s a good place to start: http://en.wikipedia.org/wiki/SMART_criteria
For your yearly planning or retrospective, SMART goals are a good tool to use.
Here’s a thought I had: you owe yourself a BFG (patent pending, but inspiration comes from http://en.wikipedia.org/wiki/BFG_(weapon)). A Big Freaking Goal (I know, it’s not freaking originally, but I aim towards young readers as well…).
Anyone needs at least one BFG. You don’t want to have too many of those, as they’re big, barely achievable (if you tell to other people about your BFG, they might thing you’re crazy or disconnected or immature or over ambitious or, well, you get the point), but it’s your BFG.
Maybe an example or two would help here:

  • Climbing Mt. Everest.
  • Be a CEO of a successful company.
  • Build the next Facebook
  • Reinvent Shopping…
A good method to distinguish a BFG from your regular SMART goal is that it’s a goal that you can’t see what happens after you achieve it.
You can’t imagine yourself taking the next step beyond your BFG. It’s just that big.
But it’ll be something you wake up in the morning, anticipating, thinking what you can do today to take one more step towards your BFG. In my world, that’s a good thing…


Some people say they like to be surprised. Sometimes it can be fun, really.

Most people don’t like to be surprised, though, especially not in their ‘professional life’. Surprises are rarely good nor fun…

There’s an old saying (well, not really old, not much of a saying) which goes something like: “If you don’t want to be surprised, don’t surprise others”.

The surprises I’m talking about can be many. For example, but not limited to:

  • You’re going to miss a deadline.
  • Your availability is going to change dramatically (going on a long vacation, for example)
  • You need to change an agreed understanding between you and a peer.
  • And more..

All of the above can be handled and nothing catastrophic will happen (probably), but the sooner your peers/managers learn about it, the better they can help you (and themselves) deal with the results.

You can also choose to not communicate the news because, hey, it’s going to happen anyway and you can handle it alone (and why bother others so early in advance), but then you might be surprised by their response once they learn about it in the last minute (or a little afterwards).

And as already mentioned above – if you don’t want to be surprised, don’t surprise others…


How to never fail

In rock climbing, courses are graded based on their difficulty, and in general, the higher the grade the harder the course. There are several grading scales, where one of the popular ones is the Yosemite Decimal System. On that scale, the 5.12 grade is considered magical, and for many intermediate climbers it is considered to be out of reach.

Climbing - fall

For climbers aiming to beat the challenge of climbing a 5.12 wall, one of the more important lessons is: fall. The fear of falling during the climb stops you from trying difficult moves, keeps you from testing your limits and eventually prevents you from pushing your performance envelope. So – fall. Again and again, first in a controlled environment where you know nothing bad will happen, then fall from a little higher (you’re always connected to the rope, and you must always follow all safety procedures) – but trust your equipment and, more importantly, trust yourself.

shooting yourself in the foot.jpg

In Software development, there are many ways you can fail – you could miss deadlines, you could have bugs, the project could exceed its budget, the customer may not be happy with the results, and it could be all of the above. So we add guards – we create a project plan, get a bug tracking system in place, do automatic testing, make sure there are reviews and reviews of reviews, get a project manager, a program manager a product manager and development manager, make sure they all meet and update each other regularly, and we then add the secret ingredient – a buffer.

What’s good about buffers is that you can never have too many of them. And if you fail, the easiest way to learn from your mistake is: add some more buffers next time. The problem is, in my view, that we’re getting too used to buffers. At times we don’t even remember why we added some of them to begin with, we just know that if we don’t do another review, get another meeting in place or add some extra time – something really bad is going to happen.


No one likes it when bad things happen to them. No one like to fall. It hurts, and you could get injured. But aren’t we missing an opportunity to learn what we can really do? Isn’t adding another buffer a dangerous block to seeing what our limits really are?


I realize there are many open questions here (like: are the customers willing to pay for you taking extra risks, and should they? can you actually control the amount of risk being taken without getting yourself killed in the process?). It may be that when things get complicated enough, when the project becomes big enough, you just have to add brakes and balances, or you will cause more damage than good. But does it mean we have to give up on our full potential at this point?

Building a Great Mobile Team – Personal Thoughts

A while back I read a great blog post by Elad Gil who kick started Google’s Mobile efforts (see link for the full post).


In the past 1.5 years we built our own mobile group in SHC Israel, and while I can definitely relate to much of what the blog post describes, I will list here a few points where I view things differently.

  • Hire great athletes; mobile “experts” will be useless in 6 months.

This is a very general saying, I’d even go further and say that if you find a ‘great athlete’ – hire him. However, I believe we are now in a different environment than even 2-3 years ago, mostly because today there ARE mobile experts. As iPhone and Android are no more than 3 years young, obviously that time ago you couldn’t find any subject experts, and when you looked for ‘mobile people’ your applicants usually had a not really relevant WAP experience at best or low-level cellular networks level in other cases. These days, if you can find people with 1-2 years of real iPhone experience or even better – who actually released something meaningful to the App Store, this could really help you boost your team level.

  • Don’t hire mobile Product Managers.

Pretty much the same as above, a great Product Manager is hard to find – if you find an all-around great PM, chances are he’ll do a great job in the mobile area as well. Here’s the thing – I believe PMs need to ‘live’ their product. If your PM is not an iPhone experienced user, the chances of him defining a great product are not promising. The relevance of real Product experience become more relevant as the mobile development industry matures, obviously.

  • You must build for all platforms from day one.

I definitely agree that you shouldn’t spread yourself thin and develop on all platforms, especially if you have limited resources. There are ‘magic solutions’ which supposedly let you build once and run on any device – I’m yet to see a good solution for that (it may run, but usability will be questionable in most cases. I’m not saying it’s not possible, I just didn’t see any). Choosing eitherAndroid or iPhone is, as the post says, a good bet. Personally, I think iPhone is a better bet as a start, if only because of Android’s fragmentation, both in the device types and deployed OSes. This may change (the starting point) in the future, though.

So, one of your employees think they have a great idea…

In a marketing book I once read (entitled Marketing Managment (2000), by Prof. Jacob Hornik and Prof. Phillip Kotler) there’s a chapter about introducing a change into an organization.

Besides discussing various ways to do that, the chapter also talks about the forces fighting the change, and brings a list of ‘common yet effective ways to fight change’, here it is:

Employee: “I have a great idea!”

Manager – quickly choose one or more of the following responses:

  • It will never work for this organization.
  • We tried it before.
  • This is not the right time.
  • It can’t be done.
  • We don’t work that way.
  • We’re doing great without this.
  • It’s too expensive.
  • Let’s discuss this in our next meeting.

Management and Momentum

There are many roles a manager needs to fill. The manager is accountable for the team’s goals, helping individuals perform, give feedback and measure performance, act as a mentor and a leader, make decisions and, well, more…

When I ask other managers how they see their role, the answers vary, covering some of the points I mentioned above and others as well. People who practice agile methodologies mention on many occasions that one of the important roles of a manager is to clear the path for the team, so they can do their magic.

While I agree with and can relate to most of the various roles, there is one aspect of the day-to-day managerial work which I didn’t get to hear much, and it’s about momentum.

Once things are in motion, it’s relatively easy to maintain movement (yes, you still need to clear the path so you won’t lose momentum), but it can be tricky to set them into motion. It can at times be even harder to increase the speed (somehow slowing down usually gets done by itself).

As a mangaer, you are where people look to. If they see you moving, they are more likely to move. If they see you just sitting there they may think it’s ok to slow down a little. If they see you running and they trust you know what you’re doing, chances are they will run as well.

I’ve been in companies where from time to time they’d gather an all-hands meeting and say ‘we’re facing some challenging goals, it’s going to be a tough period, brace your selves and let your spouses know: you’re going to be working hard’. Much more often than not, this ‘fake sense of urgency’ achieved exactly the opposite. I worked hardest when the leaders of the organization made me feel they are invested in the goal at least as much as I am (and much more). And it’s not just about staying late or working weekends, it’s about constant involvement and actual care about what’s going on. You can’t be managing from your closed-door office. You want to be out there, in the trenches, with the people. You are the flywheel.


As the flywheel, you begin spinning. Your subordinates will catch momentum, spin around you and spin themselves. Their subordinates will follow. Sounds easy, right?

Momentum is a great thing to have – in physics it’s directly related to energy, I think it’s true for management as well.


if you’re interested, kinetic energy is calculated like so:

E_k=frac{1}{2}cdot Icdot omega^2,

where ω is the angular velocity, and I is the moment of inertia of the mass about the center of rotation. The moment of inertia is the measure resistance to torque applied on a spinning object (i.e. the higher the moment of inertia, the slower it will spin after being applied a given force)

[from Wikipedia]


Team of Stars or a Star Team

One of the more exciting experiences I can think of as a manager is the opportunity to build a new team. Besides the chance to face new challenges, it has this feeling of going back to school after the summer vacation, with new books, new equipment and the feeling that you can be the best at what you do (well, now that you have new pencils!). In reality, though, recruiting in general and creating a team from scratch (or almost scratch) specifically is a very challenging task, and mistakes in that process could have a major impact later.

Even before you begin recruiting, you need to come up with a job description – besides being the baseline for the expectation setting between you and the candidates, the job description also serves as an initial sieve for the incoming flow of CVs. Set the requirements too high, and you may be losing good candidates (either because they feel intimidated or because they don’t meet a requirement you may be willing to compromise on – if you knew they were great in all the other stuff), but set them too low and you may be swamped with irrelevant CVs and spend most of your valuable time talking to the ‘wrong’ people. In order to understand where the bar should be set, I think there’s an important question you need to ask yourself – are you looking for a team of stars, or are you aiming to create a star team?

I think the answer is not trivial. Moreover, there are probably points in time where you’d be leaning towards recruiting stars and other times where you’ll be recruiting people to build a ‘star team’ (where no one in the team is necessarily a ‘star’ on his own).

For example, in a startup environment, probably in the early stages, where the team is very small, technological excellence is in many cases key for success and certain superb aspects of the product might be the difference between success and failure, you may want to have the star people who will be able to solely solve in innovative methods any given problem and make this one great feature which will make your product more attractive than the competition.

I think that once the team grows it both becomes harder to maintain an all-star team (there is more maintenance that needs to be done and less innovative work, there are increasing amounts of bugs that need to be solved, there’s more documentation to be created, and so on), and delivering quality software based on the customers requests, on time, is at least as important as innovation. The ability to share tasks, knowledge and ownership of a large codebase becomes critical to the team’s functionality. At this point you’ll still want to hire excellent engineers, but I believe you’ll want those who will appreciate the chance of being a part of something great, knowing that the fact that they belong to a star team actually makes them better engineers in the long run, giving them the chance to become that star engineer in (hopefully) their own startup in the future.

I enjoy working with smart people, as it gives me the chance to keep learning every day. I enjoy it less when the brilliant people I came to work with turn out to be brilliant jerks . I don’t think it’s an easy decision when you need to choose between a brilliant jerk and ‘just’ a great engineer. It becomes even harder when the brilliant guy, who already knows every bit and byte in your code has a negative effect on the entire team. If you want a great team, I doubt there’s room for that kind.

My bottom line is probably obvious by now – I believe in synergy, in potential and in giving the right people the chance to grow. I’ll take that star team, thank you.