Self-organised, self-managed and self-directed…do they mean the same thing or are they actually different concepts, where one might be more desirable over the other?

In the context of an “agile” team, people seemed to use these terms interchangeably. However, it’s important to note that there are subtle, yet worthwhile distinction between each.

Self-Managed Team

A group of people working together in their own ways, toward a common goal, which is defined outside the team.

For example – the CEO of a company decides to launch a new product to address the needs of a specific target market. An initial team is assembled with a budget and high-level timelines. This team decides how they wanted to operate within the given budget. Team will do their own work scheduling, training, rewards and recognition, etc. They typically do a 360 review and rated other team members for salary appraisal. Also the team manages itself and its stake holders. They collectively play the manger’s role.

Self-Directed Team

A group of people working together in their own ways, toward a common goal, which the team defines.

Usually, the team comes together for a common cause. In addition to the characteristics highlighted under the self-managed teams, a self-directed team also handles the actual compensation, discipline, and acts as a profit centre by defining its own future. In some sense, you can think of open-source projects resembling these characteristics. There is a big element of self-selection and built-in synergy.

Self-managed and self-directed have a noticeable differences in terms of autonomy and how they actually operate because of it. Listed below are attributes to consider when deciding how to structure your teams in your organisation:

Hopefully, this highlights the difference between self-managed and self-directed. What about self-organised?

First let’s understand what self-organisation, as a phenomenon means.

Self-Organisation

Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent. It is often triggered by random fluctuations that are amplified by positive/negative feedback. The resulting organisation is wholly decentralised or distributed over all the components of the system. As such it is typically very robust and able to survive and self-repair substantial damage or perturbations.

Self-organisation occurs in a variety of physical, chemical, biological, social and cognitive systems. Common examples are crystallisation, the emergence of convection patterns in a liquid heated from below, chemical oscillators, the invisible hand of the market, swarming in groups of animals, and the way neural networks learn to recognise complex patterns. Self-organisation is also relevant in chemistry, where it has often been taken as being synonymous with self-assembly.

Sometimes the notion of self-organisation is conflated with that of the related concept of emergence. Properly defined, however, there may be instances of self-organization without emergence and emergence without self-organization, and it is clear from the literature that the phenomena are not the same. The link between emergence and self-organisation remains an active research question.

Self-organisation usually relies on three basic ingredients:

1. Strong dynamical non-linearity, often though not necessarily involving positive and negative feedback
2. Balance of exploitation and exploration
3. Multiple interactions

Self-organisation in biology

Birds flocking, an example of self-organisation in biology. According to Scott Camazine – “In biological systems self-organisation is a process in which pattern at the global level of a system emerges solely from numerous interactions among the lower-level components of the system. Moreover, the rules specifying interactions among the system’s components are executed using only local information, without reference to the global pattern.”

Real Question

Now let’s look at what is a self-organised team? Actually, the real question to ask is, what aspects of the team do they self-organise?

IMHO both self-managed and self-directed teams use self-organisation to achieve their objectives. Self-managed teams mostly self-organises to achieve their tasks, while self-directed team also uses self-organisation to form the team itself. It almost feels like self-managed/self-directed is one dimension (abstraction), while self-organised is a slightly different dimension (implementation.) While it feels like you cannot be self-managed or self-directed without self-organisation, I’m not 100% sure.

Over the recent conferences, I’ve had several people ask me the follow:

I would like to better understand the expectations from the organising committee on the talk proposals. In particular, I would like your feedback on my talk submission so that I can work on improving the same.

I think, this is a very valid question:

What is the selection criteria for the talks?

I’ve been organising conferences for a decade now and following is my perspective:

In terms of the overarching themes or values, we look at the following during selection:

• Diversity  – As a conference, we want to be more inclusive (different approaches, different programming languages, gender, countries, back-ground etc.)
• Balance – We want to strike a good balance between different types of presentations (expert talks, experience reports, tutorials, workshops, etc.) and different types of experience the speakers bring to the conference.
• Equality – We encourage more students and women speakers. We won’t select a stupid proposal just because it came from a student or a female speaker. But given we have to pick 1 out of 2 equal proposal, we’ll pick the one, which was proposed by a student or a female speaker.
• Practicality – People come to a conference to learn, network, have an experience and leave motivated. Proposals which directly help this are always preferred. While a little bit of theory is good, but if the proposal lacks practical application, it does not really help the participants. Also people learn more by doing rather than listening. If proposals has an element of “learn by doing” it wins over other proposals. Take people on a learning journey.
• Opportunity – While we want to ensure the conference has at least 2/3 rock solid speakers, we also want to give an opportunity to new speakers, who have real potential
• Originality – Original ideas wins hands-on from copied one. People always prefer listing to an idea from its creator rather than second or third person. However, you might have taken an idea and tweaked it in your context. You would have gained an insight by doing so. And certainly all of us want to hear your first-hand experience, even though you were not the creator of the original idea. We are looking for Thought-Leadership.
• Radical Ideas – We really respect people, who want to push the boundaries and challenge the status quo. We have a soft-corner for unconventional ideas and will try our best to support them and bring awareness to their work.
• Demand – Votes on a proposal and buzz on social media gives us an idea of how many people are really interested in the topic. (We fully understand votes can be gamed, but we’ve a system that can eliminate some bogus votes and use different types of patterns to give us a decent sense of the real demand.)

Once the proposal fits into our value system, here are some basic/obvious stuff we expect when we look at the proposal in the submission system:

• Is the Title matching the Abstract?
• Under the Outline/Structure of the Session, will the time break-up for each sub-topic will do justice to the topic?
• Is there a logical sequencing/progression of the topics?
• Has the speaker selected the right session type and duration for the topic? For Ex: 60 mins talk might be very boring.
• Has the speaker selected the best matching Theme/Topic/Category for the proposal?
• Is the Target Audience specific and correct? Also does it match with the Session Level?
• Is the Learning Outcome clearly articulated? Ideally 3-5 points, one of each line.
• Based on the Outline/Structure, will the speaker be able to achieve the Learning Outcomes?
• Based on the presentation link, does the speaker have good quality content and good way to present it?
• Based on the video link, does the speaker have a good presentation (edutainment) skills? Will the speaker be able to hold the attention of a large audience?
• Based on the additional links, does the speaker have subject matter expertise and thought leadership on the proposed topic?
• Are the Labels/Tags meaningful?

Proposal stands the best chance to be selected, if it’s unique, fully flushed, ready-to-go. Speaker please ensure to provide links to your:

• previous conference or user group presentations
• open source project contributions
• slides & videos of (present/past) presentations (other conferences or local user group or in-office)
• blog posts or articles on this topic
• and so on…

When selecting a proposal, we pay attention not only to the quality of the proposal, but also quality of the speaker, .i.e. whether the speaker will be able to effectively present/share their knowledge with others. Hence past speaking experience (videos & slides) are extremely important. If you don’t have a video from past conference presentation, that’s fine. Try to setup google hangout in one of your upcoming local user group meeting or internal office meeting, where you are presenting and share that link. This will give the committee a feel for your presentation skills and subject matter expertise.

While this might look very demanding, it is extremely important to ensure we put together a program which is top-notch.

Many teams suffer daily due to slow CI builds. The teams certainly realise the pain, but don’t necessarily take any corrective action. The most common excuse is we don’t have time or we don’t think it can get better than this.

Following are some key principles, I’ve used when confronted with long running builds:

• Focus on the Bottlenecks – Profile your builds to find the real culprits. Fixing them will help the most. IMHE I’ve seen the 80-20 rule apply here. Fixing 20% of the bottlenecks will give you 80% gain in speed.
• Divide and Conquer – Turn large monolithic builds into smaller, more focused builds. This would typically lead to restructuring your project into smaller modules or projects, which is a good version control practice anyway. Also most CI servers support a build pipeline, which will help you hookup all these smaller builds together.
• Turn Sequential Tasks to Parallel Tasks – By breaking your builds into smaller builds, you can now run them in parallel. You can also distribute the tasks across multiple slave machines. Also consider running your tests in parallel. Many static analysis tools can run in parallel.
• Reuse – Don’t create/start from scratch if you can avoid it. For ex: have pre-compiled code (jars) for dependent code instead of building it every time, esp. if it rarely changes. Set up your target env as a VM and keep it ready. Use a database dump for your seed data, instead of building it from an empty DB every time. Many times we use incremental compile/build, instead of clean builds.
• Avoid/Minimise IO (Disk & Network) – IOs can be a huge bottleneck. Turn down logging when running your builds. Preference using an in-process & in-memory DB, consider tmpfs for in-memory file system.
• Fail Fast – We want our builds to give us fast feedback. Hence its very important to prioritise your build tasks based on what is most likely to fail first. In fact long back we had started a project called ProTest, which helps you prioritise your tests on which test is most likely to fail.
  • Push unnecessary stuff to a separate build – Things like JavaDocs can be done nightly
• Once and Only Once – avoid unnecessary duplication in steps. For ex: copying src files or jars to another location, creating a new Jenkins workspace every build, empty DB creation, etc.
• Reduce Noise – remove unnecessary data and file. Work on a minimal, yet apt set. Turn down logging levels.
• Time is Money -I guess I’m stating the obvious. But using newer, faster tools is actually cheaper. Moving from CVS/SVN to Git can speed up your build, newer testing frameworks are faster. Also Hardware is getting cheaper day by day, while developer’s cost is going up day by day. Invest in good hardware like SSD, Faster Multi-core CPUs, better RAM, etc. It would be way cheaper than your team waiting for the builds.
• Profile, Understand and Configure – Ignorance can be fatal. When it comes to build, you must profile your build to find the bottleneck. Go deeper to understand what is going on. And then based on data, configure your environment. For ex: setting the right OS parameters, set the right compiler flags can make a noticeable difference.
• Keep an Open Mind – Many times, you will find the real culprits might be some totally unrelated part of your environment. Many times we also find poorly written code which can slow things down. One needs to keep an open mind.

Are there any other principles you’ve used?

BTW Ashish and I plan to present this topic at the upcoming Agile Pune 2014 Conference. Would love to see you there.