scaffolding for a growing team - surge 2014
TRANSCRIPT
SCAFFOLDING!FOR A !
GROWING TEAM
How to Introduce Structure !Without Being Evil
Fran Fabrizio @franfabrizio
IT Director MN Population Center
University of Minnesota
MPC in 60 Seconds• Curate and distribute the world’s largest databases of
census and demographic data for > 50k researchers, policymakers, journalists and others globally.
• Our passion is to harmonize source data to make it comparable across place, time, dataset and data type and to provide tools for users to find, combine and transform the data of interest for their research.
• For example, combining census or survey data over time with political boundaries and satellite environmental data to study the effects of climate change
http://www.pop.umn.edu/
The Past 12 Months• Growth has happened, quite rapidly. Growth in staff,
in number of projects, in funding, in expectations.
• The organization has grown to nearly 200 individuals, the largest in our 25-year history.
• Within IT, we’ve increased our team size from 11 to 20.
• The MPC is no longer geographically co-located for the first time.
Inflection PointCrossing beyond a dozen team members, we observed:
• Miscommunications increase
• Our tasks started to need specialists, not generalists
• The inconsistency of work planning and tracking made it hard to get holistic understanding. Hard to answer “How are we doing?”
• Management stretched very thin.
• Silo’ing becoming ever more pronounced.
Today’s Talk• Today I’ll talk about the aspects of staff management and
work process we had to refactor, and describe some of the scaffolding we’ve created to respond to this change
• My Surge talk last year (“Rebooting the Team”) described a year spent at “micro” or individual scale, while this past year was macro/systemic focused - how do we position the whole system to scale?
• Walk away with mix of hard-earned wisdom and some tools, techniques and tips for shepherding your org through a growth phase
Scaffolding GoalsWe wanted:
• To spread the management load.
• Clearer views of work obligations and priorities.
• More consistent planning and tracking across teams and projects.
• Structure to ensure that team members are cared for and stay engaged.
Plan of Attack / Talk Outline
PART 1: POISED FOR GROWTH. Realign the staff into new teams and establish the IT leadership team. Refactor our HR practices for a larger team.
PART 2: UPGRADE YOUR RADAR. Institute standard approaches to work planning as well as work and effort tracking.
NB: Although presented sequentially here, these two aspects happened concurrently.
Core Values• There must be a balance between the individual
and the organization. We want to create a rewarding environment for each individual while preserving accountability to the organization.
• We must strive for data-driven decision making.
• Everyone has a right to know what we are doing and why we’re doing it. Overcommunicate!
• Process isn’t evil - bad process is.
Teams as Building Blocks• You’ll need to solidify your staff structure and define
your teams
• Large body of research on ideal team size: 3-5 individuals feels right for us
• Adhere to Conway’s Law and build your staff structure to reflect the systems you want
• Functional vs. Cross-Functional - an important choice. Should be informed by your goals.
Team of Teams• Recognize that your primary problem has gone
from “making the thing” to “organizing the people making the thing”.
• This requires much more management savvy than a smaller team
• Management as a skill set and priority has to become a first-class citizen!
Cultivate Management Capability
• Put talented “people people” in Lead roles. Probably not your best coders.
• Make management skill growth a priority
• Overall manager (director, etc…) now manages the other managers, allows for more strategic focus. Your second level managers have significant tactical autonomy.
New Governance ModelsTrue democracy doesn’t scale well. New forms of governance needed.
• IT Leads as representative democracy
• Standing or ad-hoc committees are a great way to keep individual contributors involved.
• Benevolent dictator - use sparingly, but needed. You pay for this with the “trust points” you earn the rest of the time.
Specialization• As the team scales, the complexity in each
problem domain tends to scale with it
• Generalists are no longer the best strategy. You need people who can deep dive and become domain experts in each corner of your operation.
• This can be a difficult transition for your devs, but remember - balance between individual and org. The org now needs specialists.
Cross-‐ Functional Project Teams
Director
IPUMS Team
Metadata Dev
Data Serv. Team
Web Designer
TerraPop Team
SysAdmin
NHGIS Team
Floating Specialists
Our Old Structure
Goal -‐ Product Vision
Metadata Store
Data Store
API Layer
NHGIS UI
IPUMS UI
and skins
Code Clients
TerraPop UI
Community UIs
Extract EngineTabulator
CONSOLIDATION OVER TIME
New Structure (circa late 2013)
Data/Metadata Group
Web Group
Project LeadsTerraPop NHGISIPUMS
Dev Dev
LeadLead Lead
WebDes
Lead Dev Dev Dev Dev
Operations Group
Ops Mgr SysAdmin
Director
Recruitment and Hiring
• One of the biggest surprises of growth has been how much time goes to hiring now - it’s constant
• Director overwhelmed. Needed a system to spread the load.
• The IT Leads defined how we wanted to run our searches in an “IT Search and Hiring Guide”
Recruitment and Hiring• We turned to individual contributors for help
running searches. They have capacity, their own hiring process is usually fresher in their mind, and it gives them a chance to make a key contribution.!
• Shrank size of hiring committee (greater trust, less direct participation), streamlined phone screen and code exercise grading for quicker decisions, separated input providers from decision makers.
Onboarding• Create a written “Firsts” Plan for each hire: First
Days, First Weeks, First Months, First Quarter/Year.
• Supervisor: Forces them to think about what they might otherwise take for granted
• New Hire: Can see a future for themselves, which has a powerful psychological effect
• It’s the journey, not the destination. We’ve -never- had an onboarding go remotely as planned.
Onboarding Tips• Design for a real contribution by the end of week
one. Doesn’t have to be huge… optimize a slow query, refactor some messy code, create a proof of concept with some new JavaScript library.
• Favor a bottom-up approach to bringing someone up to speed. Just do a lightweight, quick big picture orientation, and then bite into one small part. Gets them to “ownership” faster.
Performance Evals
• Historically: we did weekly or bi-weekly 1:1 meetings for informal check-ins, but just did the formal process of goal-setting and evaluation once per year.
• Doesn’t scale - was starting to kill the month of April
• Refactored into a quarterly check-in system
Performance Evals• May - We collaborate on goals for the year and the
manager clearly defines what success looks like for each goal. We also have more general job class responsibilities (e.g. a dev is expected to produce tests and documentation for their code) to shape expectations.
• End of Jul, Oct, Jan - We have quarterly check-ins. Write progress notes for each goal and responsibility, adjusting as needed.
• April - The review has mostly written itself. Just complete the last quarter, give a summary and score, and the cycle renews.
Meetings• Meetings are just like process: meetings aren’t evil; bad
meetings are.
• Meetings have a bad reputation, but if done correctly, they provide by far the most communication bandwidth
• Ask if the majority of the meeting is relevant to all attendees. If not, refactor. The “status meeting” is a prime abuser of this principle.
• 1:1s are not status meetings. If they are, refactor.
Meetings• Be judicious with all-staff meetings - they are
extremely costly!
• I’ve begun to advocate a “don’t accept a no-agenda meeting” policy
• Don’t forget to communicate meeting outcomes to people who are absent - be consistent with this
• Might want something like a no-meeting Focus Friday policy.
A Note on Communication• A universal workplace truth: communication is key
• Make sure everyone understands how information flows through the organization. Define these paths clearly.
• Be consistent! Everyone should be able to quickly explain “This is how we communicate meeting notes / work plans / policies and procedures / etc…”
• Tech tip: You should be leveraging an asynchronous, group-based chat tool, preferably with history (e.g. HipChat).
Staff Cohesion• Now that your teams are attacking work on multiple fronts, you
want to empower them to do what makes sense for their part of the world
• At the same time, you want the overall vision and values to be enforced across the teams
• In short, you need strategic cohesion but tactical independence. Communicate the strategy to your leads, and delegate the tactics to them. Trust!!
• Methods to enforce strategy cohesion: Defining core values. Standardizing processes. Cross-team committees. The group chat lobby.
PART 2: UPGRADE
YOUR RADAR
Getting better at knowing where you’ve been,
where you’re at, and where you’re going
Balance• More process is required to make sure that the
multiple efforts all stay on track
• But more process can lead to more rigidity unless you also allow for flexibility within the process
• Process is not mutually exclusive to being agile (or Agile). Some process needs to be more formal than others. Find transition points from formal to informal process.
Identify Planning CyclesPlanning!
Type Time Horizon Process Focus Tasks
Long-Range Years Formal Strategic Staffing BizDev
Medium-Range
Resource Allocation
Prioritization Dependencies
Short-Range Days Informal TacticalBug Triage
Change Mgmt “Trimming the
Sails”
MPC Planning Activities• Long-Term (Annual): Refresh Global Deliverables,
produce annual roadmap, refresh budgets, add in any new grants, executive strategy retreat.
• Medium-Term (Quarterly): Quarterly Planning process. Aligns development goals and priorities with available resources for quarter.
• Short-Term (Weekly): Team meetings and triage. Specific process highly team-dependent.
INFRASTRUCTURE+
PROCESS+
FEATURE+DEV+
Q1+ Q2+ Q3+ Q4+
2013+MPC+IT+MAJOR+PROJECT+ROADMAP+
NHGIS+
Rails+2+>>+3+Conversions+
Ruby+1.8+>>+1.9+
ATUS+>>+IPUMS+IntegraMon+
TerraPop+Prototype+
IPUMS+ TerraPop+ Miscellaneous+MulMple+Projects+
Minimal+AggregaMon+Nominal+IntegraMon+ InterpolaMon+
Solaris+>>+Linux+
Storage+Upgrade+
Bibliography+Rewrite+
Admin+Core+Database+
Archive+Upgrade+
Subversion+>>+Git+Conversions+
TeamCity+>>+Jenkins+Conversions+
Separate+Webapp+from+Extract+
IDHS+Metadata+Tools+
Time+Series+Support+
TerraPop+ProducMon+
IDHS+Webapp+Development+
User+AuthenMcaMon+&+AuthorizaMon+Service+
MDT+Metadata+Tool+Development+
General+IPUMS+Feature+Development+
StaMc+>>+Drupal+MigraMons+
Column>Store+Database+MigraMon+
SDA+Extensions+&+ModificaMons+
NHGIS+Data+Ingest+
v1.0+[2/19/2013]+
1960+
StaMc+Asset+Management+
Systems+Monitoring+and+ReporMng+
Hadoop+&+Big+Data+Technologies+R&D+
ESTIMATES
TASKS
RESE
ARCH
IT
WISHLISTISSUES
PLANNINGVERSION IN REDMINE
ROUND 1 MEETING
GATHER STAKEHOLDER
INPUT
ROUND 2 MEETING
QUARTERPLAN
MPC QUARTERLY PLANNING PROCESS
IT Lead
Developer
Research Manager
Researcher
1
2
3 7
WEEK 1 WEEK 2 WEEK 3
4
AVAILABILITY
5
OTHER PROJECTS’ REQUESTS
6
3 Round 1 meeting to communicate issue specifications, priorities, and deadlines.
1 Research team provides input on work tasks, priorities and deadlines to research manager.
2 Research manager enters issues into the Redmine planning version for next quarter.
4 Developers apply work estimates and task breakdowns to issues .
5 IT Lead calculates staff availability for next quarter.
6 IT Lead reviews inputs from other projects’ round 1 meetings.
7 Round 2 meeting to align wishlist to availability and estimates and produce Q plan.
!
Staying [A/a]gile• Teams have freedom to structure the intra-quarter
work as they see fit. Team-specific culture develops.
• We still wanted to welcome impromptu discussions with our customers without it derailing our plan
• Empowered our staff to engage with customers openly because they knew a process was in place and “had their back”
Tracking Work• You should already have an issue tracking system
of some sort. If not, get one (even if just a kanban).
• Goal is to make the this tool reflect and enhance the way you’re already working and collaborating in real life
• Make its usage as ubiquitous and consistent as possible across the organization
Redmine at MPC• System configured organically over time.
Permissions made no sense, issue attributes did not map to real-world truth
• People adding issues / change versions / change requirements in middle of cycle —> scope creep
• Every project had different conventions
• Researchers (customers) not often engaged with the tool
Work Tracking Goals• We wanted our tool to support our process, not dictate it.
• We wanted to separate the what (researcher responsibility) from the how (IT responsibility).
• We wanted to separate management tasks from individual contributor tasks.
• We wanted to discourage unilateral decisions where a conversation should take place.
• We wanted the tool to be an input into data-driven decision making.
The Process
• Established the “Redmine Committee”
• Catalogued the Redmine usage patterns and interviewed the stakeholders
• Developed exhaustive set of standards and recommendations (implemented August 2014)
Sampling of Outcomes• Distilled down to just four roles: Developer, IT Lead,
Researcher, Research Manager
• Features are the “what” issues, Tasks are the “how” issues. Achieves desired separation of concerns.
• Long- and Medium-Range planning tend to be done around Features. Short-Range cycles tend to center on Tasks and Bugs.
Sampling of Outcomes• Standard set of planning-support versions across
projects: Incoming, Investigating, On Deck, Dugout.
• Simplified and standardized the Priority field
• Permissions prevent abuse where critical, but mostly we rely upon social trust to do the right thing with the system - and we have not been let down.
Time Tracking• We did not do time tracking
prior to 2014.
• Once people were allocated to 2+ projects tracking became critical.
• I wanted more data on where effort was going, whether budgets were in line with demand, and whether estimates were accurate
We wanted to capture “I spent an hour on that bug, two hours peer coding with Joe on project X, a couple hours working on that new feature
for Project Y, and I had a 1:1 with my supervisor.”
!
We didn’t want “I spent 17 minutes doing email when I came in, and then 45 working on
foobar.c, and then Doug interrupted me for 6 minutes to talk about that one task, and then…”
TT Anti-Goals
• The data would not be used for performance evaluation (this will be evident in more fundamental ways if it’s a problem)
• We’re not trying to capture 100% of effort. Some effort is easier to capture than others, and good enough is good enough for our purposes.
Time Tracking Approach
• Tracked within Redmine’s Spent Time feature. Lightweight, no separate system needed.
• Administrative overhead is captured on simple ongoing generic tickets (e.g. admin meetings, search and hiring)
• Design goal is for time tracking to be a 5-minute daily activity
TT Standards
• Granularity: 30 minutes
• % Captured Hours: I felt that 75% would be great, but no specific goal - would let data dictate
• Log it daily. We analyzed time logging activity data that showed daily is most effective.
TT Tips• Expect resistance, you may need to explain
rationale many times and work hard for buy-in
• Many reminders needed to form habit
• Keep it “we” focused and avoid making winners and losers
• Share new insights derived from tracking data with the team - shows value of activity
TT Tips• Track vacation and sick time, otherwise numbers
become hard to compare.
• If it’s taking more than 5 minutes a day to record time - stop, you’re getting diminishing returns.
• Having an up-to-date calendar makes time tracking much easier at the end of the day - glance at calendar triggers memory of how time spent
Progress Report• Most important: We’re getting a lot of work done, and
it’s still a fun and rewarding place to spend our days!
• We have a better self-awareness of what we’re capable (and not capable) of doing and where we’re headed.
• We’ve developed a better partnership with our customers by living and talking through this every day.
• The IT org is stronger. Developing new leaders and providing opportunities for career growth. Trust and delegation are becoming ingrained values in the Core.
Next Year’s Talk? Hope so. We finally feel prepared to tackle them.
Tackling Your Grand Challenges: How to Stop Kicking the Can Down the Road
Questions?
THANK YOU!
Fran Fabrizio @franfabrizio
Coming soon, our IT blog: http://tech.popdata.org/