And the 'cultural' problems: isolation, in-fighting, counter-productive competition, are symptoms.
Your 'leaders' have hired misguided Engineering Managers who created an environment that made this behavior possible, and your leadership is allowing it to continue.
> First Question: Are your founders / leaders Engineers?
> Second Question: Why do team members think that you're moving too-slow / too-fast?
Actually, yes. They wrote the software that is currently used in production.
But they don't want to touch engineering with a ten-feet pole. One time they complained that engineering was taking too long to finish stuff and engineering demanded an apology.
> Why do team members think that you're moving too-slow / too-fast?
Good question. Both sides provide very good arguments, but they're super polarized.
Half the team is the MVP-lean-startup-crowd and is constantly complaining that the code is too complex, with too many abstractions and it is and hard to test and debug. They claim they want to push simpler code that works and optimize/refactor as needed, but that never flies on code reviews. They claim that the constant refactoring (I swear I hear that word ten times a day) are causing way too many bugs.
The other half comes from an enterprise background and complains that the code is currently too messy and unsafe, and claim they need to refactor weird parts before doing pretty much any feature. They believe in making bigger deliveries instead of incremental ones, and point to bugs caused by the other team as proof that they need more time to get it right.
For obvious reasons, management has ALWAYS sided with group number one, which caused a lot of problems and accusations of favoritism.
My hot take? Yeah, three years is way too long for a simple web app from a startup to be ready.
> Actually, yes. They wrote the software that is currently used in production.
> But they don't want to touch engineering with a ten-feet pole. One time they complained that engineering was taking too long to finish stuff and engineering demanded an apology.
Engineers can get very touchy about code they write. It's kind of their baby. It sounds like the highest levels of management have written what is being run, and yet not want to seem to maintain it, or directly lead the engineering org. Then they also want a great engineering team to improve what they've been doing, which inevitably ends up being ways that the initial implementation could have been done better. Sounds like a double bind for the employees. If an employee finds a much better way of doing things, the founders should be happy, but they may be sending mixed signals.
Another example is that when you've written a bunch of code, you are the expert. Anyone else working on it will be going slower, because they don't have the background that the initial author did.
If there are two sides, and one says that the code is too complex, and the other side says it's messy and unsafe I'm likely to believe both of them. For different parts of the code, you may need incremental improvement, or you may need to rewrite it. This is where you need real engineering leadership.
Well, in their defense: they have to, you know... run the company.
Engineering was supposed to maintain the current software, but they (engineering) chose to deprecate it and make a new version from scratch. It is just taking way longer than expected, three years and just a fraction of the original functionality.
> If an employee finds a much better way of doing things, the founders should be happy, but they may be sending mixed signals.
Problem is: they're not doing anything better. Customers prefer the old software. Other employees prefer the old software. Even some people on the team prefer the old software.
This seems like a key issue. It's time to evaluate progress on the re-write and work out what to do next, with all options on the table (including re-focussing on the old software, or even starting afresh with a "version 3").
Are there any people in the engineering group who have been doing non-trivial bits of work on the old software? It may be worth cultivating these people and taking their opinions seriously, even if it ends up putting other (perhaps more senior) noses out of joint within the engineering group.
He's indeed friendlier than engineering.
Might be a good idea indeed to integrate him with his old team, or maybe build a new team around him.
You're have a good point. Maybe after one year things will be different.
It also leads me to believe your product currently has a dearth of tests. Most of the bugs that are generated from refactoring should be caught by automated tests. Until you have tests, you shouldn’t refactor (always write a test first).
If your product is too difficult to test, the enterprise crowd may have a point and the initial (and further) architectural decisions have been wrong, and this suggests a lack of senior engineers.
Last point, if your abstractions are making it more difficult to test, then the abstractions are almost certainly wrong.
You're right, this is something I'll talk with HR about. I realize we're not hiring consistently and that might be causing problems.