Hacker News Reader

Comment by Pixeleen | Hacker News Reader

They are a super trendy development and cloud consultancy firm based in San Francisco and New York. They have all the right words and everything. Pretentious start time of 9:06 am, signalled by a gong. All pair programming on iMacs. I visited their very shiny office for a tech talk. Two employees (they call themselves Pivots) used the exact same language to describe how good the strict schedule is. I struck up a conversation with a gentleman wearing their logo. He seemed visibly taken aback when I asked what his role is. Turned out to be C-level and giving the presentation.

View on HN

This is unnecessarily cynical.

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.

It's a killer process for churning out mediocre cogs.

Could you elaborate?

Much of the process revolves around trying to ensure everyone on the team can tackle any problem in any part of the codebase. This is accomplished by doing all work paired, rotating pairs daily. Similarly the consultants assigned to your team are regularly rotated in and out to different projects during your engagement.

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.

So specialization is a precondition for non-cogs?

Considering the idea I was trying to convey with the word "cog" was "trivially replaced by any of the dozen others we have laying around"... yeah, at least a minimal level of specialization is a "precondition for non-cogs".

Seems to be really successful, though, no?

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.

As a commercial venture, absolutely. There will always be folks willing to buy the dream they sell.

You don't think they bring value with the work they do itself? Just hype?

You've gotta keep in mind their product is not the day to day engineering work while you're engaged with Pivotal, but the transformation of your team.

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.

Outside of your oddly combative use of the term cog, this is an accurate portrayal of an integral aspect of their process: distributing knowledge, capability, and reasponsbility across the team.

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.

> This is unnecessarily cynical.

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.

It's a great process for reigning in "great" engineers that produce a ton of technical debt. It's a fantastic approach for making your engineering team more stable and product delivery more predictable.

> It's a great process for reigning in "great" engineers that produce a ton of technical debt

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.

My experience also was that they have a huge snob factor there. I was doing consulting for a database company when I visited their office. In the meeting I was announced as someone when knew our company's product, to which one of the people responded "Oh, I think we already know how <product> works". I wanted to respond, you guys have no f-ing clue how it works, but couldn't for decorum reasons.

Yeah its pretty much crazyland over there - they 100% believe their own kool-aid, and evangelize their processes like its the second coming.

Ex-Pivot here. The kool-aid was amazing. Would drink again.

Best communicators I have ever worked with.

Having worked with Pivots in their SF office and in smaller satellite offices, the Kool-aid isn't nearly as strong away from their main offices.

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.

[disclaimer: I work for Pivotal]

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...

What's the significance of 9:06am? These guys sound like the worst kind of narcissists.

The place sounds more like a cult than a company.

That's most of SF in my experience. Well either that or staffed 90%+ by H1b. Interesting place.

> Well either that or staffed 90%+ by H1b.

I didn't believe you for a moment, but wow:

http://h1bdata.info/index.php?em=Pivotal+Software+Inc&job=&c...

I keep reading that US companies complain that they dont get skilled people and I always think its because they are not ready to pay a good salary but looking at the list the salaries look good. So is there really a skills shortage?

The skills shortage in my experience is at the management level and above. The number of people that aren't remotely qualified to even be an "IT Guy" that are in management roles are astounding.

http://h1bdata.info/index.php?em=Bank+Of+The+West&job=&city=...

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?"

oh boy they have 132 H1-B employees...out of 2300+ (2017 number)

This explains some of it:

http://www.businessinsider.com/pivotal-906-am-breakfast-meet...

"the morning was too short" = "we need butts in seats 9-5 because reasons"

TL;DR "So Pivotal decided to employ both a stick and a carrot. The stick is a mandatory morning meeting at 9 a.m., where your absence will likely be noted. The carrot is the breakfast buffet, "sort of a prize to get in,""

I'm glad I read this. Now I'm sure to never apply for this company

Are you sure? Imagine the obesity that is waiting for you at the breakfast buffet filled with jerky and puff pastries.

If you're not there for the 9am meeting do they give you a detention?

Everyone has different levels of self-control. Maybe in an ideal society the consultants with a great deal of it would work from home/for themselves while the consultants with less would get the breakfast buffet and the gong.

I run the Pivotal office in Singapore. Breakfast is wonderful, but it's hardly mandatory.

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.

Thanks for explaining

However having flexible time is a more important asset to me than doing the occasional overtime

Reply on news.ycombinator.com