recentpopularlog in

robertogreco : operations   4

The Myth of the Non-Technical Startup Employee, by Zoelle Egner | Model View Culture
"The indignities unwittingly foisted upon the early operations employee are many and varied."

As the first non-technical hire at a startup, you wear many hats.

You answer support tickets, write newsletters, even order lunch: whatever needs to get done. When you’re lucky - and I was - that means days spent untangling complex problems and creating processes to keep the chaos at bay.

Unfortunately, when it comes to the tech industry at large, it can also mean a constant battle to justify your intelligence, your value, and your very existence. It can mean struggling against gendered expectations about your work product and complete ignorance of what your role entails. Worse, as the defacto keeper of the sacred Company Culture™, you run the risk of enabling and reinforcing a system of amenities and perks which aren’t actually meant for you.

Though the indignities unwittingly foisted upon the early operations employee are many and varied, at their core, most can be traced back to three core misconceptions that pervade the industry at large.

1. You only take a job in business operations if you aren’t smart enough to be an engineer (or designer, or product manager, or…)



2. If your role isn’t technical, you don’t actually understand the product.



3. The ops person is here to be your mommy.



Operations is a necessary evil, and it doesn’t really matter

That means the people who do it don’t really matter, either.

Choosing to work at an early-stage startup can mean choosing to sacrifice a lot: weekends, the opportunity to see friends for weeks on end, even basic knowledge of what’s going on in the outside world. Obviously, it’s also rewarding enough that we continue to make those sacrifices time and time again. Yet the myths we hold so dear — the noble engineer, sleeping under his desk to get the product out on time; the company that cares for its employees’ every need — exclude and marginalize an entire class of people whose contributions to these startups make their success possible. Perhaps that just comes with the territory of working in an operational role, but it also sends a clear message: this industry is supposedly changing the world, but only the contributions of a select few are worthy of celebration. The rest, well — someone had to keep the snacks filled.

But of course it’s not that simple. If you don’t file your taxes or pay vendors on time or hire the right people at the right speed or handle any of the other, myriad issues that operations folks handle each day, it doesn’t matter how great your product is: you’re going to run into serious problems. Technical infrastructure isn’t the only part of a startup that needs to scale seamlessly. This, ultimately, is why these myths about business operations are so painful and damaging, both to the professionals who suffer from them and the businesses that perpetuate them. You can have a great product and still fail because your business was broken. But it shouldn’t happen that way, and it doesn’t have to.

Yes, it means taking the time as a founder to understand what operations means, and finding the right person to help make it happen, regardless of their gender. It means trusting that whomever you hire will be just as invested in the success of the company and just as valuable as people with more widely understood responsibilities. But the result is worth it. Particularly when it comes to early stage startups, a good operations person who is engaged as a true partner in building the business can lengthen your runway and give you the chance you need to be successful and sustainable. That’s a prospect worth fighting for."
zoelleegner  softskills  management  operations  startups  2014  gender  organizations  work  labor  culture  administration  technology  emotionallabor  shrequest1 
march 2014 by robertogreco
DrupalCon Portland 2013: DESIGN OPS: A UX WORKFLOW FOR 2013 - YouTube
"Hey, the dev team gets all these cool visual analytics, code metrics, version control, revision tagging, configuration management, continuous integration ... and the UX design team just passes around Photoshop files?

Taking clues from DevOps and Lean UX, "DesignOps" advocates more detailed and durable terminology about the cycle of user research, design and production. DesignOps seeks to first reduce the number of design artifacts, to eliminate the pain of prolonged design decisions. DesignOps assumes that the remaining design artifacts aren't actionable until they are reasonably archived and linked in a coherent way that serves the entire development team.

This talk will introduce the idea of DesignOps with the assumption that the audience has experience with a basic user research cycle — iterative development with any kind of user feedback.

DesignOps is a general approach, intended to help with a broad array of questions from usability testing issues, documentation archiving, production-time stress, and general confusion on your team:

What are the general strategies for managing the UX design process?
How do you incorporate feedback without huge cost?
What happened to that usability test result from last year?
How much space goes between form elements?
Why does the design cycle make me want to drink bleach?
WTF why does our website look like THIS?
* Features turnkey full-stack (Vagrant ) installation of ubuntu with drupal 7 install profile utilizing both php and ruby development tools, with all examples configured for live css compilation"
chrisblow  contradictions  just  simply  must  2013  drupal  drupalcon  designops  fear  ux  terminology  design  audience  experience  shame  usability  usabilitytesting  work  stress  archiving  confusion  relationships  cv  canon  collaboration  howwework  workflow  versioncontrol  versioning  failure  iteration  flickr  tracker  creativecommons  googledrive  tags  tagging  labels  labeling  navigation  urls  spreadsheets  links  permissions  googledocs  timelines  basecamp  cameras  sketching  universal  universality  teamwork  principles  bullshitdetection  users  clients  onlinetoolkit  offtheshelf  tools  readymadetools  readymade  crapdetection  maps  mapping  userexperience  research  designresearch  ethnography  meetup  consulting  consultants  templates  stencils  bootstrap  patterns  patternlibraries  buzzwords  css  sass  databases  compass  webdev  documentation  sharing  backups  maintenance  immediacy  process  decisionmaking  basics  words  filingsystems  systems  writing  facilitation  expression  operations  exoskeletons  clarification  creativity  bots  shellscripts  notes  notetaking  notebo 
may 2013 by robertogreco
Toolkit | YOUmedia
"Welcome to the YOUmedia Network Toolkit. Here you’ll find resources to help you plan, build, and sustain your digital learning lab. The Toolkit is organized in several key sections, which are displayed in the right-hand navigation. These sections are: Getting Started, Physical Space, Online Space, Programs, Staffing, Research, Operations, and Documentation and Evaluation.

In each section, you'll find a series of questions (and answers) to help you think through the process of launching a YOUmedia or Learning Lab.

Explore each section, and if you still have questions, don't hestitate to ask by using the comment tool at the bottom of the page."

[See also: http://youmedia.org/youmedia-network
and http://youmedia.org/toolkit/research ]
youmedia  howto  lcproject  openstudioproject  education  homago  staffing  programs  design  evaluation  research  operations  online  learninglab 
may 2013 by robertogreco
Velocity 2012: Richard Cook, "How Complex Systems Fail" - YouTube
[Apply this to the design of education systems (or any other type of system). Notice how the school reform movement can be described by 'design for reliability', not 'design for resilience'.]

[Notes here by Taryn:]

"@19:00 [eg:] shiftworkers as the sources of resilience in "as found" systems (monitoring, responding, adapting, learning)

@20:00 design for reliability (boundaries, redundancy, interference protection, assurance, accountability, hiding-of-details) whereas we want resilience (withstand transients, recover swiftly from failure, prioritize high goals, respond to abnormal situations, adapt)

@22:40 how to design for resilience: constant maintenance, transparency of operation, support mental simulations"
responsiveness  access  control  agency  education  schoolreform  monitoring  adaptablerules  adaptation  learning  via:taryn  2012  maintenance  transparency  operations  priorities  adaptability  reliability  accountability  redundancy  failure  complexity  resilience  organizations  systems  richardcook 
september 2012 by robertogreco

Copy this bookmark:





to read