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..

iPhone development - the beginning

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..

Why are you following me?

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..