Why don't we invest more energy into preventing fires and less into fighting them?
I would upvote this 500 times if I could.
I was a homemaker and homeschooling mom for many years, so I had enormous power to say "Okay, I'm done with this stupidity. How do we fix it once and for all?" and then making it happen. Thus I have a rather low threshold of tolerance for the slow bureaucratic process at work. I am currently on a pilot team that handles complaint files and I have tried to actively advocate for more fire prevention, less fire fighting. I think we are getting some good things done but I still feel there is too little emphasis on fire-prevention activities.
Sorry for, oops, deleting my earlier version of this post a hair before your reply showed up.
No worries. My reply was basically to say that I know what to say to make my case, but I don't know how to make the CTO listen. This is his first CTO position, and up until August he was the only developer, so a lot of bad practices we have (e.g. no process whatsoever) are holdovers from the way he worked for a year and change. The obvious problem is that working alone dodges an awful lot of problems that arise when you have to work together. Now, we're running into these problems but the CTO isn't dealing with them - he just disengages whenever they get brought up and says something like "You're right, that's important, but first let's work on ...". Quite frustrating.
FWIW: If you have a solution rather than a complaint, that tends to go over better and has more hope of being acted upon. Also, I have found that opportunistically grabbing people in the break room (by themselves, with no one around) and talking for a minute is sometimes way more effective than the formal process I am supposed to go through (proviso: I am not in IT).
To be fair, this is not an easy transition to make, if good processes weren't started from day one, which is the standard state of most early startup technical projects.
Everything from source control commit logging, to conflict resolution, to development database snapshot sanitation scripts, to audit/error log management, to configuration management, to compliance, to QA handoff, to deployment automation, etc. These things are not trivial to begin working on while training new hires, working on new feature requests and existing bug lists, at a time when 99% of domain knowledge is in that person's head. And all of them are necessary for your CTO to be able to delegate effectively for his role.
Not knowing anything about your exact situation, my guess is that none of these things were properly set up from the beginning, and now your CTO is faced with nearly impossible circumstances that he's either unwilling or embarrassed to acknowledge. He may believe that trying to explain to the other stakeholders about the importance of process and technical debt reduction will go over poorly in the face of increasing business requirements that must be done nownownow. Horrible approach, but it happens, and happens often.
Comments
* Why don't we invest more energy into preventing fires and less into fighting them?
* How many times must I recommend approach A only to be told to try approach B, and then when approach B doesn't work be told to implement A?
* When is our CTO going to step out of the "first developer" role and into something approximating technical leadership?
Why don't we invest more energy into preventing fires and less into fighting them?
I would upvote this 500 times if I could.
I was a homemaker and homeschooling mom for many years, so I had enormous power to say "Okay, I'm done with this stupidity. How do we fix it once and for all?" and then making it happen. Thus I have a rather low threshold of tolerance for the slow bureaucratic process at work. I am currently on a pilot team that handles complaint files and I have tried to actively advocate for more fire prevention, less fire fighting. I think we are getting some good things done but I still feel there is too little emphasis on fire-prevention activities.
Sorry for, oops, deleting my earlier version of this post a hair before your reply showed up.
No worries. My reply was basically to say that I know what to say to make my case, but I don't know how to make the CTO listen. This is his first CTO position, and up until August he was the only developer, so a lot of bad practices we have (e.g. no process whatsoever) are holdovers from the way he worked for a year and change. The obvious problem is that working alone dodges an awful lot of problems that arise when you have to work together. Now, we're running into these problems but the CTO isn't dealing with them - he just disengages whenever they get brought up and says something like "You're right, that's important, but first let's work on ...". Quite frustrating.
And again, no worries on the delete.
FWIW: If you have a solution rather than a complaint, that tends to go over better and has more hope of being acted upon. Also, I have found that opportunistically grabbing people in the break room (by themselves, with no one around) and talking for a minute is sometimes way more effective than the formal process I am supposed to go through (proviso: I am not in IT).
Take care.
To be fair, this is not an easy transition to make, if good processes weren't started from day one, which is the standard state of most early startup technical projects.
Everything from source control commit logging, to conflict resolution, to development database snapshot sanitation scripts, to audit/error log management, to configuration management, to compliance, to QA handoff, to deployment automation, etc. These things are not trivial to begin working on while training new hires, working on new feature requests and existing bug lists, at a time when 99% of domain knowledge is in that person's head. And all of them are necessary for your CTO to be able to delegate effectively for his role.
Not knowing anything about your exact situation, my guess is that none of these things were properly set up from the beginning, and now your CTO is faced with nearly impossible circumstances that he's either unwilling or embarrassed to acknowledge. He may believe that trying to explain to the other stakeholders about the importance of process and technical debt reduction will go over poorly in the face of increasing business requirements that must be done nownownow. Horrible approach, but it happens, and happens often.