SCAFFOLDING!FOR A !

GROWING TEAM

How to Introduce Structure !Without Being Evil

Fran Fabrizio @franfabrizio

fran@umn.edu

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.

Unclear Priorities! Unclear Direction!

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.

PART 1: POISED FOR

GROWTHLaying the foundations

of a scalable organization

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”

Sampling of Planning Activities

and Artifacts

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.

Planning Artifacts - Global Deliverables

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+

Planning Artifacts - Project Cheat Sheet

Applicable: Medium Range

Planning Artifacts - Q Planning Inputs

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.

Work Tracking Goals

“Make things as simple as possible, but not simpler.”

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

WRAP-UPProgress and Next Steps

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

fran@umn.edu !

Coming soon, our IT blog: http://tech.popdata.org/