Category: Work

Joining a Giant Company: Three Concerns

I started working for The Walt Disney Company in August of 2021 – it has 190,000 employees. The Walt Disney Company’s employee base is roughly the same size as the biggest city I’ve ever lived in.

(that’s Providence, RI, by the way)

As a younger man I did work for larger organizations – The Federal Government (roughly 2 million employees) and Starbucks (in the neighborhood of 350,000 employees) – but that was in some ways a different professional landscape. I was an AmeriCorps community organizer, I was a part time barista, whereas at Disney I’m a Proper Professional, I have a letter/number designation

(P4! Senior Product Manager II!)

I have to navigate the workings of the organization to accomplish my goals in a way that is different from those other jobs.

Since becoming a tech professional, I’ve worked at two organizations prior to Disney – Automattic, the parent company of WordPress.com and Tumblr, where I was employee number 130-something, and dbt Labs, where I was employee number 42. While these were both undoubtedly tech companies, in the same broad industrial space as Disney’s tech arm, I did have my concerns about shifting my professional context from the startup space to the established enterprise space.

(even just considered by itself, Disney Streaming Services, the arm where I work, is larger than dbt Labs and Automattic combined)

That’s what this post is about – what those concerns were, and how they’ve played out so far. Note that I’m just about seven months in, and I still have a lot to learn, and some of the following may turn out to be inaccurate, or maybe overly optimistic!

Concern: A big company won’t be as flexible or as energetic as a startup.

This concern, I’d say, is partially correct. I think maybe what I’ve found to be more important is, figuring out what I really value at work. That is to say, there is some part of working at a startup, of always having nine hats and a dozen projects to juggle, the constant uncertainty and balancing act of this vs that, of some weeks where you feel like you’ll never get to grab a breath – there is a part of me that really is temperamentally inclined toward that way of working, and the intensity of the relationships you develop in that environment.

What I’m coming to see now, though, is that I am not sure that I particularly like that part of myself; to be in a constant state of reaction and forward momentum at all costs can be thrilling, but it isn’t necessarily good for you, or your marriage, or your mental health. It might not even be particularly good for your career – more on that later.

The flexibility piece, I think I have been surprised by: I am able to operate in some ways more flexibly at a larger organization, because, and this may be especially notable for a Product Manager, who has to work across departments and functions quite a lot to get basic things done, you have so many more degrees of freedom. When you’re at an organization of 48 people, there are very few decision makers, very few paths to success for any given proposal or suggestion – when you have dozens of departments and directors to chat with, the opportunities for creative solutioning open up in ways that I had not ever expected.

Concern: I will be stifled and stymied by suffocating adherence to The Process.

Another sort-of-true, sort-of-not concern here. There are times when I do feel some pining for the faster cycles and lower organizational overhead of my earlier startup jobs – but I also think that the trade off makes sense, as an organization gets larger, and the pieces become more complex to place correctly, and the timelines and dependencies multiply exponentially, of course you need more scaffolding and structure to keep everyone rowing in the same direction.

There are also times though, especially on a Thursday afternoon, when the week’s Zoom Fatigue is really settling in, that getting a checklist of super clear action items from someone that outline exactly how to move my project forward, can be a balm on this PM’s decision-blasted brain. Sometimes it can be nice to not have to generate generational change in an explosive way at will, and instead, write the doc, and set up the meeting, have the simple satisfaction of a mildly productive day.

Concern: Working at a giant organization won’t allow for the kind of rapid career advancement that a startup can offer.

This one I feel may be right, depending on how you think about career advancement.

Part of it has to do with titles vs toolboxes (and there’s probably a longer post in here that I can loop back to later) – there’s also something here wrapped up in the book Peak (by Anders Ericsson, I had to search my own site to find, shockingly, that I haven’t written about this book already!)

That is to say, joining an early stage startup can represent a huge title gain – you can jump to a level that possibly wouldn’t be accessible to you otherwise. This can be amazing for your career, especially if you’re trying to make a lateral or business-area kind of shift (see my own move from data org to product org, in fact!)

But what it doesn’t afford you, the high stress, high energy, mostly-reactive world of a growth stage startup, is much space for reflection and repetition – since you’re doing, nearly by definition, new things all the time, and learning just-enough on the fly to move onto the next brand new thing it can be really challenging to build meaningful mental models around how to do the work itself, in a way that is sustainable and excellent – what I’m calling here the toolbox.

Whereas working at a larger org, with lots of folks in similar roles, with semi overlapping experience, can offer the kind of community of practice that you’ll struggle to find at a smaller org – notably in Product, where there tend to be few professionals, and they don’t typically have built-in opportunities to peer mentor or skillshare.

I don’t mean to say that this is a pure binary – it’s probably a sliding scale, and I’m sure there are some orgs that offer access to both title and toolbox. I also don’t mean to imply that one is better than the other – they’re both growth, but certainly different kinds of growth, and choosing one or the other (like many things!) is an exercise in trade-offs.

The Emergent Import of the Tangible for the Remote Workplace

(what a title!)

The longer I lead remote teams, the more clear it becomes to me, that there are things which take on an outsized importance within a remote team – especially within an all-remote organization.

(an aside: I appreciate the definitional challenge of calling an organization “all remote” – remote from what exactly? “Distributed” is an alternate term that I appreciate more but, has yet to gain a ton of traction)

Some of the things that take on an outsized, and sometimes surprising, importance, that I’ve written about in the past:

Phatic Communication

Eating On Camera

What’s starting to appear more and more to me these days, is how important, or perhaps how impactful, the tangible becomes.

What do I mean when I say, the tangible?

Over the course of the last year, we’ve built out an in-house ETL solution that we call SQLT – pronounced “Sequel Tee” – and had to work really hard to gain buy-in from folks within the organization to start using it, rather than defaulting to other solutions that were more familiar or more comfortable, for whatever reason.

Once we had a couple dozen folks who had committed code using SQLT, I had some stickers made, and I mailed them to those who had a commit on their record – they were a surprise, no one was aware of them coming. I trucked down to the post office and sent a dozen envelopes to three different continents.

I have a few left! They look like this:

sqlt.jpg

…and it was a great hit! Folks really appreciated them!

I wonder, if we were in a co-located environment, if it would have had much of an impact. Since, in an in-person workplace, you have many, nearly constant, tangible artifacts of your work – an office, a desk, a cafeteria.

In a distributed workplace, the tangible is much more rare: your workplace is your home, or a cafe, or another shared space – areas that aren’t exclusively the place for work, and often serve many duties.

You don’t often interact with your colleagues in the flesh: this is part of what makes regular meetups or conferences an important source of connection and re-connection.

So too, I think, receiving something you can hold, something that comes in the mail, from your otherwise largely ephemeral colleagues, takes on an outsized impact in a distributed environment.

I used to send my teammates postcards on their birthdays and their Automattic hiring anniversaries (naturally, Automattiversaries) – something that would probably seem a bit odd in a co-located workplace, but in a distributed one, it really felt like a special token of recognition, a tangible touchstone of the time and the work we’d done together.

Due to the intentionality that phatic communication requires when working remotely, it’s easy for distributed workers to fall into communication patterns that are totally professional: interactions can be purely work focused, transactional, without the kind of socially pleasant borders and decoration that you get for free in a co-located environment.

Asking your colleagues to eat lunch on camera can feel a bit awkward or out of place.  After all, in a co-located environment, which we still have in our brains as the default, it would be odd to ask for! But, part of the distributed organization’s success relies upon us recognizing the things we no longer get for free, what we maybe took for granted in a co-located office, and how we might replace them, or improve upon them.

Like that eating-on-camera piece, I think a birthday or work anniversary postcard would be strange in a traditional office – but it is, not only not strange, but maybe quite important in a distributed workplace.

The injections of the tangible help remind us that our colleagues and relationships are real – a postcard or a goofy sticker, by existing between our fingers, offers a kind of reminder that our colleagues too, are real and tangible.

 

 

Become an Analytics Engineer!

OK, so let’s get something out of the way up front – yes, I wanted to be a data scientist.

But you know what? Once, I also wanted to be a professional coffee roaster.

These jobs (and aspirations) are similar primarily insofar as that my desire to have them took a nosedive once I got a real glimpse of what doing them was like.

If you like the idea of working with data, if you see yourself as someone who has ambitions or aspirations working in the data space, you should read this article from Dan Friedman – Data Science: Reality Doesn’t Meet Expectations

I work closely with data scientists – in some ways I genuinely envy their approach to work, and the way that they can find impact within organizations. I am super glad they are out there and I am so grateful for the insights and thoughtfulness they bring to the table – but that job’s not for me!

The job that I’ve found suits my nature, allows me to have a lot of impact, and work on important and interesting problems, is a new one – the Analytics Engineer!

Job titles in data and in tech are hard – do we really need a new one? The Analytics Engineer is this sort of emergent term, that describes an area of work that folks have been operating in for a while now, but with modern tooling and third party solutions has seen a rising need.

NB, not everyone knows that they need an Analytics Engineer – often you’ll see job descriptions for titles like Data Analysts, Business Analysts, Data Engineers, even Data Scientists – but the work that will be expected is Analytics Engineering work.

That work is more technical than a strictly Excel based analyst – no disrespect to Excel, sufficiently advanced Excel is indistinguishable from software engineering in my opinion, but, you will need some SQL chops to be effective as an Analytics Engineer. It’s less statistically heavy than a data science role. It requires literacy in data engineering but, in most cases, not necessarily the chops to originate an Airflow DAG. Strong opinions about data architecture is helpful but, often you can learn that on the job!

As I talk more with folks about this kind of work, and as we struggle to find qualified candidates for our own teams, I realized that I’ve repeated the same advice probably a half dozen times: sometimes to friends, at least once to an Uber driver, over Slack and in person. When this happens, I take it as a strong signal that I ought to put up a blog post!

So here it is: this is my guide to how you can become a competitive candidate for Analytics Engineering roles (even if they’re hiring for the wrong job title!)

One of the challenges to gaining the kind of experience you need in order to become a competitive candidate is that much of the best in class tooling for this kind of work is either hard to use alone or prohibitively expensive – something like Airflow is a great solution and very broadly used, but, it’s going to be a challenge to set up locally to use with toy data. Looker is a very common tool for this kind of work, but is terribly expensive for an individual to use as an educational tool.

So, this set of suggestions is meant to be used in reality by anyone – you should be able to follow this advice at low or no cost.

Yes, if a job description is looking for Airflow ETL experience or Looker modeling experience, you won’t have exactly that – BUT as someone hiring into a role with exactly that wording in our job description, I also recognize that the free tooling below is eminently transferable to the tooling that we use in-house. You can mention that you accomplished the same tasks with a different tool and that the skills are laterally transferable in the cover letter – a cover letter with that kind of attention to detail is already ahead of the pack.

Here’s your stack:

FIRST you have to find some free data that you’re interested in. That second part should not be neglected – if you want to see this project through to its completion (and gain your Competitive Candidate merit badge!) , it is absolutely imperative that you make choices that make it as easy as possible for you to stay motivated!

Are you interested in food? See if you can get data from your local agricultural co ops or agencies on historical data. I’m interested in local politics, so I FOIA requested the voter registration data for the entire State of New York – it came on a CD!

NYS_CD

Being interested in the data you’re using is going to make a big difference when it comes to understanding it, modeling it, and then building some reporting – especially if the only end consumer is you! Bonus points if it is a streaming source of regularly-updated data, like web traffic or an ecommerce application.

SECOND I recommend using BigQuery as your data storage solution – they have good docs, they have a free plan, and they integrate really easily with the other parts of the data stack. If you have another solution you prefer, that’s fine too!

THIRD You must learn the excellent and open source dbt from your friends and mine at Fishtown. Here’s the tutorial and here is the Slack community. dbt is what you’ll use to take your ocean of raw data, transform it into  tables that fit the dimensional modeling standard, and apply robust testing to those transformations.

If you have a little extra cash for this endeavor, I recommend buying the Database Warehouse Toolkit and reading the first four chapters to really dig deep into dimensional modeling. If you’re trying to stay absolutely no-cost, you can suss out some blog posts and other resources for free!

FOURTH You’ll build out your final reporting using the free tier of Mode Analytics – note that in order to stay within their free tier, you may need to reduce your final reporting tables to “Thousands of Rows” – take this as an extra challenge to your transformation later, and an opportunity to additionally leverage the power of dbt!

FIFTH Make sure you document the journey – I always recommend blog posts, but probably a well documented Github repo will be more interesting, and more likely to be reviewed, by most technical hiring managers.

At the end, your process would look something like this:

I recognize that the above glosses over a lot of the work that is behind this proposal – probably a dedicated person already working full time, putting in some time nights and weekends, could get through the above in six months. It’s not a short trip, but, if you’re looking to make a move, this is one way to do it.

The need for Analytics Engineers is only growing, even if the job title itself is still only starting to gain steam – I hope you’ll give it a try!

Source & Medium: A Medium Sized Dilemma

Subtitle: Source, Medium, Attribution, Stale Information, and The Future of Data

Here’s our situation – we want to be able to slice reporting and dashboards by a number of dimensions, including source and medium.

MARDAT (the team I’m lucky enough to be working with) is working to make this kind of thing a simple exercise in curiosity and (dare I say) wonder. It’s really interesting to me, and has become more and more clear over the last year or so, how important enabling curiosity is. One of the great things that Google Analytics and other business intelligence tools can do is open the door to exploration and semi-indulgent curiosity fulfillment.

You can imagine, if you’re a somewhat non-technical member of a marketing or business development team, you’re really good at a lot of things. Your experience gives you a sense of intuition and interest in the information collected by and measured by your company’s tools.

If the only way you have access to that information is by placing a request, for another person to go do 30 minutes, two hours, three hours of work, that represents friction in the process, that represents some latency, and you’re going to find yourself disinclined to place that kind of request if you’re not fairly certain that there’s a win there – it pushes back on curiosity. It reduces your ability to access and leverage your expertise.

This is a bad thing!

That’s a little bit of a digression – let’s talk about Source and Medium. Source and Medium are defined pretty readily by most blogs and tools: these are buckets that we place our incoming traffic in. People who arrive at our websites, where ever they were right before they arrived at our websites, that’s Source and Medium.

We assign other things too – campaign name, keyword, all sorts of things. My dilemma here actually applies to the entire category of things we tag our customers with, but it’s quicker to just say, Source and Medium.

Broadly, Source is the origin (Google, another website, Twitter, and so forth) and Medium is the category (organic, referral, etc) – if this is all new to you I recommend taking a spin through this Quora thread for a little more context.

What I am struggling with, is this: for a site like WordPress.com, where folks may come and go many times before signing up, and they may enjoy our free product for a while before making a purchase, at what point do you say, “OK, THIS is the Source and Medium for this person!”

Put another way:  when you make a report, say, for all sales in May, and you say to the report, “Split up all sales by Source and Medium,” what do you want that split to tell you?

Here are some things it might tell you:

  • The source and medium for the very first page view we can attribute back to that customer, regardless of how long ago that page view was.
  • The source and medium for a view of a page we consider an entry page (landing pages, home page, etc), regardless of how long ago that page view was.
  • The source and medium for the very first page view, within a certain window of time (7 days, 30 days, 1 year)
  • The source and medium for the first entry page (landing page, homepage) within a certain window of time (7 days, 30 days, 1 year)
  • The source and medium for the visit that resulted in a signup, rather than the first ever visit.
  • The source and medium for the visit that resulted in a conversion, rather than the first ever visit.
  • The source and medium for an arrival based on some other criteria (first arrival of all time OR first arrival since being idle for 30 days, something like that)

It feels like at some point Source and Medium should go bad, right? If someone came to the site seven years ago, via Friendster or Plurk or something, signed up for a free site, and then came back last week via AdWords, we wouldn’t want to assign Friendster | Referral to that sale, right?

Maybe we have to create more dynamic Source/Medium assignation: have one for “First Arrival,” one for “Signup,” one for “Purchase.” Maybe even something like Source/Medium for “Return After 60+ Days Idle”

In the long run, it feels like having a sense of what sources are driving each of those behaviors more or less effectively would be helpful, and could help build insights – but I also feel a little crazy: does no one else have this problem with Source and Medium?

Working Remotely and Tangible Craft

Before I started working at Automattic (the folks behind WordPress.com and the Jetpack WordPress platform), I had a career in what I call progressive coffee: high end coffee, well made, ethically sourced, that kind of thing.

(I’ve written a little about my journey from a hospitality job to a job with a tech company here and here, if you’re curious about that)

While I was working at Seven Stars Bakery in Providence, Rhode Island, our biggest day of the week was Saturday, especially Saturday morning. One part of my job there was designing the layout of the employee space, as well as building and improving the training programs. Spending my Saturday mornings at the busiest location on the busiest day was a great way to ensure that my work was successful, and was adding value to the company and customers when the rubber hit the road.

During one of these shifts, I’d typically clock in 14,000+ steps: it is borderline insane to think about, now, when I struggle to get in 10,000 steps in a whole day!

Preparing really excellent espresso, tasting coffee to decide what to bring on as an offering: these are inherently and importantly physical and sensorial activities: awareness of the body and what it’s telling you is part and parcel of finding success in these pursuits. You have to not just heat the milk, you have to listen, to watch it, to gauge the temperature of the pitcher against your hand. You spend a lot of time focused on and attending to your sense inputs, using your body and its inputs in increasingly focused and demanding ways.

The combination of focused precise work (which being a quality-focused barista in a busy espresso bar absolutely is) with 14,000 steps meant that the days were cognitively and physically exhausting.

Moving away from this career into what I do now, working for a software company, and more specifically working fully remotely, was a real shift. It was a real change, in some ways I expected (I didn’t have to work on Saturdays anymore!) and in some ways I did not expect.

One of the unexpected changes was that I found I was attracted to hobbies that were much more manual: gardening at first, and more recently woodworking.

Over time I’ve come to realize that the part of me that is fulfilled by building things and planting vegetables is the same part of me that was fulfilled by those busy Saturdays: there’s a value to using the body, to getting to know what your body can do and how many amazing things you can teach it to accomplish.

Part of it, too, is that manual pursuits, physical crafts, impose humility on the practitioner: you cannot Google how to cut a perfect dovetail.

Well, that’s not true – you can Google it, and get lots of results! But, you can’t Google how to actually do it, like Neo in the Matrix. Once the saw hits the lumber, the truth comes out. There is no quick route: if you want to make beautiful things out of wood, you have to spend a lot of time making pretty ugly stuff first.

You simply have to put the miles on: there aren’t any shortcuts.

(This is also true for another new pursuit of mine – Brazilian Jiu Jitsu, but you’d have to substitute “make ugly stuff” to “get choked out by strangers” – different but the same!)

Like everything, becoming someone who works with code means re-learning everything I’ve known to be true again, in a new pursuit. I realized and came to appreciate the need for exposure, for time with my saws and chisels and on the mats – and at the outset it seemed so different from writing code. Coding, for the beginner, many times does feel like there are short cuts, with Stack Exchange, with other folks’ code or libraries, etc.

It turns out that what all those folks on Stack Exchange have been saying all this time (but are mostly ignored) is true: copy-pasting a solution that works is different from understanding the problem, from getting a deep sense of the solution and how to pursue it. It’s like buying someone else’s chest of drawers rather than building it yourself. It’s different from having the answer in your bones.

The more I learn, the more I learn that everything is the same. For me, I’ve learned that remote work is an amazing way to work, and writing software and doing data work is special, and important, and so satisfying: but the brain and the body, or my brain and body at least, really need that opportunity to do work in the physical space, to hold something, to engage in craft that doesn’t happen on my laptop screen.

If you are a remote worker, and you don’t have a hobby or pursuit that takes you off of your computer and into the garage or the gym – you should give it a try!