101–110 of 143 posts
Earlier quoted context omitted.
> 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, b…
Whoever is in control of this team, needs to pick one, and stick with it. Hiring enterprise developers if you really want your MVP out the door yesterday is asking for trouble. 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 yo…
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.
Earlier quoted context omitted.
I think you have a slightly distorted view of how firing works in a well-adjusted company. If someone is slowly eroding the motivation of your other engineers, then you should get rid of them for both your sakes (they probably hate working there anyway).
What you say about needing to fire some people seems a complete non-sequitur, as if I'd been advocating to never fire people; as if my "distorted view" is to never fire anyone. That is not my view.
Then what is the behaviour you are talking about here? I must be missing something.
Earlier quoted context omitted.
What you say about needing to fire some people seems a complete non-sequitur, as if I'd been advocating to never fire people; as if my "distorted view" is to never fire anyone. That is not my view.
> This advice is so shockingly bad that I'm wondering if this is a deliberate spoof. This is the kind of management behaviour that erodes trust. Then what is the behaviour you are talking about here? I must be missing something.
To me, what your describing is a management deficiency. My first guess would be you lack highly skilled engineers at all levels of management in your company. This is a common oversight in tech companies to not consider that people at all levels of the company should be skilled in engineering. If this guess is wrong then the rest of the post doesn't apply. If you were starting a chain of restaurants you wouldn't hire…
Every employee is expected "to be able to fill out reports, spreadsheets, provide data metrics, understand the work place harassment polices, health care benefits, present in team meetings, etc.." Engineers are not special.
Your response is making my point that other teams do view themselves as special by blatantly ignoring the basic skills of the engineers. For everyone of those items there are dedicated teams who are the experts, but companies expect that all employees have a functional knowledge of them. So, why do they not expect that, in a tech company, those dedicated teams to have a functional knowledge of engineering. There is no communication without a common frame of reference.
People love to say pay does not matter -- but of course it does. Go to glassdoor and see how competitive you actually are to the other companies. I can certainly put a dollar amount to BS/chaos I'm willing to deal with. Without fail, the companies that imply money does not matter 'look at all these other bits of compensation' tend to be cheap.
It can take years to build out engineering teams and get folks on the same page. Leadership is very important. Three years ago we did not have a single test or specification. Now we have a pretty solid automated CI/CD process. Technical debt is one of the core items we will be focusing on in 2019. Very easy to build out the MVP, and leave out all the things that make solid code. The other is more accurate forecasting. I don't want them to over or underestimate tasks... both are equally bad. The other bit is getting development to say "NO" (and making sure that no gets propagated).
HR is almost always there to protect the company, not the employees. If they are not processing the harassment issues out of the company... that would strike me as odd. Real harassment should be /dev/nulled quickly/harshly - and hope someone has a good eye for what was actual harassment vs something that may not be. Bickering, however, is a leadership issue and not HR. Not everyone is going to be 'happy' with a direction, nor should they. The engineering leads should be pushing their crew to be just outside of their comfort zone. My goal is to make sure I can retain the teams I'm investing in.
Earlier quoted context omitted.
What you say about needing to fire some people seems a complete non-sequitur, as if I'd been advocating to never fire people; as if my "distorted view" is to never fire anyone. That is not my view.
> This advice is so shockingly bad that I'm wondering if this is a deliberate spoof. This is the kind of management behaviour that erodes trust. Then what is the behaviour you are talking about here? I must be missing something.
Picking someone almost at random to fire.
Humiliating and ridiculing him publicly.
Yelling and screaming and throwing a tantrum.
Throwing his private property over the floor.
Swearing at him throughout.
That behaviour. That is shockingly incompetent behaviour that causes huge amounts of damage. Everything that "insiderknowled" said. His post is dead; maybe you can't see it? Here's what I see: https://ibb.co/TByZw8J
> We have a strong culture, but it is widely felt by the rest of the company that the engineering team doesn't adhere to it. What do you mean "doesn't adhere to it"? Culture isn't a policy document that you can shove down people's throats and expect compliance. Culture is much more organic than that. > Complaints from other workers range from the decision they made to isolate themselves in their own building And ther…
Maybe "fit" is a better word? Point is, engineers are different and aren't too comfortable around the other employees.
> And there are good reasons for that. Engineering requires focus and discipline and therefore usually has a very different subculture from the rest of the company.
I agree, you have a valid point here.
> And what did management do about these issues? Did management shut down the infighting? Is management accessible and responsive to users? Did management fire people who were found guilty of fireable offenses?
Issues stemming from individuals were treated accordingly. Problem is, the in-fighting and bickering is happening with pretty much the whole team.
> Why did management hire every engineer who walked in for an interview?
Other people have made similar points about our hiring process and lack of consistent between engineers.
My advice would be to set expectations and have a clear roadmap. I agree with comments who identified the lack of leadership. The point of setting the expectations might solve a bit of "we are moving too slow/too fast". The arguments from both teams that you mentioned are valid because it sounds to me there were no expectations or clear vision of the final product. An example of setting expectations would be: - We ha…
It is true that some teams in engineering work with an MVP mindset, while others work in a waterfall/enterprise pace.
Maybe it's up to upper-management and C-levels to iron this out.
Well, I’d say the first thing to fix is to talk to them and ask them why they find value in being in a separate building and why they don’t want to talk to their customers. Without strong management, it’s possible it’s because their customers aren’t correctly handled. As for the application, it’s the same thing. Your engineering team has poor management (though I’d be surprised if it were just them). If you have a Pr…
> You have a product ownership problem and an interaction problem.
This is very surprising to hear, but it aligns with other replies here. Your rationale is also sound. I indeed believe that most of our problems around complexity stem from our product team.
---
> * ask engineering to move to some rapid iteration cycle process with demos at every sprint or unit of development cycle
This is what half of engineering is trying to do. The other half is a bit more cautious, though.
Others posters have made a point that we can't have both.
---
> * if you can collocate engineers with non-engineers that would be great. Everyone has to be respectful of each other’s environment, though, so if you have a problem with self-awareness this is not great. (E.g. chatty teams aren’t good next to quiet teams, phone calls are not great near engineers, etc.)
Sounds like a nice strategy to change everyone else's perception of engineering.