6 ms·

> What management should have done (or needs to do ASAP) was to start trimming poor performing engineers. Oh, we did that in 2017. The engineers are hard worke

> What management should have done (or needs to do ASAP) was to start trimming poor performing engineers. Oh, we did that in 2017. The engineers are hard workers and good coders. Thing is, there aren't really individual performance problems. The problems are mostly cultural: Isolation from the rest of the company, in-fighting, competition, lack of camaraderie between teams and between engineering and the rest of the organization. When it comes to team performance, half the team believes we're too slow, while the other half thinks we're moving too fast. Even that is a point of disagreement.

scottdwitt 8y ago
Your company has a LEADERSHIP Problem! 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?
- thrwwyngnr 8y ago
  > Are your founders / leaders Engineers? 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.
  - cbanek 8y ago
    >> Are your founders / leaders Engineers? > 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.
    - thrwwyngnr 8y ago
      > 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. 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.
      - matfil 8y ago
        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. 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.

scottdwitt 8y ago

Your company has a LEADERSHIP Problem! 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?

thrwwyngnr 8y ago
> Are your founders / leaders Engineers? 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.
- cbanek 8y ago
  >> Are your founders / leaders Engineers? > 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.
  - thrwwyngnr 8y ago
    > 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. 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.
    - matfil 8y ago
      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. 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.