In any organization, IT or not, that is larger than zero people, there needs to be a way for the organization to identify, track, and resolve work. The tricky part is how you define "work", because that actually means a bunch of things: Work means "hours spent by workers on tasks", but it also means "the product of the hours spent by workers on tasks" and "future hours to be spent" and "future products as a result of spent".
For the purposes of this rant/manifesto, we're going to define "you" not as a generalized vagary, but a very specific person. You, in this case, are "Tanya".
Because this is fiction, I'm going to really go out on a limb and be wildly divergent from reality, so you, Tanya, are a young woman in tech (you can already tell this is fiction). You've spent your college years suffering through the horrible sexism and racism to finally graduate with your Computer Science degree, and you and five friends have just come up with the Next Facebook Idea, and coincidentally one of your friends is white and male so he's talked YCombinator into a startup grant of 10 million dollars to see if you can do anything with it. And now you've been told you're in charge of managing a bunch of stuff, for which your CS degree never prepared you.
But! You're smart. You're capable. And you think a lot about systems and workflow (which really means you should be in Ops, but nevermind that now, this is a POSITIVE fiction). You know you need a way to track the "work" and you have a pretty good idea of what "work" means from one moment to the next. So how do you track that work, and how do you make sure you're tracking the right things, and how do you know what measurements you want to use to define "right"?
"Tanya," you say to yourself, "what we really need is some sort of tool that will aggregate and distribute this information." And so what you need is a ticketing system. A way to identify a discreet chunk of "work", determine it's value and effort, and prioritize it, track it's progress from inception to completion, and then report on the estimated versus real value after you're done with it. You will also be using this system to assign or reassign work from person to person (and eventually, from team to team). So you sit down with your friends/cofounders and bring up that you need a ticketing system to manage workflow.
"But Tanya," says Chad, your white friend who knows the guys at YCombinator, "ticketing systems suck. Why can't we just handle this like we did with class projects? There's only five of us, we know what needs to be done, let's just do it." Chad conveniently forgets that the reason he did so well with class projects is that you and your roommate Lacy were always willing to do 4/5 of the work for every project, while Chad always wanted to do the presentation but never did any of the work. But that's just Chad; he often forgets the value of being white and male, but at least he doesn't get huffy about it when you call him on it. It's why Chad is still a friend and still part of the team: he's got the connections.
Why do ticketing systems suck? They suck for two reasons. The first reason they suck is because they make engineers (who are mostly self-directed people, socially) think about what other people want. The second reason is that often a ticketing system is engaged for one specific reason and then dragooned into service for every other team that needs a ticketing system, even when the needs explicitly do not fit the tool. For often very good reasons (money, time, effort -- all things relating to "work"), an organization that has sunk cost into one particular ticketing system will use that one ticketing system for EVERYTHING, when in fact that's a bad idea. Because often the things you want to track and follow are vastly different metrics depending on what kind of work it is.
"Chad, we need to know who's doing what. There's only the five of us. What happens if you get hit by a bus?" You pause for a moment, while everyone but Chad imagines Chad getting hit by a bus, and secretly you all smile a little. "We'll start with something small, lightweight. We just want to be able to know who's doing what and where we are in the process." With a little more wrangling, you're able to get everyone on board. You find a good (free!) engineering-centric system, because at this point you don't have anything but some code and some ideas. You need a way to track "who is writing what", "what is still left to write", "what is working", "what is not working", and "how long is this taking".
===
It is 18 months later. You have business cards. Chad wants the company to have a "light, open" culture, so your business card just says "Tanya, Engineering Master" and the company logo, and your various contact methods including your twitter handle. Your little idea and 12 million dollars later (Chad has been doing a lot of fundraising and not much coding) now is a Product, and people are actually using it and Chad has hired several people to figure out how to get people to pay for it and now instead of you and your four (three, really; thanks Chad) friends doing the programming there's now a dozen devs and you're not so much doing any coding as you are trying to make sure everyone else is doing their work.
It's still been a rush to see your creation grow and evolve and suddenly be introduced into the world... and promptly break. Badly. In a lot of very, very interesting ways. And you need a way to track customer's reports. That sounds familiar... Yes, in fact, you need a ticketing system. But wait, you HAVE a ticketing system! It's free, and everyone is already using it, so you can just use that, right?
Well... maybe. Here's the thing: a customer (which in this case is the same as a user, though sometimes you wish you had gone the Twitter/Facebook route and designed something where the users and the customers are different) has a very different expectation around "work". The customer wants to know that the behaviour they're experiencing is sub-optimal. They want to know when it will get fixed, and they want to know how long it will take, and they want to know who to harangue to get the behaviour fixed if it's not happening fast enough. So does it really make sense to use the same ticketing system to track "user reports" when you're already using a tool that tracks "engineering workflow"? That's probably not a great idea...
So now either you have two ticketing systems (and you have to find a way to make them talk to each other, because some (but not all) of the customer reports will be things that engineering has to fix), OR you have one ticketing system and you have to track two different metrics in one tool and figure out how to convert one kind of ticket to another kind of ticket (and back) internally.
And now the sales team wants a way to track leads and followups and contracts.
And now the desktop support team wants a way to track who needs or wants what and whose laptop got lost and how much it cost to replace it (Chad, you do not need a top-of-the-line MacBook Air if you're just going to leave it on the plane again).
And now there's a real problem, because the tool you're using purports to be a one-size-fits-all tool, but seriously, does anyone actually believe that?
And also, how did you, the woman with the CS degree, become the person who makes these decisions? You're a co-founder! You have equity!
Ticketing systems are important. But there a lot of them and they all do some things well and other things badly, and none of them do everything for everyone well. And often they are only an afterthought, which get crowbarred into positions where they are totally unsuited, and then people go out of their way to not use them (because no one wants to use a bad tool). So you have to make decisions, and often those decisions have knock-on effects that are totally unpredictable. And there's not a "right" answer. There's just a series of choices that feel like "more bad" and "less bad".
===
It's now two years later.
You took your equity and your title and went off to do something else. You still see Lacy every so often at conferences. Chad is now working at YCombinator, but you don't talk to him; you don't need money that bad, and the last interaction with him left a bad taste in your mouth. He's not quite a missing stair yet, but you're determined to avoid him if you can (and warn everyone you work with about him).
You spent some time coding with a big company but it feels too much like assembly line work. Plus, they had a horrible ticketing process, which no one used anyway, which led to lots of confusion. You've been having ideas about integration: about how to create a tool that allows different ticketing systems to talk to one another automatically, to remove as much of the human element as possible, but it's a tricky concept: ticketing systems are complicated and messy and getting the right tool for the right job often means trying several tools before settling on the right one...
===
Footnote: this essay owes a huge debt to the really excellent Paul Ford issue of Bloomberg News, "What is Code": http://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/ . I encourage you strongly to read it. Make some time; it's a big chunk of text.
For the purposes of this rant/manifesto, we're going to define "you" not as a generalized vagary, but a very specific person. You, in this case, are "Tanya".
Because this is fiction, I'm going to really go out on a limb and be wildly divergent from reality, so you, Tanya, are a young woman in tech (you can already tell this is fiction). You've spent your college years suffering through the horrible sexism and racism to finally graduate with your Computer Science degree, and you and five friends have just come up with the Next Facebook Idea, and coincidentally one of your friends is white and male so he's talked YCombinator into a startup grant of 10 million dollars to see if you can do anything with it. And now you've been told you're in charge of managing a bunch of stuff, for which your CS degree never prepared you.
But! You're smart. You're capable. And you think a lot about systems and workflow (which really means you should be in Ops, but nevermind that now, this is a POSITIVE fiction). You know you need a way to track the "work" and you have a pretty good idea of what "work" means from one moment to the next. So how do you track that work, and how do you make sure you're tracking the right things, and how do you know what measurements you want to use to define "right"?
"Tanya," you say to yourself, "what we really need is some sort of tool that will aggregate and distribute this information." And so what you need is a ticketing system. A way to identify a discreet chunk of "work", determine it's value and effort, and prioritize it, track it's progress from inception to completion, and then report on the estimated versus real value after you're done with it. You will also be using this system to assign or reassign work from person to person (and eventually, from team to team). So you sit down with your friends/cofounders and bring up that you need a ticketing system to manage workflow.
"But Tanya," says Chad, your white friend who knows the guys at YCombinator, "ticketing systems suck. Why can't we just handle this like we did with class projects? There's only five of us, we know what needs to be done, let's just do it." Chad conveniently forgets that the reason he did so well with class projects is that you and your roommate Lacy were always willing to do 4/5 of the work for every project, while Chad always wanted to do the presentation but never did any of the work. But that's just Chad; he often forgets the value of being white and male, but at least he doesn't get huffy about it when you call him on it. It's why Chad is still a friend and still part of the team: he's got the connections.
Why do ticketing systems suck? They suck for two reasons. The first reason they suck is because they make engineers (who are mostly self-directed people, socially) think about what other people want. The second reason is that often a ticketing system is engaged for one specific reason and then dragooned into service for every other team that needs a ticketing system, even when the needs explicitly do not fit the tool. For often very good reasons (money, time, effort -- all things relating to "work"), an organization that has sunk cost into one particular ticketing system will use that one ticketing system for EVERYTHING, when in fact that's a bad idea. Because often the things you want to track and follow are vastly different metrics depending on what kind of work it is.
"Chad, we need to know who's doing what. There's only the five of us. What happens if you get hit by a bus?" You pause for a moment, while everyone but Chad imagines Chad getting hit by a bus, and secretly you all smile a little. "We'll start with something small, lightweight. We just want to be able to know who's doing what and where we are in the process." With a little more wrangling, you're able to get everyone on board. You find a good (free!) engineering-centric system, because at this point you don't have anything but some code and some ideas. You need a way to track "who is writing what", "what is still left to write", "what is working", "what is not working", and "how long is this taking".
===
It is 18 months later. You have business cards. Chad wants the company to have a "light, open" culture, so your business card just says "Tanya, Engineering Master" and the company logo, and your various contact methods including your twitter handle. Your little idea and 12 million dollars later (Chad has been doing a lot of fundraising and not much coding) now is a Product, and people are actually using it and Chad has hired several people to figure out how to get people to pay for it and now instead of you and your four (three, really; thanks Chad) friends doing the programming there's now a dozen devs and you're not so much doing any coding as you are trying to make sure everyone else is doing their work.
It's still been a rush to see your creation grow and evolve and suddenly be introduced into the world... and promptly break. Badly. In a lot of very, very interesting ways. And you need a way to track customer's reports. That sounds familiar... Yes, in fact, you need a ticketing system. But wait, you HAVE a ticketing system! It's free, and everyone is already using it, so you can just use that, right?
Well... maybe. Here's the thing: a customer (which in this case is the same as a user, though sometimes you wish you had gone the Twitter/Facebook route and designed something where the users and the customers are different) has a very different expectation around "work". The customer wants to know that the behaviour they're experiencing is sub-optimal. They want to know when it will get fixed, and they want to know how long it will take, and they want to know who to harangue to get the behaviour fixed if it's not happening fast enough. So does it really make sense to use the same ticketing system to track "user reports" when you're already using a tool that tracks "engineering workflow"? That's probably not a great idea...
So now either you have two ticketing systems (and you have to find a way to make them talk to each other, because some (but not all) of the customer reports will be things that engineering has to fix), OR you have one ticketing system and you have to track two different metrics in one tool and figure out how to convert one kind of ticket to another kind of ticket (and back) internally.
And now the sales team wants a way to track leads and followups and contracts.
And now the desktop support team wants a way to track who needs or wants what and whose laptop got lost and how much it cost to replace it (Chad, you do not need a top-of-the-line MacBook Air if you're just going to leave it on the plane again).
And now there's a real problem, because the tool you're using purports to be a one-size-fits-all tool, but seriously, does anyone actually believe that?
And also, how did you, the woman with the CS degree, become the person who makes these decisions? You're a co-founder! You have equity!
Ticketing systems are important. But there a lot of them and they all do some things well and other things badly, and none of them do everything for everyone well. And often they are only an afterthought, which get crowbarred into positions where they are totally unsuited, and then people go out of their way to not use them (because no one wants to use a bad tool). So you have to make decisions, and often those decisions have knock-on effects that are totally unpredictable. And there's not a "right" answer. There's just a series of choices that feel like "more bad" and "less bad".
===
It's now two years later.
You took your equity and your title and went off to do something else. You still see Lacy every so often at conferences. Chad is now working at YCombinator, but you don't talk to him; you don't need money that bad, and the last interaction with him left a bad taste in your mouth. He's not quite a missing stair yet, but you're determined to avoid him if you can (and warn everyone you work with about him).
You spent some time coding with a big company but it feels too much like assembly line work. Plus, they had a horrible ticketing process, which no one used anyway, which led to lots of confusion. You've been having ideas about integration: about how to create a tool that allows different ticketing systems to talk to one another automatically, to remove as much of the human element as possible, but it's a tricky concept: ticketing systems are complicated and messy and getting the right tool for the right job often means trying several tools before settling on the right one...
===
Footnote: this essay owes a huge debt to the really excellent Paul Ford issue of Bloomberg News, "What is Code": http://www.bloomberg.com/graphics/2015-paul-ford-what-is-code/ . I encourage you strongly to read it. Make some time; it's a big chunk of text.
Comments
Post a Comment