Skip to main content

Breaking Hierarchies, and the birth of a Network Organisation at a Pure Project Based Company

It is an exciting and tiring time at Actum.  We are growing and changing at rapid pace, such a growth brings on new challenges and experiences that none of us, including founders had before. Most of the experiences are new to us all. None of us experience 300% or more growth in couple of months, and this is what is happening to several teams and departments currently. Right people and right attitudes are key factors in our growth and success so far. 

In any traditional organisation, growth brings on new hierarchy - more Directors, Team Leads, VPs and etc. However, we decided to go the opposite and reduce hierarchies as we grow. One of the Founders is leading such change initiative. He is brave enough to experiment it and allows the rest of the organisation to shape the idea into a more practical one. 

Actum is a project based company, we develop software, consult on digital strategy and customer experience, and we also help clients with processes (Lean, Agile, Design Thinking, Kanban, …). The organisational change we are going through now was never done in a project based company, or at least we do not know about any other example, so please share with us if you know a pure project based company (Digital Agency or Software Company) doing what I am going to describe below. We love to learn from others successes and failures 😉

What started to happen and will continue:

- We will not build teams for projects any more, but we create cross functional (generalised specialist) teams that move from one project to another. This allows stability within teams. 

- So, we will not allocate resrouces to projects any more, but we will allocate projects to teams. And eventually (in the next steps of evolution) teams will pull new projects as they are available, instead of somebody assigning them a project. 

- Whoever wants to change the team, should agree with his current and target team members. 

- A pool of projects will allow us to manage portfolio of Clients and Projects based on capability and fitness criteria (KPIs) that have meaning to clients. 

- Supportive and Domain Expert teams will provide service to each project team just-in-time. 

- We will build Innovation Team, Software Archite Team and other supportive groups such as HR, IT and Finance. 

- A network of Kanban will allow different teams to provide services to each other, and continues improvement metrics and change management nature of kanban makes sure that we improve forever. 

- We allow crews to shape on demand to handle certain situations or a short term task that requires expertise from different groups and teams. 

The bottom line is that, we will have stable and autonomous teams working with other supportive teams and experts to deliver solutions and continuously improve the way they work within a network organisation. We expect each team to improve differently and only influence each other. 

There are a lot more details to this change, But that is enough writing for now ;)  We will see the manifestation of the above initiatives in the next months, and I will share them as they happen.


Post a Comment

Popular posts from this blog

Escalate, Escalate, Escalate!

What is escalation at organizations? Is it a way to solve problems? Is it a way to report things? Is it a way to put more pressure? Is it a CYA technique? What is it? How do you use it at your organization? How other colleagues of yours use escalation? Really, think about it and observe.

At IT service companies, leadership measures the performance of IT Help Desk by number of escalated work items over a period of time. The less escalation the better. The reasons are simple:

It is cheaper for companies if an IT Help Desk Specialist resolves an issue than an experienced technical specialist at one or two level higher. This is simple math, one gets $X and the other get $X*2And when client gets result fast, he/she will be happier. So, less escalation equals happier client in IT Services. Client raise an issue, IT Help Desk Specialist resolve it, BOOM, Next!

At organizations, It is amazing (sadly) to see how much lower level managers escalate problems, that they and their fellows can resol…

Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle

I was thinking what the title of this blog post could be, I had couple of options to select from and decided to use a title that uses Disciplined Agile (DA 2.0) Lifecycle. Other options for titles were: Moving From Scrum to KanbanFrom High Performing Scrum Teams to Hyper Performing Kanban  The bottom line is that at some point you may want to move away from Time boxes to a flow of work and service oriented teams and improve performance and throughput without massive and sudden organisational change.  As always, I only share my experience and this may not apply to all situations, context is important. 
Another reason that I selected “Moving from Basic DAD Scrum Based LifeCycle to Continues Delivery (Kanban Based) Lifecycle” as the title, was that for many it is a question mark how to navigate through DAD life cycles. and I think this blog post could be one of the ways to navigate. 
Context: A Delivery Team started with Type A Scrum with 2 weeks Sprints. After a while, they deploy their …

Collocation is not the silver bullet for success and agility

To collocate or not to collocate? Most companies that are new to agile have been "consulted" by a "Scrum" Agile Coach, who suggested that they must break their organisation and have cross-functional teams to sit together in one location. Is that the recipe for success?.. Is it really?

Even though collocation has its benefits, it is not the necessary condition for a successful delivery team. Collocation as a dogmatic view may hurt you more than you think, and will not necessarily help you to deliver more successful products.

I am neither for nor against collocation, but I have experienced and worked with both approaches. And each sometimes worked very well and sometimes failed. All the variations of teams geolocation (collocated, fully-dispersed, partially-dispersed, or distributed) can work. It all depends on how the collaboration model is setup, what is the context and conditions, and how much the team and organisation are aware of each other, and are aligned.

Ha…