Data Protection Officer
Forget the chicken. It’s her right.
CFO
With a €20 Million penalty, we can live with the mystery.
CMO
Can we still tell it’s a chicken? Maybe it’s a rooster. I’m so confused.
App Dev
The chicken can’t cross until Sprint 15 anyway.
Sales
As long as she crosses by the end of the quarter, we don’t care why.
UX
Define “why”.
Legal
For increased territorial scope.
Data Analytics
[swigging from a flask] We used to know, before the Spring of ’18…
Presented at the Philadephia Business Intelligence User Group Meetup on July 27, 2017
Minimum Viable Moscow Mule
Vodka, lime juice and ginger beer drunk warm from a paper cup in Sprint 7. The ice isn’t scheduled to happen til Sprint 8, and the copper mug was cut from the budget.
Really Old Fashioned
Rye whiskey, bitters, a sugar cube, and a few waterfall splashes. Takes forever to make, and by the time you serve it, the client wants something else.
Scrum Swizzle
Gold & dark rums, juice, and bitters, drunk standing up at 9 am. Every team member takes a turn saying how many they drank yesterday, how many they plan to drink today and any roadblocks that might prevent their consumption.
Pair Martini
Vodka, pear nectar, lemon juice and simple syrup. One programmer drinks it, the other reviews the first programmer’s technique to make sure they did it right.
1. “Tracking tags will slow down our site.”
In my experience, tracking tags are often the first thing developers blame when sites load slowly. But even in the bad old days before asynchrony, tracking tags were rarely the real culprit. It’s even less likely now with tag management systems like Google Tag Manager and Tealium. So why does tagging get blamed instead of image formatting/sizing, java script minification, widgets, etc? Because IT is busy, and IT usually doesn’t own tagging. So, they kick the can to you. So, make sure the page tag is placed properly, prove through metrics that tag weight is negligible (it usually is), and kick the can back.
2. “We don’t have time to add tracking.”
IT departments in an agile development environment may classify tracking as an enhancement rather than a launch requirement. Remember, your IT buddies are graded on (a) coding and launching a digital asset on time, (b) adding enhancements and (c) making sure the asset continues to function well. Their bonuses do not depend on your ability to track. So take your favorite Finance Department buddy to lunch, sigh heavily, and opine about how much more efficient your budget could be if ONLY you could track right from launch. You’ve just gained political clout to move tracking from “nice-to-have” to “must-have”.
3. “Tracking tags can interfere with site functionality.”
Well, they could. But they won’t under your watch. Because you will make it your job to ensure tag library names are unique, and tracking is placed correctly on the page. Tags will be tested in the dev environment before going to production. Those are typically developer competencies, but your tags aren’t top-of-mind to your developer buddies. So help them help you. Once your developers reach a comfort level that your tags won’t break anything, the road ahead gets a lot smoother.
4. “It’s a waste of time to track all that stuff.”
Maybe so. That’s why you will have use cases – something like “If I knew “X”, I could do “Y”. For example:
“If I knew [which tools visitors from partner sites used], I could [optimize content to those visitors to increase engagement]”.
“If I knew [user article view sequence], I could [suggest ‘you-may-also-enjoy’ links for each article].”
Track what’s actionable now and in the future, and be prepared to justify each tag you add.
5. “Don’t tell me how to code.”
“Here’s what we’ve found works best” or “Here’s how other sites usually do it” can go a lot further than “Code it exactly the way we tell you.” I’ve found that patience, persistence and emotional intelligence can help Marketing and IT build a culture of measurement pretty quickly. At first, IT organizations may feel their autonomy is at risk when subtle code changes are needed to accommodate Marketing’s tracking. That happens. I knew we’d gotten past that hurdle the day a developer called me and said “Hey there’s no tag plan on this new functionality they just gave me to code – think we should we tag it?”
6. “Pssst…. hey, do you know how to do this web analytics stuff they’re talking about?”
Sometimes it’s because (a) they don’t know how to do it and (b) don’t want to admit to you they don’t know how to do it and (b) don’t think it ought to be part of their job to Google instructions on how to do it. This conversation may involve folks above your pay grade to get them to understand the importance of analytics and their role in it. But have the conversation. Don’t give up.
What they say: “Help me understand this requirement.”
What they mean: “Drop this requirement. I’m launching a Kickstarter campaign to fund the bribe I’ll offer you to drop this requirement.”
What they say: “Let me confer with the team on the feasibility of that request.”
What they mean: “Maybe if we had a time machine… LOL. No seriously, you’re delusional.”
What they say: “By close of business.”
What they mean: “By the time our office closes. Our Honolulu office.”
What they say: “Late in the week.”
What they mean: “Friday at 4:49 pm.”
What they say: “Sometime next week.”
What they mean: “Next Friday at 4:49 pm.”
Curiosity Wasn’t Priced In
Curiosity is a good thing. It’s vital when it comes to data. It uncovers the “why” behind the “what”. Failing to price in curiosity can be the difference between “servicable” and “wow”. Good analysts will follow their curiosity anyway.
Timelines Allowing No Mistakes or Delays
Someone will screw up and code will need fixing. Someone will come to work with the flu and infect 3 people. Machines will break. Approvals will be delayed. People will change their minds. Optimism isn’t your friend when it comes to estimating.
Death by Meeting
How long will it take to code this? About 8 hours.
Estimate: 8 hours
8 hours of coding plus 2 hours of meetings = 10 hours
Boom! You’re 25% over on the job.
A few years ago at a National Center for Database Marketing conference, a panelist said that the decision whether or not a marketing organization should build their database management functionality in-house often rests on the relationship between two people – the marketing chief and the head of technology. How does that dynamic play out in your organization?
Is their relationship collaborative and friendly? Then building and maintaining a marketing database in-house can work well. But if the two executives regularly engage in silo defense and turf-grabbing, then outsourcing may be faster, less stressful on the business, and offer you more autonomy.
Naturally, politics shouldn’t be a key factor in the decision. But it usually is because politics drives delay – and delay drives opportunity costs. You can successfully pull an internally-managed database solution into the station even if your CMO and CTO are ‘frenemies’. But it will take longer while they argue over who’s driving the bus.
How much incremental revenue, cost savings, or efficiency do you lose in the meantime? You need to figure it out, then figure it into your decision process.
I was once refused administrative rights to a database, due to a business rule that only the I.T. team members were qualified DBA’s. I challenged the rule, citing my assistant’s graduate degree in Computer Science and the fifteen years of database experience between
us. We finally did get our rights because we had the proper credentials, not because we were entitled to autonomy. If you don’t possess real qualifications within your team or have immediate plans to hire people with them, outsourcing is probably best.
You’ve got to put yourself in your tech manager’s shoes. A poorly written query against a database on a shared server could grind her production system to a halt. When the field offices suddenly can’t enter any new contracts, she’s the one who has to stand in front of the Sales VP’s desk explaining what happened, not the hapless marketing guy who set the whole thing in motion.
So give her a comfort level by talking like a DBA instead of a marketer. Which statement will be more effective in dispelling her fear?
a) “We should be able to control our own database – we know what we’re doing – you won’t be sorry.”
b) “I promise, I’ll never perform a six-table outer left join without a where clause or import a two million row table without proper indexing.”
If you know what (b) means, she will realize you’re aware of the type of bad acting that brings down servers and she has your word that it won’t happen on your watch. If you don’t know what it means, you should seriously consider outsourcing.
Consider safety and continuity. The server corrupts, the on-call junior tech loads the backup, which corrupts too, and keeps loading each previous backup until they’re all damaged. Or you discover that the backup failed every night for the last three weeks, but the failure notification went to the phone of an employee laid off last June. It happens. Tight procedures and consistent oversight help mitigate it, but the risk is inherent to any in-sourced solution.
Many consider outsourcing safer. But consider the October 2009 T-Mobile Sidekick debacle – a catastrophic database failure in which some vital client data was irretrievably lost. And the keeper of the data wasn’t some undercapitalized DB startup – it was Microsoft. They’ve since recovered a portion of the lost data, but confidence in outsourcing and cloud computing in particular took a definite hit.
Outsourcing data failures are fairly rare, and you at least have the option to sue. But either outsourced or in-house failure can cripple your operation and lose customers. You need to honestly assess how well your in-house staff can execute on database maintenance best practices, compared to the vendor’s ability to do the same, and use those risk factors in your decision.
PLAN B: TRAINING WHEELS AND TRANSPARENCY
If you definitely want to take your database operations in-house, and your tech team balks, you can offer to launch with “training wheel” rights and gradually earn your way to autonomy. Offer to:
Accept read-only and row append rights to start.
Submit all query coding to an IT manager for quality assurance prior to a live run.
Schedule meetings to review server load metrics, table change requirements, and new data loads you need them to support.
Call for advance clearance to append more than a 100K records into the database.
Give it six weeks and ask again. If you’ve been diligent, you’ll likely be granted full rights to manage your database. The tech department doesn’t really want to review your code, add more meetings to their schedules, or interrupt their day to approve your appends. They just want a comfort level that:
a) You acknowledge you are playing in their sandbox.
b) You won’t break anything.
c) You will be a good steward of the data.
No matter the relationship between your CMO and CTO, you can better develop your own relationship with IT by seeing things through their eyes.
Here are a few handy tips to annoy the bejeezus out of your co-workers in an open-office configuration:
1) If a topic’s worth discussing, it’s worth discussing on speaker phone. Bonus points if you’re talking to your dermatologist.
2) Instead of saving down a quick iPhone image to Dropbox of the whiteboard you just filled top to bottom with your multi-color Dry-Erase brilliance, just scrawl “DO NOT ERASE” on it. Then leave for your 2-week backpacking trip to Patagonia. Everyone will understand.
3) Be sure to cram as much text as you can possibly fit onto the project retrospective PowerPoint presentation. Why, with a few crafty abbreviations and a 4-point Arial font, you could get the entire Magna Carta on a single slide. The audience can get the gist via the audio anyway, since you’ll read each slide verbatim.
4) You can never spray on too much Axe. Use enough so your chick magnet scent-cloud enters the scrum before you do.
5) A garlic andouille sausage and pepper jack sandwich with extra onions is the perfect eat-at-your-desk lunch to get you through a grueling afternoon of pair programming.
10) There’s never a line for the Ladies’ Room. Like, ever.
9) Clearly, your easy access to the facilities more than makes up for your 87-cents-on-the-dollar salary differential.
8) Dudes over age 30 spot you points for being able to write code and possess ovaries at the same time.
7) Those Over-30 dudes are likely to be so impressed, they’ll hit on you – but they’re very used to hearing the word “no”.
6) Pizza and Red Bull know no gender.
5) Chicks also look great in hoodies, board shorts and flip-flops.
4) You improve the ambient scent of the work area by a factor of 20%.
3) Your colleagues avoid you three or four days a month out of fear – a great time to catch up on code debt.
2) Pair programming is tons more fun when your programming partner is utterly terrified you’ll go off on him at the slightest provocation.
1) Your boss’s offensive comment on your performance review to “stand back and let others shine” is now a meme.
