Category Archives: Innovation
So I’ve been working in New York Silicon Alley Startup Culture (initial caps intended) since April.
I may have mentioned somewhere in this blog that on some days it’s like being on swift, sleek, schooner – wind swept sunny goodness, white cotton shirt flapping in the breeze.
And on other days…it’s Deadliest Catch choppy, fending through 10 foot high cold icy waves of rapidly approaching deadlines.
Or – somewheres in between. And mostly, a lot of fun.
I’ve had a few good a-ha moments I wanted to share with you.
First A-ha: A PMP’s value-add is in Implementation
There’s one very important thing I’m learning about startups and it makes me think about thetalk I went to with Eric Reis where he noted that the hardest part about growing any company is the boring second act, where company growth means dealing with the tedious, non-sexy stuff. Stuff like documenting repeatable processes, taking down meeting notes, deciding on follow through – all things very brilliant entrepreneurs don’t really want to deal with.
So I have to give credit to my company, Crowd Fusion, for having the foresight to hire someone like me – an extremely process orientated ‘Now Wait A Minute That’s Not What We Decided Yesterday’ type of girl.
Seriously, I think that every growing startup needs someone to implement decisions. Implementation (aka execution) is having a plan for making brilliant ideas come to life. I’ve found that includes:
- Recapping decisions at the end of meetings
- Figuring out what next steps are
- Not letting people leave important decisions without figuring out who is responsible for what (action items)
- Simply reminding people of action items and gently prodding until they get done
This seems like normal PM stuff – but really, I’ve heard form my co-workers that other startups they’ve worked for are lacking this skill set. And then those companies hit walls as they grow.
As a PMP, I’m starting to see that my value-add in a startup is not in the Initiation and Planning part of IPECC, because startups are havens of good ideas, and brilliant minds who know how to…well.. “startup” stuff.
My value-add is clearly in pure decision Execution. If you are thinking of joining a startup and you’ve worked in big corporate firms, you can provide tremendous value just by knowing how to get and keep the trains running.
Second A-Ha: Don’t Control the Process, Control how the Process is Built
One of the most key Agile and Kanban principles is that teams of people are the best originators of processes, not corporate policy offices, or centralized PMOs. Process has to come from the team who is going to follow the process.
So how do you do that? You do that by setting up a process for process change that incorporates the following:
- Spontaneous Creation of Process Anyone at anytime can create/modify a process
- Easy Documentation The process must be documented following an easy to use template that specifies actors, inputs/outputs and step by step details
- Peer review and approval New/updated processes must go through peer review. This ensures the all important buy-in factor
- Process Management Review and Approval New/updated process must go through process management review. This ensures that integration points will be addressed, especially if the new process impacts other existing processes.
So by providing the mechanism for process change, rather than detailed control of the content, we can still allow teams to innovate and grow with what works for them, but get good, ratified, documented process as well. It’s the best of both worlds.
I’m inspried by my co-worker Kevin Irlen who forwarded me the Dev Fort idea, which is to sequester teams who need to get something done, away from all distractions. The dev fort group does this by literally moving people to Fort Clonque for a few days,where there is no IM, and no internet, no phone.
Sequester - Isolate or hide away (someone or something)
In this environment, teams have to solve a problem, or come up with an innovative idea, within a short period of time, usually a few days.
And its proving to be extremely effective.
This site www.Spacelog.org actually makes Apollo launch transcripts visual and interesting. It was built in a week at Dev Fort.
And if you go grocery shopping, have noticed those new order-from-your-cart handhelds? The IDEO group (see video below) came up with that in 3 days.
Dev Fort team builds SpaceLog in less than a week
Designer Hannah Donovan was a participant in a recent Dev Fort and has a great blog post about her experience. I encourage you to read it.
My takeaway from her Extreme Design Blog Post:
- Pair skill sets that wouldn’t normally work together to solve a problem together
- Job titles and experience get left behind
- Even without titles, you still need clear role definition
- Paste up your ideas for all to see
- Social design By paring designers with developers, wireframing and use case verification happen at the same time
Her key point:
“Tackle the forest collectively and the trees individually – it will make your framework more robust and your details more polished. Win/win.” Hannah Donovan
Your cool new shopping cart in 3 days
Another great example of how sequestering can work. The team at IDEO allowed themselves 3 days to redesign a shopping cart. Watch the story here.
- As with Fort Dev, there are no titles in the room
- Team members had multiple, wide ranging skillsets
- A group leader was appointed not because of experience but just because he’s good at leading groups
- User focus – the team focused on finding the user experts
- There was one team room - with lots of shared boards
- Small teams had breakouts to solve bits of the puzzle
- Ideas SHOULD clash with the boss’s ideas
- It’s a known messy process, so the time constraint is needed
- One conversation at at time
- Defer Judgement
- Build on the ideas of other
Some great quotes from the Video
- “Enlightened trial and error succeeds over the planning of the lone genius”
- “Fail often in order to succeed sooner”
Sequestering is another great tool for solving a known problem.
Sequestering Guidelines to follow with teams
- Leave titles at the door
- Be clear about roles
- Remove all distractions
- Make sure the team skill set is diverse
- Use small team breakouts to solve pieces of the puzzle
- Don’t shoot down ideas – an Open Mind is necessary
- All ideas should be visible and transparent – on boards preferably
Here’s an excerpt from my Ah-Ha moment in Project Management.
“..the client’s deadlines were fast approaching, the quality of our work was ok, not great. And after about a month, I started to become the momma on the team, not in a good way, but in a “I’m going to tell on you to momma” kind of way. It was nuts. Some people quit.
Around that time I was reading a blog about Google, and how Google allows their folks to have one day a week to work on an independent project and I thought… A-HA… That’s it. At Google, employees are trusted to do great work and to manage their time. The company realizes that smart people do better when they can be the masters of their own destinies and therefore builds in the time for that during the week.
Instead of a full day, I set up working groups that would meet for one hour. The groups were built around software disciplines; systems engineering, business architecture, testing, training, and QA and change management. When I introduced the groups, I emphasized freedom. They were free to attend or not attend. They were free to go to any group meeting. They were free to discuss what they wanted to as long as it pertained to the discipline, even if that meant they weren’t necessarily discussing client deliverables. They were free to ask me not to attend, if they didn’t want the “boss lady” there.
And our productivity….toook offf!!! “