Why the struggle with functional programming?

Slow FP adoption...

Why no widespread adoption even though functional programming exists already now for over sixty years?

Not so long ago I explained this as:

The reason is actually pretty complicated: The strength of FP is much due to its ability to be very strong. This strength in the code weakens the ability of developers to make local changes. Initially, this sounds like something good, yet it creates a new challenge: developers are bound to the constraints of code written by others, and they are not only not happy, they are less productive! You can solve this by bringing your FP to the next level: math. A few companies do this, now a developer is not subject to constraints but to mathematics. If the developer understands the math she/he finds this acceptable.
I am simplifying things a bit here, yet FP, or any language that is strong enough, brings in a whole complexity of technical ownership and people dynamics that does not need to be dealt with with OO. The reality is that FP allows more scaling, but maintaining the stability of people within that scaling is a major challenge.

I want to present this a bit differently here, because the above put too much blame on people. Yes, FP is tricky for teams, yet the root cause is not the teams, the teams just highlight the root cause!

The Design - Features - Tasks trilemma

Let's start with the following trilemma: 

Design - Features - Tasks

And by trilemma, I mean that you cannot simultaneous set goals to progress all three. (And by task, I mean "effective coding work"). You must specify two of these, and let the third one be determined by the outcome of your work. You can specify design and features, you can specific design and tasks, you can specify features and tasks... but you cannot specify design, features, and tasks before you start working.  To be more concrete: when you focus on architecture before coding, and come up with a design, you are in fact constraining the features that will be implementable with tasks that follow that design. If now you specify additional features, before you start your tasks using the given design, you will likely fail.

Functional programming done seriously "ties" design and tasks together. By which I mean that FP that pushes its higher order design model highly constrains the design. The result is that by construction, a team that pushes its FP design culture, is also a team that is "squeezing themselves" into an over constrained design-features-tasks trilemma. To be specific, an FP team may be imposing design, features and tasks all at the same time, and not understand that this is an over-constrained setup that will most often fail.

There is a solution: Just like I mentioned in that earlier post, you get a around trilemma by splitting one of its terms. Here we split tasks into design tasks and non-design tasks. The approach is then the following:

1. Given some desired features
2. Work on design-tasks so that the design can implement the features
3. Then work on non-design-tasks, that implement the features with the developed design.

From a work triplet perspective, we have:

1. features & design-tasks -> new-design
2. features, non-design-tasks -> implemented features

Here, the new-design produced by 1, are used in 2.

However, the challenge is that now we have a two phase work process, and by default teams, especially agile teams, are single phase process. Agile typically asks teams to focus on tasks that deliver MVP features, and therefore agile typically sets people up to fail, as there is no new feature in good FP without new design, and... and teams often struggles to juggle the three needs to progress design, features and tasks within a same agile effort.

TDD helps

Test driven development (TDD) is one way to escape the limits of a one phase agile process. The idea is the following: 

1. Given some design features
2. Develop tests for these features, AND extend the design to cover the features.
3. Then work on non-design-tasks, that implement the tasks, and pass the tests.

However...

Yet there is still a challenge: design changes most often depend on strong opinions. FP depends on design changes. FP depends on strong opinions. Getting teams to gel around strong opinions is often not trivial. And that why I wrote the statement shared above.

All original content copyright James Litsios, 2024.

Thinking about skills in people and in software

Here is a handy way categorize levels of software sophistication:

1. Software implements features
2. Software  supports software that implements features
3. Software supports software to support software that implements features

Here is handy way to categorize levels of people skills:

1. Person implements features
2. Person supports people that implement features
3. Person support people that support people that implement features

Let us combine some of these people skills and levels of software sophistication:

1. Person implements software that implements features
2. Person implements software that supports software that implements features
3. Person supports people that implement software that implement features
4. Person implements software that support people that implement software that implement features
5. Person support people that support people that implement software that implement features
6. ...

Note how entry 4 is a hybrid of people skills and software expertise!

The above lists actually makes sense, yet they are too simple. We can do better!

We can distinguish between support as:

• Direct support
• Proactive support

For example:

• A unit test is software that directly supports software.
• A library or a framework is software that proactively supports software.

More examples:

• A project manager directly support members of a project with a plan.
• A servant leader proactively support his or her team members.

We can bring this together as:

1. Person implements software that implements features
2. Person implements software that directly supports software that implements features
3. Person implements software that proactively supports software that implements features
4. Person directly supports people that implement software that implement features
5. Person proactively supports people that implement software that implement features
6. Person implements software that directly support people that implement software that implement features
7. Person implements software that proactively support people that implement software that implement features
8. Person directly supports people that directly supports people that implement software that implement features
9. Person directly supports people that proactively supports people that implement software that implement features
10. Person proactively support people that directly supports people that implement software that implement features
11. Person proactively supports people that proactively supports people that implement software that implement features
12. ...

You might be thinking: this stops making sense!

Not so! Each of these categories are different, and imply different levels of skills and experience. Some need more people skills, while some need more software skills. 

Wrapping this up: Yes, it makes little sense to enumerate these categories. However, it makes total sense to understand them, and understand how the micro-structures of software and teamwork combine in different ways and demand different levels of experience and skills. 

Wishing you continued success with your project!

 All original content copyright James Litsios, 2023.

Managing agile from technology to business

 This how I tend to look at management ownership in agile development (see previous blog entry for more on the alternate views of agile):

Where:

• The CTO owns technology and most often engineering teams.
• The Engineering Manager may be an inwards looking CTO and also own technology and engineering teams, but is often less owning technology and more owning agile processes and engineering teams.
• The Product Owner owns the team's product vision and possibly the customer strategy. She/he is a member of the development team or has a representative that is part of the development team.
• The Technical Product Owner owns the customer view of technology, may be a full fledged product owner, or may be a support member of a larger product owner team.

Individuals become more and more key enablers as your product and technology base become more advanced. A Servant Leader is then a manager (e.g. engineering manager) that helps individuals contribute in independence yet within orchestrated flows. This figure illustrates where the servant leader provides critical guidance (the red corners!):

Here, from the central diagonal outwards:

• The team iterates a technology and product development and review cycle, again, and again.
• In parallel, the team learns and explores productivity and innovation. Product does the same with their customers and market segment.
• Productivity issues are monitored. In a physical model of agile processes 'high momentum' is high productivity. Servant Leaders help monitor for issues such as unsustainability, diverging focus, low or over capacity, and help teams and product avoid or resolve these issues.

 My experience is:

• Product Owner and CTO have too much "skin in the game" to be effective servant leaders. Therefore engineering managers and technical product owners (when they have only partial ownership) have a critical servant leader role to play to help all deliver better.

All original content copyright James Litsios, 2022.

Agile from business to technology

This is how I scale agile towards business and towards technology.:

Where:

• In the center we have an agile process that blends team process and product process.
• To the right we have a business process that ties into the product process.
• To the left we have a technology process (expertise process to be general) that ties into the team process.

To be honest, this is my minimal theoretical business to technology agile process. In practice, a specific agile process is chosen, with process steps and process artefacts. People like to say that agile is about people, not process. Yet people need to communicate, and the common vocabulary for that is given by a process.

Deepening in to the product business view (right side above):

Where:

• The core agile process (blue) delivers features and deliverables that are part of a product and business goals.
• These deliverables are picked-up by customers
• The features and deliverable sustain (or not) the customers competitivity within its market segment
• The product owner (in scrum terminology) is the expert that guides the product with regards to the customer needs.

We can do that also for technology/engineering (left above):

Where:

• The core agile process (blue) includes experts within the team.
• The experts enable/produce the technical/engineering needs of the features and deliverables.
• The expert individuals may be experts in different domains.
• Coordinating technology/engineering frameworks allow experts to work both as individuals and in coordination (within their team).

Many domains of technical expertise are possible. Above are the ones closer to my experience.

Note:

• The complete process above needs to coordinate at least SIX streams.
  A minimal agile process only presents three streams (team vs product vs customer). 
• Each of these (six) streams will naturally be driven at their own different rate!
• Your job, as CTO / engineering lead is to work with individuals, teams and product to pace work within these different streams to achieve an optimal throughput!
•  Think laminar flow! Productive is as fast as you can go before things become turbulent!

I wrote this up as a (much longer) slide deck, and am always happy to share my experiences!

All original content copyright James Litsios, 2022. 

Three step research process

Use your brains when developing abstract innovation. It is a game of 'balance': you think-up what is needed, you set goals that take advantage of your thinking, then you work towards your goals. If on the way something does not fit, review your goals or thinking. It is an iterative effort, you try, you repeat, until it works.

Here are the three iterative steps in more details:

1. State what you believe is true
2. Express implementation goals that will leverage your beliefs
• Check consistency of goals with respect to your environment and to underlying beliefs
• Correct your beliefs if inconsistencies are found between goals and environment
3. Develop towards your implementation goals
• Check consistency of development with respect to environment and underlying goals and beliefs
• Correct goals or beliefs if inconsistencies found between development and environment

At first, one tends often to 'juggle' and develop just one idea at a time, when developing this way. Yet with experience it becomes clear that it is the iterations that take much time, and therefore it is often worthwhile to think-up more than one idea, and bring them forward in parallel until the environment gives feedback, and one idea turns out to be better than another. Lean is therefore not always agile when working with abstract development.

All original content copyright James Litsios, 2022.

Six ways to improve your organisational agility

Failing smart 

 My agile mantra is much:

"Failures must bring you closer to your vision"

It is a mantra I have often used. And very much how I approach agile innovation (e.g. see Search and Vision for Systematic Innovation)

However...

It is only partially true, as failure may happen simply because you are disorganised, with no relations to your vision. Fixing organisation issues helps avoid drifting further away from your vision, it does not bring you closer to your vision! Still, unmanaged organisational issues will eventually consume you 'from within', therefore they too must be addressed.

Can we focus on fixing organisation issues? Can we identify a subset of failures as 'organisational failures', and others as 'non-organisational failures on the way to our vision'? The simple answer is yes! Yet we most know what we are looking for.

Six types of failures

When I act as agile manager I try to distinguish between six types of failures. These are:

1. Fail Goal: Fail to achieve previously promised goals
2. Waiting: Fail deadline because of waiting on others
3. Underutilisation: Fail to use all your team members
4. Exhaustion: Fail to stay productive because of exhaustion
5. Inconsistency: Fail because of misalignments
6. Queuing: Fail because of past work no longer relevant, or past work never finished.

Failure 2 to 6 are all organisation failures!

Failure 1, not achieving goals, might be an organisational issue, yet may also be tied to the difficulty of the the task at hand.

Six ways to improve your organisation

We can express specific actions for each type of failure observed: 

#	Failure type	Observation	Corrective action
1	Fail Goal	Fail to achieve previously promised goals	Review / pivot how resources approach goals
2	Waiting	Fail deadline because of waiting on others	Review how resources approach work
3	Under-utilisation	Fail to use all your team members	Review how goals are broken down into work
4	Exhaustion	Fail to stay productive because of exhaustion	Review how goals are picked up by resources
5	Inconsistency	Fail because of misalignments	Review how work is shared across resources
6	Queuing	Fail because of past work no longer relevant, or past work never finished.	Review how common work impacts different goals

You may note the common patterns both in the observations and in the corrective measures above. This is because they all refer to the same system! This is important, and maybe the most important learning from this post. When managing fast greenfield innovation projects:

Comparing failure types is as important as to address specific failures!

This is because when a failure type happen more often than others, we can take organisational actions even before we understand the specific details of each failure! 

A final note: the approach is scalable.

All original content copyright James Litsios, 2022.

Search and Vision for Systematic Innovation

How to be productive in innovation?

The simple answer is "work hard", "be systematic", "believe in a larger vision".

Best to illustrate this:

I am writing a python program to do something new. I know that to be innovative I need to be "one level above" what was previously done. So I include a construction which I know enables this "newness". The problem is that this construction does not fit with "the normal code".  I notice this only after my first attempt to put things together, when on the way to a design, I cannot find a way to bring back in the requirements I have dropped. Let's call this first attempt design A. 

When you fail, you try again. I pivot my design, now to focus on B. Same result, design fails to bring in all requirements. I try again, now focusing on C. Same result, the design does not fit. A this point I start worrying. I step back. I explain to my daughter: "tricky, but I have got it! What we need is to go a level above and dynamically bring in A, B, and C concepts in a pre-sorted meta-design that depends on the input data". This new design, let's call it sorted ABC is not easy... and it also fails! Now I am seriously worried.  

I try again. Yet this time, knowing that A, B, C have failed, as did sorted ABC, I step back further. I go all the way to the "one level above" concept, which I take out, and put back in, in a complementary way. In two days, I have the design, and in a week I have all the requirements in it.

Innovation is just a "search algorithm". Edison knew this. The pharmaceutical industry has scaled this to the extreme. What is a little bit tricky in computer science, and similar technology domains, is that innovation is a mental game. The result is that failure within a search effort impacts moral and motivation.  The fact is, if you have not prepared yourself, it is not possible to invest yourself, and not feel the pain of failure.

The effort I described above took me more than a month. I might mention that I was getting seriously upset with my repeated failures. Yet the trick is that failures that are progress within a bigger vision are acceptable. They are painful, they make you lose time, but they are still ok if they bring you closer to your vision. Therefore the simple rule in innovation is that your need that larger vision before you start! And in fact no work should be done without that larger vision, and that larger vision needs to be a real concept of delivery of a real product with real innovative advantages.

A key ingredient to this process is that failure must reduce the search space towards your innovative vision. As a leader or in advisory roles, I find myself repeating and emphasising this more than anything else. Because this is the "crux" of productivity in innovation. Again: FAILURES MUST BRING YOU CLOSER TO YOUR VISION!

Finally, if your failures are not bringing you closer to your vision, then you have placed the bar "too high" and you need to diminish your expectations, and reduce the scope of your vision.


All original content copyright James Litsios, 2020.

Thinking versus brute force "doing" in software design in 2020

About thinking versus doing

(I put a subset of this on YouTube as: https://www.youtube.com/watch?v=_kXpyctbmrQ)

Is it ok to program by "brute force" and put aside your brain?

A few years ago, I wrote on the pros and cons of programming with explicit and implicit type declarations. In 2020, I feel that this question is almost irrelevant. Therefore to ask the question:

Should we think about software design when we program? 

There is a trend in software development which states "developing software products is not about thinking but about doing".  I know many venture people who believe very much in this statement. Yet the reality is that software is a process of thinking (in part at least). Still, from a pure seed-venture-money game, the rule of "it is not about thinking" is true"! Because the number one rule is "be fast" and thinking too much will very much slow you down.

Is it then both true and untrue, that we should both use and not use our brains when we write software? Yes, and yes! And it is exactly this subtle challenge that makes software management in innovation a tricky game.

Thinking can be done different ways, different approaches can be taken. Some are efficient, some are a waste of time. Some will help your software grow, others will block you. Some will help you meet your deadline, others will invariably lead to failure. The game is then only to think in the ways that help you!

Some of my colleagues have heard me condense these concepts into one statement:

It is about thinking backwards!

There are many ways to do this. I will cover just a few here, there are in fact as many more.

Play to win above all else

In recent blitz chess games, FM Lefong Hua repeats "it is not about calculating the end's win game", (because that is not a guarantee win), instead is about about "flagging your opponent". By which he means, winning is not about thinking within the classical rules of chess, it is about meeting the "win conditions", which in blitz chess games is much about not running out of time (being flagged).

Transposed into a software development, that means it is not about meeting the classical rules of software design, it is about thinking through how to always meet your goals and deliver results. Or to be more specific, it is about thinking backward, to find a path back from your "runnable software" goals, to your current status that guarantees your development success.

The heart of your software comes first

I have mentioned that "One of the little understood properties of programming is that at the lowest level things tend to be single dimensional".  A good software design builds a "break" or "separation" in that unique dimension "just about where your main product abstraction is", to achieve a sandwich like design where new product abstractions are added "by reassembly" of the two separated parts.

There are few ways to do this, domain specific languages (DSL) and functional programming (FP) being my favoured approaches.  While all my major software developments had DSLs, it was only much later in my career that I understood that what was working for me was not the DSLs but the effort to maintain separation between interpreter and interpreted abstractions. This separation is naturally achieved with a DSL, yet can also be achieved with adjunctive higher order FP. (The "ultimate tool" is then to combine the two concepts as adjunctive FP based DSLs, which was the base of Elevence's contract language).

Be functional and agile

Agile development is a lot about prioritizing your requirements and implementing them in work iterations. That means that the first level of your design, what might be seen as the first draft of primary keys of your data base, are directly tied to the most important business concept (taken from OO vs FP vs agile). The trick is then not to see this as a database of data, where keys are data, but a database of code, where keys are functional properties such as APIs with specific invariants (e.g. somewhat like class types in Haskell). The extended trick is then also to make this a normalized design (just like a normalized classical DB schema, but in a the "functional space"), for example by using linear types.

Brute force yes, but with the right pieces

Let us put this all together, our first conclusion is when building new software:

Use brute force and minimal brains to assemble data and call external APIs 

Importantly, keep your program structure as flat as possible when you do this. Which pretty much means to shun OO patterns, and to use as many array and container like constructions as you want.

Then, and this is the tricky part:

Incrementally invest effort to separate interpreter and interpreted abstractions in your code.

Always make sure that these abstractions fit within the plan to your deliverables. That means you are able to think backwards from your deliverable goal, and work out the path to your current development state, the path which you will follow to build your code. An agile process and a good team will make this an easier job. Also, all those arrays and containers will need to fit into a single unified concept (e.g. such as indexed tensors).

It's complicated

Sometimes things are just too complicated. Many developers do not know how to "separate interpreter and interpreted abstractions".  Here I will be honest, it is not easy. And just to make this clear, the last DSL I wrote took me multiple tries until "I got it right".  Also, to mention that embedding product abstraction in higher order FP is even harder than writing DSLs.

Worse, the process is "hack brute force" to assemble data and use external APIs, and only then think about how you can slice your interpretive abstractions. These means that initially, software development is about doing, not thinking. Tricky...

Welcome to 2020

I have been writing this blog for almost 15 years. Interestingly, a major change over these years is that there is so much well integrated open source software (OSS) out there that it is cheaper to "just try" than to "think" (when using OSS and third party APIs). And in part it was this reality that led me to write this blog today. Enjoy, and stay safe!

All original content copyright James Litsios, 2020.

Agile process vs Data Management

Modern architecture, for example for large cloud systems, have much in common with agile processes. You may know from past posts that I love agile processes. One reason is that agile processes have mathematical roots. The other is that when you know how to yield them, they deliver. I could talk for two hours on the subject! Here, for your comfort, the focus is just on the basic tie between an agile process and the architecture of modern data management.
Here is the video (9m):

Pictures from the video

Hereunder, the main pictures of the video, in case you want to refer to them in your comments:

1) Concrete vs Abstract (horizontally) and Static vs Dynamic (vertically):

(Note how I say concrete, but write "contract" in the video. That is a mistake, and what happens when you invent smart contracts and focus much on them!).

2) Agile process "functional schema" and data management "functional schema" side by side:

3) Waterfall process (red):

4) Agile iterative process (blue):

5) Traditional database architecture (red):

6) Modern data management architecture (blue):

Yes, in case you are wondering: my left hand is holding my iphone as I record. 

As always, comments are welcome, especially from old friends!

Servant Leadership in seven rules

My favorite leadership approach is servant leadership!

While leadership is needed for different reasons and is expressed in different ways, it is clear that certain styles of leadership are better suited for specific situations, characters of teams, groups and organisations.  Therefore: this blog entry about servant leadership... because it works for me!

Note that this blog entry talks of teams... Teams which could be organizations, be hierarchical, etc... Servant leadership is not about structure but about method.

Let's start by expressing a complementary view: what is not servant leadership. At the extreme we could mention dictatorship, but that would not help us much, and is in fact not complementary. Instead, it is better to bring up followership in which team members follow their leader. Let's now start with three defining aspects of followership:

Leader with followership:

1. Team leader communicates expectations, team members follow with goal to meet expectations
2. Team leader expresses expectations to optimally meet the teams capabilities
3. If the leader receives feedback from team, the leader may review their communication and expectations

The most important part of this very simplified followership leadership is that only the leader adapts! Sadly, many leaders have a hard time with the idea that they must adapt. Therefore, to understand leadership, you need to accept that you too as a leader need to adapt. This is our rule one in servant leadership, a rule that is universal for all leaders:

Servant leaders align communications and expectations to meet their team’s need

Followership leadership is useful for short lived teams, such as one time situations or events, and useful for situations where members don't consider modifying tasks, because the tasks suit everyone or are too hard to change.  It is important  to note that in all situations there will be "moments of followership", moments that are "one off"or for which debate is not wanted, nor learning expected. These moments are very much "leader leads, followers follow" moments. For this reason,  we have rule two of servant leadership:

Sometimes servant leaders lead and their team follows

Much of what you do as a servant leader is to work for others, and yet you are still "the boss"and that means that there are moments where you need to "be the undisputed leader that is followed". This much because it is needed to keep your team healthy and sustainable.

Good leaders know that the greater value is in the team, not in them. That means that we want to boost our team coherence and self drive, in effect to give more leadership ownership to the team. This will be our rule three:

Servant leaders help the team lead itself

 Each team member is a mini-leader! In parallel, each team member is also a follower of all those other mini-leaders. Therefore we take our simple followership process above, and we rewrite it twice, first focusing on mini-leaders, then focusing on team followers. This gives us:

Team members as mini-team-leaders:

1. Team members communicate expectations to the rest of the team
2. Team members express expectations to optimally meet the team's capabilities
3. If each team member receives feedback, they may review their communication and expectations.

Team members as followers of their team:

1. Team members follow the communicated team expectations
2. Team members communicate their capabilities and optimally meet the team's expectations.
3. If team members provide feedback to their teammates, teammates may adapt how they follow goals, and adapt how they communicate their capabilities, and meet expectations.

With these two lists, we have captured something of a "pure unemotional and egoless self-driven team", that is, a hive-like team where everyone is led by everyone else, and is following everyone else. Yet such a team does not exist: teams are groups of individuals, all with their differences, and most importantly with their emotions and ambitions. And a productive team is much fueled by its emotional energy and enthusiasm! Therefore rule four, an obvious one, but as you will see, that has a twist:

Servant leaders encourage emotional energy and enthusiasm

The twist is then the following:  What type of emotions is does the leader encourage? Team emotions or individual emotions? Or both?

Both! Because a team is a group of team members but also of many individuals that are part of group. Here is the thing though,  the team’s emotions and individual's emotions can sometimes be very different. Think extrovert versus introvert here. In fact, they can be so different that they challenge each other, and this often subconsciously! To simplify, what can be happening is that the team feels aggressed when certain individuals do not embrace their emotions, and the individual feels agressed when the team or other individuals act so as to disturb their personal emotions. Therefore, when I say that the leader encourages energy and and enthusiasm, I am also saying that the leader cares about how team and individual emotions interact, and when needed help emotions co-exist together peacefully. We can write this as the following rule:

Servant leaders foster acceptance of team emotions by individuals and of individual emotions by teams 

Helping the productive coexistence of the team and its individual team members is much of what servant leadership is about. In part to help sustain good emotions, but also simply because when a team needs to solve many problems, it helps when the team members are given the independence to come up with solutions. However, just like emotions may hinder and even splinter a team, so can action and ideas. This is in part because giving team members some independence is also allowing them to be mini-self-centered-leaders to some extent. This, added to people's ego, gives you something extra, which can both be valuable, as well as highly lethal to a team. And therefore, an important task of a servant leader is to help channel the effects of giving people some independence. One way to approach this is to equate being independent to following yourself. We already have a followership list above, which we can rewrite as follows, with a self-centered focus:

Team members as followers of themselves:

1. Team members follow their own expectations
2. Team members communicate their capabilities, and optimally meet their own expectations.
3. If team members provide feedback to their teammates, teammates may adapt how they follow their goals, and adapt how they communicate their capabilities, and meet their own expectations.

Note here that I am assuming best intention, and therefore do not include disruptive self-interests above. However, best intention also goes the other way: people tend to bias their communication and expectations to protect their team members independence and ego! And not necessarily on purpose. We can express this as a form of shyness, again rewriting one of the previous followership lists.

Team members as shy mini-leaders:

1. Team members do not communicate expectations that might clash with expectations of others in their team
2. Team members do not expresses expectations to optimally meet the teams capabilities when that optimality might cause issues to others in their team
3. Team member tends not to receives advice when these are too personal towards them, or towards others.

These last two lists give us new tasks for the leader: to coach individuals to help them lead themselves coherently within their team, and to help teams lead themselves without fear of interfering with each other (e.g. social shyness). We might express this as follows:

Leader as personal coach:

• Leader coaches individuals to help them align personal and team expectations

Leaders help deal cross team interference:

1. Leader helps team members communicate expectations that might clash with expectations of others in their team
2. Leader helps team members expresses expectations to optimally meet the teams capabilities when that optimality might cause issues to others in their team
3. Leader provides advice when these are personal towards them, or towards others.

Now as we will see below, we will also want help the team deal with these topics, yet still then, the leader wants to have them in their radar. And therefore we condense all of this into rule six of servant leadership:

Servant leaders coach individuals and teams around expectations

Again, good leaders know that the greater value is in the team, not in them. Therefore, when possible, we want our team to deal with their expectation issues. And therefore, we want to boost our team members and the relations they have within their team.

Now we are almost done. Our last servant leadership rule will be about process, as until now our focus has much been on people, which makes sense as teams are groups of people. However, process is the backbone of the team: if it is weak, the team will be weak, if it is too rigid, the team will be too rigid... and we could go on. Yet the process as a backbone analogy is in fact a great analogy, in part because it is telling us that the team and the process and are symbiotic relation. Processes are not rules to apply, and neither are they routines that we follow, they are productivity boosters! Taking that from an optimisation perspective, processes are mechanised ways to push your team to be better each time. And that is not easy, and very much a job for your servant leader to help you with.

Servant leaders help team grow and pivot their process to be more productive

I'll give you a simple example: Give your team the productivity boost to be on time to your meetings! This may sound like "petty" time dictatorship. But hey, do we need to lose three minutes multiplied by the size of your team with every late meeting start, as always one member comes late? I would argue not.

Here you have it, seven rules for servant leadership:

1. Servant leaders align communications and expectations to meet their team’s need
2. Sometimes servant leaders lead and their team follows
3. Servant leaders help the team lead itself 
4. Servant leaders encourage emotional energy and enthusiasm
5. Servant leaders foster acceptance of team emotions by individuals and of individual emotions by teams 
6. Servant leaders coach individuals and teams around expectations
7. Servant leaders help team grow and pivot their process to be more productive

Note: You do not need to be a purist to apply servant leadershp. Provided here is an "idealized" explanation: in the real world there is friction, things interfere, and things happen differently then planned! Still, what you do have here is a servant leadership tool box that fits all those real world moments.

All original content copyright James Litsios, 2019.