J'ai travaillé chez SugarCRM en Contrat Permanent (Pendant plus de 5 ans)
- Decent salary and benefits, even for remote employees.
- Great people to work with
- Flexible hours
- Great IT support
- A lot of opportunity for self-driven creative solutions, learning, etc.
I worked as an engineer in Enterprise Services for over five years, and the most glaring issues were miscommunication and mismanagement of people and products.
Management constantly talked about bringing code from custom products into core and pushed engineers into doing "demos" of custom product function to facilitate this. Yet demos almost never translated into code being merged back into core. In fact, the process for getting code merged back into core was a mess, even for basic updates or simple bug fixes. Trying to get a new feature merged into core was basically an imitation of Sisyphus, especially as a remote employee.
Many of these custom features would have been highly beneficial to core. At the very least, it would've saved engineers a lot of time, especially on transitioning between projects, and it likely would've made the product more marketable, too. Of course, this takes a solid process and a bit of invested time for merging and testing. People talked about the benefits that would result from such activity all the time, yet it never seemed to happen.
It took me a while to realize that management was simply that short-sighted. They saw a "feature" that would take 3 business days from 1 core engineer, 1 development lead, and 1 tester from working on short-term projects and meeting deadlines. Everybody talked about the big picture constantly, but management wasn't willing to assign the resources required to make any of it happen. There was always something more important in the short-term, and thus, management constantly dropped the ball on the long-term. This was particularly maddening for developers and teams who did the legwork of demos and presentations but found that even if their feature was lauded that there was nowhere for them to go.
There was also a strong feeling of "keep off my turf" when it came to the code that cut the heart of out pretty much any collaboration effort that crossed project lines. If a project had highly motivated individuals who came up with an interesting feature or improvement, it would benefit the project, but rarely (if ever) the core product. And, even worse, it caused anyone with specialized technical expertise to be yanked from custom products, leaving them to "supervise" or "mentor" developers... to be clear, this was NOT helpful training for developers to learn new skills. No, we were told to defer to so-and-so for certain development issues, which resulted in a coalescing of talent and product knowledge that created a horrible bottleneck and often created terrible miscommunication.
Ultimately, the short-sighted nature of SugarCRM management resulted in an incredible amount of waste. Wasted time, wasted talent, and wasted features.
This was - and likely is still - reflected in the product documentation. Locating accurate documentation is nearly impossible, and Sugar 7 did little to change this. The so-called "Sugar Developer Guide" fails to provide incredibly basic necessities, like a birds-eye-view diagram of SugarCRM's custom framework, a list of all known/core keys used in the product, and defined enumeration value sets. (The fact that I even had to write that sentence is ridiculous, especially for a company that has existed for over a decade and provides a web-based product that uses multiple programming and markup languages.)
There was a lot of push for better documentation when I was at the company. A lot of engineers had their own notes, and some of us shared them for the sake of sanity. More than one of us tried to get this information standardized and distributed on the company level, at least for the engineers. Some of us tried many, many times to push for this. You'd think that the benefits of having something so critical to good engineering standards would be higher on Sugar's radar, yet this very basic necessity failed to get any traction with the higher-ups, so it never happened.
Also, the sales team and the development team need closer integration for Enterprise clients. Very often the sales team makes promises that the development team can't keep. Not only is it incredibly frustrating for both parties, it undoubtedly makes the client angry, too. Especially because the fix is so incredibly easy: get a developer into that conversation/room/pitch. That's all it would take.
Conseils à la direction
Innovative engineers need the ability to be effective beyond the scope of their short-term projects, otherwise you're just wasting a lot of talent, time, and money. Don't make your employees constantly badger leaders/management to get basic stuff, like merging new features into core, done. Also, find a way to eliminate the code turf wars, as they don't benefit the product, the company, or its employees.
When it comes to basic stuff, get straight-forward processes into place, document those processes, and make sure engineers know about them.
Don't schedule a dozen meetings where you discuss how important something is, reiterate how beneficial something is, and then do NOTHING to actually facilitate it. Talk to the developers outside of core for their experiences. Find a way to keep track of how much code (or how many features) are actually being pulled back into the product--this can give you an understanding of how much you are wasting.
Set aside the time and resources required to achieve better product quality. Stop focusing on the quarterly numbers so much that you miss the big picture.
Also, send the IT department a fruit basket. Or throw them a party. In all my years working at Sugar, I saw nothing but excellence from them, particularly C. Hicks. Great response times, great people, great support.