They tried once, but that was a year ago.
You're have a good point. Maybe after one year things will be different.
47 karma · joined December 30, 2018
You're have a good point. Maybe after one year things will be different.
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.
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.
Yeah, that's something I also don't understand.
Honestly, I'm a bit inclined to think there is a problem with engineering, since they were able to test lots of different strategies and group dynamics in the last three years, and none of them has worked so far.
> 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.
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.
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.
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.
Publicly shitcanning. It's illegal here.
That makes a lot of sense.
The multitude of complaints show me that we're not only communicating what we want to, but also we're failing at communicating what kind of engineers we want.
We're currently changing our hiring process, and I will give that feedback to HR and to C-levels.
That's really good advice.
Thank you.
Some of them hit home for me:
---
> It sounds like the product is "simple" but the reason for the large amount of code might be that there is no clear definition of the minimal viable product. The added complexity is possibly there because the UI/product team is piping in more requirements somehow.
That makes a lot of sense.
Pretty much all our app screens are extremely complex looking and full of different details. Actually, let me rephrase that: the whole system is completely inconsistent visually and each different screen has its own special widgets.
Interactions are not standardized and even tables have 20 different styles of text fields, which confuses our customers to hell, to my own chagrin.
All our screens are prototyped in Adobe XD before engineering looks at them, and that might be the root cause for (at least) the hardships at coding the frontend.
---
> I've seen incredibly smart engineers stifle and essentially belittle other intermediate/junior engineers over their work or ideas
You're right.
I've seen senior engineers talking down junior engineers. This is something that shouldn't happen.
---
> Giving engineers the room to develop design skills and make mistakes is important
> Systems can get complex and fail for a wide variety of reasons. Personally if I were the engineering manager and an engineer brought down the system somehow I would raise that as a cause of celebration without the connotation of death ("post-mortem"). Celebration since this is one step further in figuring out how to make the system more robust. A lot of time cultures promote an environment of fear where people are afraid of changing the code because things break. Continuously improve things so that it is harder and harder to break.
This is interesting.
Another poster mentioned we're trying to cater to "all kinds of developers". Maybe we should choose a specific profile?
The people I mentioned who complain that "things are going too fast" are also very averse to production mistakes and complain about it a lot.
Without more data it is hard to know if the information in the exit interviews were valid. People might indeed be leaving for better paying pastures but we missed that.
Oh, we're also in our fourth product manager in three years. The previous three left because they were (of course) unable to deliver.
The people that were fired had some really bad performance, and the team itself agreed on the metrics beforehand. Also, it took about a year after they were fired for the problems (other than their slowness) to start.
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.
---
Now, the paragraph you quoted from me is a bit weird indeed. I'll try to explain what I wrote:
We can't keep the engineers working with us because they're either getting fired for some reason, or leaving while complaining about different things. All but salary. They had two raises in 2018 and pretty much everyone left got a promotion in 2018.
Hiring is *harder because the economy is strong again, so we have a smaller pool to hire from. But this has never been a problem before. Problem is, people is leaving too fast.
> Your company should be an engineering team, some of which can't code very well, that also kicks ass in whatever field you're in. That's probably a big mental leap! But it's where you have to go.
> Tear down the barriers and integrate engineering as tightly as possible with the "real" work. Hint: whatever you do, you can do more. Put coders on the customer support phones. Rotate people through the teams as SMEs. Physically put them in places where they rub elbows with other groups. Got a bug in a CSR app? Bring in the folks affected and have them personally explain the impact to the team.
This is kind of amazing to read, and a great idea to reorganize the team. Would surely solve our cultural problems, and would actually free time from the programmers. Makes a lot of sense.
> Once you get the social walls down, work on the technical stuff. Otherwise you'll just make more arrogant tech teams.
That's interesting to read and makes a lot of sense. Thank you.
This is an interesting idea and might work really well!
Currently the hamster wheel ticket thing is a demand from engineering, but maybe suggestions for changes would be welcomed by the team.
The other things, we sorta have it all, I think? I asked a friend about the Spolsky Checklist and we pass it.
That makes a lot of sense. Come to think of it, we started having those problems after a string of very aggressive or very anxious managers.
Indeed. Problem is, HR is desperate because everyone is engaging in such behavior. Which makes the rest of the company to think that it is a systemic rather than an individual problem.
> But, these are probably symptoms of work related problems (lack of expertise, lack of clear responsibilities, managers who escalate rather than de-escalate situations) rather than pure conduct problems.
Thanks for that. Indeed, those things might be the root causes of the problems the teams are facing.
And I forgot to thank you for the insight you gave me with your previous post:
> What management thinks is irrelevant to morale. > What the engineers believe management thinks is relevant.
Maybe we should focus on listening more to the engineers, instead of focusing on sending the right messages.
Might seem obvious to anyone outside, but sometimes we need to be reminded of those things. Thanks.
Yep, there were some talks among engineers about the possibility of them being laid off and replaced by another team. But that's far from the case, as they've been repeatedly told that's not going to happen, have all gotten raises, stuff like that.
I could go with the unrealistic deadlines, which is something half of the team complains about, but the other half complains of the opposite. It's hard.
The whole team agrees that they're under-performing, though, which might be the reason for the fear of being laid off.
The "shit rolls downhill" thing is exactly the kind of thing all the previous managers did. I'd like to think that they stopped doing that, but that has left some scars on the team.
---
> 2) Much more rarely, but it does happen, it could just be someone with an abusive personality. Those sorts of people are capital-T Toxic to your organization and will definitely result in your best people leaving. You want them gone, yesterday.
The worst ones were already removed, but they seem to have caused lasting damage. We should see how it goes.
---
> I provide consulting for organizations about engineering teams and culture and it seems like you might benefit from that. I'd be happy to have a free call with you if you'd like to talk further. My contact info is in my profile.
Thanks, I'll definitely talk about it with our CEO and CTO.
Yep, I agree with you. That's good advice.
Yeah, that's not gonna fly here at all.