Software Development
Why project managers act like a frog in boiling hot water
Imagine a frog and then imagine a pan of boiling hot water. Now imagine that some crooked mind lifts the frog and puts it in the pan of boiling hot water. What do you think will happen? Yes, the frog will jump straight out of the pan within a faction of a second (if the lid of the pan is not closed).
Now imagine the same frog and a pan with room temperature water. Now imagine an even more crooked mind leaving the frog in that pan and putting that pan on a burner with a slow flame underneath it. What do you think will happen now? Yes, in this case the frog will not jump out but will feel at home in water.
Now, over time, the water in the pan will get warmer. What do you think frog will do? It will feel even more at home; feel happy at the warm water giving it a gentle massage to its skin & legs.
Now the crooked mind increases the flame and slowly the water starts getting warmer & warmer and then hot. What do you think the frog will do? As the water gets warmer, it will feel happier but it will not be able to realize when the water has become too uncomfortable for its own good. As the flame gets bigger underneath & water gets boiling hot, the frog will have lost all the energy in its legs to jump out. Its mind will tell to bail out but there won’t be any energy left in the frog and it will continue to be in the pan and face a slow death…
So, what has this got to do with project management & project managers?
Well, analyze carefully and you will realize that there is not much difference between a frog & the most project managers. There is also not much difference between the pan (with water) & the project environment. Most project managers, if asked to take over a project in between, would know how ‘hot or cold’ it is and then take appropriate action. This is just like the frog being put in hot water and it taking immediate action.
However, what most project managers don’t realize the 2nd scenario they land up in — where they start with water at room temperature & the water gets warmer at first and with the flame getting bigger over time the temperature under the collar gets soaring. At the start of the project, just like the water in the pan at room temperature, things look perfectly in control for the PM – a small team, key members staffed, not much confusion.
Things remain fine for some more time (till the water is warmer) but somewhere down the line things just implode and before the PM realizes things have gone out of hand (water is too hot, in the pan, for the frog to take any action). There are quality issues, builds are failing, customer is dis-satisfied, the team is unhappy & clueless, senior management is watching with eagle eyes, your family life is ruined and while driving to office you wonder how things came to be where they are today…
You wonder how & when that excellent Tech-Lead became a bottleneck & the go-to person for even small things – such as from where to setup the development environment or which version of IDE to be used with what plugins — you wonder why the leads are spending more time in answering routine questions & forwarding emails rather than doing their actual work. You wonder why the testing team doesn’t have access to the latest requirements in order to prepare the test cases. You wonder why the same question is being asked and answered a gzillion times. You wonder why customer wants you to resend the status update report of last month. You wonder when this project will end..!!!!
The fact is that we don’t realize or observe or are blind to the small changes happening around us and the long term impact of these small changes. Many downstream issues are caused by our inability to react to significant changes that occur gradually. And in today’s era, nobody pays attention to anything ‘small’ unless it is on fire or priority#1. Everybody loves a hero – a person who turns around a losing situation into a winning one (organizations reward people who get troubled projects back on track but not necessarily those who avoid trouble and go unnoticed.) Because changes (from room temperature to warm to hot to boiling hot) happen so slowly that they go unnoticed and you are then left to wonder where and when things went wrong.
The irony is that it is not just first time PM’s who fall for this. Experienced PM’s also fall into this over & over again and then blame the ‘system’. Great PM’s foresee & preempt the ‘upcoming changes’ and plan accordingly. They plan like good chess players – several moves in advance and multiple scenarios. They manage the environment of the project accordingly to prevent the effects of ‘global warming’ within the project. Such PM’s ensure satisfied customers, happy people and predictable outcomes.
So, how can PM’s foresee & preempt the ‘upcoming small changes’ and prepare well? What can they do? That’s for another post 🙂
Are you a developer without a side-project??
Shania Twain would have sung: ‘Ok, so you are a software developer in the IT industry? That don’t impress me much..’
The reality of software industry is that 9/10 times you will not get to work on the technologies that you are interested in. Even if you are lucky to work in the area of your choice, chances are that you may be working on the older versions of the technology. Every day there are more and more cutting edge technologies coming out and how do you, as a software professional, get to work on them?
Suppose, you want to keep your skillset upto date(for various reasons :-)) & want to learn new technologies and skills. How do you get about that? The reality is that opportunities are limited and if you just wait for opportunities to come to by; time will run by.!!!
OK, time for a pop quiz: When was the last time you created an application/software from scratch? Most projects require package implementations, maintenance work, adding new features, fixing bugs, etc. Even in the few projects where applications are built from scratch, you would be part of a large team and not creating software all by yourself.
So, what can a software developer do that will impress Shania Twain?
Enter Side Projects: Call them pet-projects, side-projects, pickle-projects, etc whatever.. In a nut-shell, they are projects that you do for yourself. They are a great place to do all you want with no one else asking you to do this or that. Side-projects will allow you to work on the technologies that you want to work on, problem statements that you want to solve — at your pace & leisure without any pressure of worrying about bugs or performance issues. It’s perfectly ok if the side-project build crashes 10 times a day and has a few bugs here and there.
Side-projects will allow you to work towards creating software that you are passionate about, something that you enjoy working on. Yes, side-projects can bring the fun back into programing and can also help prevent the burn-outs that one can encounter while working on customer projects/areas that one is not passionate about.
Side-projects can help you keep up-to-date with latest technologies & emerging trends in software development. You can try out the bleeding edge of software for yourself. Never written a jQuery +CSS3 + HTML5 code yourself? No problem, just start a small side-project using it and soon you can have something to show off as proof of your newly acquired skills. (and this can help you in ways that you can’t even imagine :-))
Having your side-projects will force you to think of your software from scratch. You will need to think of design issues performance issues. You will have to think of trade-offs and make ‘this-vs-that’ decisions. Your side-projects allow you to program in an exploratory way which allows you to take paths that you would have normally not done in your work projects. You can try out different algorithms, logic and see what happens without any worry in the world. Your side-projects will also allow you to incorporate all your past learning’s into creating a new (and improved) project.
And you know what; all said and done, real programming & coding is an art, a creative process that can take you onto a ‘zone’. A ‘zone’ where things just flow… and to get into the zone, you need to be working on code that you are passionate about and may not necessarily come from coding what your day job code requires.
But yes, just like nature, nothing worthwhile will come without its own set of challenges. Yes, you will face challenges in your side-projects.
The biggest challenge to your side-projects will come from your losing interest in your side-project. You will have all the enthusiasm at the start but slowly you could end up skipping days and procrastinating the work to tomorrow. Before you know, two months later you would have forgotten about it.
You will have pressure of time. You may be tempted to say that you don’t have time… but you know what? Most of us complain about not having enough time. The truth is, we have enough time to do whatever we want, but we’re not willing to make the sacrifices to do it. Yes, you’ll have to sacrifice good things for great things.
So, what are you waiting for… Get that side-project going…!!!
What do you want? User adoption or compliance?
I believe that successful KM initiatives & professionals pay a great deal of importance to the change management aspects. If, there is one place where “build it and they will come” doesn’t work, it is KM. After all, users are tuned to a way or working and majority of them would resist any kind of change. It’s a natural reaction and for various reasons a very tricky area to deal with.
Now to counter this tricky area of change management, KM initiatives/professionals rely on approaches which could be counter-productive to what their intentions are. Once such approach, that is commonly adopted is the “top down” mandated approach. On the surface of it, this looks simple, obvious, fast, scalable, logical and the most powerful approach that one can envision. What could be better than the top most management sending out a ‘memo’ asking people to do things a certain way.
I have seen this approach and have observed that this works best when you need ‘compliance’. Areas such as ‘time sheet entry’, ‘filing expenses’ etc are best suited for this approach. Anything transactional can be rolled out on a mass scale using this approach.
The issue arises when you try & roll out KM initiatives with this compliance driven/top-down method. Chances are that more often than not this will not yield the desired results and one can get in a vicious cycle of asking for more ‘top down compliance support’. This can frustrate the hell out of people who are leading these change management initiatives as they can’t fathom why on earth the seemingly obvious method of top down/compliance driven approach is not working.
We all know the results of a top down approach that mandates submission of 2 documents to the knowledge repository every quarter by each employee. On the last week of the quarter you will have a deluge of submissions and most of them would be not worth the bytes contained in them.
On the other hand, KM initiatives/professionals that rely on the adoption approach have greater chances of success. On the surface of it, the adoption approach looks to be an insurmountable obstacle but with patience & a long view of time this can be achieved. Adoption happens when people ‘buy into’ things and not because they are being ‘told to do so’. Adoption happens because people see that things actually help them, appeal to them on an emotive/cognitive wavelength. Adoption happens when people, who we trust, tell us that it is good, they are using it & it makes sense. Adoption happens ‘through’ people… (We adopted facebook, twitter etc using these principles of adoption.)
The key to adoption approach also lies in finding the right set of people, who you will work with initially. They are going to be your evangelist and believe me they will be like customers who “tell 1 more person, at best, if they satisfied and will tell 100 people if they are not satisfied”. Starting the process of adoption is slow and takes time. However the growth over time can be exponential and usually has a more stable foundation which is not only dependent on ‘top down’ directives. Adoption approach is akin to trying to move a heavy flywheel… lots of effort & commitment is required initially to even move the flywheel but as the revolutions go by the speed increases and over time the flywheel literally moves on an auto-pilot mode.
I have also observed that a combination of adoption (at a macro level) & top-down (at a micro level) also works in several circumstances. The key is in knowing which one to use when and for what. And that’s comes from experience & losing your hair over the years 🙂
Compliance is best achieved through systems & adoption is best achieved through people. So, if you need compliance of initiatives then build systems that monitor themselves for the compliance automatically. However; if you need adoption then be prepared for the long haul & work with people
Do processes kill developer passion?
Two interesting pieces of content i read on the internet, around programming, that I would like to share
An O’reilly article that says ‘Best practices sound good in isolation, but they can suck the life out of developers...’
O’Reilly Radar argues that excessive process in software development is sucking the life out of passionate developers, all in the name of making sure that ‘good code’ gets written. ‘The underlying feedback loop making this progressively worse is that passionate programmers write great code, but process kills passion. Disaffected programmers write poor code, and poor code makes management add more process in an attempt to “make” their programmers write good code. That just makes morale worse, and so on.'”
http://radar.oreilly.com/2011/05/process-kills-developer-passion.html
My take is that the time for these processes need to be budgeted in the development process itself. If we don’t then we may not get the benefits of these processes. To be fair, even the O’reilly article doesn’t make a case for the ‘wild-wild west’ kind of chaotic programming. What I found even more interesting than the article itself was the comments on that article. Makes for a pretty interesting read.
The other question I had was: combined together, with all these best practices to be followed, do developers even get time to code? Here is a humorous take on what programmers eventually spend their time on
http://www.mrclay.org/2011/04/01/programming-is/
Not all of the above is true but it kind of makes the point 🙂
So, what’s your take on this subject? Are these & a hundred other industry ‘best practices’ a great idea. Or do they ‘in isolation‘ make a great case but lose out when chained together and become an unnecessary overhead leaving little time for developers to be innovative and creative?