When your team scales beyond the point where information flow happens organically (~8 members), you’ll be confronted with some seriously uncool topics, like time tracking, work estimation, meetings with actual agendas, long-range planning and formalizing your HR processes. In this talk I discuss how our team is tackling these challenges in an engineer-friendly way and get the input we need for data-driven decision making while keeping the dev team happy.

1. 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

2. 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/

3. 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.

5. Unclear Priorities! Unclear Direction!

6. Inflection Point
Crossing 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.

7. 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

8. Scaffolding Goals
We 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.

9. 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.

10. 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.

11. PART 1:
POISED FOR
GROWTH
Laying the foundations
of a scalable organization

12. 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.

13. 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!

14. 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.

15. New Governance Models
True 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.

16. 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.

17. Cross-­‐
Functional
Project
Teams
Director
IPUMS
Team
Metadata
Dev
Data
Serv.
Team
Web
Designer
TerraPop
Team
SysAdmin
NHGIS
Team
Floating
Specialists
Our
Old
Structure

18. 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

19. New
Structure
(circa
late
2013)
Data/Metadata
Group
Web
Group
Project
Leads
TerraPop NHGISIPUMS
Dev Dev
LeadLead Lead
WebDes
Lead Dev Dev Dev Dev
Operations
Group
Ops
Mgr SysAdmin
Director

20. 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”

21. 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.

22. 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.

23. 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.

24. 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

25. 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.

26. 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.

27. 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.

28. 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).

29. 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.

30. PART 2:
UPGRADE
YOUR RADAR
Getting better at knowing
where you’ve been,
where you’re at,
and where you’re going

31. 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.

32. Identify Planning Cycles
Planning!
Type
Time Horizon Process Focus Tasks
Long-Range Years Formal Strategic
Staffing
BizDev
Medium-
Range
Resource
Allocation
Prioritization
Dependencies
Short-Range Days Informal Tactical
Bug Triage
Change Mgmt
“Trimming the
Sails”

33. Sampling of
Planning Activities
and Artifacts

34. 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.

35. Planning Artifacts - Global Deliverables

36. 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+

37. Planning Artifacts - Project Cheat Sheet
Applicable: Medium Range

38. Planning Artifacts - Q Planning Inputs

39. ESTIMATES
TASKS
RESEARCHIT
WISHLIST
ISSUES
PLANNING
VERSION IN
REDMINE
ROUND 1 MEETING
GATHER
STAKEHOLDER
INPUT
ROUND 2 MEETING
QUARTER
PLAN
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.

41. !
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”

43. 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

44. 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

45. 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.

46. Work Tracking Goals
“Make things as simple as
possible, but not simpler.”

47. 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)

48. 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.

49. 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.

50. 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

51. 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…”

52. 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.

53. 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

54. 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.

55. 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

56. 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

59. WRAP-UP
Progress and Next Steps

60. 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.

61. 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

62. Questions?
THANK YOU!
Fran Fabrizio
@franfabrizio
fran@umn.edu
!
Coming soon, our IT blog: http://tech.popdata.org/