This is the first I'm hearing of Pivotal. Are they a cloud provider or something? I'm having a hard time figuring out exactly what they do from their website.
Best communicators I have ever worked with.
But, I do really like a lot of their processes. Pair programming isn't for everyone, but I think it's a better way of building software. Now that I'm not doing it full time, I constantly miss the benefits of it.
Their strict schedule is kinda nice for work life balance, but it also means working with them was a little strange. Our whole team would go out for happy hour at 5, but they would stay until 6, even with almost nobody else in the office.
I'm sorry you had such a disheartening experience at Pivotal; it's uncommon — in general, Pivotal people tend to be very warm and kind, and not snobby at all.
When I joined Pivotal six (seven?) years ago, I assumed that I'd stay maybe two years, tops, but the people were nice, and that's what has kept me here.
Also, the comment you heard ("Oh I think we already know how [Database X] works") may have not intended to be snobby but rather a nod to one of the developers there: if the database company was InfluxDB, and the office you visited was the NYC office, then there's a good chance that they were referring to one of the Pivotal developers, John, who was one of the early developers of InfluxDB along with Paul Dix and Todd Persen. [1]
---
[1] https://www.influxdata.com/blog/influxdb-1-0-ga-released-a-r...
The place sounds more like a cult than a company.
I didn't believe you for a moment, but wow:
http://h1bdata.info/index.php?em=Pivotal+Software+Inc&job=&c...
http://h1bdata.info/index.php?em=visa&job=&city=&year=All+Ye...
http://h1bdata.info/index.php?em=Adp+Technology+Services+Inc...
I could find you 100s like this just in the Bay Area.
The joke was always, "You're white, why aren't you the manager?"
http://www.businessinsider.com/pivotal-906-am-breakfast-meet...
I'm glad I read this. Now I'm sure to never apply for this company
Standup at 9:06 is important, though. In order for pairing to work, you need to have everybody there at the same time.
The iron bargain is that you work a rigid eight hour schedule, but then you go home (or wherever) and don't think about work. No overtime or crunch mode, ever.
It's not for everybody, but many folks really really really like it.
However having flexible time is a more important asset to me than doing the occasional overtime
I did a couple consulting stints at Pivotal, working on the CF team. They have a very particular methodology that evolved from the earliest days of agile (Rob Mee was a friend of Kent Beck back when XP was being worked out). I walked in there as a very experienced engineer and a healthy amount of skepticism... and it turned out to be a fantastic learning experience. I've since taken the Pivotal process (yeah, even the weird stuff like pair programming) and used it effectively to manage subsequent companies.
I don't love everything about Pivotal (neither Ruby nor Go make my favorite-languages list) but then, not everyone at Pivotal does either. But overall they do agile right, and they have a lot to show for it. You can mock 9:06 but also note that people go home at 6pm and have lives. The schedule has its upsides.
Specialization is highly discouraged, so the result is a mix of people who can kinda accomplish most things eventually, and a rush to find external resources when you need even moderately specialized knowledge about components in your stack.
I'm not defending them, but I know I'd love for my shop -- we do the same things as them -- to grow in this way.
If they're successful, you're left with a team who adheres to or even enjoys the rules and rituals laid down by Pivotal, and you end up with that team I described who can "kinda-sorta mostly get anything done... eventually... with the help of a few external vendors..." From a business perspective, this isn't a terrible place to be.
If they aren't successful, oops, your entire team churned during your engagement with Pivotal, but don't worry -- they're happy to help out with your hiring processes.
I am no capitalism apologist. The interoperability of technicians diminishes our marketplace bargaining power, thus diminishing labor's leverage over management/capital. At this point in my life, I have accepted this trade-off in exchange for 1) mutual code-review, 2) nights off on-call, 3) opportunities to learn new tech, 4) a product roadmap that can be prioritized without a freaking gant-chart to slot e.g. language-dependent work into language-adherent technicians' backlogs.
While these and other factors make my role less stressful, and my team more effective, I do concede that knowledge dissemination diminishes tech workers' bargaining power.
I think it's pretty clear that these strict agile processes work well for some and poorly for others - some people do better in a highly structured environment and others do worse - it's a bit like remote work on the other end of the spectrum.
The criticism and pushback comes from the negative experiences devs have had when management pushes a one-size-fits-all approach.
I've been involved in more than 5 failed agile methodology process improvement initiatives. I've seen great engineers reduced to a tiny fraction of their former productivity and seen other "hopeless" engineers get a lot better.
So any positives can safely be attributed to the new process and any negatives are clearly just the new process shining a light on existing problems.
Gotcha.
And the parent poster was wondering why people were so cynical.
> making your engineering team more stable
Can you expand upon what you mean by more stable?
One of the main selling points to management is it becomes much easier to switch developers between teams.
> product delivery more predictable.
In what sense? And through what mechanism?
It does reduce risk on short term deliverables but that's a very narrow interpretation of predictable.
It's certainly not the case as an external customer - trying to nail down an xp team to a fixed deadline more than a few weeks away is an exercise in frustration.
https://www.sec.gov/Archives/edgar/data/1574135/000104746918...
to paraphrase:
Besides consulting and software development (Labs), their main product is PCF (Pivotal Cloud Foundry). Basically it helps combine the best bits of cloud centric, automated, containerized tools - without locking you in and letting you be portable across AWS, Google, Azure or private clouds.
The big thing here is that there is a massive opportunity of large companies still managing large monolithic apps with slow, expensive horribly inefficient infrastructure and deployment practices. Pivotal helps (especially bigCo.'s) rebuild their whole app infrastructure as well as transform their culture of software development. The biggest thing, according to their case studies, is that both speed of development as well as the ratio of 'ops' headcount to 'developer' headcount can be significantly improved.
Pretty smart way to do it - and I can see how it would be really aggravating from a power-user/10x engineer perspective.
I also suspect that providers will not keep feature-competitive with one another. It seems like every month, AWS is releasing new tools, and there's no way that other providers are maintaining this pace. My suspicion is each provider will specialize in non-overlapping domains. So unless your company will always be running a lowest-common-denominator site, you'll eventually encounter a vendor lock-in feature.
This is the level PCF plays at; and the level they’re useful, but in my experience Pivotal doesn’t know how enterprise companies develop software. Their scrappy pair-programming Dojos don’t really build systems the way those kinds of companies need to design system requirements.
So in my mind, Pivotal’s consulting services are a bunch of startup guys coming in to the enterprise world telling enterprise developers how to build java services. They’re smart and know what they’re doing, but they’re totally out of touch with the kinds of internal controls, reporting metrics and architecture management that larger companies often require.
Its just extremely hard for the old "enterprise world" to adopt to change that is inevitable.
Also DR.
But again, this is really only useful if you’re big enough to have many application groups developing for a bunch of different business units. I have yet to see a good use case for PCF outside enterprise IT departments.
Large competent software companies like Facebook and Google have still not completely integrated Instagram and Waze respectively for example.
You can run whatever you like, even Windows stuff. You only need to have (a) build pack(s) (aka runtime layer) and a stemcell (base operating system).
CF is like Heroku on steroids or like Lamda+API Gateway+Services for more complex applications.
And Pivotal provides one product of Cloud Foundry ( Pivotal Cloud Foundry), that can be deployed to various Cloud Providers (such as AWS, Azure or OpenStack). There are other vendors, like IBM (Bluemix).
I guess, you mixed it up with the Spring ecosystem, which surely a big driver in the adoption of Cloud Foundry. Pivotal is the core maintainer of the ecosystem.
And no, you don't need to be a big enterprise to run a CF.
They are kind-of the OG multi-cloud vendor.
I also had to do work with Pivotal HD, which was their custom Hadoop distribution. Not sure the status of that these days, they may have nixed it - it's been a while since I worked on that platform.