My company, Grove Collaborative, is hiring full-stack
engineers. If you like what you read here, and want to work on
similar problems, email me ([email protected])
more & apply.
This is a post about change management at a start-up.
Kaggle, at just under 20 people, is an interesting size because we are
right on the cusp of being able to wing it in terms of process and
communication, and needing more formal processes to make sure changes
and plans are communicated to everyone who needs to know.
For a while our engineering team was just winging it - we used Asana (a
sophisticated to-do list application) to assign and track tasks, but
didn't have much estimation rigor, work would get scheduled "just in
time", and priorities were constantly changing. While this roughly
worked, and product was going out the door, we could have been doing
better on a few fronts:
- Productivity. With better prioritization and specification,
task-switching time drops, and there are fewer questions to answer
while an item is in flight.
- Morale. With an ad-hoc process it's very easy to agree to deliver a
new feature without a clear understanding of what's getting
traded off. This leads to misset expectations, or poorly
communicated changes and stresses everyone out.
- Predictability. People are crummy at estimating how long complex
tasks will take. So it's no surprise that, lacking good estimation
techniques, we were consistently inaccurate estimating delivery
dates for features.
- Transparency. Asana is great for many things, but it was ultimately
too flexible and inconsistent for anyone to look to it as a single
source of truth for all development activities. So instead, they
would ask me or individual engineers when something is going
We wanted a process that addressed these issues, without creating a
bunch of bureaucracy that is anathema to start-ups (or, as one of our
engineers put it, "better to manage, but worse"). I'll detail the
process itself in a future post, but wanted to discuss here how we
managed the change.
There were two basic approaches we could take:
- Make incremental changes, learning along the way, and evolve a
process the whole team was happy with. We could research and try a
few different tools, experiment with stand-ups, and ultimately
figure out what makes the most sense for our team
- Make a sudden, larger, opinionated change and tweak from there. Do a
big-bang roll-out of an agile development process and incorporate
the agile tools I've come to really like over the years.
I went for option 2. Management strong-arming is not likely to go over
well with any engineering team, but I thought it actually made sense in
this case for a few reasons:
- The developers on the team had either good experiences with agile,
or no experience with agile; there was no scar tissue.
- While our company culture is contemplative, flat, and autonomous, we
also place a lot of value on just trying stuff quickly.
- I had earned enough political capital as an engineering manager that
I the team would give it a fair shake even if I was being a
dictatorial jerk. In fact, I had tried to do something like this
much earlier in my tenure at Kaggle and the team pushed back because
I hadn't earned credibility yet.
And crucially, during the roll-out meeting, I explained that yes, I am
being unilateral here, but here's why I think it makes sense anyway, and
here is the meeting we are having in 3 weeks to evaluate how you like
it, and at that same meeting you can decide to blow it all up if you
The final piece of the puzzle was to make it *feel* like a real change.
When changing largely invisible things like process there's the risk
that, in spite of the change, people roughly go back to doing roughly
what they were doing before, just with different window dressing. To
make it feel tangible and different, we mounted a big TV on the wall
that displayed our current sprint, rearranged the floor plan to give a
clear sense of space to the team, and made sure out our tracking tool
(Pivotal) was integrated with our company chat room on day one so
everyone would seem the stream of activity generated by the new process.
And bang! On Friday we were in ad-hoc winging-it land, and on Monday we
were starting our first sprint, sitting in our first sizing meeting,
with Fibonacci planning poker cards in front of us.
Like what you read? Join the newsletter and get updated when there's something new.