- Climbing Mt. Everest.
- Be a CEO of a successful company.
- Build the next Facebook
- Reinvent Shopping…
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?
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.
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)
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.
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”.
A while back, I assumed responsibility for an initiative which includes iPhone development. Having had to bootstrap the project, I went through the various stages of learning, technology choices, getting the right material and establishing the basic methodologies for developing mobile applications, specifically on iPhone, in a company. I will try to describe in this post some of the more interesting issues I encountered during the beginning of the development, hopefully it would save someone some time.
Let’s begin – just to make it clear, you better have a Mac to develop for iPhone. There are Hackintosh solutions with questionable legality, there are Terminal Server solutions (like Aqua Connect), and if your iPhone is jail-broken, you can even use it as the development platform (again, not an Apple legitimate method), but the best experience for the developer and probably the only Apple approved way of doing iPhone development.
So, after having a Mac around, the first thing someone beginning to develop on the iPhone platform should probably do is to register with the Apple Developer Connection. In addition to the basic resources you need, and assuming you plan to publish your stuff on the App Store (there are other, at the moment not ‘legitimate’, options to publish your application, I will not discuss them here), this is where you’ll get you certificates and keys to test your application on your device. Developing using the iPhone simulator is free, but deploying on an actual device will require you to pay, currently it’s $99 yearly subscription. If you plan to have a team of developers, choose the Team option (costs the same..), and if you’re a company, note that you’ll have to prove it (by sending Apple the relevant documents), this, too, will cost $99 per developer. The Enterprise registration is for development of Enterprise applications (not to be published on the App Store).
Once you’re done with that, you can start reading the relevant manuals, there’s a pretty good Objective-C (the language you use to develop on iPhone..) guide there, there are some other guides online (line here), and I personally recommend having a physical book around (Programming in Objective-C 2.0 is the one we’re using, and I think it’s very good). Having done most of my programming in other languages, I found some ‘weird’ aspects in Objective-C, but that’ll probably have to wait for another post.
Now that the basics are established, I found a great way to get acquainted with iPhone development is the Stanford online course. Although it doesn’t cover iPhone OS 3.0, in my opinion it’s a great starting point. I think it’s important to get to know the tools and the environment, maybe create a simple app (or try to) before going through the course (it’s probably the equivalent of doing the exercises given throughout the semester), but it really allows the beginner developer to close some holes which are hard to close when you’re just going through documents and online tutorials which, in many cases, have varying levels of assumptions on the knowledge of the reader. This course aims for beginners and tries to makes sure everyone knows their stuff by the end of it, regardless of their original background.
In addition to the Stanford course, again I found a physical book very helpful, and the best one I found is Beginning iPhone 3 Development, which both includes changes from iPhone OS 3.0 (complementing the Stanford stuff), and has some very common and good examples for iPhone applications.
Ok.. That’s the beginning. Right after that comes the part where you actually do stuff and hit some walls. I’ll try to describe some of the walls I hit and how I got around, over, under or through them in future posts (promises, promises..).
Update: I found this list of online resources from StackOverflow which looks very helpful..
I’ve been playing around with Twitter lately, and found the social aspects of it quite intriguing. In other social networks I participate in (like Facebook or LinkedIn), connections usually denotes there’s some kind of personal relationship (‘friendship’ based in Facebook or professional based in LinkedIn) between two individuals. In Twitter the most visible connection is the ‘follower’ notion, and at first I treated it with a similar approach as I do in other networks (meaning – being very selective as to who I follow and expecting only familiar faces in my followers).
Then (quite quickly, actually) I got the first unfamiliar person following me, and that got me thinking – cool, I’m interesting (that was my main motivation to following someone – I was actually interested in what they were saying..). I guess I thought it would be interesting to know this person who decided to follow me, so I followed back (and he did have a couple of thousands followers, so he must be an interesting person, right?).
A couple of days later two other people started following me (and I followed them in response), and then this little flow of followers started, and I was thinking to myself – why is this happening? I know I’m interesting :-), but how do this people know? Do they actually read what I’m writing? I know I couldn’t possibly keep following dozens of people, how could someone follow hundreds or thousands of people? What’s the point of all that?
Then I heard of someone proposing a prize for followers (something like that, there are others..), and it occurred to me that some (hopefully only some) of my followers are actually only following me because they expected me to follow back.. Not that I mind, but I figured if I follow that many people sooner or later (probably sooner) my incoming twitter stream will be a big haystack, and finding the needles will become increasingly hard..
So, I got to thinking, how can I maintain a large number of followed people while still noticing the interesting information? There are some tools out there like Twitter search or Filttr , there are #hashtags and Tweeter trends, but it’s not exactly what I’m looking for.. Here are some of my thoughts, I’m not sure if some or all of them are already implemented somehow, I’ll be happy to here:
I’d like a way to distinguish between ‘information’ tweets (something happened somewhere), ‘status tweets’ (I’m going to sleep..), ‘reference tweets’ (hey, look at this site..) and so on. I’m not sure if there’s a tool that does that, and obviously it requires cooperation from the tweeter himself (you need to mark your outgoing tweet under some category, and maybe it misses the point of quick updates..), although to some extent this could probably be done in the receiving end using some sort of a learning client (bayesian based?).
In addition, if I’m already following someone, I don’t really want to see retweets of that person in my list (in fact, I don’t want to see double retweets at all..). This should be easier to implement, I guess, though maybe what I actually want is add some client side learning here as well – mark tweets as ‘not interesting’ automatically?
Another thing is – it seems to me like ‘all tweets are created equal’, and that seems to work out well, but maybe you could have the ability to highlight/promote a tweet? I guess you’d have to limit the amount of promotions (per day? charge for them? charge over a threshold?), but if I know that someone (who I already follow) consciously marked something as more important, maybe I’ll give it more attention..