> That's something you're willing to share out loud? Your company's technical process (which you're fully in control of, Mr. CTO) is so cumbersome that it seriously hinders your ability to execute
This is exactly what someone who can't be easily unseated should be doing at a company - demonstrate to middle management that the process they've constructed is whack and take away excuses for not delivering. CEO or someone else on the founding team should be doing that to sales, marketing, etc as well
You need to exercise your god given right to mog goons below you.
Show everyone that system (that you’ve created) is shit and when some lowly SE thinks he’s above them all, you publicly flay him and make example for all that you’re the god emperor.
God forbid you'd actually have to do any real work when there's so many design, retro, and daily sync meetings to attend and so many jira issues to groom.
Only indirectly (through management) and still having control is exactly my point. Obviously if you need to do that over and over there’re some other actions need to be taken
Ive worked on both ends of the spectrum and id prefer too much process to too little
With too little process, people release bugs that I then have to scramble to fix. The CEO who pushed to skip QA and unit testing and everything in the name of release never has to deal with the consequences of their impatience
That same CEO would likely also push to have all of the things including no bugs, then complain people aren't productive enough when arbitrary and unrealistic deadlines aren't met.
Source: my personal experience. Very few of the managers who can code that I've worked with were better than any of the ones who couldn't, and those who did actively code while managing were universally worse.
Trouble is, I don't think they'll just get it and then set about to changing the processes. Besides, the process doesn't come from the middle management, it originates from the top, usually the CTO.
Unless you're at a very small company, CTOs set technical vision, choose high level tooling strategy and outline engineering culture in broad strokes, but the nitty gritty of process will be from an engineering director or other role below the CTO. The CTO will probably provide feedback if needed, but they're not in the weeds and won't be able to see problems unless they're raised.
You are correct, my post was more for the situation where the CTO is also the engineering director but in larger orgs that is not usually so.
I do think, however, that the coding CTO is not the way to go about to change the process. If it's too cumbersome, the CTO should talk with engineering director to find a way to make it less so, not just bypass the process.
Surely there is room for both. Most people don't found companies because they want to sit around on their ass. They're typically driven and do'ers. If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok. After all THEY founded the company.
> If things are not working as they want, and folks are not being responsive enough... they'll do it themselves and that is ok.
If the CTO has rank then why not work to solve the unresponsiveness or undesirable things?
If someone--even a founder--can act as a loose cannon then there is a risk that they'll introduce problems like instability, security vulnerabilities, or unnecessary conflict or resentment. Compliance programs like SOC and PCI don't look fondly on staff bypassing SDLC processes because of those risks.
That’s not a role that I’d normally associate with “Chief” anything (which, by definition, means direct reports). More like Principal Engineer, or Architect.
In smaller companies, this is probably fairly normal, but you can’t maintain this, as the company grows.
I had a similar path, in my career. I originally started as a regular engineer, in a two-person team, and eventually ended up managing a small team of up to ten engineers.
Towards the end, I couldn’t write any code (for the company), at all. I still needed to code, but did so, for volunteer/open-source stuff. I think it made me a better technical leader (I had an employment contract without a clause that interfered with outside coding).
I remember wanting to take an iOS training course, but the company wouldn’t support it, so I took vacation, and went on my own dime. I never regretted it, but it was discouraging.
The happy medium that the CTO did at the company where I worked where I was the architect guiding the technical direction, he would do non production level experimental coding as research - integrations with third party APIs, see if an AWS service was suitable - to take some of the load off of me hand the code over to me and I cleaned it up and made it production ready and championed it to the rest of the teams.
He still helped accelerate efforts, got his coding fix when he had time, wasn’t in the critical path of any work, and he made the entire org better.
This is exactly what someone who can't be easily unseated should be doing at a company - demonstrate to middle management that the process they've constructed is whack and take away excuses for not delivering. CEO or someone else on the founding team should be doing that to sales, marketing, etc as well