:wave: Hey all. I'm the author. This content is over ten years old now (2013), as is the slide tech backing it.
Hopefully it's obvious that the click-to-advance is a style that suits my presentation style, and I would have made different choices if I intended it to be consumed online.
In any case, I've learned a lot since this talk and have on occasion considered updating it. I'm pretty surprised it's trending, TBH.
Not that you asked for this, but as a @flavorjones admirer I figured I'd post anyway, my favorite actually recorded talk of theirs https://www.youtube.com/watch?v=zOutXbz_7Ns
No video, sadly. The Enterprise Agile 2013 conference didn't record the talks, and otherwise I've only given it at a lunchtime "tech talk" for my co-workers.
Hmm. I don't think my opinions have changed too much.
I would _definitely_ present these ideas differently today; the language we all use to describe problems and solutions has changed quite a bit in the meantime.
And how I _apply_ these tactics and strategies is much less confrontational than when I was in fintech, mostly because I'm older and more patient.
But the essence of the advice in here is still a big part of how I work: having a technical roadmap to match the product roadmap; getting small wins on the path to long-term goals; talking about what you've built and showing it off; taking responsibility for product and design decisions if nobody else is; building a team who will share ownership; diagnosing dysfunction with Vaillant's defense mechanisms; using estimates to pay off technical debt and experiment with new technology and approaches. All of these tactics and strategies are still valuable in my opinion.
A lot of this sounds like "You can make bad to okay money doing other people's jobs while they collect a salary working 1 hour a week." Enterprisy indeed.
Anyway, has it ever been the case that someone asks Pivotal (1) to do something well-specified (2) that they really, truly can't do themselves (3) but actually makes sense to do, like is positive ROI? If those three things align, you are never hiring a contractor!
In the spirit of no true Scotsman, you're not truly enterprise until there is a combination of barely working software and aggressively wrong documentation working in perfect harmony
The comment predates the author's arrival in the the thread.
I did consider the possibility that it was a slide deck, but as a slide deck it appears designed for the presenter to read aloud the words the audience is seeing on the screen.
Presenting in that way is generally a much greater sin than simply making a pretentious web page, because the audience is generally trapped when faced with that sort of presentation. I "assumed the best" and assumed it was a web page rather than a slide deck.
You know the author is in this thread, you weren’t there when this was presented, and you call “presenting it that way a much greater sin”. Why? What do you hope to accomplish with such a dismissive attitude?
The author wasn't in the thread originally. Lots of us hit the page and said WTF? You responded. I explained why, prior to the author's arrival, I assumed this was a web page not a presentation.
That's valid. I think familiarity with Takahashi style presentations (https://presentationpatterns.com/glossary/#takahashi) helps. These are admittedly less common in corporate settings, though I have given one or two.
It's hard to be critical of the content — if you take it from the perspective of a mid-senior developer within a non-Big Tech role who is starting to see into the leadership decisions being made or pathways available to them, it's probably true to their experience.
But I would caveat that the "hell is other people" and "learn to not-obey" section are recommending behaviours that at best the organisation's people managers, and at worst leadership, would recognise as "career limiting" — and would end that person being stuck in place or on a performance plan. The stance is confrontational and not collaborative — somewhat myopic.
"Business has a short memory. take advantage of it." — Very true, but only when it is adventitious to do so.
I can see how the slides might come across as confrontational or not-collaborative; but when I gave the talk in person I think the message was much more positive.
One of the core ideas is to identify -- and even search out! -- people who you can collaborate with. For the people who will put obstacles in your way, either find a way to work around them, or find a way to align them to your team's goals. Avoiding open conflict is a big part of the message, and I'm sorry it didn't come through in the slides.
On the topic of "career-limiting" moves, that might be true, but I think there's some nuance. If you know what is the right thing to do for your employer, and you're afraid to do it because you might get fired, you're gonna have a bad time. My advice is to get past your fears and do the right thing and take some risks, or else buckle up for a career of quiet desperation that is likely limited by your avoidance of responsibility and the absence of meaningful successes.
I had to close this after the 10th click the next slide for a single word to appear "Like Ninja" No "Like a Samurai!" No "Like a ninja samurai". Yeah can't handle this.
"Enterprise-y" appears to be a catch-all term for an organizational culture built on a foundation of lack-of-trust where interactions among people need to be gamed in order to accomplish...well, anything. And the presentation covers strategies of how to be effective in that kind of environment.
I like some of the tactical suggestions, which apply in any organization trying to get things done. I dislike all the actions that are based in hidden agendas or ulterior motives, no matter the intent.
"Working code always beats vaporware" is very good advice. I got a lot better at engineering when I realized I could just... stop trying to convince people of things and start shipping instead.
You do have to be working on a long enough timeline. I've seen vaporware beat working code over the scale of a couple of years, when it's the current exec team's pet vaporware, but eventually execs rotate.
Presentations aren't generally received well if the presenter just reads aloud the words shown on the slides, which seems like the only way one could present this.
> you know you're "enterprisey" if ... you don't know that you're a software company
That hit hard. I've seen so many companies that defined themselves as something else, despite employing more than 1000 programmers. In denial of being a software company - a bad one. Limping along due to strong brands or regulatory barriers to market entry.
Every day I'm getting more and more convinced that this attitude will get their lunch eaten by a company that can software.
Companies like Stripe and Rippling have so much potential displacing "enterprise", it's disgusting.
This is very good, but I think there is one thing missing:
Understand your organisation's DNA
You need to understand the way your organisation thinks. Do they sell products or services? Are the products physical or digital. Are the services digital or people based. When you understand the world view of the exec you can then understand how to talk to them and persuade them.
A case in point. I was originally recruited into a large infrastructure management organization (bridges, roads, airports - that sort of thing) to answer a client question: Do we need more remote monitoring of our infrastructure. The answer turned out to be "no, you just need to understand and make better use of the data you are already collecting". All well and good, and we built (and now sell to major clients" a remote monitoring, data integration and ML platform. The problem was selling it internally. The organisation (in those days, and to a lesser extent still now) had a DNA of a service organisation, selling people (some of them highly skilled) at day rates. Do they didn't understand the idea of selling a software based service. Initially we could only give the software away and sell support contracts - because that was selling people at a day rate, which they understood. And their understanding went to: how do we write contracts for selling people, what are the risks and potential liabilities of selling people, and how do we mitigate those risks.for a software solution they didn't understand what questions to ask, so they couldn't understand the risks.
It's taken a long time to change things, and while the organisation still mainly sells people at a day rate, software solutions are understood, and we can sell them.
I'm now working on building IoT sensor systems within the same organisation. But my better understanding of the organisation's DNA makes it much easier and more effective. For example, it is cheaper to spend more money on working with a partner than spending less on doing it internally - because our organisation understands systems integration (we now sell it as a service) so building sensors with a partner and saying "we do the systems integration" is easily understood. If we tried to do it internally we would spend huge amounts of time and effort explaining (repeatedly) why we were doing something that wasn't in our organisation's DNA
Wouldn’t it be cool to write something that is ostensibly interesting and then spend a bunch of time obscuring it through an annoying click-for-each-word presentation?
Hopefully it's obvious that the click-to-advance is a style that suits my presentation style, and I would have made different choices if I intended it to be consumed online.
In any case, I've learned a lot since this talk and have on occasion considered updating it. I'm pretty surprised it's trending, TBH.