Policy statements for a lean startup

1. One fair and shared process.
 We have a process that we all share as a team and company and continuously discuss and improve.  
2. Metric- and performance-driven.  We define how we measure our business (KPIs and metrics)
3. Targets.  We set business goals
4. Contexts.  We know what our business drivers are in any given context or situation
5. Customers first.  We know the key dissatisfiers (and satisfiers) of our customers and make sure we act to remove those problems post haste
6. Clear, shared vision.  We set and manage to milestones so that we can share direction and vision with everyone
7. Detail-oriented.  We're clear on what we do and write things using SMART goals and language
8. Clear communications and commitments.  We do what we say and say what we do
9. Smart and thoughtful.  We are good at analysis and problem solving
10. Dynamic and creative.  We "strategically plan" (possibly digress) when necessary in search of shared consensus and vision but we do not get overly distracted
11. Analysis and direction-setting together.  We review and agree on the best course of action from a set of options for any given problem or opportunity we face
12. Document everything.  We document almost everything for the purposes of clarity, record-keeping, transparency, and collective knowledge
13. Delivery excellence.  We deliver what we promised on time and to quality standards or we tell the people to whom we're committed that we won't be able to make it and we set other expectations.
14. Work breakdown clarity.  We define very clear project milestones and deliverables, we break deliverables down into tasks and assign them to the right resources
15. Growing.  We go and get more resources if we need them
16. One team.  We recognize when we get distracted on hard projects that require new resources and come back together to get focused again
17. Total accountability and responsibility of all personnel.  We are a "test-driven" organization, meaning that we think in terms of "how we would know" that something were true or false.  We make no assumptions but if we do have to, we IMMEDIATELY test them. 

Toward good: internal control, innovation, automation

Let's do three things: seek to develop internal control over ourselves and our organizations (create quality systems), innovate (make new things that people love), and automate (make things easier for ourselves and our organizations).

Total and supplier-level stack-ranking

Doing product development is complicated because there are many places that you have to "stack rank" (build queues for feeding things into processes / systems).  When you're a product manager of a big product or initiative, you have to plan the product and features "all up" (know what you need in what order at the highest level), and also on a per-supplier basis.  This makes things really complicated and complex.

The anatomy of an information process

Event - A thing that happens at a point in time.
Role - A generic category for an actor.
Function - A thing that is engaged upon, done, executed.
Authority - A right had by an actor or role to perform an action.
Measure - A way of knowing how a function is operating.
Tool - A method to support, enable, and/or enhance a function.
Actor - A person.

Integrate and extend what's there: collaboration over competition

A lot of times,  the stuff that's already there in an organization (people, tools, processes, knowledge) is good enough to start.  I'd even go so far as to say it's always enough!!!  There's always a place to start...

As managers and leaders, we need to leverage and depend upon what *is* already there, and then be able to extend and support it through more stuff  (people, tools, processes, knowledge).  Let's stop competing and hating each other and start collaborating and appreciating each other.

Customer Experience: What happens before and after the User Experience (UX)

There's a problem right now in the way that we're thinking about the product and customer service in our organizations.  Many organizations are broken because they're not agile.  The graphic below provides a very simple way to understand what's going on here.

The problem
"Customer Experience" matters way more than User Experience.  We spend *a lot* of time trying to get the UX right; maybe so much time that we forget about the overall Customer Experience (CX).  Customers call and complain (or don't) and have a bad time using the product.

The Solution
Let's invent a new practice: Customer Experience Management, that incorporates the best from things we do before UX (sales and marketing), during UX, and after UX (marketing and feedback).  I believe that the Pre and Post UX functions are missing in our software development practices today!

UX
This is all about what the customer experiences WHILE they are using the product.  Everything they experience WHILE.

Pre-UX
This is everything that the user experiences before they use the product.  Online reviews, recommendations from friends, word of mouth, marketing materials, sales people, training materials, etc.

Post-UX
These are all of the options that the user has for engaging in SUPPORT of the product after they have used it.  Online materials, customer service agents, sales people, support staff, etc.

Call to Action
Let's start to manage by this model.

Hierarchy of a process

There's a lot of swirl and craziness in my current workgroup right now.  I just created the following graphic as a guide to my boss to help him create structure that is much needed.  We used this hiearchy (or a variant of it) at Siemens and it seemed to work.  Hopefully the current client can use this, too!!!

Top 7 lessons learned in my last Sr. Program Management role

Background:

I'm moving onto my next career adventure on an adjacent team to my current one.  We got re-orged and I had to bounce to the next opportunity.  I'm sad leaving but learned a lot here, made a lot of great new relationships, had fun, and delivered!  Overall, it was a really great experience.  Here's the main stuff I learned during this time.

The Lessons:

1. Have your project really well planned and make sure all of the resources are there to deliver it.  This was one of the major benefits of my main AutoRenewal project: that the team was there and ready to do the work.  We just had to get semi-organized and pretty good things happened overall.
2. Plan your business intelligence and measurement/control initiatives very well; realize that these are projects / programs unto themselves.  This was a miss on my project.  This was a workstream that was neither defined nor planned and wound up taking up a lot of time, energy, and resources to get it off the ground.  We had to define the product, then build the supply chain and resources to make it happen.
3. Get organized at the aggregate and with each supplier.  Being organized at the aggregate is hard, and being organized to give clear instructions to each supplier / engineering team is also hard.  Both functions are critical, though, and this creates the overall process and organizational challenge.
4. Supplier-level management is probably the key process that matters.  In the context of this group, since they have so many suppliers and dependencies, they have to get these people organized and rowing in the same direction.  It's hard work and each one requires a lot of care!!!
5. Integration management is super essential to making things happen.  Without an "all up" view of workflow and delivery, nothing good will happen.  It has to.
6. Process does not come from thin air; it takes intention, rigor and experience.  A lot of teams WANT process but don't know how to get it.  They're not organized, they're not focused enough, they're too busy.  Process management is a leadership exercise that really only comes from experience creating new teams and forming consensus and conformity around a goal and an operation.
7. Organize the scenarios at the policy/process level rather than at the implementation level; but you do have them go down to the channel level at some point.  There's a lot of data involved in making big things happen at scale.  Keep it simple by only managing and communicating the policy, rather than the implementation details.  KISS is so critical here, but it requires structure and rigor to do this.

The role of the non-technical software developer

I'll admit it.  I'm technical.  I am probably REALLY technical, but I am no longer a great software engineering.  I *know*--for a fact--that I alone do not have the talents and aptitudes required to make the software product myself: it's too complex!!  But...I *do*...on the other hand...have the talent, aptitude, and abilities--I think--to make and implement software through teams and people.  I know how to create a vision for the customer, for the software product, I know how to *sell* it, I know how to convince people that they need it and need to implement it.  I know how to hire the technical resources, etc.  But I do all of these things in a very non-technical and human-friendly way.  I guess I'm a manager now, officially.  Although my business is software, it is just that: a business.  Software is not a technical function necessarily but many parts of it ie the engineering and delivery are...

I am looking forward to my new role with Bridge Partners Consulting where I will hopefully have a chance to act on this vision of implementing software through processes and then selling software through solutions and engineering.  Go team!!!