Raising a ticket — It isn’t like raising your hand in class… not one little bit… not even slightly.
Whenever I go to raise a ticket, I either immediately think of the time in school where you raise your hand to answer a question or when you would stroll up to the meat counter in a supermarket and take a ticket and wait your turn. We use Jira, the developers enjoy it, it’s fairly easy to break down tickets and integrates into our good friend Slack. The first ticket I raised was an easy one. When you aren’t sure of the implications or what it really means, you don’t think about it. I mean, what could possibly go wrong? I just filled out some forms and raised the ticket for our developers. They will get round to it soon, I hope?
What soon began to unfold was a piece of string I couldn’t see the end of. Apart from the marketing team, I sit in an office of developers. Developers who enjoy doing what they do. But they work in a different way to what I (and I am sure most marketeers and salesmen) work and approach things. Developers are pragmatic with technical problems. They find the bigger picture. They handle a ticket and place this right within how it affects the project and analyse its importance.
The first ticket I submitted, had nothing attached to it. I mean nothing. I gave the ticket a name, and nothing more. Didn’t assign it to anyone and nor did I make any effort (wasn’t aware it was required) to explain the ticket in any depth. Now, I am still no expert, I still have similar tendencies. You can get away with being a little brief within a start up.
We all sit in an open office at Drum making it easier to just have a discussion. That saves me a little bit. But at the same time led me to think it was just like raising your hand in class as a six-year-old and shout out ‘Miss, miss, Miss!’ over and over again.
When you are six, it can sometimes be that easy. That was how it was right? Walking up to the front of the class. Discussing the question in hand. Providing an answer to the question (at least your rationale). And how things have a knock on effect. Then coming back next week and standing up in class again to talk about the benefits. The teacher then tells you ‘good job’ or at least we hope!
But it isn’t like that in the startup. Sure, we can wheel around to one another on our fancy chairs and have a conversation. But in a startup where everyone is accountable, it isn’t feasible to be submitting a ticket and allowing people to be reading your mind. In class, the teacher could fire questions at you to try and understand your thought process. A startup requires more of the ‘entrepreneurial’ spirit. The, get up and go with the drive to make stuff happen. That’s why raising a ticket is absolutely nothing like raising your hand in class.
There is never a strong pat on the back for a similar use of the arm in an office. Aside from the fact no one enjoys handling bugs or being told there is a bug. If only we could build everything perfectly from day one? And if only browsers remained similar in their code and functionality. But again, as mentioned in previous posts, this is what makes working for a startup so much fun and fulfilling. Barriers don’t appear here. When something crops up, we all fix it together with the same level of urgency. It is expected for us as part of the team to be at the forefront of any potential issue, way before a user comes across it.
Weak recipes tend to lead the chef to a weak cake (we always think about cake). Even the most talented chef, Nigella Lawson, might find it hard if she was handed a vague and disjointed recipe. You just have to look towards the Great British Bakeoff to see what a vague recipe can deliver. These contestants are clearly extremely talented. But when left to a vague recipe (usually the second task) in an episode a varying set of results appear. Some good, some not so good. Some even end cooking a completely different cake! Now we are getting hungry.
But imagine handing the team of developers hear a brief title with just one or two bullet points. No direction and an extremely brief overview have misled our developers in the early days of Drum. Frequently, things became misinterpreted, tickets are closed in the belief the bug has been squashed. And when has that done any good? So a learning curve needed to happen in a rapidly growing company. Overnight, short brief tickets couldn’t afford to go back and forth. They needed to be self-explanatory. They need to tell the developers the whole story, nothing but the story. This includes:
- Identifying the issue and explaining the issues
- Explaining the environment, multiple environments?
- Explain the expected experience
- What needs changing
- Benefits of changing
- Assigning the urgency
- Assigning the correct developer
Here is the before and after comparison:
Each tickets to become its own mini story. You need the developer to buy into the ticket and understand its importance. Raising your hand in class is about delivering a one-word answer, usually the correct answer. Everyone else within your classroom understands the context.
The teacher acts as an adjudicator to clarify answers and the other pupils in the class can fire additional questions. When in a startup, don’t simply raise your hand and think everyone will turn to you give you their undivided attention. Be prepared to take the responsibility for each and every ticket and the progress of your start up.
