Fridays are for working ON the business

Posted on December 5th, 2009 by Paul McArdle1 Comment

.

I posted recently about how I have fallen down, sometimes, in the establishing a shared understanding about the ways in which our business needs to operate.

See aside below**

Recently I ran into another of these internal points of confusion …

What should I be working on?

This is a key question I have been asked numerous times in the past 10 years.

As a result of the restructure we put in place with Autopsy 1, we have had some Product Managers accept responsibility for the scheduling of development work each week – and increasingly in the sprints we are developing as a result of the initial moves we have made to adopting Agile.

This has reduced the amount of time I have been asked this question on a day-to-day basis.

However the details of the technical work that the team does in coding software solutions is only part of everyone’s job (it’s akin to the “working IN the business” metaphor in the E-Myth)

Being a small company, it is essential that everyone is involved (to varying degrees, and in different ways) in also “working ON the business”.

This is especially important, given that each person has accepted responsibility for some aspects of business improvement, at least at a tactical level, as a result of one of the planning sessions conducted as part of Autopsy 2.

However, to date people have struggled with the self-management of this dual focus (another paradox), which has meant that some questions have been ongoing:

e.g. when am I supposed to do this other work?

e.g. Is Beer O’clock a waste of time?

.

Our version of 20% time

Hence, starting the week just passed, we have formalised a working weekday structure that will make it easier for everyone to understand both:
1)  That they need to be focused on two aspects of work each week; and
2)  How they are to set aside time, every week, for both types of focus.

Note that it has been suggested by some previously that the type of “Working ON the business” type work could be scheduled in batches (say one month in every four) and dealt with in that type of approach.

Especially given the level of experience we have in our current team, such an approach would not work – hence we have (at least for the foreseeable future) adopted this more rigid approach to coordination.

Our approach is simply that, on Monday-Thursday each week, the Software Development team is to focus on deliver whatever aspect of the sprint that they are currently working on.

COB Thursday then forms the basis for when deliverable code is due each week.

Come Friday, it is now understood that everyone is to shift their focus to some aspect of working ON the business.

.

How did this Communication Shortcircuit arise?

As an aside, I am finding that more of my communication shortcomings have occurred internally (with employees and investors) than externally (with customers).

When I think about the way in which our business has developed, I can understand how this has happened – being the sole marketer in the company (to date) I have been primarily focused on growing our client base to the stage where we now have a sustainable business.  To do so, I have been focused on communicating a clear message externally.

Unfortunately, in parallel with this, I have neglected to focus as much attention on communicating clearly internally.  This has been compounded by the fact that:

1)  We’ve had a few key people leave over the years, reducing the amount of institutional memory available to those who have remained; and

2)  The team that has evolved is one that could be categorised as “warm” in “ The Myth of Nine-to-Five” – hence open to dealing with uncertainties.

This blog (which has been up since about May) has been developed for a number of purposes – one of those being to provide a record of these types of understandings.

The personal coaching I am receiving as a part of Autopsy 2 is also helping me to understand the specifics of how I need to improve communications internally.

Leave a Reply