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. 

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.

Skunk Works Rules (Kelly Johnson's Rules) Agile Style

#	Skunk Works Rule	Agile Interpretation
1	The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher.	Control is delegated to teams. Direction is owned by business/product team leads who report at the business stream level.
2	Strong but small project offices must be provided both by the military and industry.	Leaders are strong and few.
3	The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people (10% to 25% compared to the so-called normal systems).	Keep teams small.
4	A very simple drawing and drawing release system with great flexibility for making changes must be provided.	A very simple process to integrate, validate and release the full deliverable must be provided.
5	There must be a minimum number of reports required, but important work must be recorded thoroughly.	Process is minimal and simple, and yet records all important work.
6	There must be a monthly cost review covering not only what has been spent and committed but also projected costs to the conclusion of the program. Don't have the books 90 days late, and don't surprise the customer with sudden overruns.	Process is iterative. Achieved and validated results are systematically compared against projected iteration estimates. Consolidated project estimations are updated with learning from discrepancies observed within estimates of iterations.
7	The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for subcontract on the project. Commercial bid procedures are very often better than military ones.	External dependencies are delegated (not remote controlled) to meet defined requirements that make sense from that external view.
8	The inspection system as currently used by the Skunk Works, which has been approved by both the Air Force and Navy, meets the intent of existing military requirements and should be used on new projects. Push more basic inspection responsibility back to subcontractors and vendors. Don't duplicate so much inspection.	There is just one way to validate that deliverables meet their requirements. This may include multiple categories of criteria (e.g. acceptance criteria, definition of done, test suites, ...). Don't duplicate validation work.
9	The contractor must be delegated the authority to test his final product in flight. He can and must test it in the initial stages. If he doesn't, he rapidly loses his competency to design other vehicles.	Components delegated to external parties can be finally validated within the full (functioning) deliverable.
10	The specifications applying to the hardware must be agreed to well in advance of contracting. The Skunk Works practice of having a specification section stating clearly which important military specification items will not knowingly be complied with and reasons therefore is highly recommended.	Validations process is communicated and accepted by all before work starts.
11	Funding a program must be timely so that the contractor doesn't have to keep running to the bank to support government projects.	Manage budgets "outside" of teams.
12	There must be mutual trust between the military project organization and the contractor with very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.	There must be mutual trust between those that say what the product does (e.g. product) and those that build it (e.g. engineering).
13	Access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures.	Communicate your innovation inwards, not outwards.
14	Because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised	Reward performance, not the role.

Explanation

The table above is a short analysis of the "Skunk Works Rules". As this is about innovation, I chose to express each rule from an agile perspective.

I love the engineering of the Lockheed Skunk Works. A few years ago, I enjoyed very much listening to Ben Rich's book on the subject (Skunk Works:...), Ben Rich having been the second director of the Skunk Works, (he succeeded its founder Kelly Johnson). In this book, and in many sources, Kelly's management approach and "rules" are mentioned, but not "deconstructed". I made a note to do so, which I do today, and I share that above. Comments are welcome, I took a very direct approach here, and am happy to hear how else to look at this.

Remarks

3 - Size of team

Size of team too big when it can no longer absorb new information from individuals (e.g. learning), or when individuals no longer stay aligned with changes of direction of team.

5 - Reporting work

Too many documents kill productivity. Recording work is ideally done in something as close as possible to what is the work. Yet to be a record of work, there must be more than work, there must be a record of some context of the work. In software development, text that describes work tends to age much too quickly.

7 - Delegating towards specific requirements

How to delegate work and still be agile? How to capture just enough of the future for the teams to be independent within the right amount of dependence? (Think distributed algorithms to answer that!).

14 - About rewarding people

Long term company stability may depend on stability of certain roles and people. Sometimes you need to pay key individuals to ensure that stability.

All original content copyright James Litsios, 2019.

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.

Lean Startup is about market making your product

I am a big fan of lean startup, and will therefore tell you why. Still, the method is not universal, and has its limits, I will tell you about that too.  If there is one thing you should remember is that lean startup gives you a simple recipe that can shape a new product both to meet the needs of its customers and to be profitable. To do that, the method needs customer interaction, and without enough of it, the method is likely to fail.

Lean startup is an iterative process. Yet unlike other development processes that only focus on the "how", lean startup gives you some very precise rules to follow on the "what".  Once you understand how the method works, these rules make sense. Here are the important "whats":

• Value is defined relative to a reverse income statement (defined as the "engine of growth"). In effect you are expected to model both your product and your customers. You can use a simple model of fix price values per events (such as client clicks), or you can be more creative and use some real financial engineering tricks to build your notion of value.
• Risk is to be minimized, and as risk is hard to measure, it is up to you to judge your uncertainties, and then to diminish your largest know risk/uncertainty at each development iteration.
• Customers and products are understood through the data that can be collected out of them (this is the notion of "measure"). All value assumptions must be validated through the collection of data. Risk assumptions are not validated.
• Continuous deployment means that software changes go directly into production (with some smart test automation in between). 
• Software is "staged" into production. So new changes go into production, but normally only to be initially used by few. As data comes in that validates the code change and expected value improvements, the change will be made available to more users. Staged deployment makes it possible to simultaneously collect data on different versions of your product. This is the notion of split testing. If you have done enough math you will know that split testing, well implemented,  gives you the most reliable measure of how the customers are effected by your code changes.  Other ways to collect data will include much more noise..
•  The careful observer will have noted that split testing within a "learn and change" loop is in effect a quasi-Newtonian optimization process. That is, we a looking for the best way to improve our product (equivalent to the steepest gradient). As we do not know that best way, and only know "a way", when the split testing confirms that the new version of the product is better than its previous version, we have a "quasi" method. As Newtonian methods are susceptible to getting stuck in local minimas, we need something more, and that is inspired by linear programming with the the notion "pivot": To pivot is to swivel variables into constraints and constraints into variable. Said differently, to pivot in business terms, is to change assumptions, to change your beliefs.
• Data and data collection are core values in Lean Startup, and therefore the notion of pivot. In lean startup you must note all your assumptions down, and any change to these assumption (any "pivot")  must be noted down too. This type of detail may sound pedantic but that is how smart learning happens. And more importantly that is how good team learning happens, by making the effort to express and note down your assumptions, to validate them, and make the effort to update your notes (data) when you change these assumptions.

Expressed in this way, lean startup is one big algorithmic machine. People still have a role to play as they decide the changes they might want to bring to their income model and to their product. The lean startup algorithm makes sure that changes really do have impact on revenue and on product perception. The originality of the method is to be expressed within one recipe.

I do not know what made the creator of lean startup put his method together, but if you have worked in finance, and especially market making and algorithmic trading, then you have already been using  very similar methods. The big differences is that the method is meant for material products, and not immaterial financial products, and that these material products normally only have a single sided market, unlike financial markets where you can buy and sell. These two aspects do make the method a bit tricky when the income model is not obvious. For example, when income comes from advertisement, you can equate each advertisement screen refresh with income, therefore it is pretty simple to map customer events to income values. But suppose you want to move to a subscription model, now your customer is paying a monthly fee, how to map your products features to this income? If you have done enough math and worked in finance, you can think up a few ideas on how to do this, but nothing is obvious when you do not have this math experience. And that can make the method tricky to apply.

I like the method's smart tie into  financial theory. For example, simple portfolio theory say that it equivalent to maximize return under fixed variance, as to minimize variance under fixed return. So lean startup chooses the second option: minimize risk (variance) while having asked you to express return (inverse income statement, growth engine). To then make sure that you validate that return model with your collected data. As a full notion of variance would be impossibly complicated, lean startup says: focus on the largest risk. That is a simplest approach, but also the smartest approach.

Another tie to financial markets is that you need to make a market in your product for lean startup to exist. Making a market means that you attract customers to use your product. And because lean startup relies on a "market fitting" approach, that is, you fit your product and income model to your market of customer, the type and amount of customers you have will make all the difference in how your product evolves. This is a real issue because the good clients are not the ones that want to spend their time playing with small applications that only have a subset of functions. Therefore, a critical difficulty with lean startup is in how to bring valuable customers to a product that is not yet really valuable enough to them. This bootstrap phase can be most difficult and that explains why you need to cheat at bit and sometimes offer what you do not have to get the necessary feedback to validate your product's evolution. Unfortunately, customers will hesitate to come back to your product if the first time they came they felt deceived. So offering what you do not have, in order to get a feed back on the demand, will also tarnish you ability to grow later. This is especially true with small niche markets.

Market dynamics are much the higher order properties of a product. Many just ignore them and hope for the best when launching their new product. Lean startup makes the effort to try to learn about these market forces while you develop the product. It is not easy, it is not obvious, but it is still the right thing to do.

Agility is both about individuals and collaboration: Analogy between agile teams and chess

What can we learn from chess to better our agile management? Here I use analogies from the game  to highlight a few important concept that all agile team members should be aware of. For example, the game of chess highlights the difference between the strength of individuals versus the strength of teams, as well as the difference between experience versus talent. 

I watched a few of the 2013 world chess championship games between Carlsen and Anand. (I am not a chess player, I am just happy to be a good spectator). It was a great fight! Looking back you might say that Anand just made too many mistakes, yet during the match I think that many of us though that Anand had good chance to do much better.

While watching those games, I could not help seeing some of the universal principals that can also be found in management. To explain the analogy, I first present the chess concepts, and then map these into a management world.

When you learn chess, you learn that pawns are the weakest pieces, queens, the strongest, bishops and knights have a similar strength, and that rooks are the second most powerful pieces. Therefore it is "normal" to make moves which exchange same value pieces. And as a beginner, you base your moves on this principal and start by thinking that the strength of a position is determined by summing the strength of your remaining pieces. Yet with experience, comes the realization that only pieces that can do something have value. And of course, it should not be easy to take them. Which really means that good players build their positions as complex supporting dependencies between their pieces, and complex attack/defense relations between their pieces and the adversaries pieces.  And relations are built not only for the existing position but also for selected possible future positions. Still, even though positional strength is usually more important than "piece value" strength, strong positional strength often ebbs away when it does not provide victory, and fortunes shift. In these moments, an extra piece or two may make the difference between winning and losing.

One way to make sure to build "the right" position in chess is to rely on learning many chess openings. With a chess opening "catalog" you are more sure "to do the right" thing. The same can be said for end games: there are techniques to learn to deal with many type of end scenarios. Note that to use such methods you do not need to be talented, you need only to have learned the skill (see recent talent blog entry for more). Therefore to mention that (in theory) you do not need to "think" to build a solid starting position in chess, you just follow the previously learned opening lines. Still, this only works if your adversary is doing the same. And, you do need to think, because there are often multiple choices possible for a given opening position. Also, opening lines in chess are not necessarily very deep. (I couldn't find how deep openings are on average, only total number of opening moves, e.g. 16.3 million ).

Let us now try to associate team management ideas to the chess concepts introduce above.

	Chess	Agile management
1	Piece value strength	Team member strength
2	Positional strength is built on relation between pieces	Agile team strength is built on relations and collaborations between people
3	Game position	Each team member has a task activity, and relations and collaborations with other  team members
4	Piece is moved	Team member finishes a task, picks up a new one, and possibly changes how he interacts with others.
5	Chess openings build strong positions	Use of past experience builds strong and productive task assignments and collaborations within the teams.
6	Chess endgame theory helps win in difficult situations	Use of past experience allows team to meet their delivery deadline.
7	Chess player thinks	Team interacts and prepares tasks.

We should not push this analogy too far. A game of chess is not a team.  And in fact in chess, each player controls his individual pieces, which could be compared to a project manager ordering his people around. There are many industries where this comparison would make sense. The reasoning works like this:

1. If you have acquired enough expertise so that each task is repeatable and demands little new learning.
2. If what you need to do is known and fits within your expertise.
3. If you find individuals that can perform the tasks needed.
4. Then you can run a central project management, and as "everything" is known, no collaboration or individual decision taking is needed.

But, such a situation is explicitly disallowing all the new situations and new learning that appear in playing chess.  Which is why I have chosen only to focus on an agile view of the world here. In fact my only "starting" goal was to repeat the "mantra" that agility is both based on individuals and collaboration. And so is the game of chess (from a perspective of the pieces).

To conclude:

• If you are a less skilled individual, you can provide critical strength to your team by supporting your teammates with valuable and well timed help.
• If you are a very skilled individual, then you can make you team even stronger by leveraging your strength through appropriate interactions with your teammates. 
• Use past experience to choose best how to assign tasks, to interact and support your teammates, and meet your deadlines.

And if you have any doubt that this is true, you should watch more chess.

All original content copyright James Litsios, 2013.

Managing talented people

Misfits of science

Talented people are outstanding at what they do best... and often dysfunctional in one way or another. This post is about how to manage talented people. And especially about managing them within organizations that need a lot of collaboration (e.g. software development).

I'll start with a quote from a TV show from the eighties:

"Everybody that is worth the trouble is a little weird"

(To be found in episode three of the Misfits of Science)
 
I have worked with many talented people that were "pretty normal", yet I would need to argue that the majority of the "good people", those that are worth the trouble to "keep", from a management perspective, are also "focused in their own way". And even the talented people that did not show outward signs of "idiosyncratic" behavior, had their special side, which within work organization often showed up as social issues in abrupt or surprising manners, like when they decide to quit (see Bob Knowlton at Simmons Laboratories for a great example of interesting material collected on the subject in the fifties). 

Changing oneself takes an incredible amount of time and focus, even with the help of other, and is simply something that cannot be "managed at work". This brings us to rule one and two in managing talent:

Focus on your organization's culture and work process.

Ignore any dysfunctional side of talented individuals.

As a manager your first priority is to make sure that the "group thing" works, because it will cost you a fortune if it does not. A culture of healthy proactivity is worth gold, and so is a culture of efficient quality (e.g. test driven with automation). So your job as a manager, before all, is to bring in that productivity without worrying about dealing with any dysfunctional side of your talented people.

Note that I did not say that you should ignore your talented people, just their dysfunctional side. Which brings us to rule three:

Never ignore your talented people.

Here is the theory: Talented people are "special people" (see my blog entry on the subject). Which means that part of what "makes them tick" is independent from the social and group "thing". Talented people can build "a lot" on top of this independent "part of themselves", that is what gives them their speed and creativity. And they do it for different reasons: they may be driven by the purity of the building process, a form of aestheticism; they may be driven by their social imbalance, forever trying to compensate for it. Yet most importantly, this drive is almost always there! It does not matter if the person is doing good or bad. Therefore, if care is not taken, talented people may build "bad stuff" in this independent part of themselves, effectively growing their dysfunctionalities. This happens subconsciously or not.

Breaking bad

Talented people may build "bad stuff" and this can lead to bad behavior. Top on the list bad behavior with talented people is "the control thing". People with this problem may invest a lot of effort to control their surrounding with the only goal of preserving or protecting their "inner independence". This can happen in many levels of "badness": I have worked with people that lied to me and to others, a very bad behavior; I have worked with people that needed to "own" all or part of the solution, a sometimes bad behavior.  This ambiguity of what is a bad behavior is part of the trickiness of managing talented people. But it also leads back to rule one: first make sure your overall process is working. Do that for the productivity reasons I mentioned above but also to set limits for your talented people. The thing is, they are experts, they know more than you in specific domains, yet their effort to "stay in control" may well be leading you elsewhere than you want to go, and they may even not be aware of this. Therefore, as a manager you need to set (and help set) standards and make sure you have a very active monitoring process to enforce these standards. In fact you not only want that monitoring of "good organization process and culture" to be active, you want it to be visible to all. That will help remind your talents what the good rules are, and that is our rule number four:

Actively and publicly monitor "good" work process

You can be the traditional director, or project manager, that "walks the floor" and that tell the team what they see and what they like. Or this can be an agile process where the monitoring is done as part of everyone's job,  for example, in the Scrum's daily standup meetings. What is important is that the effort is steady, repeated and maintains expectations of simple work behaviors.

Now having said all this, you might say I am providing little help, and I am not saying how rule three should be implemented. The one about not ignoring your talented people. I will come to that, but I really wanted to reenforce rule one, two, and four. And just to really, really, reenforce this notion of "make sure the environment is right", I need to add that just like with computers, there is a bit of a "garbage in, garbage out" aspect with people: if you do not give them good input, they will mostly not produce good output. With talented people, this effect is compounded, because they "soak in" more and faster, but also because they typically are more sensitive to connections between things.

This brings us to rule five:

 Maintain clear business goals, actively evangelize your teams towards them.

Having a company vision and a good product management that works hand in hand with your development resources goes a long way to keep your talented people aligned and feeling that someone cares about them. But that is not enough. There is an alpha person like hierarchy in talent. Therefore not only do your product owners or managers need to be good, they must also be talented. Otherwise the attention they bring to your talents will not be considered as relevant.

This last rule is little tough, I am saying you need a balance of talent in product management and development, yet if you know how hard it is to hire talent, this is not always an easy balance to achieve. Yet I am asking you for more, rule six is:

Have a head of HR, or CEO for smaller organization, that understands talent.

Now you might be thinking: talented development, talented product management, therefore talented head of HR or CEO; a form of "alpha person" hierarchy. That is not what I am saying -- although it is an option to shape your organization as an "alpha hierarchy" -- I am not saying that because if you build your company just by "stacking" talent, you end up with strong silo structures and a very political culture where people will put themselves before their organization. Such an approach is fine for specific business models, for example, to support a "pyramidal" sales organization. Yet it leads to organizations with limited sharing and team culture. In my business (software development) you want collaboration, therefore you want your head of HR or CEO to understand the subtle rules of managing talents. And therefore rule six says that your head of HR or CEO is experienced enough that he/she knows how to manage talent.
 

Just say no

Even with a "talent friendly" organization framework, we do need to accept that sometimes people just go too far, and there are situations were bad behavior needs to be stopped. Therefore, rule seven is:

Stop bad behavior that goes against your organization's culture and work process.

(This rule is really just a repeat of part of rule one. Yet it is so critically important that I give it its own rule.)

Talented people need a work culture as much as everybody else, but the more talented the person, the less their culture tends to be fed by "standard" social rules. "Nerds" are an example, almost a caricature, of such a different cultural standard. Other examples of "special cultures" exist, and each individual has their own "special" personal culture, built upon good and bad behaviors. Although it is nice to be fully integrated in a culture, it is also nice to be just "in" a culture, especially if there are other ways to grow. Many talented people are satisfied to work within "simple" work process, even if this ends up being a pretty static activity, as long as they can pursue their personal growth in their talent domain. In fact, people that are "rationally" talented tend to do better with a simple and somewhat unemotional work culture. Yet even with a simple process and work culture, some people refuse to, or simply cannot, "play by the rules". Talented or not, that is not acceptable, and rule seven is there to reenforce this. In fact often this is the most critical activity of management, you need to stop people that are bringing others down when it happens, waiting is not an option.

Now having said all that, we can address rule three: "Never ignore your talented people".

In an ideal work world, we are all equally positively collaboratively driven, analytical, social and mature people. Yet the reality is different, and the more talented the person, the more issues he or she may have. One character pattern I have seen many times is the complementarity of analytical and social skills. Not only does talent in one of these stunt the other, but worse: talent often feeds a complementary negative character. Said simply, the more rationally talented people tend to be, the more emotionally immature they may be. Likewise, the more emotionally talented people tend to be, the more "rationally immature" they may be. The best way to deal with this is to have a healthy work process and culture. That is why all those previous rules are so important: they make good process and culture happen. Yet the question is still: given that not everyone has similar talents, what more should be done? What specific "talent oriented" action should you take as a manager?

One option is to do nothing. Or more specifically, run your normal process, and if your talents are not happy, well... tough luck for them! 

This option of "do nothing special about your talented people" is a real option. You may be within a domain and business where you are getting enough talent that you do not want do anything more than just to run your company efficiently. Still, you do need to be extra careful that your bring in the right talent for each specific job. That brings us to rule eight:

On hiring, make sure the talent matches the job;
Later, make sure the job matches the talent.

You might be thinking I am saying: "make sure that the skill set matches up with the job. Yet that is not the case! In fact that brings us to a major trickiness: Talent and skill set is not the same thing!

Making sense of talent

In order to stay on safe grounds, I make use of the the dictionary, which states that the definition of talent is "natural aptitude or skill". The dictionary is saying that talent is "natural" while by default "skill" is learned. What the dictionary is trying to express is the "special" property, which I have already talked about, and which is the fact that the talented person is developing on his/her own inner construction, independently of others. But more importantly, the difference is between learning "on one's own", and being talented at it, versus learning from others. It is the key understanding that you want to pick up here.  It support everything I said above about normal management rules, it provides a "simple" explanation for the "unusual talent" syndrome, and finally it gives us a lead into how best to use talent.

The idea is that a talented person can build new skills "on their own", while the "less talented" person will need someone else from which to learn the new skills. (Obviously, this is somewhat of a reduces view of the world, but in my experience it is very useful view of how growth happens). We have eight possible scenarios:

	Talented	Less talented
Learns good things on their own	More likely	Less likely
Learns bad things on their own	More likely	Less likely
Learns good things from others	Possible	Likely
Learns bad things from others	Possible	Likely

To explain:

• Talented people are more likely to learn on their own (good or bad).
• Less talented people are less likely to learn on their own (good or bad).
• Talented people have an inner independence that may block them from learning from others. Therefore it is possible that they learn less from others.
• Less talented people have less inner independence and therefore are more likely to learn from others.

This help support the statements from above:

• Normal management  is needed to help talented people learn from others and detect situations when they are blocking this process.
• "Unusual talent" syndrome happens because talented people are likely to have learned differently on their own. This variation from the "common social standard" feels "unusual".

It also gives us another insight: talent has some similarity with volatility in finance.
And therefore managing talent has some similarities in with managing portfolios: there is really a notion of risk versus return, and a notion of steady return of value versus volatility in this return.

The science of working talent

The idea is that work is a form of investment, people get payed, and return value on this investment. (You can skip this paragraph and the next two if you do not want my "pseudoscience"). This rate of return depends on their skills, the compatibility of the skills with the needs of the project, but also varies widely, in a volatile manner, with the complexity of each project, but also also with the nature of each person. This is not pure science, but more of a qualitative effort of understanding what dependencies a manager needs to work with. The talent return and volatility model works like this:

• Skills are like a rate of return: As more skills bring back more value on investment. This is independent of talent.
• Rate of returns (skills) grow with time: Because people learn new skills and to be more productive, but usually peeks at a limit.
• Volatility on return grows with talent:  Because talented people accumulate both good and bad learning on their own.
• Less talent often means less volatile: Because less talented people learn from others and this is a filtering process that reduces uncertainty.
• Asymmetry in volatility grows with time: People that acquire good behaviors tend to grow them and same for bad behaviors. On the long term there is a trend.
• Skills are multidimensional:  Skills depend on their usage context and on the desired goal. Some skills can be composed, or used together, others not. So even though skills are similar to the rate of return of investment into a person, this rate of return is very context dependent.
• Talented people often find it easier to mix different skills together: Because their skills are often learned "on there own", and therefore have a "more compatible common base".
• The volatility of talented people may explode when meeting their limits: The reasoning is, their independent part may become unstable when no longer supported by their surrounding (social or domain specific). When talented people get lost, their independent part will frantically work alone until either it finds a "new balance" that still addresses the desired "work goals", or in the less desired equilibrium that is incompatible with work goals.

Now that we have laid out the major dependencies in talent management, we can can talk about strategy. We cannot be too complicated. For example, it would be tempting to take the above results and try to create something similar to modern portfolio optimization applied to the management of people. But that would be forgetting that we would need precise parameters of each individual, and also a precise understanding how each individual collaborates with others. That is something that we do not have. So while hedge funds exist based on many different strategies, there are usually much less different ways to manage talent. Still, the above results are telling us a few major elements of strategy that can be applied generally without the knowledge if someone is talented or not:

• When hiring worry about talent:
• Favor skills: The minimal risk approach. Ignore talent, just favors the skills you need.
• Favor precise skills: Similar to favoring skills, you favor the skills you need, but as you keep the skill set very limited you are "repelling" many talented people because they would feel "boxed in". With less talent, you reduce your risk to acquire "bad talent".
• Favor broad skills: You focus on the skills you need, but you ask for a wide enough variety of them to make the right talented person feel comfortable.
• Favor good work culture:  Good work culture is good for everyone, but here we are interested in work culture that "filters" and "aligns" your talented people. People that do not "feel right" to your culture are not hired (and often do not want to be hired).
• Favor engaged work culture: Talented people need to feed their inner independence. The easy option is for them to invest their talent elsewhere than work. The better option, is that the talent is invested into their work or into areas that are supporting their work. In academia, publications (and other forms of collaboration) are used for this purpose. In the "normal work world", blogs and open source/collaborative projects may be a way to judge someone else's "talent alignment". Yet many people do not have such public activities.  Unfortunately, it is not easy to judge where people invest their effort when no public material is available.
• Favor past success: One success may be luck, but a lot of success is a sign of skills, and most likely talent. Yet past success does not indicate that the current skills are still usable, nor that bad learning has not tainted the person, so care must be taken.
• Favor recent past success: As above but lowers the chance that the person has not acquired bad learning that would block his/her skill set and possible talent. 
• Share your long term vision: As described below, your company will need to provide a reason for the person you are considering to hire to stay. Better present enough of your vision up front to make sure the candidate is buying in to it.
• Have some social diversity (e.g. gender, age, ...): Who is going to tell your unusual talented staff that they smell bad, make annoying funny sounds, or nasty remarks? Ideally their co-workers! But for this to happen there needs to be enough social diversity, and this only happens if you hire some diversity in. The thing is, the more we are alike, the harder it is for us to chastise others. Social difference, for example man versus woman, are great enablers that help teams address social issues.
• Monitor velocity: Faithfully sizing and estimating future work and measuring progress  (velocity in Scrum), is very important, talent management or not. Yet for talents it is a way to give them a hold when they fail to succeed. On the longer term this is important as unmanaged failures may result in more "explosive" reactions in talented people, such as burnout, breakdowns, and resignations.
• Evangelize your staff with long term visions: There is often a latent insecurity in talented people. It is their independence that sometimes worries them. Best is that your company vision provides long term reassurance. In the tech industry, option plans were one way to do this. Now,  social visibility is way to "provide more" to someone. Yet both of these methods have  disadvantages, therefore ideally you want to get you talented people to "buy in" to your long term business strategy. This is one reason I recommend to have good product owners and product managers that evangelize your teams.

Example of strategies that do not work within a collaborative environment:

• Focus only on high talent: If you are a gallery owner, or a consultancy firm, your business model may work by considering talent before all else in your selection process. Yet this strategy has a high risk of bringing in lots of bad behavior, and skill mismatches, something you definitely do not want in a collaborative environment.
• Mushroom Management or "Keeping your developers in the dark and feed them fertilizer": Such an approach does not take a active approach to product management, communicating business vision, nor development culture. In effect, it does not provide the teams nor your talents with enough "elasticity" to make the right decisions. This results in bad alignment, issues "rotting", and ultimately your talents "exploding".

Some of you may feel that I have again avoided to address how to directly manage talented people, and again have focused on to "general" management process rules. That is true! In fact, it is a key observation: I am not going to tell you how to micromanage people on a people by people basis. First because so much value can be brought by ignoring micromanagement , and second because I cannot teach you to micromanage well in a single blog posting.

Hiring comes first

Now to cruise us to the end of this blog, we need to bring the elements of strategy introduced above into at least one rule. The most important element of strategy is in the hiring process. The interview process needs to bring productive people and filter out "bad talent", therefore you must first focus on skill, on culture, and filtering out bad talent, and then only in second priority on good talent. Note that when I mean culture, I mean "work culture": Someone who is "just nice", is not necessarily productive. Therefore rule nine in managing talent is:

Hire for skills, for work culture, for past success,  for some amount of social diversity, and for compatibility of vision; Filter out bad talent.

You need all these focuses to make a good hire. What is important is that you communicate well in your hiring process, you want to attract good talent, and repel bad talent, therefore do talk about your culture and your vision too.

You will note that I have already covered the other elements of strategy as part of the "normal" process above. Therefore we are almost ready to wrap up this "strategy section". I just want to bring one more rule, which is about levels of maturity. In a typical organization, you need different personal characteristics. You may need specific areas of professional skills, as you may need more generic attributes such as analytical and emotional skills, and also management and work culture skills. The thing is, the productivity of collaboration is directly related to the compatibility of the maturity level of the different people. Part of what I am saying is that we need to share the same work culture to work well together, yet work culture cannot "do away" with the difficulties that two "very different" people have in communicating. When your organization is confronted with the difficulty of communication between different types of people, you might be tempted in using your talented people fill in the gaps and make communication happen. Although this might be perceived as good use of resources, it is only a local good use, better would be to use those talented people somewhere that would be delivering new "value", not supporting the delivery of "current" value.

You may have noted that organizations tend to be split internally into groups and hierarchies by specific skill sets and maturity levels, and that these different groups and hierarchies work together with the help of cross organizational processes. This is because it is more efficient to use an "inhomogeneous" way of working, than a flat system were too many different skills and maturities are mixed within same groups. (Note that even agile processes have their separation of roles and hierarchical dependencies). Yet as organizations evolve, their structure and processes do not always follow, and one pattern I have noted is that overall company "weaknesses" due to inadequate structure and processes are resolved locally by bringing talented people in to fix "communication issues", when in fact the real issue to address is a bigger non-local one. Therefore my final rule ten is about about trying to do without talent when the more scalable and sustainable solution exist to fix your organization:

Do not use talent when good organization structure and processes can do the job.

Managing talent, a summary

Talented people may bring both value with them as well as problems. To have good talented people in your organization, you want to hire them, and you want to keep them. To make that work, your biggest priority is to organize your company well, run good processes, encourage good culture, and stop bad behavior as soon as possible. Ideally, you want enough social diversity so that bad social behavior is quietly resolved "locally" with no need for interaction by management. Also, you have to be careful of supporting talent with talent, and you want at least one person high up in your organization that understands how talented people perceive each other. This is the concept of that a "alpha-person of talent" relations exists in your organization, but also that some form of "hierarchy of maturity" also should exist.  Finally, although you may be relying on talented people for key positions in your organization, you need to ask yourself if that is necessary, and if you would not be better off with an improved structure of organization or with better processes.

Here are the ten rules again.

1. Focus on your organization's culture and work process.
2. Ignore any dysfunctional side of talented individuals.
3. Never ignore your talented people.
4. Actively and publicly monitor "good" work process
5. Maintain clear business goals, actively evangelize your teams towards them.
6. Have a head of HR, or CEO for smaller organization, that understands talent.
7. Stop bad behavior that goes against your organization's culture and work process.
8. On hiring, make sure the talent matches the job; Later, make sure the job matches the talent.
9. Hire for skills, for work culture, for past success,  for some amount of social diversity, and for compatibility of vision; Filter out bad talent.
10. Do not use talent when good organization structure and processes can do the job.

2023 Update: Ask me about my one day workshop on innovation and talent management!

All original content copyright James Litsios, 2013.

What does the US government teach us about managing software projects?

Most of us have probably worked all night and all weekend sessions in order to finish a project "on time". And we all know that is the sign of "bad management", and can also be the sign of an impossible task. Therefore, looking back at the US government working hard a few days before the deadline to get the debt ceiling raised, can be seen as a sign that the US government is badly managed, but can also be seen as a sign that it had an something impossible to do.

You might say, a government and politicians is not the same as a software development organization. Governments are fragmented, many politicians only have a job because of these differences of opinions, politicians are continuously trying to shift blame, etc. While the goal of all members of a software development team is to finish a project on time and be successful.  Or is it?...Hmmm...  In fact, that is not always clear!

The tricky nature of people, is that if they do not feel enough belonging into a  common cause, they can very easily switch to supporting its "anti-cause". Politicians know this, and much "political noise" is the game of making sure that not everyone agrees with your oponents. A development team can suffer much damage when not everybody is just "happy" to work towards the common goal of finishing the project on time. This "bad behavior" is often subconscious, yet can also be a very conscious feeling, and even sometimes an open secret, referred to, for example, with flippant remarks. What happens is that dissension can feed upon itself and simply suck away much precious work time. The team may recover under the stress of the approaching deadline, but often that pressure simply comes in too late.

Luckily, difficulties in managing teams is not new, and good guidelines exist. The first recommendation is to use an agile process:

• The "short" duration of the each iterative step ensures an optimal common focus driven by the "stress" of the deadline. And by the way, that is how you decide how long your agile iterations should be: short for a less mature team, longer for a more mature team. 
• The independence of product management (e.g. product owner role in scrum), ensures that no dissension exists in the business goals presented to the team.
• Roles like the scrum master, help focus on value to all, above the value of individuals.

Yet the agile process does not keep dissension happening on "long term" concepts. For example, on design and architecture, or product goals. Usually, technical dissensions are more problematic than business dissensions. The question is often: "How to make sure that people work together productively on long term technical goals"?

My answer is:

Get every one to agree that common long term technical goals exist only to constrain the team; New concepts can be brought in by the team's individuals, but only within the short term "iterative" process. 

For many, the idea of only be able to bring in new concepts within a short time frame is just not acceptable. They argue: we need more time! But too much time would mean too much uncertainty, and uncertainty is an area in which dissension can strive. Another argument is that vital new concepts will never be brought in if there is no long term goal, and as a result the team may fail. This is true. But the consequence is that people need slack time: unmanaged time outside the process in which they can mature new ideas (see delivery focus versus creative slack). It is only when ideas and new concepts have matured that an attempt can be made to bring them in to a project within a solution. And the criteria of maturity is "needs to be able to deliver within the short term iterative part of your agile process".

People may still argue that a bleak constraining, almost pesimistic, long term technical vision does not provide value, is "no fun", and possibly even not worth working for! These are not unreasonable worries.  Yet these remarks are all based on experiences where short term efforts fail to provide enough value, or fail to provide enough satisfaction.They are also come out of cultures that do not understand the critical need of a "side" process in which ideas and techniques are selected, grown, and matured, until either they are rejected or they are brought into production.

US politics, like most political systems, have this concept of the parallel process that prepares material before bringing it into the short term process of getting decisions made.This is a system of influence, of key players, committees and lobbyists. It would be wrong to deny that development organization are not subject to similar games of power, yet the big difference is that a development organization should only get one source of funding (from business). While a democratic system gets multiple sources of funding with often contradicting goals.

I cannot make this posting too long, therefore to summarize:

• Run a tight development process: only bring in ideas that are mature enough to succeed withing your "short term" production cycles.
• Encourage independent new long term ideas but outside your production process: Accept that there is some political process in how your team brings in new ideas into their production effort; Make sure that new concepts are mature enough that they can be brought into production with good certainty, within the normal "short term" development cycles.
• Encourage "constraining" long term team goals within your production process: It is OK to debate as a team on longer terms plans that simplify things and restrict usage of new technology. I say this because technical entropy, the fact that things "grow more complicated with time" will kill you if you do stay united as a team to fight it.
• Make sure that your team has enough slack time: And make sure also that they have the culture to use it wisely, for the benefit of the project (and not for each developer's ego).
• Have only one external driver per development team: The same for "normal" short term development process as for the long term "creative process". This will keep the "political" debate healthy. And that is again a reason why agile processes have only one business representative per team.
• Drive software with deliverable features, business with revenue streams: It is this separation and its "double layering" within the overall development process (e.g. agile development teams versus one product management team) that keeps the political "game" sane! Technology does not generate money, only features do! (Well, within a bigger model it can, but that is why you might consider having a CTO outside the development team process).

 This brings us back to US politics: they are like a very, very, bad development team. They apply none of the "good behaviors" above. Not a very good role model for their fellow citizens!

All original content copyright James Litsios, 2013.