Work styles: Disruptive, collaborative, or both?

Pick your poison.  But why not do both in harmony?

Our work styles can be seen as disruptive (creating major change without regard to the current situation), collaborative (partnering deeply with peers to get things done), or a mixture of both.

Disruptive.  The disruptive style is cool and exciting.  It's about innovation and major change.  When I was in 8th Grade, when asked what I wanted to do when I grew up, I told my teacher, Mrs. Moore, that I wanted to either be a heavy equipment operator or a brain surgeon.  She laughed and asked me if I realized as she did that those two fields were markedly different.  I did not and I responded, "I really want to change things dramatically."  I suppose both on macro (bulldozer) and micro (brain) scales.  This still holds true to me.

Collaborative.  The collaborative work style is a really critical, key and important one that I have had to learn over the years.  As an aggressive person who wants to change things drastically I've learned that I have to collaborate and partner with others to get things done.  Leading without followers is not possible.  Sometimes I have to take the back seat and let others drive.

Having both of these capabilities as a disruptive, innovative person and a collaborative person provides balance and synergy between two forces.  Both are good for change but together they provide a pace that is realistic,  sustainable, and powerful.

Front-office and back-office folks: and getting to trust

Creating the right perception is tricky and risky.
First you have to know and trust yourself.

Getting to trust with your customers and the public takes a long time and it might even be impossible at the aggregate.

Life and selling are processes; they're complicated.

In life we have to choose between those people we rely on and trust to deliver for us (the back-office people) and those people we choose to sell for us (our sales or front-office people).

I've stated in previous posts today that I need to grow my team of sales people and advocates.  I need personal advocates who can help me sell my value and what I offer.  I also need people to help me deliver what I can deliver, but I think I need fewer of these people.

In all, I need to trust myself before I need to trust others.  But if I can get to a place where I trust myself then I can surely get to a place where I can trust others and hopefully one where others will also trust and advocate me.

Everything is better on a team

We are not alone until we think of ourselves as such.

Selling as an individual sucks.  Marketing yourself sucks.  Being the main person who is delivering the thing sucks.  Teams are way better than individuals most times and this is true in almost all contexts.

When it comes to sales and selling the same holds true.  I like to sell by myself but I do not love it.  What I love is the idea that I can sell as part of a team and system, rather than as an individual. 

We need to find ways to take ourselves as individuals out of the picture and figure out how we can grow teams around ourselves who love and support us in our efforts and interests. 

We need to get excellent at having others help us.  The more we can define a process and system for growing, selling, and success, the better off we all will be.

Changing agendas

Sometimes our agenda and their agendas
are not aligned.  Make sure you detect
at the start of the meeting that this is the case
and redirect the meeting accordingly.

It's nice to have an agenda and bring it to a meeting but it's quite possible and sometimes likely that the meeting agenda and objective will change.  There's a good practice called 'resetting' when you state what you had planned for the meeting agenda and ask the attendees if anything has changed to make sure that everyone's still on the same page before starting.  If things have changed, then the facilitator can decide to focus on those new issues, cancel the meeting, postpone it or hold it as it was originally specified.

Main point here is that we have to be able to change when people have changed and adjust accordingly.  Although we may have agendas in or meetings and need and want to get things done, we still have to be very flexible and dynamic in dealing with people and their constantly-changing needs, moods, and desires.

Teams can grow without increasing in count

Grow, baby, grow.
(Just don't necessarily multiply, please.)

Growth is a funny thing.  It can happen in your mind or in the physical world.  Growth can be seen as in increase in a population: it can be seen as an increase or improvement in anything.

I made the point to a colleague yesterday that our team can grow even if we don't add people to it.  It sounded profound to me and he agreed.

What I meant by this was that the thing that matters more than anything that our team (regardless of its size or members) grows and learns and improves.  It would be nice if it grew in terms of count and influence but that is not my current need or expectation.  I am trying to do just the basic things and make sure we have a plan and are tracking.

Team-building is difficult but can be extremely fun and rewarding.  Growing in any way positive is a great goal but we have to remember that we have to control growth as well.

Control is a challenging part of growth.  You don't want to grow too fast because it is painful.  You don't want to grow uncontrollably because it is scary.  You want to grow 'just enough' so that you are meeting your objectives and doing the right things.  You want to fit and be the right size within your environment.  You don't want to get too big and consume too many resources: this is not sustainable.

So next time you consider growing a team, or anything for that matter, consider that you might already have enough and that it is internal reflection, collaboration, and communication between the existing organism that needs to grow.

Basic schema for tracking a project

I’m managing a project/program right now and am using the following basic structure for communications to the team:

• Deliverable Name.  What’s the body of work/thing.
• Sub-Team members.  Who all is working on it.  Be semi-descriptive, “Jim and Mary with Joe”
• Status color.  Red, yellow, green, N/A.
• Status notes.  Be clear about the current status of the thing.
• Active assignments.  The things that people need to do with respect to this item in the near-term.  This should include risk mitigations, escalations and everything.  Everything needs to be work / an action.

In the meeting, we review last week’s list, and update it for this week.  It’s a simple process that seems pretty effective.  As new Deliverables appear, I add them.

Using design-first to build the backlog

It is great (necessary is a better word) in application development projects--especially when the customer is concerned about the app looking good--to have a graphic artist / designer involved.

Right now, we're working on a project for state lotteries and we need a prototype. There's no customer but we want it to look good (have some sizzle) so it can sell.

To make it look good, we had a designer mock up some screens and UI/UX stuff for us. The mockups look great!!! ...BUT... (And I this is a very big BUT)...the designs have proven very hard to IMPLEMENT...so we've had to punt and backlog some...and I'm okay with this.

For me, in software, the goal is a functional prototype. An idealized prototype or mockups is not functional. Being too wrapped up in what the software should/could be is great but it's definitely not the goal for the project. For the project, what the product *can* be is the goal.

I think there's a balance between ideal and practical and here's my current thinking on it: if the customer is asking for a good-looking design, then get a designer to mock stuff up. Have a BA/PM-type-of-person parse out the observable behaviors in the screens and share those two things (mocks and use case descriptions) with the developer. Have the developer dive in. Most likely, there will be things that the developer thinks are too hard or are impossible to implement; the project manager will likely agree they are too hard. Proceed! Backlog the items that are hard/impossible and as fast as possible, get to the minimum thing that the developers can produce that most nearly complies with the screens and spirit of the designs and use cases / user needs. (imperfection is tolerated and encouraged...the speed to completion and "done" is the goal)

In my opinion software development is a process and can't all be done/solved in a single iteration. Get to "done" as fast as possible and let the developer decide what done is (he's the furthest down the chain and has the hardest/most stressful job in my opinion). Over time, as a team, the software can more closely comply with the ideals of the designers and users...over time...and it will never be done...never...