For the first half of my career, I found the term transparency to be kind of, well … scary. Not because transparency itself is bad, as much as it’s step-children and cousin words — governance and accountability.
Governance, to me, meant that someone up above didn’t know what was going on, so they were going to give us still more work to prove something. Exactly what we were proving was always sort of undefined; it felt a bit like a tiger chasing its tail.
Accountability wasn’t much better; it meant that someone would call us to “account” for missing the commitments someone else made six months ago to project deadlines, before they really knew what the project was going to be. Even if the estimates were good, because the steering committee was probably going to add more work without shifting the deadline, then call us to “account” for “missing” the deadline.
I’m not really this cynical. I just want to set explain what my reaction would have been to a word like transparency ten years ago.
Today, I think transparency is the secret sauce. It is the magic milk, the healing homebrew. All those problems above go away with transparency implemented correctly.
Let me give you an example.
Transparency in Action
Say I have far too much work to do, and not enough time to do it — but I can break the work down into tasks that can be done in an hour or so. Not all kinds of work falls into this category, but a lot of what I do, testing, configuration, consulting — a lot of it does.
I make three columns on a white board – “To Do”, “In Process”, and “Done”, then write down a sticky for each task. Once the setup is done, I pull the first task from “To Do” to “In Process”, and work on one thing at a time. Now this isn’t a perfect list; there is no tasks for “check email” or for scheduled meetings, but for the most part, my tasks are modeled on the board.
Any leader, any boss, any executive that walks by can re-arrange the tasks, and put something to the top. Because the tasks are small, I can tell you how long it will take on average from putting a task to the top to moving it to done. If I want to, I can count the number of tasks I get done per day, to predict when things will get done. A process improvement wonk would call this a “kanban” system, and they’d be right – but a Kanban is simply a Japanese word for tag system to manage a flow of work.
Here’s a Kanban that I set up at a client a few months ago; the tasks are a list of business risks we were testing for:
We had five team members on the project, thus, give items or less of work in progress on any given time — when we were pairing, we’d have less. If we were under pressure and had to ship, management could look at our ideas to test remaining (and we always have more ideas) and decide the benefits outweighed the risk.
Think about how that decision changes things when there are problems in production, versus the ancient model of testers “certifying” software for release while under time pressure.
Kanban and You
Imagine walking into an annual review meeting and finding out you worked on the wrong thing, or your priorities were wrong, or, after 12 months, your manager was disappointed you hadn’t accomplished (some_thing).
Only this time, you had a kanban. Everything you did was visible. Anyone in leadership could see them, adjust them, ask “What about (some_thing)”, create new stickies.
At that point, the person who has the problem is the reviewer, right?
I don’t mean to be manipulative here — the point was just to illustrate how powerful this kind of transparency can be. What I have above is just one way to model a Kanban (it is a team board) and Kanban is just one way to make the work visible. For more, check out Jim Bensen’s book “Personal Kanban”, or keep it tuned here.
Until then: Have you tried some form of radical transparency? When you did, what kind of results did you have?
My article was not inspired; I’m not a genius. Instead, the timing was right, that’s all. I literally happened to be reading William Zissner’s On Writing Well this week, perhaps the most respected book on late 20th century writing style, good enough to keep updated into the 21st. It was Zissner, and his book, that explained my discomfort on reading the memo, a discomfort we probably all felt.
After clicking the publish button, the very next questions in my mind where why, and how, the CEO of a Fortune 50 company could get it so terribly wrong.
I believe I may have some answers.
Yesterday I was struck this tweet from Fog Creek Software CEO Joel Spolsky:
Then I read the memo.
Now I’m with Joel.
The document is not something someone leaked, a half-baked message sent off in a moment when a quick decision was needed. Nor is it an insiders document, full of shorthand terms and abbreviations that make complete sense, but only to insiders. No, this was actually designed for everyone to read, for all employees to read. It is on the web now, hosted on a Microsoft Website; you can read the full memo yourself.
I’ve got a lot to say here, but I’m going to start by answering Joel’s question (‘what the heck does all this mean?’) with a little bit of commentary, leaving conclusions for next time. The original text will be in italics; what it means, in bold.
Here goes … Continued »
At least, that is one of the major themes in Malcolm Gladwell’s book Outliers, and it makes sense to me.
It doesn’t really matter what you are working; it could be on MySQL clustering, writing mobile applications (or testing them!). It might be your golf swing or your knowledge of University of Michigan football.
Today, I’m going to talk a bit about how to know when you’ve ‘arrived’, and what to do with that knowledge.
Bad bosses seem especially prone to IT, or, at least, IT workers seem especially prone to complain about them. We even have our own comic strip, Dilbert, to celebrate the cult of the … i’m not quite sure what.
Whenever I think of bad bosses, I think of my friend, who I will call Sam. Cue the music … Continued »
I’ve been talking about The Lean Startup, which is all about cheap experiments to find value. My last post was on the new book, “Lean Analytics“, and how it focuses primarily on web-based startups — but there was at least one idea that applies to every business, every team, even every person.
It’s called the Lean Business Canvas, and you’ll find it in chapter 3. Here’s an overview of it’s parent process, the business model canvas:
If you wanted a simple guide to map out your career, or the future of your department, this is it.
Take, for example, the looming shadow of outsourcing, or offshoring. If you take the twenty minutes to analyze your department’s partners, key activities, cost structure, customer relationships, and so on, along with your potential competition, you can figure out what advantages your team can offer against outsourcing … and what to look out for.
Don’t worry, it gets easier.
“When Joe the Helpdesk guy goes to IT leadership, he has statistics. Same day call resolution, percentage of calls that go through to a person versus to voicemail, and number of tickets resolved per day. When the CIO goes to board meetings, he can represent that. Accounting has cost numbers; Sales has actually dollars. What does IT dev have? Expenses. The only way to show improvement is to spend less. We need metrics! It doesn’t matter what they are; we’ll just through out a bunch of them and see what sticks. What ideas do you have?”
I’m not kidding; that was the actual conversation.
We came up with a number of measurements, things like the number of projects completed in a month, or the number of requests on the small projects team divided by the number completed in a month, which would estimate the size of the backlog. As you can probably guess, I was less than excited – “we’re really going to base our performance on our customers ability to think of new things for us to do?”
So when I heard that Eric Ries, author of The Lean Startup had planned to editing a second book in the series called Lean Analytics, I was excited. My copy arrived two weeks ago, just in time to read on airplanes and in hotels; here’s what I found. Continued »
I was recently out in San Jose for a business trip, John Ruberto, friend of mine and one of the engineering leaders for QuickBooks Pro Product, offered to give me an insider’s look at the company and how they apply lean startup concepts.
Yes, Intuit, the company that brought you TurboTax, QuickBooks Pro, and Mint.com – the company you might use to balance your checkbook or pay your taxes. One of the earliest adopters of the “lean startup” philosophy, Intuit earned its own mention in the original Lean Startup book.
I brought my camera. Continued »
A strange thing started happening to me about two years ago. I would be at a social event, probably a user’s group, and someone would start talking about either their startup idea, or, perhaps, the idea of startup ideas — specifically, The Lean Startup. The next steps were usually consistent: The person would describe the lean startup with superlatives (“awesome” and “amazing” are common), would find out I had not read the book, then refuse to actually explain it (“it’s too much, you must read the book”). Toward the end of the conversation, they would find out that I had my own business and assume that I had not read the book and must be doing it wrong.
After a couple of years of this I went out and bought the book.
And yes, for what it’s worth, there is plenty of good stuff. I do think I can explain it in the course of a conversation — at least in enough depth to recognize how it is different than other approaches.
Let’s get started. Continued »
In the office, not so much.
So it probably won’t be a surprise to any of us that the culture of downton Abbey, the English Edwardian Period, was almost a perfect fit, set-up by the culture to generate a simmering pot of hidden agendas, plots, conflict and drama.
What you might not have considered is the ingredients of that “culture soup” — and if they might exist in your own workplace.
Today, I’ll talk about three of them, … and how to spot ‘em, starting with an example. Continued »