Enterprise-Fu
mike.daless.io
mike.daless.io
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.
It's nice to see these patterns and thoughts written out.
Finally somebody understands their ABD's
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.
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!
Only mentioning for fidelity
> documentation over working software
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
I gave up after about a dozen "give me the next word" finger taps on my phone.
Just post the prose. Better writers and worse writers have done so, and people have read them.
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’re making a whole lot of assumptions man.
That's the whole point of the previous comment.
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.
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.
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.
"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.
As always, your mileage may vary.
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 don't work so well if nobody is presenting.
Reading this word for word would be pretty silly but presenting alongside it would be great.
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.
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
edit: which now makes sense! didn't see the date.