That's not Agile!
I cannot tell you how often these words are uttered these days. Arwafn has gone over the cliff, and Nerdhaven has had to publicly walk back from its launch posture of "Wow, look at this!" to the less inspiring message of "Watch this space."
Upper management is involved to an alarming degree.
Faced with the possibility of completely shutting down Arwafn, dev effort was flung at the TURN issue to determine which customers could retain the feature and which could not. The SMEs drew a line in the sand and in the end, about a third of our customers could keep the feature.
Which would be encouraging, if it weren't for the filters. Arwafn has more than a few, and two of them in particular are near total flops. Both are based on fields that customers have never been required to supply. We'd assumed they were, and our limited beta tests looked promising. Data flowed in, and the filters acted on that data.
Trouble was, that data was crap. For some customers, Filter A's key field was being populated only 20% of the time - or was co-mingled with another field, rendering it unusable. In beta, these filters appeared to work, but what they would show was wildly inaccurate.
In beta - our users were not doing a rigorous comparison between their system's data, and what Arwafn was showing. Our users viewed the beta sessions as a preview - play time. And while they surely care about the accuracy of the report - they evaluated Arwafn based on what they imagined it was doing.
Fellow UXers of the world: learn from me. Spell out exactly what you want your beta testers to do. If you need them to do system testing, you need to tell them that. Regardless, you should ensure that your feature has system testing with live data before you green light it for wider release.
But some customers had good data. And there were options for us to explore - an alternate key field might get us there. It would mean an immense amount of re-tooling, though. The thought of it made my mind hurt.
Filter A was the good one.
Filter B was based on a field that not only had issues with being populated only some of the time, when it was populated it was almost always the right kind of data - at the wrong point in time. Filter B is supposed to present its value as of a specific moment - and it was showing a value that was a few days later. And those few days were killing us.
We had a few customers who were happy to get the data at all - even asked for Filter B to be left on despite the time shift - but Arwafn is supposed to follow a standard. A few days later was not the standard. With over 100 clients active on the report, we only found 1 who had a working Filter B.
Worse, when I spoke with Data about our prospects for getting Filter B working, I read out the point in time requirement and Data just groaned. "If we ask the customers to send us an entirely new set of data, we could get closer to what is needed. But the literal criteria for Filter B does not exist in any data element that I know of."
For the millionth time, I ask myself - How is it I am learning this now? How did we get to the point where we have code in production, and I literally just found out that the data point I need does not exist?
And I don't have a good answer for that.
UX was primarily focused on the front end stuff - what the user sees and touches - and the back end stuff (where the digital bodies are buried) was supposedly the realm of other smart people. Our former UXDir encouraged us to provoke the change by asking for things without looking under the hood. "We'll figure it out," they'd say, "we can't design based on just what we have now, or we'll never make new things."
And there is a point there. If every design is vetted against the current codebase, legacy code limits what your customers get.
Fellow UXers of the world: learn from me. If a feature is dependent on a lot of user supplied data, design it to fail gracefully when some or all of those elements don't show up.
That's pretty basic, but its one thing to nod at a good idea in principle, it's quite another to realize that your feature is built on a house of cards while you are working on it. When all of this was happening, it all seemed so...right. And now Arwafn was a pile of roadkill in the middle of the road.
* * *
And everyone was rushing in to help. Which is great, but with upper management calling folks out, the agile culture in NerdHaven was beginning to crack.
Upper management said: Turn off Filters A and B. NOW.
And NerdHaven jumped to obey. Devs created branch code, stopped all other feature work and slammed two shutoff switches for Filters A and B into production. Devs were up in arms, because upper management never tells NerdHaven to work on this feature or that feature - and now they were.
But a fire was burning and this would put it out, so everyone got it done.
Next up was the TURN problem - and dear God what a mess. Telling upper management that the key value for Arwafn is being adulterated by our product was the easy part. Management realized there was a problem and TURN fit that bill. Resources were allocated to fix this issue and commandments were given.
FIX THIS. NOW.
The problem was, as we fixed TURN for Arwafn, we realized that TURN was used all over our product - and fixing it for just Arwafn would mean that other features would be out of synch with Arwafn.
Mind you, I'd always thought of Arwafn as a modest feature - and it is. Just a little report in one corner of the product. But TURN is a value that is used in the NumeroUno feature, and Nachen work, and more besides. I spoke with Sprint when we started fixing TURN and they gave me the full list of what they knew would be affected and it was alarming.
Then, in the middle of one of our situation room meetings for Arwafn, I started spelling that out to the group.
This launched another round of anxiety telephone and soon fixing the TURN issue for Arwafn, became fix TURN everyGoddamnWhere.
Which meant the scope of work just ballooned - which naturally had to be reported up the food chain.
Upper management's response was predictable:
FIX EVERYTHING NOW. AND SWEAR IN BLOOD THAT THIS WILL BE THE LAST OF THE TURN PROBLEMS.
Now, you're an agile dev shop and you get this kind of directive. What do you say to that? There is absolutely no guarantee that we will get everything in one go.
The SMEs are being asked to sign in blood that everything is fine from their perspective - and they are already anxious about the current state of things. They don't see everything and now they want to see EVERYTHING.
We've got SMEs crawling down our necks asking for more access and more analysis. And then Gumby's asked to provide proof that UX has discussed our designs with SMEs (in a meeting, with no warning - so they don't have that information, which itself becomes a thing)...
...and now we're careening towards Waterfall.
Waterfall: an epithet in dev shops. Shorthand for let's add more analysis and more documentation and more signoffs and when that doesn't result in a perfect product - slow down and add still more analysis/docs/signoffs. Lather, rinse, repeat.
All the UX folks hate this idea with a passion, and I pointedly ask if this change is the new way of things going forward, or just until we get Arwafn/TURN fixed.
Gumby is direct, "this is going forward."
I feel like throwing up. Yes, we steered the company in the ditch, but we learned a boatload and absolutely nobody wants to go through that again. We will be more vigilant, and we don't need more goddamn documentation.
I point out (for the umpteenth time) that more SME contact in our process would not have caught our data issues. The SMEs don't go under the hood any more than UX does. But we have experts in house who do, and we will be joined at the hip with them the next time we roll out features driven by client data.
Let's do that, I say, before we get all process heavy. We are already getting berated for being slow, all this bloat is not going to make software happen faster.
Wasn't this why Agile was invented? to prevent this kind of stuff?
But the powers that be are unassailable - we will add process and hope this will get better - or blow over.
Or something.
* * *
Today was a day that threatened to be the end of all things. I was roped into three meetings in a row, one about some future data issue I knew absolutely nothing about, one with the SMEs to discuss their (well aged) laundry list of desired features (that have absolutely nothing to do with Arwafn/TURN), and one that I was dreading most of all: a review of all our Arwafn/TURN work with the SMEs.
The laundry list meeting was a total bust - the SMEs want us to build what they want (as opposed to what Product has prioritized, or what the customers want). Their list of wants will solve issues that the SMEs have experienced, but may not do much to address root causes of user pain. And it is very unclear if all the items on the list should be solved with more computer code. Some might literally be user error. And all of the items are broadly worded concerns that cannot be vetted without specific examples of the behavior in question.
Sprint is in the meeting with Gumby and I and (heroically) volunteers to vet the list for the SMEs. I say (as diplomatically as I can) that this list should be given to our support staff, who can explain the inner workings of the application and perhaps get to the root of the matter without us trying to build a solution based on a speculative issue. I'm not sure the message took, but Gumby and Sprint are clearly way ahead of me. They want to do right by the SMEs, but route support work to support resources.
And then the review meeting. I wanted to keep my hackles in check, but this had all the hallmarks of being a "why did you put the button there?" kind of discussion. One of the SMEs, Ihaq, had ridiculed our design of a new form and I was dreading a new session of "Move that button, because I want you to."
The lead SME was Voldemort: brilliant, hardworking and overworked beyond all reason. They started out with a few probing questions which Gumby fielded for the first few minutes. Ihaq was there and clearly confused about what we would be running through. They had a few questions they wanted to run through before we got started. Ihaq's questions are never brief, and usually involve follow ups.
It was getting awkward.
When we got to the list of feature work, Gumby gave me the podium.
At the risk of appearing arrogant - I am pretty good at explaining things. So long as I understand something, I can transfer that information to pretty much anyone.
And the work we've been neck deep in for the past two months is stuff I can't help but understand. I wake up in the middle of the night thinking about this stuff.
Grok it? Hell, I wrote it.
And I go to town. You have a question, Ihaq? I got you. Voldemort wants clarity on the hideously technical matter of historical TURN values? I got you, too.
And as soon as I realize that the SMEs are (rather predictably, I might add) solid professionals trying to do their jobs - the tension goes out of the meeting. The SMEs are not there to grill us, or re-design our work - they are literally trying to understand where the work is now and where it will be when we are all done.
Gumby asked our new UXer, Dash, to study our stakeholder demos and they pointed out a host of issues with how we present our work and how it is consumed and retained.
Predictably, shortcomings in our presentations leave lasting misunderstandings in the SMEs as well as others in our organization.
Having this Q and A session allowed us to close that gap for Voldemort and Ihaq at least, and at the end of it - it was a really good feeling.
Voldemort was exultant "That was awesome."
And I cannot tell you how much better that made damn near everything.
Yes, we have a metric sh!t-ton of work ahead of us, but we are beginning to round the corner and we've started to mend things with the SMEs.
The technical work is in flight, the release date is set. Our culture has taken a massive hit to the jaw.
But if today was any indication-
We can do this.
Showing posts with label Growing the hell up. Show all posts
Showing posts with label Growing the hell up. Show all posts
Thursday, June 04, 2015
Derailment, part IV
Friday, May 22, 2015
Derailment, part III
Continued from Part II
I literally go from the airport, to Gumby's office, and thence to G's house to watch basketball. I'm absolutely shredded and a long weekend away from it all could not be better timed.
Hoops with the gang is sacred. I know next to nothing about basketball, but the gang puts up with me anyway. We eat a lot, drink a lot and loaf a lot - which is good for your mental state.
And my mental state needed a helping hand. I'd booked my PTO back when the West Virginia trip was not a threat - then the trip was moved to be right on top of Hoops.
Not cool. I ride out the weekend and soak up the camaraderie. Then I slouch back home to deal with Arwafn.
First there's the anxiety tag: Nerdhaven, like any business, has factions - and the loudest faction at present is the SMEs. The SMEs are frontline staff, up to their eyes in subject matter expertise, but also expected to perform a slew of customer contact, sales & support.
Since they have real jobs, they're not deeply plugged into what goes on back at Nerdhaven, and a lot of the work that our UX team does seems (to them, at least) to come from outer space. There are a lot of reasons for this: distance, iterative design, and a long history of unsatisfactory dealings with UX.
We don't build exactly what they ask for. Largely because every request out of the SMEs starts with a solution. They are smart people, and they know what they want.
Being in UX, we know that any solution causes more problems - and the trick is to look for root causes before you "just build what they ask for." It doesn't mean that UX folks have the answers (lord knows we don't) but our approach is to get more data to see if we can gain enough insight to make a 'big win' kind of solution.
The SMEs don't have time to wait for that kind of thing. They need answers yesterday - and are confident that their chosen approach will begin paying off immediately. They may be right - but one of the things we hear from our end users is classic alert fatigue: the users have more warnings then they have time to respond to. And a lot of the requests from SMEs amount to 'gimme a new alert option.'
Its difficult, and frequently frustrating for both UX and the SMEs and I don't see a good way out of it.
* * *
With that bit of background, you can appreciate the amount of anxiety tag that is ripping through the SMEs after the launch of Arwafn. They've done demos of the report in front of clients. They've described its many features and clients have oooohed and aaaaaaahed. And now the product has been flipped on for their clients and the result is a big, wet, thud.
And it's the SME on the horn or in the room with the client having to take the abuse, not me. Nobody in UX is on the phone with a baffled customer trying to explain why their numbers don't add up. Historically, the SMEs have to run with whatever features make it out of UX and they quickly share the skinny on what they've seen so they can go into client contact forewarned and forearmed.
I'm eventually cc'ed on a series of messages between the SMEs "Did you hear? This filter is a failure across the board!!" and that SME tells the next one, and the next - and soon you have a whirlwind of anxiety making its way to the higher ups.
The higher ups have seen this movie - and they rapidly direct their power on various minions who are ordered to bring them clarity about what the hell is going on. One of the higher ups is Gumby, new to Nerdhaven and that means I'm getting pulled into their office and other meetings to explain everything I know in detail.
I spell it out over and over again. I state my mistakes and assessment of where the product is at the moment. I spell out the issue with TURN codes and list out a half dozen other things that could be made to work better.
Then I do it again in front of the the execs. I have to go before the Wizard, who is mighty, but never really says much. I live in mortal terror of having to go before MGM, who is mightier still, but those fears are thankfully not realized.
Airing the TURN issue in front of this crowd means we are going to fix the issue. HockeyOne will be happy, Ajax will be relieved, and our client's data will at last be made whole.
And the exec level folks will make our lives an unending hell until all of this is done.
Product is leaving the company - completely unrelated to this situation, they just got a VP gig elsewhere, so this 'fix the Arwafn' effort is going to need a point person.
Absolutely no one volunteers. So, after a loooooong pause, Gumby raises a hand.
As the newest manager at Nerdhaven, Gumby has a free pass in the situation. They had nothing to do with what has happened up until now. Their role is enthusiastically endorsed by a roomful of cowards.
* * *
The boss is in this up to their neck, and UX is now on the hook in a larger sense. Gumby has to prevail.
And Nerdhaven has to fix Arwafn. All of it.
I literally go from the airport, to Gumby's office, and thence to G's house to watch basketball. I'm absolutely shredded and a long weekend away from it all could not be better timed.
Hoops with the gang is sacred. I know next to nothing about basketball, but the gang puts up with me anyway. We eat a lot, drink a lot and loaf a lot - which is good for your mental state.
And my mental state needed a helping hand. I'd booked my PTO back when the West Virginia trip was not a threat - then the trip was moved to be right on top of Hoops.
Not cool. I ride out the weekend and soak up the camaraderie. Then I slouch back home to deal with Arwafn.
First there's the anxiety tag: Nerdhaven, like any business, has factions - and the loudest faction at present is the SMEs. The SMEs are frontline staff, up to their eyes in subject matter expertise, but also expected to perform a slew of customer contact, sales & support.
Since they have real jobs, they're not deeply plugged into what goes on back at Nerdhaven, and a lot of the work that our UX team does seems (to them, at least) to come from outer space. There are a lot of reasons for this: distance, iterative design, and a long history of unsatisfactory dealings with UX.
We don't build exactly what they ask for. Largely because every request out of the SMEs starts with a solution. They are smart people, and they know what they want.
Being in UX, we know that any solution causes more problems - and the trick is to look for root causes before you "just build what they ask for." It doesn't mean that UX folks have the answers (lord knows we don't) but our approach is to get more data to see if we can gain enough insight to make a 'big win' kind of solution.
The SMEs don't have time to wait for that kind of thing. They need answers yesterday - and are confident that their chosen approach will begin paying off immediately. They may be right - but one of the things we hear from our end users is classic alert fatigue: the users have more warnings then they have time to respond to. And a lot of the requests from SMEs amount to 'gimme a new alert option.'
Its difficult, and frequently frustrating for both UX and the SMEs and I don't see a good way out of it.
* * *
With that bit of background, you can appreciate the amount of anxiety tag that is ripping through the SMEs after the launch of Arwafn. They've done demos of the report in front of clients. They've described its many features and clients have oooohed and aaaaaaahed. And now the product has been flipped on for their clients and the result is a big, wet, thud.
And it's the SME on the horn or in the room with the client having to take the abuse, not me. Nobody in UX is on the phone with a baffled customer trying to explain why their numbers don't add up. Historically, the SMEs have to run with whatever features make it out of UX and they quickly share the skinny on what they've seen so they can go into client contact forewarned and forearmed.
I'm eventually cc'ed on a series of messages between the SMEs "Did you hear? This filter is a failure across the board!!" and that SME tells the next one, and the next - and soon you have a whirlwind of anxiety making its way to the higher ups.
The higher ups have seen this movie - and they rapidly direct their power on various minions who are ordered to bring them clarity about what the hell is going on. One of the higher ups is Gumby, new to Nerdhaven and that means I'm getting pulled into their office and other meetings to explain everything I know in detail.
I spell it out over and over again. I state my mistakes and assessment of where the product is at the moment. I spell out the issue with TURN codes and list out a half dozen other things that could be made to work better.
Then I do it again in front of the the execs. I have to go before the Wizard, who is mighty, but never really says much. I live in mortal terror of having to go before MGM, who is mightier still, but those fears are thankfully not realized.
Airing the TURN issue in front of this crowd means we are going to fix the issue. HockeyOne will be happy, Ajax will be relieved, and our client's data will at last be made whole.
And the exec level folks will make our lives an unending hell until all of this is done.
Product is leaving the company - completely unrelated to this situation, they just got a VP gig elsewhere, so this 'fix the Arwafn' effort is going to need a point person.
Absolutely no one volunteers. So, after a loooooong pause, Gumby raises a hand.
As the newest manager at Nerdhaven, Gumby has a free pass in the situation. They had nothing to do with what has happened up until now. Their role is enthusiastically endorsed by a roomful of cowards.
* * *
The boss is in this up to their neck, and UX is now on the hook in a larger sense. Gumby has to prevail.
And Nerdhaven has to fix Arwafn. All of it.
Thursday, May 21, 2015
Derailment, part II
Continuing from Part I
Arwafn is coming undone. And for a reason I first started hearing about a month after I came to Nerdhaven.
One of the base data elements of Arwafn is something I'll call TURN. TURN is a series of codes that factor into the key datapoint of the Arwafn report. Calling it the lynchpin of the report would not be overstating it. The customer sends Nerdhaven TURN codes and we group them, count them, and make them look beautiful.
Classically, a TURN code is a single character value. Like T, or U, or R, or N. And Nerdhaven's process is built on this standard.
Single character come in, single character go into database. Arwafn is happy.
But what if TURN comes in as multiple characters?
Instead of T, let's say it comes in as T<*
Then what?
This question had been posed and answered for me by Noddy. Noddy had raised an issue about multichar TURN codes in their usual manner: Airily, arrogantly "raising a concern" via email to a slew of senior staff. Runner and I were cc'ed so we would be aware of his brilliance.
Look at me!
That's Noddy, and the truth is - its hurts their message, since the resulting eyeroll drowns out the content. But the issue sounded serious.
According to Noddy, when a multi-character TURN code came in to a system I'll call Dragon, it would get truncated. Dragon would take just the first character and bin everything else.
T<* would become simply, T.
And that didn't sound so bad, and really wasn't bad, until new values were added to the TURN code like NO and TDD. These were values that were distinct from T, U, R, and N.
But if Noddy was right, Dragon would take an incoming code like TDD and convert it to T. NO would become N.
And that really would be a problem. Because now our system would be adulterating client data - and that is not cool. Arwafn would be inaccurate, and other features in our product would be wrong as well. TURN is deep, deep in the works. And Noddy wants us to know he's found this problem.
I remember Heater responding to Noddy's initial email. Heater had a few stories written up to deal with this issue - they'd never been given priority before, but maybe now the time was ri-
Dragonman kills that noise almost immediately. Dragonman is lead dev on the Dragon system, and his response took the wind out of Noddy & Heater.
Here's a count of all the incoming TURNs we've received in the past two months: out of millions of messages, we're only gettting a few hundred N values. Even if all of them were really 'NO' values, its a negligible amount of data.
In other words, Dragonman was saying this is not a problem.
Heater lives in fear of Dragonman, and Noddy never follows up on anything. So that was enough to make them drop the issue.
I'd remember talking with UXDir and they were frustrated that we weren't fixing this issue. "We shouldn't treat this like a tech support call! Who cares if there isn't a lot of volume now? We should make this right, so we future proof the system!"
I also remember talking to Product & suggesting that supporting longer TURN values might be a selling point for our product. Product said we didn't have any data to support that it would be worth it. Between that and the technical pushback, the idea was buried.
Yeah, we truncated the TURN codes, but it didn't matter enough to warrant allocating dev resources to fix it.
* * *
That answer became the party line: We truncate, but so what?
Months later, even I used that line to shoot down Suit when they tried to grandstand on the discovery that OMG, we're truncating TURN values!
Suit was engaging in that same chicken little exercise where "lookee everybody! I found a problem (and gosh, aren't I smart?)" and I was in no mood. I forwarded Dragonman's original response on TURN to Suit and cc'ed about everyone. This is a crap issue, leave it alone.
I felt proud of myself, too. I knew what was going on under the hood with TURN. It's no big deal.
* * *
Rewind to about five months ago. I'm on the phone with Goldeagle, one of our beta testers, and they are looking at their version of Arwafn and they are confused.
The numbers for this item just look wrong. It's way too high, and I think the count is off.
I'd seen this before, but it had always been a setting problem. The user had misconfigured things and broke the output. But a quick check showed that Goldeagle had the settings right. The numbers were just wrong. I told them I would figure out what the problem was.
This was weeks after Arwafn went live to over 100 customers. And this was definitely not good.
I asked BigDog to give me the under the hood data for Goldeagle's report. I do the math and everything adds up to the same crappy numbers Goldeagle was wondering about. And I notice a pattern in the data: the calculation is based on the occurrence of T's out of the total of T's, U's, and R's.
And there are no R's at all.
Which is odd, because Arwafn is report that spans a year or more. In the course of a year, for this particular datapoint - there should be at least an R here and there.
I check again. None.
As all the data I'm looking at is in the Guardian database, I wonder if we're screwing things up somewhere upstream: in Dragon, maybe.
But Dragon doesn't hold data, they take incoming values and slot them into our Guardian db. True, Dragon would be the place where we are truncating TURN codes, but truncating still passes something and I was seeing no Rs at all. Was there a process that was eating the Rs?
And why was it only for this one record? Arwafn has dozens of record lines, each crossing columns with other values. And only this one combination was showing this total lack of Rs.
What the hell?
At this point, I trot over to the other side of the building and visit HockeyOne. They are a code slinger, an expert on incoming client data, and they're one of the folks that are always asking me painful questions when I'm showcasing new features.
HockeyOne lives and breathes in another system that is upstream of Dragon. It's called Lizard. And Lizard is very low level stuff, grabbing up massive volumes of text files sent by our clients and flinging them into the jaws of Dragon.
HockeyOne is a guru of all things Lizard and I start asking them if they have any idea what could be happening to my missing Rs. HockeyOne looks at me with a sort of amused smile and says "have you looked at the KIM fields?"
No. KIM fields are not TURN fields, why the hell would I look there?
"Because if the TURN is too long to go into Dragon, we'll append it to the end of a KIM field and pass a blank TURN value."
Shut
the
front
door.
HockeyOne goes on to explain the problem. Lizard wants to pass all TURN values to Dragon, but it will get an error if it tries to pass a TURN that is longer than 1 character, since Dragon will only take a 1 char TURN code.
Rather than give up, Lizard will look for a neighboring field, KIM, and append the TURN value to it so the data has somewhere to go in Dragon. Lizard doesn't truncate the TURN, it puts it elswhere and passes nothing at all to the TURN code in Dragon.
I start to sweat. "Can you run a query to show me what kinds of extra noise is getting tacked on to Goldeagle's KIM field?"
HockeyOne says "sure!" and writes up byzantine query in a few minutes. They show me a list of values that are in the KIM field, but supposedly came in as values in TURN:
Whiskey Tango Foxtrot? I've never heard of these values coming across in TURN. I ask HockeyOne to make sure - absolutely sure - these values exist in the client's messages to our system. HockeyOne goes deep into the weeds to show me - that these are real values Goldeagle is sending to us AND that they are sending to as as TURN codes.
I ask for samples that prove this, so I can show them to others. HockeyOne has just demonstrated that we are NOT truncating TURN codes, we are moving them elsewhere. Which to downstream features like Arwafn, is essentially the same thing as deleting them, since Arwafn is looking at the TURN field, which ends up blank every time one of these multicharacter values bounces off Dragon's front door.
HockeyOne is excited. They've always hated the fact that Lizard was shoving data in weird places, and they've asked repeatedly for Dragon to take longer values and store them. They give me all kinds of examples of what is going on in Goldeagle's incoming messages - and I find front end examples of this data mangling so I can sell this as a real issue.
Then I get back with Goldeagle, and ask them what is going on with these other codes. What do they mean? and why are they being sent in a field that should only have 6 discrete values?
Goldeagle tells me that their system uses those other values to track TURN as well as an entirely different dimension called BLES. In their system, the code BLES = R and also has some additional meaning as well. UB is also the equivalent of R.
Which means I've found my missing R values, they are being sent as multichar values in TURN, which means Lizard isn't putting them into our db as TURN values, because Dragon won't let them.
Which means Arwafn is pretty much screwed at this point, because Arwafn only sees TURN values in the Guardian database. If multichar TURN values aren't landing in Guardian's TURN field, they might as well not exist - because to Arwafn - they don't.
I ask HockeyOne how often Lizard would move TURN values into KIM and send a blank value in TURN to Dragon. I mean, I'd always been told we truncate.
HockeyOne is pretty sure that we do this for a majority of our sites. Which means that Goldeagle has a lot of company. And a lot of our Arwafn customers are going to be missing data.
I flip out and go to Data and Heater and declare that the sky is falling. Data tells me that what I am saying is inaccurate. "We truncate."
I show them the messages. "No, we don't. At least not for this site."
My equivocation doesn't help my case. I may have just found an outlier. I email a wider group and provoke an exasperated response from Ajax, who is the sheriff of these kinds of data issues. Ajax is a supremely competent person and they tell me that I'm describing the situation wrong. That any moving of data into different fields would require changes that they would be aware of. And they have seen no such changes.
I take this as "murph, you are full of sh!t" and as I have only one site as a datapoint, I can't press much further. I get more data by hitting up OneTwentyEight to run HockeyOne's byzantine query against all of my beta sites.
More long TURN values show up, noisier ones like "NEG" and "POS" and a slew of things that look like equations. I run this past Data and Sprint and start to get some traction.
Sprint (who is awesome) runs ahead and sorts out a list of what chunks of work would need to be done to get these longer values into our system correctly.
We get Dragonman into the fold and a reasonable solution is proposed. Dragon will create a path for longer values to make it into Guardian. We draft up a list of work to present to Product.
We're on the verge of pitching this plan when all hell breaks lose on Arwafn.
I'm in West Virginia getting an alarmed email message from Product asking what the hell is going on with Arwafn. I'm wrung out from a long day of client visits yet completely unable to sleep - and so I lie in bed and type an epic mea culpa with my thumbs. We didn't go under the hood enough when we were in beta. This is over and above the TURN problem, but this starts the crazy train rolling.
I fly back home and drive straight to the office from the airport and see Gumby and Atlas clearly having a strategy meeting. I make myself available and soon we are in stage one of responding to an epic managerial sh!tshow.
The executives have heard that Arwafn isn't all it was cracked up to be and they are demanding answers.
The execs are flipping out about filters on the report not working - and they are pissed.
And at this point, they have no idea about the issues with TURN.
Its about to get a whole lot worse.
Arwafn is coming undone. And for a reason I first started hearing about a month after I came to Nerdhaven.
One of the base data elements of Arwafn is something I'll call TURN. TURN is a series of codes that factor into the key datapoint of the Arwafn report. Calling it the lynchpin of the report would not be overstating it. The customer sends Nerdhaven TURN codes and we group them, count them, and make them look beautiful.
Classically, a TURN code is a single character value. Like T, or U, or R, or N. And Nerdhaven's process is built on this standard.
Single character come in, single character go into database. Arwafn is happy.
But what if TURN comes in as multiple characters?
Instead of T, let's say it comes in as T<*
Then what?
This question had been posed and answered for me by Noddy. Noddy had raised an issue about multichar TURN codes in their usual manner: Airily, arrogantly "raising a concern" via email to a slew of senior staff. Runner and I were cc'ed so we would be aware of his brilliance.
Look at me!
That's Noddy, and the truth is - its hurts their message, since the resulting eyeroll drowns out the content. But the issue sounded serious.
According to Noddy, when a multi-character TURN code came in to a system I'll call Dragon, it would get truncated. Dragon would take just the first character and bin everything else.
T<* would become simply, T.
And that didn't sound so bad, and really wasn't bad, until new values were added to the TURN code like NO and TDD. These were values that were distinct from T, U, R, and N.
But if Noddy was right, Dragon would take an incoming code like TDD and convert it to T. NO would become N.
And that really would be a problem. Because now our system would be adulterating client data - and that is not cool. Arwafn would be inaccurate, and other features in our product would be wrong as well. TURN is deep, deep in the works. And Noddy wants us to know he's found this problem.
I remember Heater responding to Noddy's initial email. Heater had a few stories written up to deal with this issue - they'd never been given priority before, but maybe now the time was ri-
Dragonman kills that noise almost immediately. Dragonman is lead dev on the Dragon system, and his response took the wind out of Noddy & Heater.
Here's a count of all the incoming TURNs we've received in the past two months: out of millions of messages, we're only gettting a few hundred N values. Even if all of them were really 'NO' values, its a negligible amount of data.
In other words, Dragonman was saying this is not a problem.
Heater lives in fear of Dragonman, and Noddy never follows up on anything. So that was enough to make them drop the issue.
I'd remember talking with UXDir and they were frustrated that we weren't fixing this issue. "We shouldn't treat this like a tech support call! Who cares if there isn't a lot of volume now? We should make this right, so we future proof the system!"
I also remember talking to Product & suggesting that supporting longer TURN values might be a selling point for our product. Product said we didn't have any data to support that it would be worth it. Between that and the technical pushback, the idea was buried.
Yeah, we truncated the TURN codes, but it didn't matter enough to warrant allocating dev resources to fix it.
* * *
That answer became the party line: We truncate, but so what?
Months later, even I used that line to shoot down Suit when they tried to grandstand on the discovery that OMG, we're truncating TURN values!
Suit was engaging in that same chicken little exercise where "lookee everybody! I found a problem (and gosh, aren't I smart?)" and I was in no mood. I forwarded Dragonman's original response on TURN to Suit and cc'ed about everyone. This is a crap issue, leave it alone.
I felt proud of myself, too. I knew what was going on under the hood with TURN. It's no big deal.
* * *
Rewind to about five months ago. I'm on the phone with Goldeagle, one of our beta testers, and they are looking at their version of Arwafn and they are confused.
The numbers for this item just look wrong. It's way too high, and I think the count is off.
I'd seen this before, but it had always been a setting problem. The user had misconfigured things and broke the output. But a quick check showed that Goldeagle had the settings right. The numbers were just wrong. I told them I would figure out what the problem was.
This was weeks after Arwafn went live to over 100 customers. And this was definitely not good.
I asked BigDog to give me the under the hood data for Goldeagle's report. I do the math and everything adds up to the same crappy numbers Goldeagle was wondering about. And I notice a pattern in the data: the calculation is based on the occurrence of T's out of the total of T's, U's, and R's.
And there are no R's at all.
Which is odd, because Arwafn is report that spans a year or more. In the course of a year, for this particular datapoint - there should be at least an R here and there.
I check again. None.
As all the data I'm looking at is in the Guardian database, I wonder if we're screwing things up somewhere upstream: in Dragon, maybe.
But Dragon doesn't hold data, they take incoming values and slot them into our Guardian db. True, Dragon would be the place where we are truncating TURN codes, but truncating still passes something and I was seeing no Rs at all. Was there a process that was eating the Rs?
And why was it only for this one record? Arwafn has dozens of record lines, each crossing columns with other values. And only this one combination was showing this total lack of Rs.
What the hell?
At this point, I trot over to the other side of the building and visit HockeyOne. They are a code slinger, an expert on incoming client data, and they're one of the folks that are always asking me painful questions when I'm showcasing new features.
HockeyOne lives and breathes in another system that is upstream of Dragon. It's called Lizard. And Lizard is very low level stuff, grabbing up massive volumes of text files sent by our clients and flinging them into the jaws of Dragon.
HockeyOne is a guru of all things Lizard and I start asking them if they have any idea what could be happening to my missing Rs. HockeyOne looks at me with a sort of amused smile and says "have you looked at the KIM fields?"
No. KIM fields are not TURN fields, why the hell would I look there?
"Because if the TURN is too long to go into Dragon, we'll append it to the end of a KIM field and pass a blank TURN value."
Shut
the
front
door.
HockeyOne goes on to explain the problem. Lizard wants to pass all TURN values to Dragon, but it will get an error if it tries to pass a TURN that is longer than 1 character, since Dragon will only take a 1 char TURN code.
Rather than give up, Lizard will look for a neighboring field, KIM, and append the TURN value to it so the data has somewhere to go in Dragon. Lizard doesn't truncate the TURN, it puts it elswhere and passes nothing at all to the TURN code in Dragon.
I start to sweat. "Can you run a query to show me what kinds of extra noise is getting tacked on to Goldeagle's KIM field?"
HockeyOne says "sure!" and writes up byzantine query in a few minutes. They show me a list of values that are in the KIM field, but supposedly came in as values in TURN:
- BLES
- UB
- CLAB
Whiskey Tango Foxtrot? I've never heard of these values coming across in TURN. I ask HockeyOne to make sure - absolutely sure - these values exist in the client's messages to our system. HockeyOne goes deep into the weeds to show me - that these are real values Goldeagle is sending to us AND that they are sending to as as TURN codes.
I ask for samples that prove this, so I can show them to others. HockeyOne has just demonstrated that we are NOT truncating TURN codes, we are moving them elsewhere. Which to downstream features like Arwafn, is essentially the same thing as deleting them, since Arwafn is looking at the TURN field, which ends up blank every time one of these multicharacter values bounces off Dragon's front door.
HockeyOne is excited. They've always hated the fact that Lizard was shoving data in weird places, and they've asked repeatedly for Dragon to take longer values and store them. They give me all kinds of examples of what is going on in Goldeagle's incoming messages - and I find front end examples of this data mangling so I can sell this as a real issue.
Then I get back with Goldeagle, and ask them what is going on with these other codes. What do they mean? and why are they being sent in a field that should only have 6 discrete values?
Goldeagle tells me that their system uses those other values to track TURN as well as an entirely different dimension called BLES. In their system, the code BLES = R and also has some additional meaning as well. UB is also the equivalent of R.
Which means I've found my missing R values, they are being sent as multichar values in TURN, which means Lizard isn't putting them into our db as TURN values, because Dragon won't let them.
Which means Arwafn is pretty much screwed at this point, because Arwafn only sees TURN values in the Guardian database. If multichar TURN values aren't landing in Guardian's TURN field, they might as well not exist - because to Arwafn - they don't.
I ask HockeyOne how often Lizard would move TURN values into KIM and send a blank value in TURN to Dragon. I mean, I'd always been told we truncate.
HockeyOne is pretty sure that we do this for a majority of our sites. Which means that Goldeagle has a lot of company. And a lot of our Arwafn customers are going to be missing data.
I flip out and go to Data and Heater and declare that the sky is falling. Data tells me that what I am saying is inaccurate. "We truncate."
I show them the messages. "No, we don't. At least not for this site."
My equivocation doesn't help my case. I may have just found an outlier. I email a wider group and provoke an exasperated response from Ajax, who is the sheriff of these kinds of data issues. Ajax is a supremely competent person and they tell me that I'm describing the situation wrong. That any moving of data into different fields would require changes that they would be aware of. And they have seen no such changes.
I take this as "murph, you are full of sh!t" and as I have only one site as a datapoint, I can't press much further. I get more data by hitting up OneTwentyEight to run HockeyOne's byzantine query against all of my beta sites.
More long TURN values show up, noisier ones like "NEG" and "POS" and a slew of things that look like equations. I run this past Data and Sprint and start to get some traction.
Sprint (who is awesome) runs ahead and sorts out a list of what chunks of work would need to be done to get these longer values into our system correctly.
We get Dragonman into the fold and a reasonable solution is proposed. Dragon will create a path for longer values to make it into Guardian. We draft up a list of work to present to Product.
We're on the verge of pitching this plan when all hell breaks lose on Arwafn.
I'm in West Virginia getting an alarmed email message from Product asking what the hell is going on with Arwafn. I'm wrung out from a long day of client visits yet completely unable to sleep - and so I lie in bed and type an epic mea culpa with my thumbs. We didn't go under the hood enough when we were in beta. This is over and above the TURN problem, but this starts the crazy train rolling.
I fly back home and drive straight to the office from the airport and see Gumby and Atlas clearly having a strategy meeting. I make myself available and soon we are in stage one of responding to an epic managerial sh!tshow.
The executives have heard that Arwafn isn't all it was cracked up to be and they are demanding answers.
The execs are flipping out about filters on the report not working - and they are pissed.
And at this point, they have no idea about the issues with TURN.
Its about to get a whole lot worse.
Wednesday, April 29, 2015
Derailment, part I
All at once, work is exhilarating and terrible.
Arwafn is rolling out to the world, and while the internal reviews are good - the only score that counts is the one you get from the end users.
The early reports are the worst. Not because they are bad, but because they usually represent incomplete opinions, initial reactions - delight in something new. They are passed along by hopeful co-workers who want to believe the same thing I do: that it has worked. That our customers are pleased with what we've done.
Somehow, I always manage to fall for this. I supposed to be dispassionate, but after a year of working on the project, I want success. I want happy customers.
And so I flatter myself to think that this time, we did it right.
And then the second round of reviews roll in.
Second round is usually polite, deferential even. "Hey, I'm wondering about this bit here..."
By the third round, you know you have problems, and you start looking for patterns. This is not a drill. You'll need to fix this.
Bin the ego and lean into this, because it's going to hurt.
There is no worse feeling in UX than watching a customer delight in seeing what they wanted to see - and then watch them realize their mistake.
Oh...I guess that isn't working.
* * *
The flaw in Arwafn that managed to make it all the way into production is the most maddening of all. Arwafn relies on customer supplied data - in the form of a data feed.
Data flows from a client's system and flows into Arwafn. Arwafn turns the tidal wave of data into an intelligible grid and allows the user to manipulate it in several ways. We've checked the design against the industry standards, we've verified that the added functionality was wanted by the customers - we've set up beta testers with their live data in Arwafn and let them play with it to get their responses.
And we've had QA try to beat it to death with everything short of a tire iron.
Arwafn came through all that. The board was green.
But we'd missed something - something that was admittedly pretty hard to quantify, but something that we could have noticed earlier.
The client data feeds are crap.
We were like engineers building a colossal aqueduct across miles of countryside and then aiming it at a dry lake.
Or, more accurately, a bog.
Some customers follow the agreed on specification for supplying the data and - for them - all is well. But for a still to be determined group of customers, they send us garbage - and for them, Arwafn is smelling pretty foul.
And it's no good pointing the finger back at our clients. We told them Arwafn was a new feature - we did not tell them it might work if your data isn't godawful.
Nor did we design the report to degrade gracefully. That principle I began learning with regards to crap browsers ages ago was noticeably absent when I baked out the stories to build this report.
It's a basic idea - and yet I'm re-learning it for the umpteenth time:
Okay, it works when A, B and C are present. What if I take away A?
Easy. It looks like it's still working - but isn't.
What if I take away B?
Same thing.
And so on. Any of those questions getting some real thought would have resulted in what NerdHaven is now rapidly deploying to the field. Switches to enable the functionality dependent on A.
Don't have A? We'll shut that off for you.
No B? We'll turn that off, too.
The rest will still work.
That's how it should have been designed from the get go, but in my naiveté thought "Of course, they'll all be sending us this information. How could they not?"
And they're not. Or rather, I wish they just weren't - that would have been easy to spot.
When we did beta sites, no data would have resulted in obvious failures. But that didn't happen. We had data flowing into our UI, and the dependent features worked as expected.
Did we ask users to go through our report line by line to ensure accuracy?
We did not.
Did we ask our internal experts to crawl around under the hood of our beta sites?
We did not.
All of this, every new expression of the problem, slams home into whatever professional pride I'd managed to save up. Three weeks ago, Runner and I were heroes. Now, I'm being forwarded emails from our SMEs where they are describing Arwafn's failings in scathing terms. I'd have hoped I would have been included in those messages when they were sent, but I get them secondhand. After they've been routed through management.
Atlas has been unfazed by this - they point out we've had data issues in the past, and the scope of the issue is being overblown. I feel genuinely ill. Atlas and Gumby finished up my performance reviews before this all blew up. I came out really well in their eyes. I was proud.
And now this. The folks who sang my praises are now being hauled in front of the executive leadership team.
And there is something else. Something that goes beyond a customer sending us crap data.
Something I'd heard about and went after.... just way too late.
Arwafn is rolling out to the world, and while the internal reviews are good - the only score that counts is the one you get from the end users.
The early reports are the worst. Not because they are bad, but because they usually represent incomplete opinions, initial reactions - delight in something new. They are passed along by hopeful co-workers who want to believe the same thing I do: that it has worked. That our customers are pleased with what we've done.
Somehow, I always manage to fall for this. I supposed to be dispassionate, but after a year of working on the project, I want success. I want happy customers.
And so I flatter myself to think that this time, we did it right.
And then the second round of reviews roll in.
Second round is usually polite, deferential even. "Hey, I'm wondering about this bit here..."
By the third round, you know you have problems, and you start looking for patterns. This is not a drill. You'll need to fix this.
Bin the ego and lean into this, because it's going to hurt.
"Customer has some questions about this filter. It doesn't seem to work"
"...numbers aren't adding up. They want to know why..."Third, round - the co-workers have stopped being nice. They want to know what the problem is. And how those problems managed to make it through QA and beta testing.
There is no worse feeling in UX than watching a customer delight in seeing what they wanted to see - and then watch them realize their mistake.
Oh...I guess that isn't working.
* * *
The flaw in Arwafn that managed to make it all the way into production is the most maddening of all. Arwafn relies on customer supplied data - in the form of a data feed.
Data flows from a client's system and flows into Arwafn. Arwafn turns the tidal wave of data into an intelligible grid and allows the user to manipulate it in several ways. We've checked the design against the industry standards, we've verified that the added functionality was wanted by the customers - we've set up beta testers with their live data in Arwafn and let them play with it to get their responses.
And we've had QA try to beat it to death with everything short of a tire iron.
Arwafn came through all that. The board was green.
But we'd missed something - something that was admittedly pretty hard to quantify, but something that we could have noticed earlier.
The client data feeds are crap.
We were like engineers building a colossal aqueduct across miles of countryside and then aiming it at a dry lake.
Or, more accurately, a bog.
Some customers follow the agreed on specification for supplying the data and - for them - all is well. But for a still to be determined group of customers, they send us garbage - and for them, Arwafn is smelling pretty foul.
And it's no good pointing the finger back at our clients. We told them Arwafn was a new feature - we did not tell them it might work if your data isn't godawful.
Nor did we design the report to degrade gracefully. That principle I began learning with regards to crap browsers ages ago was noticeably absent when I baked out the stories to build this report.
It's a basic idea - and yet I'm re-learning it for the umpteenth time:
Okay, it works when A, B and C are present. What if I take away A?
Easy. It looks like it's still working - but isn't.
What if I take away B?
Same thing.
And so on. Any of those questions getting some real thought would have resulted in what NerdHaven is now rapidly deploying to the field. Switches to enable the functionality dependent on A.
Don't have A? We'll shut that off for you.
No B? We'll turn that off, too.
The rest will still work.
That's how it should have been designed from the get go, but in my naiveté thought "Of course, they'll all be sending us this information. How could they not?"
And they're not. Or rather, I wish they just weren't - that would have been easy to spot.
When we did beta sites, no data would have resulted in obvious failures. But that didn't happen. We had data flowing into our UI, and the dependent features worked as expected.
Did we ask users to go through our report line by line to ensure accuracy?
We did not.
Did we ask our internal experts to crawl around under the hood of our beta sites?
We did not.
All of this, every new expression of the problem, slams home into whatever professional pride I'd managed to save up. Three weeks ago, Runner and I were heroes. Now, I'm being forwarded emails from our SMEs where they are describing Arwafn's failings in scathing terms. I'd have hoped I would have been included in those messages when they were sent, but I get them secondhand. After they've been routed through management.
Atlas has been unfazed by this - they point out we've had data issues in the past, and the scope of the issue is being overblown. I feel genuinely ill. Atlas and Gumby finished up my performance reviews before this all blew up. I came out really well in their eyes. I was proud.
And now this. The folks who sang my praises are now being hauled in front of the executive leadership team.
And there is something else. Something that goes beyond a customer sending us crap data.
Something I'd heard about and went after.... just way too late.
Labels:
Bad customer service,
Bad UI,
Being a dork,
Gobsmacked,
Growing the hell up,
UX
Tuesday, September 02, 2014
Man Down
I'm going to break one of my rules and address how long it's been since I've posted.
It's been forever - and my thanks to those who have asked after me.
Nerdhaven has been good to me. I've herded some new features into production along with Runner & Sprint. Code was written, users were interviewed, and future iterations are planned.
And I've gotten two vacations since I started. Honest to God take-the-family-someplace-fun vacations.
We saw waterfalls - and buffalo. Someone broke into our car.
Fun was had by all.
We've survived the child care pong of summer - and with school at last beginning - I felt poised to start the final big push to land Arwafn with a full set of features.
Runner and I are joined at the hip these days - and we are going to get this thing done.
Without Noddy.
Because of a date picker. I'll explain.
Runner and I spent a good deal of time sorting through the work pile and looking for what gets spec'ed out next. We're given a truly staggering amount of leeway to do this and neither of us want to tank on this so we start getting micromanaged.
Deliver the goods on time, you get to run your own room. Fail to deliver - and corporate will be all up in your sh!t.
We want to avoid that at all costs. So we're hitting it hard. Problem is, that 'we' only includes two people. Noddy - while on paper assigned to help out with the larger effort that includes Arwafn - pointedly does jack sh!t.
I wish I was exaggerating this, but we log all our work into a web app. I can run activity histories on anyone on the project and the work they contribute to queue. True, a good amount of work is done outside of the app - but any tangible end product must end up there. You might have a gap in a log for awhile, but the gap would end with a flurry of activity when all your offline efforts turned into deliverables. I'm looking at Noddy's activity history and there's a two month gap of nothing.
Nothing. In two months. The gap starts when Noddy copies a set of old stories written by Sensei into a new section of the app. Copy and paste. Then two months of nothing... then three bits of work were slightly edited. Then two more weeks of nothing.
I have watched Noddy sit at their desk and surf Ebay. Now, we all hit the web sometimes at work. Perfectly acceptable, so long as you keep it under control.
Noddy is running a side business selling collectibles - during work hours, on their work machine.
Runner and I tried giving work to Noddy, in the hopes of bringing them around. Every single task we gave them turned into weeks of delay - followed by their asking us to do the work for them.
"Can you look through this? Feel free to edit whatever."
Or, you know, do it for me.
We asked Noddy to do a truly basic piece of UI - select a date range - just to keep them from meddling in the work that mattered. THREE WEEKS later - they return with a fully functioning prototype, delivered in executable file. They demo'ed it to us for feedback and Runner and I were just aghast.
In UX - you don't do this. Not out of the gate. Not without bouncing your early drafts off your colleagues. Because now we have to tell them that their shiny executable is (to put it mildly) horsh!t UI. A huge wedge of screen real estate devoted to a small problem - that could have been addressed with a one day mock up!
Three weeks. True - Runner and I were glad to have the break from Noddy. So long as they had something that was theirs, they would stop leaning over our desks and offering high handed wisdom about what we "should" be doing. So, we let them waste their time instead of ours.
But that was the last bit for me. I have regular check ins with the boss, UXDir and while I'd tried to stay above the fray - I finally lost it.
"What the hell is going on with Noddy?" I detailed our frustrations with getting work out of him - using two specific examples where time and effort were lost waiting for them to produce.
UXDir nodded knowingly and asked "If I get them out of your way, would that help?"
"Absolutely."
UXDir told me neither of us had to involve him in our project work - and that Noddy would be given other assignments.
Sweet!
Freed up from pretending to count on Noddy - or invite them to our meetings. Runner and I settled in to do get stuff done.
Noddy chose some low priority work and basically stayed at the back of the queue. They were working on stuff, they said- but it was so far down on the list it would never get worked on.
Which meant, again, that they did nothing.
Runner and I hurled ourselves into our project work. We would get nothing out of Noddy, but we had two kick-ass devs in BigDog and OneTwentyEight and we were giving them a steady stream of work.
Sh!t. Got. Done.
Over on the west coast, our senior team member, Sprint, was in a similar situation. The Professor had bailed out leaving a huge pile of smoke and mirrors in their wake that Sprint (and Data) would be expected to turn into awesomeness. And they were still crushing it. Sprint is just an incredible person. There's no real way to express my professional admiration for them without coming across as a total dork, so I try not to get in their way and remain pleasant.
I want to be like Sprint. Pair me up with a snobbish, do-nothing, pot-head of a designer - fine. I'll still kick this job's ass. What about that? Oh, they quit? Fine. Less hassle for me.
Sprint works with Data, but being down a UX role in that office is way less than ideal. Sprint has still outproduced Runner and I combined. For months. They rock.
Months you say? Yeah. I hate to pick on the boss, but UXDir is not really quick out of the gate on administration things. Y'know, stuff like standing on laggers' heads - or hiring replacements for folks who left in May.
A few weeks ago - we got invites to participate in panel interviews for replacing the Professor. I'm flattered to be asked. I remember my interview panel: Heater, Noddy, Flyer, UXDir and OneTwentyEight. Aside from Noddy - it was among the most fun I'd had at an interview, ever.
Now I was going to get to vet the replacement for the Professor. Cool!
Reading through the resumés, however, made me really wonder. Only one of the candidates had UX experience of any kind. Which is weird, because I get that you would get these applicants - I just didn't see how they would make it to a final interview stage.
UXDir flew out to the west coast office to do the interviews along with Sprint, the rest of us videoconferenced into them.
True to form, Noddy's phone rang in the middle of an interview (they always set it on piercingly loud, too). Later in the same interview, they surfed the web in full view of the camera.
That earned us all an admonition to bring no phones or laptops into the remaining interviews.
Next interview? Noddy brought an apple that they proceeded to eat during the interview. To be discrete, though, they sat immediately behind me and ate the apple right behind my head so it wouldn't be seen by the video camera.
Awesome, right?
I learned a lot about interviewing people by watching Sprint and most of our team agreed on who we'd hire and who we wouldn't. UXDir joked that he was thinking of settling down on the west coast - it was so nice, and they'd get to work with Sprint.
It was a good bonding thing.
Next week UXDir is back in the office looking utterly shredded from travel. I stayed out of their way. UXDir's got enough to do and I knew what my punch list was before vacay. No final decision was going to be made before I got back - so I sorted out my priority list and tried to make sure there were no loose screws.
I'm walking out the door "See you in a week"
UXDir "Yeah, if I don't get fired."
????
Okay, I'm terrible at getting UXDir's sarcasm - and they have a wicked sense of humor that I keep mistaking for candor.
"Uh..."
They grin. "Kidding. See you in two weeks. I'm on vacation, 'week after next."
Elevator door closes. Queue vacation montage.
Mountains.
Valleys.
Wildlife.
Crime-ridden, hellscape that is Billings, Montana.
Home.
Exhausted.
I reorient myself with the workflow. BigDog is bogged down in admin stuff, OneTwentyEight is absolutely killing it. Coding up a storm and tackling a particularly thorny custom PDF document to boot.
It has finally occurred to Noddy that performance metrics are being logged. So a flurry of vapor-work is appearing in our tracking app. They are doing something, but again - it is so far down in the priority list, they might have well stayed home.
Now, I might have sympathy for Noddy in this - they are being given the ass-end of project work - but only because no one wants to rely on them to do important work.
Further, were I Noddy - and found myself getting sh!t work - I would slap down some work, get it to RFD and march into my boss's office and demand more and better work.
Not Noddy. Noddy spins their wheels in purgatory like they're in paradise. Yea! Look at me, doing make work while everyone else is so stressed. Why so serious, guys? Huh?
Runner and I are no longer polite to Noddy.
Part of this is my fault. I had this ideal that I would not stoop to denying a fellow UX'er client time. Runner and I had interviews with clients who are testing our Arwafn feature and I just could not see excluding Noddy from them.
On what grounds would I do that, really?
We'd studiously scheduled meetings without Noddy when the entire topic was project work they weren't on - namely, Our work. Those I could stomach. I could look Noddy in the eye and say - "You aren't working on Arwafn - so we figured your time would be better spent on your projects."
I could do that.
But when it came to client contact (the all too rare source of many a good design) I just couldn't stoop that low.
So I invited Noddy.
Runner was just about apoplectic. "What the hell are you thinking? Sprint warned us about this!"
And they had. Told us how Noddy would jump into somebody else's client interview asking drawn out questions from their own agenda - derailing Sprint's carefully constructed interview script and wasting priceless client time.
But I'd sent the invites already. I figured Noddy might not come to all of our interviews. We had like six lined up, he might only go to half - at most.
The week of the first Arwafn interview - Noddy hears Runner and I talking about the setup work we're doing for them and asks "Do you have some interviews coming up? Can I come?"
Now, understand - They would have received invites for at least four interviews by this time. Four. They'd accepted all of them. Which means all of them are on their calendar - or should be.
"Yeah. We have three this week. One next week."
Noddy looks hurt. "Can you forward them to me?"
I. Fricking. Did.
"Sure."
I send all four that I have. Again.
Runner rolls their eyes.
* * * * * *
When we fire up the first Arwafn interview, Noddy is nowhere to be found. Runner and I get things rolling and we have a great interview going and -
Noddy bursts into the room 20 minutes late, and immediately starts offering commentary to Runner - distracting them from facilitating the interview. Runner's taken by surprise, and goes along for awhile. Noddy wants them to look up an online document for them that relates to something that Noddy wants to ask about.
Something that has NOTHING to do with what this interview is going after.
Noddy passes me a note about a question they want to ask. Noddy wants to build a certain feature in Arwafn - and he wants to ask the clients if they would like it.
This is bullshit research. A user who just says they 'like' something hasn't told you anything. They have to say what they would do with it that they couldn't do before. Give me a reason. When you do show and tell, or lead them with a question - you'll often get: 'that'd be nice.' Which doesn't help you understand why they want it.
But more to the point - the thing Noddy is asking about - is something that we've already gotten quality feedback on, fifteen minutes earlier on - when they weren't here. Now they want to waste our interview time so they can be personally caught up.
I head them off and keep to my script. Then Noddy passes me some other notes about other features - features that are nice to haves - when the purpose of the interview is to validate the basic function of Arwafn.
I don't need feedback on these other features - I know the users want them - and if I have time, we will build them for them. But FIRST, we need to know if Arwafn is hitting the mark on the absolute basics.
Noddy's done NONE of the design work, none of the interview setup, none of the legwork, hasn't read the script and shows up late - yet they still want to drive the interview towards their pet questions.
Worse, their pet ideas for Arwafn aren't even their ideas - these are features that are plain as day requests from the market - writ large. In Noddy's mind, however - they are championing a needed feature and Runner and I shutting them down means we are close minded.
The interview ends and Noddy continues to press for these extra bells and whistles. Like Runner and I haven't heard of them. Like we're opposed to them.
We're not. At this point, we just hate Noddy's guts and anything they say - but more professionally - we had research goals for the session and these features aren't part of them.
* * * * *
Incredibly, Noddy repeats their performance at least once more (late, pestering us with BS questions, the whole bit).
Runner is about to stab me in the eye with a pencil, but not before I stab Noddy first.
So. Sick. Of Noddy.
* * * * *
It's been forever - and my thanks to those who have asked after me.
Nerdhaven has been good to me. I've herded some new features into production along with Runner & Sprint. Code was written, users were interviewed, and future iterations are planned.
And I've gotten two vacations since I started. Honest to God take-the-family-someplace-fun vacations.
We saw waterfalls - and buffalo. Someone broke into our car.
Fun was had by all.
We've survived the child care pong of summer - and with school at last beginning - I felt poised to start the final big push to land Arwafn with a full set of features.
Runner and I are joined at the hip these days - and we are going to get this thing done.
Without Noddy.
Because of a date picker. I'll explain.
Runner and I spent a good deal of time sorting through the work pile and looking for what gets spec'ed out next. We're given a truly staggering amount of leeway to do this and neither of us want to tank on this so we start getting micromanaged.
Deliver the goods on time, you get to run your own room. Fail to deliver - and corporate will be all up in your sh!t.
We want to avoid that at all costs. So we're hitting it hard. Problem is, that 'we' only includes two people. Noddy - while on paper assigned to help out with the larger effort that includes Arwafn - pointedly does jack sh!t.
I wish I was exaggerating this, but we log all our work into a web app. I can run activity histories on anyone on the project and the work they contribute to queue. True, a good amount of work is done outside of the app - but any tangible end product must end up there. You might have a gap in a log for awhile, but the gap would end with a flurry of activity when all your offline efforts turned into deliverables. I'm looking at Noddy's activity history and there's a two month gap of nothing.
Nothing. In two months. The gap starts when Noddy copies a set of old stories written by Sensei into a new section of the app. Copy and paste. Then two months of nothing... then three bits of work were slightly edited. Then two more weeks of nothing.
I have watched Noddy sit at their desk and surf Ebay. Now, we all hit the web sometimes at work. Perfectly acceptable, so long as you keep it under control.
Noddy is running a side business selling collectibles - during work hours, on their work machine.
Runner and I tried giving work to Noddy, in the hopes of bringing them around. Every single task we gave them turned into weeks of delay - followed by their asking us to do the work for them.
"Can you look through this? Feel free to edit whatever."
Or, you know, do it for me.
We asked Noddy to do a truly basic piece of UI - select a date range - just to keep them from meddling in the work that mattered. THREE WEEKS later - they return with a fully functioning prototype, delivered in executable file. They demo'ed it to us for feedback and Runner and I were just aghast.
In UX - you don't do this. Not out of the gate. Not without bouncing your early drafts off your colleagues. Because now we have to tell them that their shiny executable is (to put it mildly) horsh!t UI. A huge wedge of screen real estate devoted to a small problem - that could have been addressed with a one day mock up!
Three weeks. True - Runner and I were glad to have the break from Noddy. So long as they had something that was theirs, they would stop leaning over our desks and offering high handed wisdom about what we "should" be doing. So, we let them waste their time instead of ours.
But that was the last bit for me. I have regular check ins with the boss, UXDir and while I'd tried to stay above the fray - I finally lost it.
"What the hell is going on with Noddy?" I detailed our frustrations with getting work out of him - using two specific examples where time and effort were lost waiting for them to produce.
UXDir nodded knowingly and asked "If I get them out of your way, would that help?"
"Absolutely."
UXDir told me neither of us had to involve him in our project work - and that Noddy would be given other assignments.
Sweet!
Freed up from pretending to count on Noddy - or invite them to our meetings. Runner and I settled in to do get stuff done.
Noddy chose some low priority work and basically stayed at the back of the queue. They were working on stuff, they said- but it was so far down on the list it would never get worked on.
Which meant, again, that they did nothing.
Runner and I hurled ourselves into our project work. We would get nothing out of Noddy, but we had two kick-ass devs in BigDog and OneTwentyEight and we were giving them a steady stream of work.
Sh!t. Got. Done.
Over on the west coast, our senior team member, Sprint, was in a similar situation. The Professor had bailed out leaving a huge pile of smoke and mirrors in their wake that Sprint (and Data) would be expected to turn into awesomeness. And they were still crushing it. Sprint is just an incredible person. There's no real way to express my professional admiration for them without coming across as a total dork, so I try not to get in their way and remain pleasant.
I want to be like Sprint. Pair me up with a snobbish, do-nothing, pot-head of a designer - fine. I'll still kick this job's ass. What about that? Oh, they quit? Fine. Less hassle for me.
Sprint works with Data, but being down a UX role in that office is way less than ideal. Sprint has still outproduced Runner and I combined. For months. They rock.
Months you say? Yeah. I hate to pick on the boss, but UXDir is not really quick out of the gate on administration things. Y'know, stuff like standing on laggers' heads - or hiring replacements for folks who left in May.
A few weeks ago - we got invites to participate in panel interviews for replacing the Professor. I'm flattered to be asked. I remember my interview panel: Heater, Noddy, Flyer, UXDir and OneTwentyEight. Aside from Noddy - it was among the most fun I'd had at an interview, ever.
Now I was going to get to vet the replacement for the Professor. Cool!
Reading through the resumés, however, made me really wonder. Only one of the candidates had UX experience of any kind. Which is weird, because I get that you would get these applicants - I just didn't see how they would make it to a final interview stage.
UXDir flew out to the west coast office to do the interviews along with Sprint, the rest of us videoconferenced into them.
True to form, Noddy's phone rang in the middle of an interview (they always set it on piercingly loud, too). Later in the same interview, they surfed the web in full view of the camera.
That earned us all an admonition to bring no phones or laptops into the remaining interviews.
Next interview? Noddy brought an apple that they proceeded to eat during the interview. To be discrete, though, they sat immediately behind me and ate the apple right behind my head so it wouldn't be seen by the video camera.
Awesome, right?
I learned a lot about interviewing people by watching Sprint and most of our team agreed on who we'd hire and who we wouldn't. UXDir joked that he was thinking of settling down on the west coast - it was so nice, and they'd get to work with Sprint.
It was a good bonding thing.
Next week UXDir is back in the office looking utterly shredded from travel. I stayed out of their way. UXDir's got enough to do and I knew what my punch list was before vacay. No final decision was going to be made before I got back - so I sorted out my priority list and tried to make sure there were no loose screws.
I'm walking out the door "See you in a week"
UXDir "Yeah, if I don't get fired."
????
Okay, I'm terrible at getting UXDir's sarcasm - and they have a wicked sense of humor that I keep mistaking for candor.
"Uh..."
They grin. "Kidding. See you in two weeks. I'm on vacation, 'week after next."
Elevator door closes. Queue vacation montage.
Mountains.
Valleys.
Wildlife.
Crime-ridden, hellscape that is Billings, Montana.
Home.
Exhausted.
I reorient myself with the workflow. BigDog is bogged down in admin stuff, OneTwentyEight is absolutely killing it. Coding up a storm and tackling a particularly thorny custom PDF document to boot.
It has finally occurred to Noddy that performance metrics are being logged. So a flurry of vapor-work is appearing in our tracking app. They are doing something, but again - it is so far down in the priority list, they might have well stayed home.
Now, I might have sympathy for Noddy in this - they are being given the ass-end of project work - but only because no one wants to rely on them to do important work.
Further, were I Noddy - and found myself getting sh!t work - I would slap down some work, get it to RFD and march into my boss's office and demand more and better work.
Not Noddy. Noddy spins their wheels in purgatory like they're in paradise. Yea! Look at me, doing make work while everyone else is so stressed. Why so serious, guys? Huh?
Runner and I are no longer polite to Noddy.
Part of this is my fault. I had this ideal that I would not stoop to denying a fellow UX'er client time. Runner and I had interviews with clients who are testing our Arwafn feature and I just could not see excluding Noddy from them.
On what grounds would I do that, really?
We'd studiously scheduled meetings without Noddy when the entire topic was project work they weren't on - namely, Our work. Those I could stomach. I could look Noddy in the eye and say - "You aren't working on Arwafn - so we figured your time would be better spent on your projects."
I could do that.
But when it came to client contact (the all too rare source of many a good design) I just couldn't stoop that low.
So I invited Noddy.
Runner was just about apoplectic. "What the hell are you thinking? Sprint warned us about this!"
And they had. Told us how Noddy would jump into somebody else's client interview asking drawn out questions from their own agenda - derailing Sprint's carefully constructed interview script and wasting priceless client time.
But I'd sent the invites already. I figured Noddy might not come to all of our interviews. We had like six lined up, he might only go to half - at most.
The week of the first Arwafn interview - Noddy hears Runner and I talking about the setup work we're doing for them and asks "Do you have some interviews coming up? Can I come?"
Now, understand - They would have received invites for at least four interviews by this time. Four. They'd accepted all of them. Which means all of them are on their calendar - or should be.
"Yeah. We have three this week. One next week."
Noddy looks hurt. "Can you forward them to me?"
I. Fricking. Did.
"Sure."
I send all four that I have. Again.
Runner rolls their eyes.
* * * * * *
When we fire up the first Arwafn interview, Noddy is nowhere to be found. Runner and I get things rolling and we have a great interview going and -
Noddy bursts into the room 20 minutes late, and immediately starts offering commentary to Runner - distracting them from facilitating the interview. Runner's taken by surprise, and goes along for awhile. Noddy wants them to look up an online document for them that relates to something that Noddy wants to ask about.
Something that has NOTHING to do with what this interview is going after.
Noddy passes me a note about a question they want to ask. Noddy wants to build a certain feature in Arwafn - and he wants to ask the clients if they would like it.
This is bullshit research. A user who just says they 'like' something hasn't told you anything. They have to say what they would do with it that they couldn't do before. Give me a reason. When you do show and tell, or lead them with a question - you'll often get: 'that'd be nice.' Which doesn't help you understand why they want it.
But more to the point - the thing Noddy is asking about - is something that we've already gotten quality feedback on, fifteen minutes earlier on - when they weren't here. Now they want to waste our interview time so they can be personally caught up.
I head them off and keep to my script. Then Noddy passes me some other notes about other features - features that are nice to haves - when the purpose of the interview is to validate the basic function of Arwafn.
I don't need feedback on these other features - I know the users want them - and if I have time, we will build them for them. But FIRST, we need to know if Arwafn is hitting the mark on the absolute basics.
Noddy's done NONE of the design work, none of the interview setup, none of the legwork, hasn't read the script and shows up late - yet they still want to drive the interview towards their pet questions.
Worse, their pet ideas for Arwafn aren't even their ideas - these are features that are plain as day requests from the market - writ large. In Noddy's mind, however - they are championing a needed feature and Runner and I shutting them down means we are close minded.
The interview ends and Noddy continues to press for these extra bells and whistles. Like Runner and I haven't heard of them. Like we're opposed to them.
We're not. At this point, we just hate Noddy's guts and anything they say - but more professionally - we had research goals for the session and these features aren't part of them.
* * * * *
Incredibly, Noddy repeats their performance at least once more (late, pestering us with BS questions, the whole bit).
Runner is about to stab me in the eye with a pencil, but not before I stab Noddy first.
So. Sick. Of Noddy.
* * * * *
Labor Day Weekend.
Sloth. Food. And More Sloth.
First day back promises to be busy. There's a critical prioritization meeting in the afternoon, and a team lunch we won at the company Olympics.
(Told you this place was cool.)
Anyway we start up with the Retro. Agile demands it.
BigDog is running the show - which is odd, because OneTwentyEight was on the signup sheet for leading today. OneTwentyEight's not in yet, which is also odd, because they always like to arrive early and leave early.
BigDog plows through the Retro with all speed, which is good because I've got my regular meeting with UXDir in less than a half an hour. I've been out, they've been out- there's a lot to talk about. I wrote an agenda for crying out loud.
Mid retro- UXDir sends a meeting to all of UX. "Quick Meeting."
I know what you're thinking. Sudden meetings with the boss are bad. But that was CorpWorld. This is Nerdhaven. Runner is thinking the same thing.
"What do you think the meeting is?"
I bluff. "A decision's been made on the new UX hire."
But I know that's not right.
* * * * *
Retro ends and we go into UXDir's office.
They start out with "Candidate 3 has accepted our offer."
Awesome. They were my favorite.
UXDir continues, "...and my last day will be September 17."
And there it is. The answer to that hollow spot that's been floating around them for the past month.
They have been marginalized in their current role. They've been looking for a new challenge and there did not seem to be any good choices for them here at Nerdhaven. Their kids are just starting school - so a move at this point is easier than later. And they've been offered a good opportunity to start a UX team from scratch. They had to....
That old feeling, back again. The Boss leaves, and the team they leave behind feels the world tilt a bit...
...towards the door.
I have my one on one with them immediately afterwards and they go out of their way to assure me that UX is not going anywhere. "It is ingrained in our process here. That's part of why my current role is so limited."
I joke, "Your work here is done."
UXDir laughs. They are such an immensely likable person. I've never had more trouble reading a person I liked so much. I'm constantly mis-communicating with them - yet the are truly inspiring in their role. They've done it all before, and my suggestions always sound stupid to me when I'm talking to them. They let the air out of any procedural bullshit they see - seize on it and hurl it outside before it derails the room.
I've spent a lot of time working for people who don't get UX, and until September 17 of this year - I will be working for a person who makes me feel like I don't get UX at all. I want them to stay. I want to catch up to where they are.
UXDir is a bit of a mess as a manager - but they are an inspired designer.
And they lead from the front.
* * * * *
I'm back in the project room - I think. We rip through the day - Lunch with most of the team. No YQA or OneTwentyEight, but the rest of us have a good time.
Later we get with product, sort our priorities out. Mostly. Product refreshingly doesn't want to deal in the details, but that means sometimes they assume the "obvious" details are being handled. We're meeting to get on the same page.
UXDir and Product come to an agreement. Then I'm off to telecommute from home.
I'm in my easy chair, firing up the VPN and Runner IM's me and we decompress about UXDir's departure means.
I sincerely believe that UX is sound in this shop.
But Noddy.
Noddy scares me. UXDir was never going to can them - but with UXDir gone, there are a few possibilities that are unfolding simultaneously in Runner's mind and mine.
- Nerdhaven hires to replace UXDir, Noddy applies for the job and since they are "Lead UX" some higher up decides they should go with the internal candidate.
- Nerdhaven doesn't hire to replace UXDir. The purely admin duties of managing us go to some other manager with lots of other mouths to feed and the day to day leadership of UX is given to "Lead UX" Noddy.
- Nerdhaven doesn't hire to replace UXDir. UX is left to its own devices and Noddy continues their well established pattern of doing the absolute minimum.
Runner and I are advancing our most likely scenarios going forward - IM'ing back and forth like pessimistic hummingbirds when they stop dead:
OneTwentyEight is in ICU!
What?
Runner explains. OneTwentyEight is a diabetic. They've been admitted with DKA - Diabetic Ketoacidosis. This means that OneTwentyEight's insulin level is low enough that their body has started to eat itself.
OneTwentyEight is not some elderly, overweight person neglecting their health. They are young. Very young. With a disease that will progress in severity over whatever time it is given.
And they are sitting in an ICU - while Runner and I have been fretting over something as stupid as an annoying coworker.
It's hard to express the sentiment that builds up on a good team for me. Most of my life I moved around and left the people I knew behind without much thought.
But I like stable. And I like my team - and I don't want to get too over the top, but they are good people. I want to help them.
I doubt we would hang out outside of work without some pronounced awkwardness - but as a unit we kick major ass. And OneTwentyEight is in real trouble. And there is nothing we can do for them.
I suppose I could stop whining.
...
OneTwentyEight is in ICU!
What?
Runner explains. OneTwentyEight is a diabetic. They've been admitted with DKA - Diabetic Ketoacidosis. This means that OneTwentyEight's insulin level is low enough that their body has started to eat itself.
OneTwentyEight is not some elderly, overweight person neglecting their health. They are young. Very young. With a disease that will progress in severity over whatever time it is given.
And they are sitting in an ICU - while Runner and I have been fretting over something as stupid as an annoying coworker.
It's hard to express the sentiment that builds up on a good team for me. Most of my life I moved around and left the people I knew behind without much thought.
But I like stable. And I like my team - and I don't want to get too over the top, but they are good people. I want to help them.
I doubt we would hang out outside of work without some pronounced awkwardness - but as a unit we kick major ass. And OneTwentyEight is in real trouble. And there is nothing we can do for them.
I suppose I could stop whining.
...
Friday, May 02, 2014
Circular Firing Squad
I'm on the phone with Data, our in-house BI expert - talking about a feature of Arwafn that utterly blew up when we met with the SMEs.
It's not going well.
I've let Data down - again. This seems to be my lot in life. I'm told to move the ball forward, with the understanding that a first attempt will not be perfect - but we will improve as we go.
This is the opposite of what Data wants from me. Data wants me to have all of my sh!t together before I ask them to do their bit.
And I understand this. But UXDirector has given me explicit instructions to not to wait until everything is perfect. UXDirector is tired of waiting for perfect - and they want movement. Now.
They are the boss. So, I do what they say - only to end up utterly letting down Data.
Data has conviction. They are principled. "We cannot fake this. We have to get it right."
And I agree with this. I just believe that we will get it right, after a few revisions. We do not know what we do not know. So we will go forward, take some beatings - and learn.
Data doesn't want to take beatings. Right now, they are dishing them out.
I've often joked that a big part of UX is taking the beatings. So I lean into it until they are done.
"Do you know this stuff? Really know it?" They are talking about Arwafn.
I hedge a bit - which is stupid.
"I don't have it memorized, but I believe I know it."
Data can sniff out BS like a bloodhound. "Because we cannot get this wrong. This has to be right. Customers won't go through the misery of setting this up if they don't see the value."
I'm trapped between two competing design strategies. UXDirector and Data are not on the same page. And there seems to be no way to make them both happy.
Somewhere in the beating Data drops a bomb.
"The Professor is leaving."
What?
The Professor is Data's partner on a big chunk of our current project. They both share the "first, get it right" philosophy of design - and have been collaborating well.
"Yeah, their last day is a week from Friday."
I do the math. It's Wednesday, which means if the Professor gave two weeks notice, the UXDirector has known for two days and has not told anyone.
What the what?
I like the UXDirector. But if they have a major weakness, it is in their communication skills. In person, you will get all you need to know - but only if you seek them out. If you are waiting for a bulletin from them - don't hold your breath. Once, they emailed us the day before they left the office for two weeks. Nobody knew a thing about it. "Bye department, I'll be gone until..."
And now, mum on the departure of a team member.
* * *
Bit of background is in order here: The Professor is someone I have a good deal of professional respect for. They clearly have UX and research chops.
But here's the thing: they flat out suck at working with people like me. I've never had a meeting with the Professor where I didn't feel like I was getting lectured.
Here's what I did... and here's the background on how I approached it and here's the proper technique...and-
"I have a question"
Let's table that for now. Now you can see here that..."
"What is that pattern?"
I would push back on the term 'pattern.' This is clearly an expression of a design language. Now, as I was saying...
And so on.
Hours of this.
We used to refer to some of the meetings with the Professor as "Watch Professor Type." They'd show up with stuff they wanted to show off, and brush off anyone else's material until they'd lovingly walked through every last facet of their design. At which point, any questions or alternate designs were swatted aside until the Professor would conclude that their design had carried the day.
It's just a strawman.
Strawman. They said this so often that it became a joke with Runner, Noddy and I. We actually had a drinking game where each of us would take a drink every time the Professor said the word.
Being in the office the drinks were usually sparkling water, but it made us all smile.
And I don't think the Professor is a bad sort, they just had no idea how to collaborate. At one point I got into an email rant with them about a particular design choice they'd assumed we'd all adopt. I proposed a compromise and - they took me up on it.
The ice was broken - somewhat. And I'd hoped this would be the beginning of better things. The Professor had a good sense of humor and our meetings usually had more than a few good laughs.
So, right after Data tells me the Professor is leaving, they invite me to a technical review of the work Data and the Professor have been doing. This, I consider a win. Data would like me to be there. They would like Runner to be there as well, but not Noddy. As they put it "I don't want them to screw it up."
So, Data and I are on the same page about Noddy. Really, how could we not be? Noddy is a total tool.
Anyway, I go into the tech review and sit back while the Professor launches into another tour of their grand vision.
I've seen this part before - and I'm wondering what the Hell the Professor is up to. A technical review is basically "I want to build this. How many technical hurdles do you see at first blush?"
A rapid description of the features would suffice. But this is the Professor: He begins with his persona research. Then his task patterning. About three more abstract visualizations later, the developers are checking their smartphone email. Then the Professor starts talking about their prototyping tool. How it works, what their initial approach was - the problems they encountered - and why the performance of the tool was currently sub-par.
If the Professor had any empathy for their audience (aside from me, all developers) they would realize that absolutely nobody gave a sh!t about what they were talking about.
Some 45 minutes into the verbal barrage, the Professor finally arrives at showing page mockups and discussing the data requirements. This - devs care about. Questions begin flying in earnest, but there are so many unknowns that the meeting ends 15 minutes later with the devs as mystified about what was required as they were when the meeting began. Eight high-priced developers burned an hour to get a UX theory lecture and walked away with very little new information.
Awesome.
And there was a niggling little detail in the presentation that I couldn't manage to forget. In the past, the Professor hasn't been shy about lacing his documents and communications with snide nicknames for people and things he has little respect for. They'd referred to the Marketing Department's branding guidelines as "the art project" and I suggested we stop calling it that - lest one of these folks get wind of it and take offense. This was my attempt at being diplomatic.
The Professor laughed it off - like it was silly to even worry about it - and just left the term in their documents. And proceeded to forcefully use the term in our subsequent meetings. It struck me as tacky - not a huge deal, but evidence that the Professor didn't easily turn off their scorn.
This is in the back of my mind, when I see the Professor's summation of our UX team's current projects.
Next to the entry for Arwafn - under the column that indicated who was working on it - the Professor had written 'the three Amigos.'
Meaning Runner, Noddy & I. In the eyes of the Professor, we're the three Amigos.
Now, I'd seen this 'cognitive walkthrough' of the Professor's before - only this part hadn't been in the tours I'd seen.
And I wasn't supposed to be in this meeting - Data had invited me at the last minute.
Nice. Way to belittle your peers in front of the Devs.
I mean, Runner and I are making fun of the Professor on a regular basis - we're just not documenting it and showing it to folks outside our team.
Okay. I see how it is.
* * *
So, the Professor is quitting. Taking a job for less pay, because they want to get out. They've tried ("and tried.. and tried" they say) to win UXDirector over to their design philosophy. No traction.
Hmm... maybe it's your delivery.
And they're going to - in their words - "a rockstar shop." So be it. If they find an environment that suits them, they are better off. Frankly, I think we will be, too.
I mean, I've been in a lot of pointless meetings - but the Professor had a way of describing things that they were "going to do" - and then not do them.
This is perhaps the reason that UXDirector is not embracing their design philosophy. Because it is so slow.
* * *
Which still leaves the question as to why the UXDirector hadn't bothered to tell anyone that the Professor is leaving the company. Given the UXDirector's communication style - I can't say this omission carried any special significance. You don't get much from UXDirectory unless you ask for it. Nobody asked them if the Professor was leaving the company - so, they hadn't said.
* * *
So, it's today. I'm still smarting from the week's beatings. I've recently acquired a new set of standards for Arwafn - and I can see it will require changes to its basic function. This will go over with Data like a lead balloon.
I remember Noddy talking about this particular function and find an email from them from March. They are asking about this function based on another document. They email basically everyone on the project to say "look what I've found." Product weighs in and says "make this change." A SME weighs in and says "we must do this."
I remember talking with Noddy about it - I was trying to figure out how big a deal this would be. I had no concept of how big of an issue this was - it seemed like an edge case. I wasn't eager to make changes, but I wasn't opposed to it. And Noddy had been greenlighted by Product.
Noddy does...nothing.
A month later - I'm looking at new specs that tell me I need to make this change
Hooray. I'm looking for ways to break this to them and opt to go to another person in Data's field - Heater. Heater instantly knows what I'm looking for and starts the machinery to make the necessary changes.
Heater is thorough - so they copy the UX team - which means Data. Data is clearly irritated at this new discovery. Clearly I'm not doing my job well - otherwise I'd have known about this.
My attitude is that making fixes as we go forward was always part of the plan. UXDirector has said we'll put our code into an environment and throw actual production data against it to see where the holes are. This strikes me as a great next step.
I've mentioned this to Data and while they are clearly on board with this - test and make improvements. But this new change of mine is still heresy.
*sigh*
UX is all about taking the beatings.
Later, I'll go tell the devs that we'll have to change working code.
Noddy stops by to tell me that he knew this would be a problem, that'd he'd asked for these features a long time ago and "...nothing happened."
Gee, wonder why that was...?
*sigh*
* * *
It's the afternoon. I'm looking at a farewell email from the Professor in amazement.
I've seen my share of awkward goodbye messages - but the Professor's is on a whole new level.
I mean, what do you usually say in a goodbye message? "So long, it's been great. I've learned a lot. Here's my contact info. Keep in touch."
Not the Professor. Their message has something else.
It has a chart.
The Professor is having their last meeting about the style guide. The style guide has been a recurring lecture series where the Professor tells everyone to do what they say.
To be fair, the sessions had improved from the first few sessions - but we hadn't met in recent weeks because we were all too busy.
Now the Professor wanted to have one last session and we couldn't really find a reason to turn them down.
We started out cordial enough. The Professor asked if anyone had some items for the group and I pointed out that everyone else in the room would still be around the following week to discuss things - but if the Professor wanted to say something, they should probably say it now.
"Fair enough," says the Professor - and they proceed to walk us through "their process."
Again.
I've seen this document before. At least three times. And now four. This matters not at all to the Professor and they replay their earlier lecture as if it were hot off the press.
They detail personas and affinity diagrams. And how they "informed their early iterations" and how this led to "an integrated feature set." How meeting with users had allowed them to "move forward with confidence."
At this point, I've had it.
I interrupt. "Are you showing us these things because you think they are new to us?"
I mean seriously, pal. Everyone in this room works in UX. You are talking to us like we are schoolchildren.
AND I - FOR ONE - AM SICK OF IT.
The Professor seems surprised. "No. Not at all."
Then why the F*#k are you lecturing us on this stuff like you've just invented it?
The Professor just wants to share their design philosophy with us, they say. They want to point out how they've managed to do all this research AND still deliver stories in a timely manner.
* * *
Need to step back a bit here - and I appreciate you for hanging in there on this one. It's ramblier than usual because this stuff just happened a few hours ago.
The Professor and Data have been working on their project for as long as Runner and I have been working on Arwafn. We have a number of accepted stories and a bunch of stories Ready for Development. RFD, the coveted status of UXers in our company.
RFD = Devs don't go hungry = points on the board.
And we have stories that are in progress - and more on the way.
The Professor? The one saying they were able to "deliver stories in a timely manner?"
They have zero stories that are RFD.
TWO DAYS AGO, they dropped 40 stories into the queue and got them estimated. This means they are not RFD, not about to be RFD, but about to be worked on so they will eventually become RFD.
And the Professor is leaving in two hours. These stories - whatever they eventually become - will owe precious little to the Professor, since Data and Sprint will be stuck doing the work to actually make them happen.
And quite possibly Runner and me.
Professor? I CALL BULLSHIT.
* * *
So, knowing this - hearing all this, I've stopped being patient and started to call out the competing philosophies in the room. Up front vs as you go.
If I had a choice, from a standing start - with room to breathe - I honestly can't say which of these I would reach for first. Each of them have their advantages.
But there was no choice. UXDirector spelled it out. We are an as-you-go shop. We'll move stuff forward, make mistakes - and then make things better. The Professor has basically ignored this and has gone their own way. UXDirector has let this happen, under the hope/assumption that good stuff will eventually come down the chute. And - to my mind - the Professor has landed a big pile of maybe and is trying to rub our noses in it on the way out.
"I'm frustrated." I say. I point out how I'm told to write a simple story NOW - then make it better. And my reward for that is to drive Data into a near fury.
"I'm not trying to drive you crazy. I'm doing what my boss has expressly told me to do."
And then all kinds of sh!t starts letting go. Data takes issue with my version of RFD. The Professor asserts that our amount of rework will be less than theirs. I'm incredulous.
"You think you won't have rework?"
"Not as much."
The Professor is shoving 40 pigs through the python at once. Or, they would be if they were sticking around to make them RFD. Instead, Sprint and Data will try to make these pieces flow through the system - all interconnected - all co-dependent - and minimize the rework.
Good.
Effing.
Luck.
A lot of the stories are clones of one another, so you build one, you can easily build the other. But if you start them at the same time and one dev finds a problem that another doesn't...?
The devs were saying as much after the tech review. All that interconnectivity being built at the same time ups the risk substantially.
Sprint, bless them, stands up for me. I get the sense that Sprint and UXDirector are on the same page. Sprint lets go with some stuff that had been bottled up for awhile.
And Runner joins in. "We are not an effective team."
And we aren't. Runner nails it. Three of us are in one office and three (soon to be two) are on the coast. We used to have regular meetings as a team and now it's just impromptu phone calls and email.
And stuff gets missed. And then we get angry at...everything.
It's like therapy. Soon people are apologizing and we're agreeing to have regular check ins. Data volunteers to have regular work sessions with Runner and me on Arwafn.
It was horrible and beautiful all at once.
But I'm so glad it happened.
I end up wishing the Professor well - I do hope they are happier in their new shop - but I am glad they are moving on. I suspect I am not alone in that. I want to work in a team and (with the exception of Noddy) everyone else on the UX team is somebody I like and respect.
We just need to get past the awkward and the awful and move forward.
And I think despite - or perhaps because of - the Professor, we took a big first step.
Huzzah!
It's not going well.
I've let Data down - again. This seems to be my lot in life. I'm told to move the ball forward, with the understanding that a first attempt will not be perfect - but we will improve as we go.
This is the opposite of what Data wants from me. Data wants me to have all of my sh!t together before I ask them to do their bit.
And I understand this. But UXDirector has given me explicit instructions to not to wait until everything is perfect. UXDirector is tired of waiting for perfect - and they want movement. Now.
They are the boss. So, I do what they say - only to end up utterly letting down Data.
Data has conviction. They are principled. "We cannot fake this. We have to get it right."
And I agree with this. I just believe that we will get it right, after a few revisions. We do not know what we do not know. So we will go forward, take some beatings - and learn.
Data doesn't want to take beatings. Right now, they are dishing them out.
I've often joked that a big part of UX is taking the beatings. So I lean into it until they are done.
"Do you know this stuff? Really know it?" They are talking about Arwafn.
I hedge a bit - which is stupid.
"I don't have it memorized, but I believe I know it."
Data can sniff out BS like a bloodhound. "Because we cannot get this wrong. This has to be right. Customers won't go through the misery of setting this up if they don't see the value."
I'm trapped between two competing design strategies. UXDirector and Data are not on the same page. And there seems to be no way to make them both happy.
Somewhere in the beating Data drops a bomb.
"The Professor is leaving."
What?
The Professor is Data's partner on a big chunk of our current project. They both share the "first, get it right" philosophy of design - and have been collaborating well.
"Yeah, their last day is a week from Friday."
I do the math. It's Wednesday, which means if the Professor gave two weeks notice, the UXDirector has known for two days and has not told anyone.
What the what?
I like the UXDirector. But if they have a major weakness, it is in their communication skills. In person, you will get all you need to know - but only if you seek them out. If you are waiting for a bulletin from them - don't hold your breath. Once, they emailed us the day before they left the office for two weeks. Nobody knew a thing about it. "Bye department, I'll be gone until..."
And now, mum on the departure of a team member.
* * *
Bit of background is in order here: The Professor is someone I have a good deal of professional respect for. They clearly have UX and research chops.
But here's the thing: they flat out suck at working with people like me. I've never had a meeting with the Professor where I didn't feel like I was getting lectured.
Here's what I did... and here's the background on how I approached it and here's the proper technique...and-
"I have a question"
Let's table that for now. Now you can see here that..."
"What is that pattern?"
I would push back on the term 'pattern.' This is clearly an expression of a design language. Now, as I was saying...
And so on.
Hours of this.
We used to refer to some of the meetings with the Professor as "Watch Professor Type." They'd show up with stuff they wanted to show off, and brush off anyone else's material until they'd lovingly walked through every last facet of their design. At which point, any questions or alternate designs were swatted aside until the Professor would conclude that their design had carried the day.
It's just a strawman.
Strawman. They said this so often that it became a joke with Runner, Noddy and I. We actually had a drinking game where each of us would take a drink every time the Professor said the word.
Being in the office the drinks were usually sparkling water, but it made us all smile.
And I don't think the Professor is a bad sort, they just had no idea how to collaborate. At one point I got into an email rant with them about a particular design choice they'd assumed we'd all adopt. I proposed a compromise and - they took me up on it.
The ice was broken - somewhat. And I'd hoped this would be the beginning of better things. The Professor had a good sense of humor and our meetings usually had more than a few good laughs.
So, right after Data tells me the Professor is leaving, they invite me to a technical review of the work Data and the Professor have been doing. This, I consider a win. Data would like me to be there. They would like Runner to be there as well, but not Noddy. As they put it "I don't want them to screw it up."
So, Data and I are on the same page about Noddy. Really, how could we not be? Noddy is a total tool.
Anyway, I go into the tech review and sit back while the Professor launches into another tour of their grand vision.
I've seen this part before - and I'm wondering what the Hell the Professor is up to. A technical review is basically "I want to build this. How many technical hurdles do you see at first blush?"
A rapid description of the features would suffice. But this is the Professor: He begins with his persona research. Then his task patterning. About three more abstract visualizations later, the developers are checking their smartphone email. Then the Professor starts talking about their prototyping tool. How it works, what their initial approach was - the problems they encountered - and why the performance of the tool was currently sub-par.
If the Professor had any empathy for their audience (aside from me, all developers) they would realize that absolutely nobody gave a sh!t about what they were talking about.
Some 45 minutes into the verbal barrage, the Professor finally arrives at showing page mockups and discussing the data requirements. This - devs care about. Questions begin flying in earnest, but there are so many unknowns that the meeting ends 15 minutes later with the devs as mystified about what was required as they were when the meeting began. Eight high-priced developers burned an hour to get a UX theory lecture and walked away with very little new information.
Awesome.
And there was a niggling little detail in the presentation that I couldn't manage to forget. In the past, the Professor hasn't been shy about lacing his documents and communications with snide nicknames for people and things he has little respect for. They'd referred to the Marketing Department's branding guidelines as "the art project" and I suggested we stop calling it that - lest one of these folks get wind of it and take offense. This was my attempt at being diplomatic.
The Professor laughed it off - like it was silly to even worry about it - and just left the term in their documents. And proceeded to forcefully use the term in our subsequent meetings. It struck me as tacky - not a huge deal, but evidence that the Professor didn't easily turn off their scorn.
This is in the back of my mind, when I see the Professor's summation of our UX team's current projects.
Next to the entry for Arwafn - under the column that indicated who was working on it - the Professor had written 'the three Amigos.'
Meaning Runner, Noddy & I. In the eyes of the Professor, we're the three Amigos.
Now, I'd seen this 'cognitive walkthrough' of the Professor's before - only this part hadn't been in the tours I'd seen.
And I wasn't supposed to be in this meeting - Data had invited me at the last minute.
Nice. Way to belittle your peers in front of the Devs.
I mean, Runner and I are making fun of the Professor on a regular basis - we're just not documenting it and showing it to folks outside our team.
Okay. I see how it is.
* * *
So, the Professor is quitting. Taking a job for less pay, because they want to get out. They've tried ("and tried.. and tried" they say) to win UXDirector over to their design philosophy. No traction.
Hmm... maybe it's your delivery.
And they're going to - in their words - "a rockstar shop." So be it. If they find an environment that suits them, they are better off. Frankly, I think we will be, too.
I mean, I've been in a lot of pointless meetings - but the Professor had a way of describing things that they were "going to do" - and then not do them.
This is perhaps the reason that UXDirector is not embracing their design philosophy. Because it is so slow.
* * *
Which still leaves the question as to why the UXDirector hadn't bothered to tell anyone that the Professor is leaving the company. Given the UXDirector's communication style - I can't say this omission carried any special significance. You don't get much from UXDirectory unless you ask for it. Nobody asked them if the Professor was leaving the company - so, they hadn't said.
* * *
So, it's today. I'm still smarting from the week's beatings. I've recently acquired a new set of standards for Arwafn - and I can see it will require changes to its basic function. This will go over with Data like a lead balloon.
I remember Noddy talking about this particular function and find an email from them from March. They are asking about this function based on another document. They email basically everyone on the project to say "look what I've found." Product weighs in and says "make this change." A SME weighs in and says "we must do this."
I remember talking with Noddy about it - I was trying to figure out how big a deal this would be. I had no concept of how big of an issue this was - it seemed like an edge case. I wasn't eager to make changes, but I wasn't opposed to it. And Noddy had been greenlighted by Product.
Noddy does...nothing.
A month later - I'm looking at new specs that tell me I need to make this change
Hooray. I'm looking for ways to break this to them and opt to go to another person in Data's field - Heater. Heater instantly knows what I'm looking for and starts the machinery to make the necessary changes.
Heater is thorough - so they copy the UX team - which means Data. Data is clearly irritated at this new discovery. Clearly I'm not doing my job well - otherwise I'd have known about this.
My attitude is that making fixes as we go forward was always part of the plan. UXDirector has said we'll put our code into an environment and throw actual production data against it to see where the holes are. This strikes me as a great next step.
I've mentioned this to Data and while they are clearly on board with this - test and make improvements. But this new change of mine is still heresy.
*sigh*
UX is all about taking the beatings.
Later, I'll go tell the devs that we'll have to change working code.
Noddy stops by to tell me that he knew this would be a problem, that'd he'd asked for these features a long time ago and "...nothing happened."
Gee, wonder why that was...?
*sigh*
* * *
It's the afternoon. I'm looking at a farewell email from the Professor in amazement.
I've seen my share of awkward goodbye messages - but the Professor's is on a whole new level.
I mean, what do you usually say in a goodbye message? "So long, it's been great. I've learned a lot. Here's my contact info. Keep in touch."
Not the Professor. Their message has something else.
It has a chart.
A timeline illustrating the projects the Professor has been involved in - what the goals were - and the (Totally awesome) success each of them ended with. There are at least three swim lanes in the data table and...
...skip it. It was ridiculous. A victory lap for someone who saw their every action as triumph.
I'm deleting it when I remember that I have another meeting with them.
The Professor is having their last meeting about the style guide. The style guide has been a recurring lecture series where the Professor tells everyone to do what they say.
To be fair, the sessions had improved from the first few sessions - but we hadn't met in recent weeks because we were all too busy.
Now the Professor wanted to have one last session and we couldn't really find a reason to turn them down.
We started out cordial enough. The Professor asked if anyone had some items for the group and I pointed out that everyone else in the room would still be around the following week to discuss things - but if the Professor wanted to say something, they should probably say it now.
"Fair enough," says the Professor - and they proceed to walk us through "their process."
Again.
I've seen this document before. At least three times. And now four. This matters not at all to the Professor and they replay their earlier lecture as if it were hot off the press.
They detail personas and affinity diagrams. And how they "informed their early iterations" and how this led to "an integrated feature set." How meeting with users had allowed them to "move forward with confidence."
At this point, I've had it.
I interrupt. "Are you showing us these things because you think they are new to us?"
I mean seriously, pal. Everyone in this room works in UX. You are talking to us like we are schoolchildren.
AND I - FOR ONE - AM SICK OF IT.
The Professor seems surprised. "No. Not at all."
Then why the F*#k are you lecturing us on this stuff like you've just invented it?
The Professor just wants to share their design philosophy with us, they say. They want to point out how they've managed to do all this research AND still deliver stories in a timely manner.
* * *
Need to step back a bit here - and I appreciate you for hanging in there on this one. It's ramblier than usual because this stuff just happened a few hours ago.
The Professor and Data have been working on their project for as long as Runner and I have been working on Arwafn. We have a number of accepted stories and a bunch of stories Ready for Development. RFD, the coveted status of UXers in our company.
RFD = Devs don't go hungry = points on the board.
And we have stories that are in progress - and more on the way.
The Professor? The one saying they were able to "deliver stories in a timely manner?"
They have zero stories that are RFD.
TWO DAYS AGO, they dropped 40 stories into the queue and got them estimated. This means they are not RFD, not about to be RFD, but about to be worked on so they will eventually become RFD.
And the Professor is leaving in two hours. These stories - whatever they eventually become - will owe precious little to the Professor, since Data and Sprint will be stuck doing the work to actually make them happen.
And quite possibly Runner and me.
Professor? I CALL BULLSHIT.
* * *
So, knowing this - hearing all this, I've stopped being patient and started to call out the competing philosophies in the room. Up front vs as you go.
If I had a choice, from a standing start - with room to breathe - I honestly can't say which of these I would reach for first. Each of them have their advantages.
But there was no choice. UXDirector spelled it out. We are an as-you-go shop. We'll move stuff forward, make mistakes - and then make things better. The Professor has basically ignored this and has gone their own way. UXDirector has let this happen, under the hope/assumption that good stuff will eventually come down the chute. And - to my mind - the Professor has landed a big pile of maybe and is trying to rub our noses in it on the way out.
"I'm frustrated." I say. I point out how I'm told to write a simple story NOW - then make it better. And my reward for that is to drive Data into a near fury.
"I'm not trying to drive you crazy. I'm doing what my boss has expressly told me to do."
And then all kinds of sh!t starts letting go. Data takes issue with my version of RFD. The Professor asserts that our amount of rework will be less than theirs. I'm incredulous.
"You think you won't have rework?"
"Not as much."
The Professor is shoving 40 pigs through the python at once. Or, they would be if they were sticking around to make them RFD. Instead, Sprint and Data will try to make these pieces flow through the system - all interconnected - all co-dependent - and minimize the rework.
Good.
Effing.
Luck.
A lot of the stories are clones of one another, so you build one, you can easily build the other. But if you start them at the same time and one dev finds a problem that another doesn't...?
The devs were saying as much after the tech review. All that interconnectivity being built at the same time ups the risk substantially.
Sprint, bless them, stands up for me. I get the sense that Sprint and UXDirector are on the same page. Sprint lets go with some stuff that had been bottled up for awhile.
And Runner joins in. "We are not an effective team."
And we aren't. Runner nails it. Three of us are in one office and three (soon to be two) are on the coast. We used to have regular meetings as a team and now it's just impromptu phone calls and email.
And stuff gets missed. And then we get angry at...everything.
It's like therapy. Soon people are apologizing and we're agreeing to have regular check ins. Data volunteers to have regular work sessions with Runner and me on Arwafn.
It was horrible and beautiful all at once.
But I'm so glad it happened.
I end up wishing the Professor well - I do hope they are happier in their new shop - but I am glad they are moving on. I suspect I am not alone in that. I want to work in a team and (with the exception of Noddy) everyone else on the UX team is somebody I like and respect.
We just need to get past the awkward and the awful and move forward.
And I think despite - or perhaps because of - the Professor, we took a big first step.
Huzzah!
Monday, March 31, 2014
One Small Box
I don't know exactly what I expected to find when I started chasing after my great grandfather, but it wasn't this.
I was hot on the trail.
As it happened, there is a facility with that name right where I live (what luck). All the documentation I needed practically fell into my lap. All I needed to do was write a letter and ask them to send me everything they had on my great grandfather. This was going to be a fairly straightforward case.
So be it. If the hunt was to be easy - there was still the anticipation of what I would discover - what they would send me.
Here's how I pictured it:
I would wait a few days, then weeks, and then about the time I'd forgotten about ever making the request, it would arrive.
In my imagination, it would be a small, well-worn box. It would have a few dusty photographs of people I'd never met, maybe a book or two written in Russian, and (best of all) official documentation of my great-grandfather's confinement. There would be a certain amount of finality to it, but with enough leads to take me to new mysteries - if I was interested.
That's what I expected, but then - Hollywood has really done a number on my generation.
What I did get was a letter. In it was the request and supporting documentation I'd sent them - they were sending it back. They'd attached a cover sheet with four lines of text on it. Each line was next to a check box.
One of these boxes was checked. It said:
Our files have been carefully checked and we are unable to determine that the patient was ever seen at [our facility]
So much for round one. Round two is in the mail, and I've queued up round three. Mysteries be damned, I just hate to lose.
I'm still on the trail.
Friday, March 28, 2014
Accent on the 'We'
Okay, Great Grandpa George is gonna have to wait.
I'm gonna let go with some sh!t.
I'm gonna let go with some sh!t.
And I want to start this off by saying that my current job is - by far - the best job I have ever had. Challenging work, a noble cause, outstanding UX support, and free coffee.
I'd also like to say I've been there long enough to say this isn't a case of being in love with the honeymoon.
I work on a team stocked with rockstars. These are people worth going to the mat for.
My UX role is backed up by management. I own the problem, study it, design a solution - and then my devs build it.
Note the curious absence of corporate bullsh!t
As I said, It's a killer UX job.
But I am now going to hurl a co-worker under the bus.
...because they so effing deserve it.
Back when I interviewed for this job, the only sub-awesome bit was the UX guy. A veteran designer, but clearly somebody who thought an awful lot of themselves.
This post is about them.
Let's call them Noddy.
Over two months ago, the UX director called us into a room and asked each of us to take one of the many projects on Product's to-do list. Immediately after doing this, they informed me that I would be working on a report with a funny name.
The UX director has a way of doing this. I think it's their way of cutting the crap.
Fair enough. At the time, it's not like I would have known enough to make an informed choice - so they chose for me.
UXDir then drove the point home by asking "What do you know about [A Report With A Funny Name]?"
Having decided to be honest at this job, I said, "If I think about it awhile, I might be able to spell it. ARWAFN."
UXDir grinned.
Okay, we're all friends here.
The rest of the UX team got their marching orders. Noddy got a pair of reports, Sprint and WatchMeType already had serious project work - which they kept, and Runner got the dashboard that held all the reports.
Work these problems.
So, off we went. And I spent a pornographic amount of time learning about Arwafn. What it is, what it does, why people use it, how people use it.
In all former lives, this luxury of time was unheard of. You need to be done two weeks ago. Go.
At Nerdhaven, so long as the devs had stuff do, you could take the time you needed to solve your problem.
Awesome!
We all plunged into our assignments and started ramping up.
In the meantime, Noddy was still keeping our devs busy by giving them features and fixes so they had stuff to do - AND they had to work their reports.
Sprint and the Professor kept their devs working on their project work.
All was well.
I started writing up things for our devs to do, a lot of Arwafn was stuff people had been asking for for ages, so writing requirements for it was a lot like transcribing our customer's broken dreams.
For the love of God, give us an Arwafn that works!
Doesn't take a genius to write specs for that feature.
1) Make an Arwafn report that works.
2) Also, make it not suck.
I write these up - give it to the devs, aaaaand - they pause.
They hem. They haw.
The existing Arwafn is not in our code base.
Ramping up for my Arwafn work will take time. They will do it, but all my work is the same to them: Stuff they cannot start now.
The Devs are hungry for work, and my stuff doesn't help them. Runner's still ramping up to make stuff, Noddy's stuff is all they have.
And... Noddy's stuff is pretty thin gruel.
I mean, we work in two week sprints, so you don't give a dev a slab of work that takes more than fourteen days. But still...
Noddy writes up stuff like "add a value to a dropdown menu," or "change this text label." These are things that need to be done, but if I was writing up the work, I'd do a bunch in an afternoon and move on to real work.
I'm sure the devs think of them the same way. Developing even simple things takes longer than you'd think - particularly if you do it well, and our Devs are awesome. So, I can't help but think they are uninspired by the work they are getting.
But Noddy's the only one giving them stuff they can do, and they're on two other projects. Runner and I need to step up.
Runner connects with our Subject Matter Experts, and starts getting a list of things that need to get better in report-land. This is something I'm bad at as a noob. I have all kinds of research materials at my disposal, my first inclination is to use them - not schedule a conference call.
Runner does the right thing - they get the SME's on the phone and Noddy shows us the ropes on Nerdhaven's version of virtual meetings.
Aside: Virtual meetings suuuuuuuuuck.
But Noddy shows us how to record our sessions so we don't miss stuff, and facilitates the introductions to the SMEs and generally gets us rolling. I spend the entire call waiting for someone to talk about Arwafn, and I don't think anyone did.
Afterwords, Runner reviews the recording and writes up a summary/partial transcript with timestamps. At the time we're both looking for guidance for what we should be doing and Runner's wondering if they're wasting their time with the transcript. They send it to me and Noddy for review and I forward my edits.
Noddy never forwards any edits. To Noddy, this is a waste of time.
I believe this is not a waste of time.
We had a session full of good info, but all of it was stored in our fragmented memories - and a video recording.
Months from now, when someone asks what we came up with in the meeting, we'll all have forgotten the call and we'll be left with the video.
A two hour video.
PRO TIP: You cannot skim video.
If we wanted to know what was in that file, it would take 2 hours. And if we didn't write anything down when we watched it, we'd have the same problem a month later.
This, I learned, from Sensei.
Sensei wrote up notes on some conference calls that saved me a ton of time. A summary I can skim and learn "This two hour video is all about reports." If I want more, I can read in detail, or (last resort) watch the video.
Moral: Write the damn notes. If you never find a use for them, someone will.
Also: Thanks, Sensei.
Anyway, our Devs are starving for work. Our team lead, BigDog, is trying to be patient, but wants us to give his devs work.
Soon.
I write up more stuff for Arwafn. Because it's what I've been told to do. The other UX folks are going to land stuff soon, and after those are done - the devs can take my stuff.
Noddy lands a few more appetizers, but nothing resembling real work. The devs sigh, but when all you have is fritos, you eat the fritos.
Fast forward a sprint.
We're reviewing work for the devs and I proudly call up my specs for more Arwafn stuff. BigDog is straining to be nice, but they can't eat Arwafn yet. I've got a seven course meal of inedible.
I feel like I've let the BigDog down. I go to UXDir and ask if there are things I can give our devs to work on that they can do right now. They aren't on our goal list, but there are literally a *ton* of things we could improve in our UI.
UXDir is polite, but firm. "No."
Noddy is no help. This time around, they don't even have appetizers.
What we end up with is pretty much a typo correction: Remove Reports 1 & 2.
What we end up with is pretty much a typo correction: Remove Reports 1 & 2.
Dead simple features. Not even features, really. Delete some things. Whoo...
Dev's gotta eat...
So, we're deleting Reports 1 & 2. Maybe a hour of code time for each. Twice that to make sure nothing else got broken in the process.
But it's a joke of an iteration. Devs are meeting to figure out how to spool up for Arwafn work and a bunch of other things we have in the pipeline - but when we show our clients what we've been doing lately, we should expect a yawn.
At Nerdhaven, we do Agile - and Agile means you stand in front of your work and show your clients what you've been up to. When you land big slabs of awesome, you and your team look awesome.
When you take a bow in front of a heap of nothing - you and your team look stupid.
Agile is about forcing that realization upon people and using it as motivation.
We don't want to look stupid, ergo, we will get our sh!t together.
We don't want to look stupid, ergo, we will get our sh!t together.
Yesterday, we took our bow in front of nothing. Noddy was the MC, and tried to put the best spin on it they could. "We'll have you out of here in two minutes, end to end."
Noddy shows the clients that - in the past two weeks - a room of highly-paid professionals has succeeded in deleting two reports.
And then things go wrong. And not in the way you'd think they would. Our SMEs are on the conference call asking why in the hell we've deleted Reports 1 & 2.
Noddy's ready with the pat answer, "Reports 1 & 2 have been replaced by newer reports and are no longer needed."
I vaguely remember this, and something about having never removed the old reports. We were just fixing this. Why was this a question?
I'm almost relieved no one is giving us the business about the scant offerings, but the SMEs aren't done.
"Reports 1 & 2 have functionality that do not exist in the newer reports. Why did you get rid of them?"
Noddy mentions the earlier meeting with the SMEs about reports. "We'd agreed we could get rid of these reports. But if you need them back, we can certainly roll back the changes."
QA weighs in - Reports 1 & 2 have some benchmarks that are unique.
This is news to Noddy.
This is news to me - I paid no attention to these stories. I'm the Arwafn guy. I know nothing about Reports 1 & 2.
All three UXers in the room look dumbfounded.
In front of the clients.
Awesome.
Noddy assures everyone that the SMEs had agreed to this change, but we can revisit the decision.
We end the meeting promising to follow up with the SMEs.
Back in the room. BigDog has had it. He gives Noddy an earful "I can accept that the reports need to come back, I can accept that we made a mistake. What I can't accept is that we're at showcase and DON'T KNOW WHY WE DID THIS WORK?"
There is no argument. BigDog is completely right. We work up ways to check on this sort of thing. The SMEs have changed their minds since we talked - and now they want their report back. We should be ready to confront them with evidence of their reversal. We should not sit silent while they ask why we did what they asked.
Product shows up and catches the tail end of BigDog's rant. Product is clearly displeased that the SMEs are pointing us in different directions.
Product is clear: Sort this out.
Later that day. Runner and I are hashing out what happened. Runner points out that removing Reports 1 & 2 was their feature, but Noddy pushed it to the devs. Runner is just sick that people think they pushed bad work.
Runner had some doubts about it, but Noddy said it was ready. So it went.
It was a simple task: Remove Reports 1 & 2. Not like there was a lot to review.
But Runner's pointing out there was a whole meeting about those reports. And it was recorded. And Runner transcribed it.
The SMEs asking questions today has Runner remembering that we were supposed to migrate stuff out of Reports 1 & 2 before we blew them away.
Runner's worried. BigDog is pissed - and BigDog knows this feature was written by Runner. And we all should have caught this, but Noddy shouldn't have given Runner's story to the devs.
I tell Runner I'll talk to BigDog. If this story comes from Runner, it's going to sound like Runner's shirking blame. Runner's not like that, but they don't want soak up all the fail on this.
I talk to BigDog and lay it out. This is a UX fail, not a dev fail - but Noddy moved somebody else's work without knowing it was ready. We should have stopped them, but no way this is Runner's thing.
BigDog nods like I'm telling him something he already knows.
Today.
I'm rolling in around noon - little e was sick - and I meet Noddy in the hall.
They're like "That call with the SME's on the reports, that was recorded?" Or words to that effect. I was out of it. But it was odd that they were asking about this, first thing, in the hall.
I'm like, "Yeah. We recorded it."
Noddy starts talking about it being a two hour recording, and grumbling about how hard it would be to listen to the whole thing. They said something like they'd started to, but it was just too much of a pain...
I kill that noise.
"You could just read the transcript." I am so glad I talked with Runner yesterday. "Runner wrote the whole thing up and sent it around for edits, remember?" I bet you don't.
Noddy leaves and I hit my desk.
BigDog is on me soon as I get my coat off. He wants to know the details on the Report discussion we had with the SMEs.
This is a thing.
I find the transcript, CTRL-F for the report names.
It is dead obvious that the SMEs are right. The transcript has them asking us to move the features out of Reports 1 & 2 and afterwards we can delete them.
Five seconds to the answer.
I spend five minutes scrubbing to the matching part of the video file to listen and make certain.
Noddy told them they'd agreed to remove the Reports.
He was mistaken, or he lied.
I give the information to BigDog who begins digging into it immediately.
The day is a blur of catching up from missing the morning, but finally we arrive at the moment that made me write this.
I'm talking to BigDog after a long meeting with Runner. Noddy's talking to one of the SMEs on the phone.
He's saying "Well, we had a new BA."
I'm like: No way I heard that right.
BigDog and I are cross talking about something funny. BigDog is either hilarious or fascinating on pretty much any subject he wants to be.
I'm trying to keep up with him, but I keep hearing Noddy's cross talk.
Noddy is blaming Runner.
I sit straight up and look right at Noddy, but it has no effect. Noddy wraps it up and before I can think to say anything, BigDog is all over Noddy.
"I heard you talking to the SME, and you said some things that were not true."
BigDog's been tracking the conversation longer than I have and he's going after what Noddy told the SMEs in our showcase.
Noddy starts out with his "its in a two hour recording-"
BigDog takes him out at the knees. "I've read the transcript. I listened to the 20 minutes where you were discussing these reports."
Noddy keeps weaving, shifts to saying it was Runner's story.
BigDog calls up the audit trail. "You pushed it to 'ready for dev.' There's your name, right there."
And finally, Noddy shifts to the position he should have started with - shared blame.
"We missed it."
Which is just another floor down in Noddy's house of bullsh!t, but closer to a professional truth. UX gave Dev specs that should not have been coded.
Which is just another floor down in Noddy's house of bullsh!t, but closer to a professional truth. UX gave Dev specs that should not have been coded.
At this point, I should pile on with BigDog, stick a fork in Noddy.
But I don't.
BigDog did the right thing, the hard thing. He stuck it to Noddy over the BS line to the SMEs.
About pretending it was all on Runner.
I did the easy thing. Said something magnanimous about making sure any new features pushed to dev have been agreed on by UX. But that's shit. Noddy was part of a mistake the team had to eat. Instead of owning up to that, he tried to lie his way out of it, then blame it on Runner.
He's a weasel.
And there was a right thing to say right then and I didn't.
Which is why I'm writing this post. This post is my promise into the void that I will not let this slide.
Noddy and I are going to discuss this - and I am going to say what's on my mind.
My team is a good one and they deserve better.
From Noddy - and from me.
Labels:
Bad UI,
Being a dork,
Growing the hell up,
Just desserts
Subscribe to:
Posts (Atom)