Upload
andreas-ehn
View
1.415
Download
1
Tags:
Embed Size (px)
DESCRIPTION
The original deck included a lot of builds, which made some of the reasoning clearer
Citation preview
The role of the manager in modern tech organizations
Stretch, Budapest, December 6, 2013 Andreas Ehn <[email protected]>
Claim promotions Get updatesDiscover & follow brandsGive free & paid gifts
TV Commercials In the 1950s, people read
radio ads aloud on television
Internet ads In the 1990s, people launched static newspaper ads online
Mobile banners Today, we put website
banners on mobile phones
2.32 million users 27 million vouchers!claimed/shared
2.34 million vouchers!used in stores
CEO CTO
Dev Dev Dev DesignerTeam lead
VP Eng
VP Prod
Chief architect
CTO!• An architect, a thinker, a researcher, a
tester and a tinkerer!• “Usually can’t manage their way out of
a paper bag, but have huge vision, the ability to pull an all-nighter and crank out a rough prototype, have the unique ability to translate complex/abstract thoughts into simple English for a non-technical end-user, and a willingness to get up in front of 1,000 people and talk about the latest greatest thing they are working on/thinking about”!
• Happy to work collaboratively with the VP Engineering while leaving the engineering team completely alone
VP Engineering!• Runs the engineering team on a day-
to-day basis!• Process/management gods (and
goddesses)!• Totally focused on building and
shipping products!• Should have an engineering
background, but isn’t necessarily the strongest tech person on the team
Fred Wilson: http://www.avc.com/a_vc/2011/10/vp-engineering-vs-cto.html!Brad Feld: http://www.feld.com/wp/archives/2007/10/cto-vs-vp-engineering.html
CEO CTO
Dev Dev Dev DesignerTeam lead
VP Eng
VP Prod
Chief architect
Communication
Prioritization
The traditional manager
• Makes most decisions by him-/herself
• Over-specifies
• Tells you what to do in detail
• Tells you when it should be done or, at best, requires you to say when it will be done
The problem
• Generalists without a lot of domain knowledge make most decisions
• Little room for experimentation
• No validation of different options against real data
• Communication is highly directed and often inefficiently routed
What to do instead?
• Decentralize • Enable and empower
Decentralize• Push decisions
“downwards” • Empower individuals
and small teams to make decisions and build end-to-end features
• At the most, decide on what, never how
Enable and empower
• Be a problem solver, remove blockers
• Channel communication with other parts of the organization
Problems (and solutions)• Expectations – very important to
manage expectations for the rest of the organization
• Consistency – have architect and UX roles that span across teams
• Focus – clearly define, explain and argue for the company vision; convince rather than force
• Stay the course on the vision, but experiment on the implementation
Minimum viable features• Experimentation is only
feasible if tested/validated against reality frequently
• Short iterations; well defined, testable goals
• Readjust course quickly • Easier to keep the rest
of the org up to speed
Avoiding getting stuck in a local maximum
• How do you avoid limiting yourself to a hill-climbing approach that risks getting stuck in a local maximum?
• Allow for a bit of craziness – injecting randomness into the system
Hacking
• Hack days, hack weeks, 20% time
• Maybe all the time should be for hacking?
Is anyone really doing this?
Haier without middle management
• Now Zhang Ruimin, who turned the company into its current success, has eliminated the firm’s entire middle management
• “In the past, employees waited to hear from the boss; now, they listen to the customer.”
• The firm’s 80,000 employees are now organized into 2,000 zi zhu jing ying ti (ZZJYTs): self-managed teams that perform many different roles. Each is responsible for profit and loss, and individuals are paid on performance
• “An unsteady and dynamic environment is the best way to keep everyone flexible.”
CERN• Goals are well defined (find the
Higgs boson), but not the way to get there; individual design decisions are put off for as long as possible, which lets the project “absorb uncertainty”
• Teams with rival proposals spar publicly, forcing all the boffins to articulate their assumptions, justify their choices and learn enough about their rivals’ ideas to criticize them at length
But…• Is it easier for companies
that have a perfect fit between what developers and customers want (GitHub, Valve) than for companies building for a different audience (Stardoll, Wrapp)?
• How to achieve product–market fit? VP Product as translator?