My boss, Kevin Gamble, has been actively brainstorming the concept of the Free Range Enterprise. It’s perhaps a new term to describe a known idea, and defining the term helps to set (perhaps even own) the discussion. Higher education is surprisingly rigid, particularly the closer you get to the areas that have been bureaucratized — it will be interesting to see where the discussion evolves.
There’s one aspect of it that I’ve been thinking about recently — Kevin calls it “radical transparency”.
I’m going to call it “Work Wide Open”
I’ve been in some form of IT my entire career, and as far as I can tell, there are few concepts that seem to scare IT more than “Work Wide Open.” Heck, I have been scared of it.
4 years ago, I asked the folks I worked with to blog our activity notes every week — wide open, to the world. I spent a lot of time debating it — mainly with myself — both for the tired old mantra of most IT organizations of “operational security” — but also out of the fear about exposing the tasks lists of what we do. An awful lot of people don’t understand what most IT organizations do — and there are people that understanding partially what we do and every one of them have an opinion on how we can be doing things better or how we can solve X with Y.
Opinions, well, everybody’s got them.
But the dirty little secret is that they really don’t care. Most of the people that we are all afraid of telling us how we could all do our jobs better aren’t going to be watching. And those that are watching, they actually don’t say much it turns out.
( And then when they do, it can be really useful actually, because contrary to our circling of the wagons in IT when those that know far less than we do raise questions — those questions actually have merit. The problems that others outside of IT will bring up aren’t often problems — but you can bet that there really is a problem, it’s just masquerading as something that isn’t. Try to answer them sometime, it’ll be eye-opening about what all you don’t really know and have been doing because of a bunch of false assumptions you made a long time ago and never questioned. )
So, extraordinarily long parenthetical aside, nobody really cares about the details of what you do (nobody outside your work team). So that means that the most important audience for being open is for you and by you — I mean you and your work team
You might think to yourself — in that case, why not just be open, but only with my work team?
That might be fine and all, and for most organizations it’s a big step up from where they were with not being open in the first place. But there’s two reasons that being open beyond the work team matters.
One, it helps to refocus what you write, and what you say. It lends itself to a bit more positivity. Sometimes it lends itself to being a little too generic (especially when something under that “security” banner is discussed) — but for the most part, being aware of a wider audience, real or imagined, helps you write in ways that are more clear, better defined, less likely to be “inside-only” information. This turns out to be enormously helpful — again for you particularly when you go back 6, 9, 12 months later to figure out what in the heck you were thinking when you implemented X in Y way to solve Z.
Second, somebody else is really going to read what you write in the open, Somebody like you, actually — in the same way you are looking for resources through feeds, search, forums, commits, source, etc. There are others doing the same. And like crazily phatic 140 character messages lead to greater personal understanding of colleagues, and help spread information — work wide open helps others understand what you do.
Four years later — I don’t know if the every week blog posts were successful or not. I know they are still done in that group today with my successor to the job asking the same of the people that work for him. And it’s useful, I still read them, and it has helped me on more than one occasion, seeing references to tools and solutions to problems I was having — or would soon have.
Others that went on to other jobs don’t do it, and I wish they did, they work on incredibly interesting projects that could be served well to have regular updates and highlights about what’s going on inside the project.
So, success or not, I don’t know. What I do know is those weekly status notes were a stepping stone. One small step in the direction of “work wide open”
Fast forward 4 years. New job, new boss, new work team. And a completely different way of working.
The same operational security fears are there — I won’t deny that having every last bit of your source code isn’t a bit disconcerting (in addition to being a developer, I’m also a system administrator — it’s part of my job to be a bit paranoid). And the same “is our work going to be questioned by those that don’t have a clue about what we do and how it works, but think that they do” fear still exists, in some forms.
But neither can overcome the incredible utility and usefulness, and maybe even flat out accountability of working in the open brings. And as a completely taxpayer-funded endeavor — really, isn’t our work supposed to be in the open? (okay, that’s a separate topic, but not by much)
On the perso-professional level, bookmarks, photos, silly phatic updates, and semi-serious phatic updates — all public — and that, plus a couple of blogs, get aggregated together in one public place, too
In addition to being a system administrator, I develop our identity/authentication/directory application — and that application tracks every login to every app, every edit in every app. All that activity is available, but it’s currently limited to viewing, closed down to only just over 8,000 of my Extension peers — but pretty soon, I’ll be coding in an option to make that public.
My work team does maintain a private mailing list — and doesn’t even archive the messages, there’s a place and time where some discussion needs to be frank, and private. But it’s open to our whole team, and I dare say that 90% or better of the emails that involve more than two or three people, go to our whole staff of 8, full time, temporary, part-time, etc. There are still a few systems-related things that aren’t in the open, particularly those that involve serial numbers, or cron processes that have embedded authentication tokens or passwords. But for the most part our work is completely open.
You know, one day, there will be some security issue I’m sure that comes from something we did in the open. But that’s one of those things that you deal with when it happens (and I quite imagine that I’ll do it quite publicly when it does). And I’m sure at some point there will be someone annoyed because we didn’t do their request, while we check in who-knows-how-many-changes for other requests. We’ll deal with that then too.
In the meantime, I can’t begin to tell you the benefits, how its brought our work team closer together, how every member of an 8 person team is as close as I’ve ever seen to being on the same page, aware of the team, and what they are doing as part of that team, and moving in the same direction — and doing so in a way that is in front of and interacting with peers in our system, at our University, and colleagues in other institutions. We are, I believe, extraordinarily efficient at what we do, I’ve rarely seen this many systems, and apps done by just 8 people, and the occasional contractor — and done in a way that keeps moving forward. We couldn’t do it if we weren’t open. There’s no excuse, particularly in a public-funded endeavor, to be anything different.
We don’t just value and talk transparency, we are transparent. We live it and breathe it. We are work wide open, taking a road less traveled by.
And it’s making all the difference.