How to be an Insanely SUCCESSFUL Software Manager
Expect the best, plan for the worst, and prepare to be surprised
I’ve realized as of late that I come home nearly every day (which, quite often is the next day) and do the following:
· Say something along the lines of “Phew, another fucking day.”
· Grab a can of chilled beer (brand does not matter, the more chilled, the better).
· Get back to work.
And this has been continuing like clockwork for the past 12 years, all through my travails as a software manager.
Management guru Henry Mintzberg once rightly observed,
“The great myth is the manager as orchestra conductor. It’s this idea of standing on a pedestal and you wave your baton and accounting comes in, and you wave it somewhere else and marketing chimes in with accounting, and they all sound very glorious.”
And the reality is that the orchestra being conducted is in a permanent rehearsal mode, where everything is going wrong.
In other words, life will never turn out the way you think it will. Anything; processes, people, technical glitches will always have the ability to turn your life into a living nightmare.
That is why the most important thing that you can do as a manager is to keep learning and improvising every single day.
And the good news is that during my journey, I was fortunate enough to collect some invaluable nuggets of wisdom that helped me to evolve into a better, more successful software manager.
And here are some of those pearls which are a must in every software manager’s arsenal.
Create a repeatable, reliable and resilient process for releasing software.
Jerry Moran nailed it when he said.
“Perfection has to do with the end product, but excellence has to do with the process.”
In many ways, Software and cathedrals are much the same — first we build them, then we pray.
But does it always have to be like that?
Efficient software should never depend on the whims and fancies of that one “whiz kid” developer you have. Instead, it should be the culmination of a well-oiled process that is repeatable, reliable and resilient against any change whatsoever.
Ultimately releasing software should be child’s play. It should be easy because you have tested every single part of the release process hundreds of times. It should be as easy as pressing a button. This finesse can only come by enforcing a process in place which is religiously followed by every single person in the team.
As a manager, your job is not that of a “guard dog” supervising the developers furiously. Your job is more like a “shepherd” who ensures that all the “sheep” (read software, hardware, and people) are aligned into a process that ensures giving maximum business value to the customer through your application.
Automate everything possible
Eliyahu Goldratt once said.
“Automation is good, so long as you know exactly where to put the machine.”
Humans are prone to errors. That is a fact of life. On the other hand, there are a lot of things a machine cannot do. The key is striking the right balance.
There are some things which are impossible to automate. Exploratory testing depends on experienced testers. Similarly, demonstrations of working software to user community require human intervention and approvals.
But having said that, list of things which cannot be automated is much smaller than people think. Acceptance tests can be automated. Database upgrades can be automated. Even network and firewall configurations can be automated. The key is to automate as much as you possibly can.
The point to be noted here is that, the first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. So don’t automate inefficient processes. That defeats the very purpose.
Keep everything in version control
Dexter Palmer hit it bang on the nail when he observed.
“The thing about memories wasn’t that many of them inevitably faded, but that repeated recall of the ones you remembered burnished them into shining, gorgeous lies.”
And these “shining, gorgeous lies” are the real reason for most of the heart burns, conflicts and blame games we encounter in our project when things cannot be proved with certainty.
Everything you need to build, deploy, test and release need to be kept under some form of version storage. This includes requirement documents, test scripts, test cases, libraries, tool-chains and so on. All these stuff should be version controlled and should be identifiable against any given build. Don’t leave to human memories. Memories are notoriously bad even for the best of humans.
Version controlled artifacts not only give you better control but also give you a great backup option to “revert” back in case things go wrong. It also provides a great self-help learning guide to any new person joining the team.
Do the Toughest activity frequently.
Jeff Humble has rightly said.
“If it hurts, do it more frequently, and bring the pain forward”
Perhaps this above statement cannot be understated and is one of the most important principles of successful software delivery.
If integration is a painful phase of your project, do it more frequently in small bits and alleviate the pain. If testing is a painful step in your project, don’t do it at the end; instead do it continuously right from day 1 of your project.
If application documentation is something which is “hated” throughout your project, do it as soon as a new feature is incorporated into your project. Make documentation as an integral part for “signing off” on the feature.
This whole approach requires discipline and a serious effort to achieve efficiency. Gradually work to approach the ideal; even small steps will deliver great benefits and act as a catalyst towards the ultimate goal of completing “subjugating” the pain forever.
Quality is Everything
Steve Jobs rightly observed when he said.
“Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”
There is nothing called “quality” phase in your project. Quality can never be an accident. It is always the result of intelligent effort and fanatic proactiveness. It is everybody’s responsibility.
“Build Quality in”, the famous motto given by Edward Deming should be the guiding principle of every single person working in the project. The earlier you catch defects, the cheaper they are to fix and the less the possibility that they might end up on the customer’s table. In the earlier point, I spoke about “bringing the pain forward”. The next step is to fix the pain immediately as soon as you see it.
As a manager, it is your primary responsibility to inculcate the non-negotiable culture within the team of “fixing defects” as soon as they are found. As Henry Ford has rightly said.
“Quality means doing it right when no one is looking.”
Everybody is Responsible for the final outcome.
Audrey Hepburn makes a great point when she says.
“I don’t believe in collective guilt, but I do believe in collective responsibility.”
“The unit testing was not done properly. The developer goofed up. What can I do?
“The tester did not capture this scenario. Not my problem”
“The business should have identified this scenario before signing off. Now they have to live with it”
Everybody wants to eat the cake but nobody wants to clean the mess after eating. If your project has such kinds of attitudes, it is a recipe for disaster even before it is completed.
In an ideal world, everybody within an organization should be aligned to its goals and people work together and help each other to meet them. However, the reality is obnoxiously bitter. So many projects have instances where developers throw their work over the wall to the testers. The testers throw work over the wall to operations and so on.
And when something goes wrong, people spend as much time blaming one another as they do fixing the defects that inevitably arise from such a siloed approach.
It is the manager’s responsibility to ensure everybody is involved right from the starting of the project. Create strong channels of communication and encourage discussions within teams. Once the barriers are down, the communication will happen continuously but it is an incremental process which takes time to establish and be efficient ultimately.
Bringing it all together
So, as you can see, good software managers need to juggle a myriad of tasks, teams, and priorities. They need to be effective communicators and technically adept, so they can interact with the development team and also speak clearly with customers and stakeholders. They need to be big-picture thinkers, all while balancing customer expectations with business needs and budget.
And last but not the least they need to be ADAPTABLE; Everything is in a constant state of change; the market, technology, customer preferences. If you don’t keep up, you won’t be successful for long.
As Denis Waitley has rightly summed up.
“Expect the best, plan for the worst, and prepare to be surprised.”
About the author-: