Guilds and Community inside a company. Can it work?

Posted on Leave a commentPosted in management

How Guild works:

1. Conduct Guild days on a weekly basis across whole product development organisation. Agenda and format is random and should be always adapted to the context: conferences, trainings, watching conference, workshops, contribution into shared services… Guild leader is completely responsible for running it.

2. Guild leader is fully dedicated for that job and he is an expert in the field

3. Guild core members naturally migrate from existing teams or hired externally. Core team members are working full-time on horizontal activities and shared services. Rest of community participate part-time or during guild days and are part of the feedback loop

4. Guild leader has all financial and organizational tools to achieve required engagement in activities of the community: prizes, bounty program, direct contact with business and technical leaders and more

5. Guild leader and core team actively involve others into guild work and tasks through constantly sharing information with community, solving problems, being transparent

6. Teams are guaranteed to get support from Guild if they use services and output of the community, but if quality of services is low teams are not obliged to use crap they can always take the risk and responsibility to do things on their own

Challenges of horizontal community:

  • Strong guild leader with enough practical knowledge and experience
  • Build motivated core team who has the same passion for the topic
  • Defined end state and path of achievable mid-targets (desire to skip some steps in evolution might lead to some losses in long-term)
  • Dedicated days for all development to participate in guild days
  • Setup out of the box services and tools that can be used by the teams

Main Principles of Work

  • Sell, not control
  • Pull, not push
  • Be valuable
  • Be transparent

Network Structure: Use verbs to describe your service

Posted on Leave a commentPosted in management

we often focus on results and this drives our behaviour - setting targets and metrics, evaluating performance and etc. But is it always right thing to do? Isn’t action is the thing that describes you service much better?

Couple examples from the top of my head:

  • Zero bugs vs Keep customers happy
    • it’s not only zero bugs that will keep you happy
  • Simple ui workflow vs Help user to do the job faster
    • why to keep it simple?
  • High velocity vs Deliver right things on time
    • working fast and delivering random stuff is not needed
  • Files Storage API vs Will keep your files safe, synced, and easy to share
    • which one would you approach first?
  • Taxi Service vs You’ll get a driver in less than 5 minutes
    • there are lots of taxis now
  • SettingHadoop cluster vs Store and retrieve any data you want
    • the second one just explains it better

Why it’s better and more fun? Because verbs:

  • help you better define what problem you are actually solving. early defined deliverables (names of the service) are not necessarily the right ones and you will have to iterate through couple of versions
  • force you to think how actually you are going to solve the problem
  • describe service better as reflect “why” part
  • help you to differentiate yourself
  • help you to start a conversation with your “client”

And all these are very important for network structure as you need to understand easily who can provide what services to you (including yourself)

Network structure - choose the one you like

Posted on 1 CommentPosted in management

Looking for a way how to organise work in your company? Than i would suggest getting yourself familiar with these works:

  • Organize for Complexity by Niels Pflaeging. 
    • Niels has managed to distill the essential components of organizational development, leadership, and management into a single, short, clear volume that is easy to read and understand
  • Wirearchy by Jon Husband.
    • Organizing principle for interconnected participative era. Implications for biz models, org structures, leadership & mgt. development
  • LiquidO by CocoonProjects.
    • The original “liquid organisation” model for governance, born from direct experience within Cocoon Projects and in use in a growing number of for profit and not-forprofit organisations willing to get liquid.

Inspired by these people i with my team came up with practical implementation of some ideas that we believe will help us to:

  1. Focus on value
  2. Adapt to fast growth
  3. Keep everybody engaged and collaborative
  4. Remain fast and handle bottlenecks

Network organization - roles evolution

Posted on Leave a commentPosted in management

Main difference between standard company structure and network structure (more information about that topic can be found here) is dynamics:

  • company structure fits business model
  • structure changes together with business
  • cells have autonomy to make decisions

And it means that role description must also be dynamic and change together with POD’s evolution. Here is possible evolution of POD keeper role.

POD stagePOD Keeper focusRole & Responsibilities
Idea, early stageProgramming
POC creation
Explore technology
Tech Lead
2-3 people
Determine needed resources
Lightweight delivery process
Experimenting technology
Scrum Master
5-12 people
StabilizationProduct development process
Quality assurance
Ensuring capacity
Managing technology
Development manager
15-40 people
ExpansionDefining product lines
New technologies
Managing product portfolio
Planning new offerings
Development manager
40+ people
MatureOptimize whole value delivery
Avoid centralization
Identify new value chains
Set up new PODs
Change agent
100+ people

Principle is simple as POD grows POD Lead and Keeper responsibilities are changing accordingly to meet business goals and needs.

Good luck