“the real action in any administration is executive in nature: knowing what regulatory buttons to push, which enforcers can really go for blood, who to put where, and how to manage them.” - Emily Stewart via Ezra Klein
Most of our work life, we think of managers as overseers: people who enable individuals to do their jobs and enforce how they’re done. Usually doing a job is following a set process moving towards a defined goal. In the post-DevOps world, we think of that as some open ended form of bottoms-up creativity, something far from Burger King employees following a set process for moving burgers from truck, to grill, to wrapping, to the burger chute, to a try, and to my mouth sitting down at an over the highway food court in Basel. (The burger was good, but they wouldn’t give me extra pickles: “your way,” my ass!)
But, even in DevOps/agile think, there’s a strict process and direction: often even more strict and deliberate than what came before. The cloud native approach to software has many, many rules. When I was learning and applying XP and Scrum I had an epiphany: sure, these are good processes, but a large part of why they improve things is because we weren’t following any process previously. The RUP people accused agile people of being directionless cowboys back then, but it was really the “waterfall” people who were just doing whatever in Word docs that were the aimless “cowboys” - or cow_pokes_ as we’d de-gender now.
Managers enforce that process and that goal. Employees will go cowpoke if they’re not given that tunnel of direction. They can seek to self manage and all that, and that can work (maybe?), but they still need management, esp. in large organizations.
Anyhow! There’s another thing managers and “executives” do that’s even less observed: building organizations. I’m now in a new business unit at a large company: pretty much all the managers are doing now is building the organization, the teams who Do The Things, the philosophic theory of the process, how teams coordinate with each other, the - I’m never sure what this word means - ethos. Just as a product manager and developers define and build an app, these managers are defining and building an organization.
It’s thankless work, and a lot of it. Well, that’s not accurate: the company thanks them by paying them more and giving them more authority and perks. But, as with DevOps, those managers are responsible for the organization and have to wear a pager. Managers have to check their email all the time and fix the problems in “production” quickly. Think of all the PowerPoint. They’re full stack managers. Still, building an organization is thankless because the employee in the organization don’t really see the work done or realize that someone has to do it.
And, as with software, all of this is just the first release cycle. You build the organization, push it to production, and then the whole cycle begins on Monday (or, Sunday night in most cases). It never ends.
I observed this continuous management a lot when I did M&A and as an analyst. Organizations that sought to set up a “machine” often failed. They spent a lot time upfront defining what the organization would look like and how to would run. There were lots of meetings, meetings for meetings (“pre-wiring”), and consequential walk-and-talks. Then a PowerPoint called something like “new-org-FINAL-14.pptx” was emailed around, team managers were told to “go over it” with their teams. And then the organization was put into action! EBIT(A)!
Sound familiar? We call that “waterfall,” and I’d guess it has the same success rate as in software (I’d guess something like 15% to 25%, if not worse).
In contrast, managers that follow a more agile process, coming up with theories, testing out if they actually work, and changing things as they learn more seem better positioned.
Again, back when I did M&A you’d have an overall theory (a strategy!) of what the business would look like and how the gestalt of the existing organization and the acquired company would work better together than apart (you see, this is why us M&A-wonks use the term “synergy” without snickering, otherwise we’d have to learn how to spell “gestalt”).
As an individual employee I’ve always assumed that management had, like, a plan. They knew exactly everything that was going on. When they asked me to help define what to do and left the goals ambiguous, it was a frustrating mystery. When I was programmer in my 20s (there should be a whole book series about “how to not be a jerk naif programmer in your 20s.” I could have used that.) I thought this meant that “no one knew what was going on,” that they were “idiots.”
Some times this is the case, but more often it’s that management is in the state of a good product team: they generally know what the app should do, who the user is, and are working on a long backlog. But they learn and adapt each release cycle. They start with little and hope to create something good. (I’m not sure how long a management release cycle is: a quarter, a year? Probably something like six months.)
I think the word “culture” is starting to do a disservice to a technical appreciation of organizational building, both at the product team level (the people building the software) and especially at a management level. Good culture is required, but it’s not the core execution engine that keeps a company going. Culture isn’t the thing that moves pixels on the screen, writing code does. And culture isn’t the only thing that determine how an organization runs each day, well, managing does. The work begins after you get a good culture in place.
Management builds the organization structure, procedure, policy, and governance. They mediate conflicting priorities, set strategy and goals, and deal (primarily) with people issues. People issues from individuals to groups: often just people who are anxious and need to be reassured (this is me once a year), most difficulty, with people who need to start following, start taking advantage of new procedures and organizational assets (so called “frozen” people which, I don’t know, is usually an artful way of saying “old”).
Good management, again, will look at the organizations and how it runs as an ever evolving product, just like a good team does with software.
That ongoing product management and building of the organization is the most important thing a manager does, especially when starting a new business. But, it’s also the least visible, least rewarded aspect of what managers do. For many, it seems like the most boring thing one could do. I hate (and I’m not using that word in the playful, flippant way, I really have “intense hostility and aversion usually deriving from fear, anger, or sense of injury”) doing that work, despite spending the last five years studying and telling people about it. (As they say, those who can do, those who can’t give conference talks.)
Even Bono has a boss. We’re all cogs, hoss. Just try to actually do something instead of aimlessly spinning.
This week’s Software Defined Talk episode:
VPNs, Windows 7 EoL, & Crapplications - This week the title says it all. There’s also some more bread talk.
There are so many paths like this in Amsterdam. My understanding is that most of the trees were chopped down right after WWII for wood fires. So, they had to replant trees. That’s why so many of them are artfully straight, why there’s such a variety. Like the rest of the city - and The Netherlands - so much is carefully, artfully, and practically planned out AND executed.
This is just one instance. There’s thousands.
My generation of web users (the first) is worships the URL as a sort of freedom, independence, and, I don’t know, Truth. URLs encrusted with parameters (the utm_ carbundles) and shortened are not true and, if you sway to the mid-2000’s Doctorwian wings of the URL party, evil.
Apple News hides its news articles behind apple.news URLs that are used to blinder you and shuttle you from the open web to…a desktop GUI. This is evil, my people would say.
I don’t know. I’m tired. I just want to link to articles like. This is a way of saying: sorry for the apple.news links: ¯_(ツ)_/¯