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.

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.

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:

,

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.

The Buck Stops Here

Shortly after becoming a manager, most managers realize that one of the advantages in this new situation is that you don't have to do everything by yourself. Some realize sooner or later that you actually cannot do everything by yourself (others somehow reach the conclusion that you don't need to do anything by yourself, but that's a different story). At this point you get to 'choose' which kind of a manger you want to be, I guess the scale can be set between micro-management and what I refer to as management by context.

I had a manager once who said that his entire job is to give us context (obviously, in the managing-down direction only. Managers do sideways and upwards management work too, but I'll concentrate on the down part). This also meant that conflicts and questions in his group shouldn't reach him, as he, in principle, do not want to give concrete guidance - the solutions should be reached within the group's scope, relying on and following the provided context. This may sound nice in theory, but practically this meant that it was very hard to reach any decision, mainly because there was no single point in the hierarchy who could and/or would take the responsibility for hard decisions.

It seems to me that this notion of providing context (and effectively nothing more) is the most extreme case of delegation, which got me thinking about the fine line between delegating tasks to achieve more and create synergy, to de-facto delegate core management responsibilities (like, for example, avoiding decision making when decision making is due).

Delegating stuff to your subordinates requires you to trust them in more than one way. You need to believe they are competent, you need to believe they will come to ask for help when they get stuck, but you also need to believe that they will learn and grow from this experience. That last point seems important to me, as delegation is not about the day-to-day tasks of your team, it's about the day-to-day task you have, which are inherently of the, well, managerial type. So, sharing your tasks with a person reporting to you gives him a chance to prove himself in an area he doesn't get to experience every day, usually out of his comfort zone and gives you both a chance to increase this assurance that he can take on bigger and bigger roles. However, I tend to think that not every managerial task should be delegated.

I tried to think of a definition for the kind of tasks you should avoid delegating on regular basis (there are cases, of course, where you would make an exception for that, more on this in a moment..), and I think an analogy could be outsourcing. A rule of thumb for outsourcing I learned is that you don't outsource your core business (one good reason for that is that your core business should hold your competitive advantage), and if we apply this for the manager role - this will mean you generally don't delegate core management functions. Some of those would probably be more obvious like performance reviews, salary related issues, and in general personal/private issues between you and your reports (by the way, there are organizations and positions which use the 'second in command' position to take care of some of the administrative stuff related to personal issues, but I think that's a spacial case). There are tasks which should be quite easy to delegate (and managers many times do) like departmental budget (internally), daily status reports, etc.

The exception for that rule would probably be in the case of 'growing' a replacement. During the initiation time, the person replacing the manager should ideally have the chance to experience all the aspects of the new position while the current manager serves as his mentor/backup/ghost. There could be a longer period before the actual initiation where a couple of candidates get to experience significant parts of the manager's role as a kind of a long examination of their capabilities (many organizations choose this approach officially).

I, personally, like delegating. One of the main reasons I wanted to become a manager was to be able to create something bigger than I could create by myself. I also like making decisions as a manager since I believe when it comes to your responsibilities you should envision the sign on Harry S. Truman's desk: "The Buck Stops Here".

  

iPhone development - continued..

So, last time I wrote about what you need to get started with iPhone development. I thought now would be a good time to talk about stuff I encountered along the way, which I guess almost anyone developing for iPhone would encounter eventually.

This time, let me focus on memory management. Objective-C uses reference counting for its memory management, and the version running on the iPhone does not have garbage collection (yes, this is so 90s..). Anyway, this forces the developer to actually think about what is being allocated, when and where. Apple has a guide about Objective-C memory management in its developers' resources, begin by reading it.. Assuming it's clear enough, the next thing to do is to actually check your program for leaks (if you're a beginner, there are leaks - trust me..). Luckily, Apple provides a tool along with its SDK called Leaks (here's one place where they didn't think they need to be original..), which tracks your program in runtime (on the actual device, actually, which is pretty cool and also recommended, as the device behaves differently than the simulator in some aspects, and memory is one of those..) and marks places with leaks. The tool is very nice, but in my opinion not the friendliest tool for beginners. One downside is - it can only detect flows you actually went through (obviously), and it's sometimes hard to determine what's the actual source of the leak. Still, if there's a leak during runtime and yo u passed through the leaking flow, this is your best chance to catch it.

One downside I didn't mention about the Leaks tool and which is not that obvious, is that even when you find a leak, it's not always obvious why are things behaving the way they are. It so happens that I found a great tool which does static analysis for Objective-C code, and the best thing about it is that when it finds bugs (memory leaks are bugs, duh..), it also explains why is that a bug. The tool is called Clang Static Analyzer and it's pretty straight forward to use - you download it, extract it, and then use two simple commands:

/path/to/clang/installation/scan-build xcodebuild

(This should be executed in your program's home directory).

Then, once this is done, a report will be generated and the last line in the verbose output of the build will have the report name, then simply execute>

/path/to/clang/installation/scan-view <report name>

Which will open a browser window with your report, links to the source files and cool embedded explanations. Once you do the fixes, execute the scan again and check there are no more errors.. note that the default behavior if there are no errors is not to generate a report at all..

So, that's it for now. More on the fun in iPhone development next time..