Working with heavy documentation requirements


In a previous entry, we looked at how to work with minimum specifications. Unfortunately, in practice, this is not always possible.

Let’s suppose you have won a contract to build software to manage medical records. The software would be used by the government to collate records and process relevant statistics. How satisfied do you think the taxpayers’ representatives would be with some minimal documentation and criterion for “it works”?

While even in this cases unnecessarily long form documentation is still useless, I have come to accept it’s also part of the constraints you must live with in order to practice software development.

All is not lost, in this entry, we will be looking at how to build software when heavy documentation is a must-have.

Consider documentation as a story in the backlog

For teams still struggling to adopt a technical practice such as unit testing, the advise I give is simply put it in your backlog and then have an acceptance test for it. This practice will hopefully nudge the team to using it consistently.

In the same way, it helps to acknowledge that documentation is work, thus have it as an item in your backlog. Not only will you be tickled to remember it, it also makes the cost of writing the documentation clear to everyone.

Use continuous integration tools

One of the riskiest parts of your application is in its deployment. Thus the running jokes on the idiot who chose to deploy the update on Friday 5 pm have in effect committed the team to work the entire weekend. Organizations have evolved documentation to help derisk this activity as much as possible. This includes documentation on how to stage, set up environments and deploy the application.

Thankfully, a lot of this work can be automated away by using CI/CD tools. By carefully setting up your environment so that not only is it replicable but a bot can do it for you, then you eliminate the need for documentation related to it.

Even if you are not familiar with CI as a technical practice, I would still encourage you to consider adopting a Platform as a Service Tool such as the ones provided by Google Cloud or Heroku. It will cost you more but the savings in development time and headache will be worth it.

Insist on requirements as a point of discussion

Unless you are reading for leisure, any other kind of reading is hard work. Furthermore, most books out there are just not worth reading. Now, if authors whose primary work is to produce reading material are not doing a very good job of it, what about developers who don’t consider themselves authors?

It’s then better to remind yourself and the organization you work with the point of documentation is to enable discussion between the various stakeholders not necessarily to get a comprehensive view of the workings of this system.

This slight change in wording means whoever is writing the documentation writes it with a particular person in mind and keeps it short enough to support a discussion without getting bogged down in details.

Work to understand the goals of the documentation

Rather than viewing documentation as another drudgery you have to go through, try to inquire why the organization cares so much about having such heavy documentation.

Sometimes, it may be an auditor who insists on a certain quality level. In such situations, having a one on one discussion with them would help you understand what their goals and for your team to work on how to meet the goals in an agile manner.

Follow your own process

Scrum and agile in general works but just like any other process, if you don’t abide by its principles, the results may vary. Thus in your quest to reduce unnecessary documentation load, ensure you are delivering working software, talking with stakeholders, in general, being a good scrum team.

In this way, over time, you will be able to make the case just because your process is remarkably different, you are still able to achieve the goals of the organization.

How have you worked with heavy documentation requirements in the past? Talk to me in the comment section below or on my twitter @jchex



A case for simpler project management tools


Today, there is a tool for everything. Furthermore, they are becoming, even more, fun and sophisticated. For a software engineer, this is very good news, after all, whatever you can automate should be automated. As software engineers, we are in the business of reducing as much manual work as possible.

Yet, I would argue for human relationships, more automation is not necessarily a good thing.

Project management tools come in various levels of sophistication. As an example, JIRA would be a highly sophisticated tool, Trello would be mid-range, pen and paper is as simple as you can get.

In this entry, we will be looking at why sophistication is not always for the best.

Brevity is key

Documentation is awesome. I certainly must admit there is something I find alluring about huge academic texts. It just makes the person pouring through them seem smarter than the rest of us mere mortals. Not to mention, there is some comfort to know its all captured.

However, over the years, I have come to learn the value of big documents ends there. In practice, no one reads the manual!

By definition, more sophisticated tools capture more data. For example, if you write your requirements in Jira, the story is likely to have much more detail than the same story in Trello. Even the structure and the relationships are likely to be more complex simply because Jira can do it!

Now when using the simple tool, all the richness will likely be lost but the final requirements will be much more accessible to human beings. Even better the analysts will be forced to more clearly write their requirements and open themselves up for discussion to elucidate on the missing details. Such face to face communication should be higher priced than any document you can conjure up.

You deal with inert information

When I worked at the UXLab, our boss used to say:

Constraints are awesome!

The fertility of this concept is amazing. Every single design challenge I have ever come across seems to become much clearer when some sensible constraints are imposed on it.

Modern tools fight this concept by appealing to an even more powerful mental feature, loss aversion. Loss aversion is the idea that we respond more strongly to losses than to gains. In this context then, faced with the possibility of either having all our old data which we can’t find meaning for or a clean slate to work with, we almost always chose the option in which nothing gets lost.

Inert information consists of facts about the state of the world which are no longer discernible. Think about the todo captured in a meeting three months ago of which today you have no idea what to make of it.

Simpler tools force you to think through this problem. For example, if your release board is literally a physical board with sticky notes, then as development continues, you must renegotiate what you wrote there purging out what is no longer needed. However, if you have a super-powered tool that can handle it all, then you are more likely to leave the stories which as a team you decided will not be executed for one reason or another.

Encourage everyone to participate

No one wants to look like an idiot. A sufficiently complex tool is likely to make anyone feel as such. The project manager probably has gotten past this through experience with the tool. Unfortunately, the rest of the team has not, especially for tools with a steep learning curve.

In a complex project such as software development, you want as much mental horsepower as is available to you actively contributing. A simple tool enables everyone not only to verbalize their ideas but also directly put them on the tool, thus building a sense of ownership.

Specialist tools can generate beautiful reports but will remain the purview of business analysts with little relation to the people who are actually building the product.

Resistance to change

Deep in our culture lies the doctrine:

More work = More virtue = More value

This doctrine skews us to value what we have put much effort into even when everything else in our environment is screaming at us how useless it is.

Don’t fool yourself, no one is immune it, whatever you have worked hard for, you will also work hard to protect.

Simple tools help mitigate the problem before it even becomes a problem. By its very definition, simple tools are easy to use and the artefacts generated thereof can as easily be recreated as they can be disposed of. This feature enables you to be more nimble with your tool and change it to reflect reality when its warranted without the extra burden of feeling you are destroying “work”.

Which tool do you use to manage your own projects? Talk to me in the comment section below or on my twitter @jchex



Common biases to look for when running a tech interview

Walking into an interview, you are almost always self-absorbed. You imagine the people on the other side of the table have all the power and somehow are looking at you to see if they can grant you some kind of favour.

This is never true, speaking from the other side of the table, its tough. You are not running this interview because you had nothing else to do with your time. Chances are you need someone to work on your project yesterday.

Furthermore, it’s fairly easy to gauge if the company will be a good fit for you, services like Glassdoor offer a window into the company culture. From a hiring perspective, most of the time a CV and linked in profile is all you have to go with.

In this situations, recruiters tend to substitute the hard problem of determining if a candidate is a fit with other easier to answer questions.

Of the many assumptions, in this entry, we shall be exploring the most common.

How well does the candidate do on aptitude tests?

Aptitude tests are by now an industry standard. They are the modern version of the IQ test.

To be fair, high IQ is a major predictor of success later on in life. Individuals with high scores tend to more easily grasp new concepts and apply them in practice. My argument then is not against IQ tests but against using them as the sole measure of capacity.

You see eventually it gets hard. Sure natural talent will help you breeze through the basics of the language and the framework, but no amount of it will make your first true mess up any easier.

In the office, we were discussing the intricacies of software development and whether it really is a high IQ sport as its touted. We concluded it wasn’t, 90% of the time, the work is processing simple inputs from the user and triggering the right events. As Thierry Schellenbach from Stream puts it

For many applications, the programming language is simply the glue between the app and the database

Then perhaps you should not be as worried about how high the IQ of the candidate is but how well they are able to understand and interpret your client’s needs.

Do I like this person?

Usually, this question is masked as “Are they a culture fit?”. Formally known as the Halo effect, we naturally drift to individuals we like.

Now, the good engineers I have met care a lot about their craft, not so much how symmetric their face is. By being ignorant of the fact you are actively biased towards likeable people, you may lose out on great talent.

This is where stereotyping happens. Take the unspoken case of ageism, it is far harder to be trusted as a developer once you hit the 40s. Somehow, coding has been taken as something only young people do. Thus when a middle-aged person walks into the interview room, your mind starts looking for signs something is terribly wrong with them.

For those who imagine they are somehow immune from this effect, think again, no one is. The bias is hardwired into your brain, you must then design your recruitment process to remove the bias.

How many twitter followers does the candidate have?

Sounds kind of stupid when read aloud doesn’t it? Yet this seems to be routine in a recruitment exercise. So much so almost all CVs I now see have a link to the candidate twitter profile.

I honestly have no idea why this happens, my best guess is a big followership implies others have also validated the talent and so you follow suit.

A friend of mine actively filters out candidates with an average of more than ten tweets per day. He reasons anyone who can afford to sink that much time into Twitter is not likely to be working on whatever they are actually paid to do. I don’t actively support this position but I think its worth some consideration.

What is their presence online?

Building a personal brand is very important, you should try to at least have content you control on the first page of the search results for your name.

This doesn’t mean you dismiss individuals who are not as adroit in the art of personal promotion. Maybe they just don’t like writing about themselves.

Open source software is great, but it’s not a requirement for you to contribute before you earn your stripes as a software engineer.

Have you ever experienced any of the issues mentioned above? Talk to me in the comment section below or on my twitter @jchex



A case against detailed plans


While for now am not as active in the software consulting game. I have been there enough to come across the perils of overrefined plans. This issue primarily has come up as an artefact of how most westernized countries do work, through contracts.

A contract is a binding agreement between two or more persons or parties; especially :one legally enforceable

Now contracts and especially written ones are great, they have certainly played a key role in the formation of the economy as we know it. Yet their traditional use as loss prevention tools doesn’t auger very well with what we now know about software development.

What you find is the client what everything to be developed in written form and in great detail at while at it.

This is a bad idea. In this entry, let’s look at why detailed contract and detailed plans, in general, are a bad idea.

The future will likely turn out differently.

The art of predicting the future has a long and time honoured tradition of being dead wrong. Matt Nauvak has an extensive library of predictions made in the past and how they turned out.

The problem is when we think about the future, we simply imagine what we know today but in an exaggerated format. For example, the client imagines the application will have to handle thousands of query requests from sales managers who are looking to better understand their customers. This feature may be based on another plan to capture user activity within the application.

All this is well and good until we realize nobody wants to login to use the application and we now need to pivot! So there is no data to be showed on the beautiful dashboards to be used by the salespeople. Some time wasted, but still all good, the real problem comes six months later when the client once more wants their dashboard. You remind them you had a meeting and decided to pivot, they, of course, proceed to remind you meeting notes are not binding, contracts are!

I thus urge you, no matter how certain you feel about the project, bake within the agreement the provision things will change.

Decisions should be made at the last responsible moment

My personality registers as INTJ. One of our key strengths is the ability to make decisions quickly, as you already guessed it, this is also a weakness.

Plans are great because you are able to constrain the range of possible options and get everyone focused on one path. Swahili’s have a saying:

Kuishi kwingi kuona mengi

Roughly translated:

To live a long time is to see a lot of things.

This rings true in software. As your product unfolds more information comes to the foreground as assumptions get tested in the crucible of reality.

It would be terrible to ignore your insights because the plan you made one year ago is in contradiction to them.

Plans fail in highly dynamic environment

Homogeneity is great for some types of work. This tends to happen in routine types of businesses. To give an example, imagine the work of building an estate with fifty apartments all of the same design. There will likely be some surprises in the first few houses, but after that, you can make fairly detailed plans to take the remaining houses to completion.

Now imagine a software project, even if you were CTO at a successful startup say Stripe, if you then started your own business say Airbnb, you would still be encountering surprises every day. In fact, even if you stayed at Stripe, new technology say bitcoin, would still keep presenting new and surprising information.

Fighter pilots have a term I particularly like. OODA

Observe Orient Decide Act

The world changes, OODA loop makes sure we don’t stay stuck with our plans which are now irrelevant.

Avoid the trap of elegance

A common misconception is we love our children and that is why we give up so much for them. In reality, we actually love them because of all we have given up for them. Think about the concept of sunk cost fallacy.

Sunk cost fallacy: The idea that a company or organization is more likely to continue with a project if they have already invested a lot of money, time, or effort in it, even when continuing is not the best thing to do

Now, if you have ever been to a proper planning session, you know they can take entire days if not weeks. Once you have put in that kind of time, you generally don’t want to see it all go to waste. Your mind will play all kinds of tricks on you to ensure you stick to it.

Elegance is great, but as Reid Hoffman says:

If you are not embarrassed by the first version of your product, you’ve launched too late.

This is also true of plans if you put too much effort into your plans, its value is now lost.

Look through your own plans? Are any of them excessively detailed?  Talk to me in the comment section below or on my twitter @jchex




The DNA of Agile practices



Some years back, Martin Fowler and Alistar Cockburn adapted the concept of ShuHaRi from Japanese martial arts.

At its core, it’s simply a way to think about learning.

The idea is that a person passes through three stages of gaining knowledge:

  • Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
  • Ha: At this point, the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
  • Ri: Now the student isn’t learning from other people but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

From this lens, you realize the sacred cows of your own agile practice can be criticized.

Is it really necessary to have a daily standup meeting which is physical every day?

Does your Kanban board really need to have all those lanes?

Must all pairs share a keyboard in your XP practice?

In this entry, we will look past the individual features of the specific agile methods and look more broadly at what unites them, what is their DNA?

Frequent delivery

The idea that final products should well, be final is a pervasive one. It’s one thing to read all about the benefits of iteration and quite another to have your boss or client scream at you for presenting a half-baked product.

Thus we build generous timelines to protect us, to allow to do all the work needed to ensure we present the product that is just right. We know when it’s not. There will be hell to pay.

Agile adopts a more evolutionary mindset, it advocates you ship what works, for now, gain feedback and improve on the product.

This is why Scrum, for example, insists on two-week sprints. There is nothing magical about the number, its simply meant to convey you are supposed to ship something, perfection be damned what we need is working software.


You may have noticed this, the speed by which a project is executed is closely related to how well everyone understands what is to be achieved.

Simon Sinek explains the concept quite well.

If you did manage to forgive the audio quality, you got the vibe, people respond to alignment.

You see communication, especially in software development, goes much deeper than sending and receiving of signals. It took me long enough to realize you can be in a meeting speaking where everyone else is only there physically appearing to be listening to you but lost in their own world.

To properly communicate, you must be able to externalize your mental model and have the other person internalize it. This, in my opinion, is best done when you work together on a physical media, say a whiteboard or a shared doc to express what you perceive. This back and forth helps expose any incoherence in your understanding of the situation.



Thus boards and other interactive information radiators in Kanban help the teams build a shared mental model of the work to be done.

Continuous improvement

The primary school I attended had an interesting motto:

Better your best

It has taken me all this time to finally appreciate what it means.

Continuous improvement is the idea there is always something you can improve. It doesn’t matter if you are a beginner or have thirty years of experience.

Integrating this philosophy into your mindset has two advantages.

First, you never settle, your product is always going to be improving. This is in line with the more general truth of impermanence, no matter how fit the product is to its market today, the market will change tomorrow. Thus you must continue to adapt.

Second, you get the validation to ship your product imperfections and all. After all, there will be a chance to improve on it later.

In agile practices, this principle shows up in retrospectives, where the team stands back at the end of an iteration and reviews its work searching for clues on what they could have done better.

If you learn nothing else about agile, learn this three principles.

What do you think is the unifying theme of agile practices?  Talk to me in the comment section below or on my twitter @jchex



Striving for team balance



Recently, I have switched over from leading the software and design team at iHub to a new role at Twiga foods.

Just like iHub, Twiga has a great development team which I am proud to be a part of.

The big difference is that the organization is rapidly growing. In this environment, it has become critical to once more ponder the question, “What makes for a well-composed software team?”.

In this entry, we are going to go through some of my thoughts on what to consider when you have to rapidly scale your team.

Is there a right balance of junior and senior engineers?

I can’t tell you how many CTOs I have met who brag of an all-senior team. Don’t get me wrong, a senior team works much faster, gets higher quality work done. But when everyone is a senior, who is going to do the plumbing work?

Plumbing work is the necessary rote work in development. An example would be building out an email notification feature. Getting it right is simple in principle but time-consuming in practice. This kind of work would bore a senior engineer but present an exciting learning opportunity for someone greener in the field.

Junior engineers also tend to be a bit more amenable and thus more likely to fully buy into your vision.

With that said, you really don’t want a team skewed too much on the junior side. Their lack of experience means they will not see architectural land mines guaranteed to come back to bite you.

A ratio of 4 senior to 1 junior should work fairly well.

Is there someone with domain knowledge?

On paper, I learnt to drive from a driving school, in truth, I actually learnt from my uncle. One of the things he used to say was

You can only be a great driver of your own car, on the others you are at best mediocre

This statement might seem ridiculous, I mean, aren’t the control’s standard for all vehicles?

Yes, they are. But what about the time the car takes to break? Or accelerate? How has performance been fairing since the last service? In reality, you gain some knowledge of the performance of your car, something like its personality over time.

In the same way, a developer who has worked in the banking industry has some knowledge that a developer who has worked in Agri-tech just doesn’t and vice versa. You thus want in your team at least one person who has some tacit knowledge of how your industry works.

Does there exist a level of cognitive diversity?

In the current heydey of gender diversity, it’s easy to think that is all that matters. There is an even greater consideration, how do your people think through problems?

In a homogenous team, everyone comes to the same conclusion all the time. This is great for speed but it also means you lose out on creative ideas which would have possibly been a better fit for the problem at hand.

You also don’t want a team so diverse, no decisions can ever be fully agreed on. In this kinds of situations, all the energy is spent thrashing ideas which would have been better placed executing on any one of them.

Is the team cross-functional?

The most obvious question in agile, yet still worth mentioning. From a corporate level, functional teams are more legible than cross-functional ones. This means there will always be pressure to split up the team to functional roles.

Even developers do this to themselves, why do so many profiles have the tagline “PHP Developer” or “Angular Developer”? It’s because it’s so much easier to define yourself and your team by what you do rather than by what you produce.

Fight this tendency, focus on your outputs, you can better build a team that carries all the skills necessary to get the job done.

Do you have any advice for me as I embrace on this journey? Talk to me in the comment section below or on my twitter @jchex



The problem with big teams



If two are better than one, a small team is better than two then a big team is definitely better than a small one. No?

Intuitively it seems that the more people you have, the better.

For a software team, this is just not true and not because they are mostly introverts.

In the entry, what to consider when growing a software team, I hinted you should consider limiting your team size.

In this entry, I define a big team as one having more than 10 members. These kinds of teams come with their own set of challenges.

Communication over head

Have you ever tried to organize an unscheduled all hands meeting?

Getting schedules to match is almost impossible even with oversight into what is going on in the entire organization.

Now imagine an individual developer trying to get her blockers worked on in a 10+ person team!

What ends up happening is she spends most her time communicating with other people trying to get work done instead of you know, getting the actual work done!

This is not the perfect picture of effectiveness.

Individual effort lags

Maybe it’s because people feel less attached to others in big teams I am not sure. What is certain is less work gets done per person in teams.

It is natural to assume that someone else will do the work. In small teams, this assumption comes into sharp contrast. If you are not doing the work then who is?

Sluggish behaviour is likely to be more quickly noticed by the rest of the team.

As the Poppendiecks say:

Peer pressure is far more effective than the concept of a boss and much more powerful

In big teams, no one has the cranial capacity to keep up with what everyone else is doing so they just assume they are slacking off and do the same themselves.

Collective ownership goes down the drain

Just as there is individual skill, I believe there are also team skills which need to be nurtured.

When teams are large, the production line becomes the most effective way to organize work.

This is fine if your work can be broken down into small sub tasks which can be easily tested for completion.

Software projects are the antithesis of such work. To be successful it’s critical that all team members have a shared mental model of the product they are building and have a clear understanding of its value to the customer.

The negative effects of hand over will get to you before any Taylorian benefits flow.

There is no direct line between team and individual success

We are all the centre of our own universe. If I have pulled off several all nighters on a project (I don’t recommend this) then I want to see myself acknowledged when the product is launched or another similar success event happens.

If my individual effort will never be recognised anyway, then why bother putting in more effort than is expected?

In small teams, what each individual did can be clearly seen in the work output. This makes the work personal and meaningful with the effect that everyone is now more committed to it.

How big are the teams in your own organization? Talk to me in the comment section below or on my twitter @jchex



How to achieve consistent estimates



At the iHub, we work on multiple projects with multiple teams sometimes all at once. The process of software estimation is perilous at best even when there is only one team working on it.

Our situation is even more complex with individual developers serving in multiple teams and sometimes in a team of one!

Getting to consistent estimates across this various scenarios is not easy. In this entry, I will share some of the tips we have found to work in the past.

Find a common denominator

Estimates usually come in two flavours, days or story points. Ideally, estimates should always be in story points from which you derive days of work.

Unfortunately for most people, story points are just not intuitive. This means they make a great tool for establishing the work to be done but not a particularly great one for communicating the same.

Thus to establish consistency in communication, all our estimates are communicated in ideal days.

To be sure, this has come back to bite us once or twice where the client confused ideal days with calendar days but all in all the gains in shared understanding made for a worthwhile trade-off.

Review stories from similar past projects

Hofstadter’s law states:

It always takes longer than you expect, even when you take into account Hofstadter's Law.

Obviously, this is not a physical law, but you would do well to be mindful of it.

Thankfully, well measured past projects cut through our biases and reflect on us the truth.

For example, one of the more successful projects we worked on, our initial estimate was 5 months, as an e-commerce platform we were sure we understood everything related to it. In the end, it took 8 months from the first commit to a fundable version.

In current projects, we keep this hard lesson in mind as we think of the estimates we provide to clients. Particularly if a client wants a similar application, we now know how long it takes to get it done.

By having such a repository of past projects and the time it took to complete it, disparate teams can base their estimates on them and come up with consistent results.

Estimate some stories together

I expect developers to be very good at writing clean code that has a solid architecture with minimal coupling. I am however quite forgiving if they are not exactly masters of the black art of software estimation.

Still, the more estimators you have, the better. Groups will do wonders to the quality of the estimate.

Even if you will need the developers or individual teams to do their own estimates, it still makes sense to have a session where you work on it all together first.

How do you ensure consistent estimates in your organization? Talk to me in the comment section below or on my twitter @jchex



Fostering a culture of team learning



Recently, we were sharing our experiences with my friend. He mentioned a statement his boss used to tell him when he worked at craft silicon.

I would rather hire three average developers than one rockstar developer. Within six months they will have delivered more.

Obviously, this rings true to my team orientated mind.

Yet such delivery does not just happen automatically. In the same way, individuals need to learn, so do teams.

Anita et al describe why some teams are smarter than others

In this entry, I will be looking at what you can do to stimulate learning in your own developer teams.

Break down communication barriers

As companies grow, the amount of paper work grows as well. This is not necessarily a bad thing, it implies the organization is codifying its knowledge thereby reducing rework.

For example, if you are hiring 8 – 10 developers every month it probably makes a lot of sense to have the on boarding process in a document.

The problem comes when communication happens primarily via documents.

The key here is to challenge yourself not to create a policy every time something goes wrong. Policies are only useful when the situation reoccurs many times within the course of your business.

You maybe intimately aware of agile’s face to face communication principle, yet the allure of beautifully detailed dashboard is guaranteed to get to any manager.

Don’t get carried away, there is such a thing as, over collaboration, constant communication also disrupts creative work.

If you do manage to hit the balance between process and communication the next biggest challenge is to ensure the team is kept intact and members are learning each other’s vocabulary

Build whole team responsibility

I find it surprising some people deliberately pigeonhole themselves with meaningless titles; “PHP developer”, “Python developer” etc. Of what use is your language to the business?

Clients care about having their problems solved. This means everyone in the team is a problem solver first then whatever other titles they chose.

In this mindset, everyone owns the outcome, not just the tasks they are working on. This means if as an individual you do everything right but the project still failed, then you also failed!

The more everyone has been involved in everything the more responsibility they will feel towards its success.

Lynda Gratton puts it as:

    working with other people was never more exciting and exhilarating and when you knew deep in your heart that what you were jointly achieving was important and purposeful

Capture useful knowledge

Let’s start with some timeless advice from Seneca

It is the mind which is tranquil and free from care which can roam through all the stages of its life: the minds of the preoccupied, as if harnessed in a yoke, cannot turn round and look behind them. So their lives vanish into an abyss; and just as it is no use pouring any amount of liquid into a container without a bottom to catch and hold it, so it does not matter how much time we are given if there is nowhere for it to settle; it escapes through the cracks and holes of the mind.

Here he was referring to the people who waste their time. But I feel it equally applies to those who waste their experience.

Whenever you work on a project, there is always something new to learn. Maybe you just figured out the lighting in meeting room A does not allow for easy projection. How do you capture this knowledge? How do you ensure no one else does a client demo in that room? If you encounter a rare bug in one of your core libraries, what do you do about it?

Reconciliation is a useful concept in this regard. Whenever you are done with a sprint, a project or even a day. Consider what did you expect to happen vs what actually happened.

How do you foster team learning in your own organization?  Talk to me in the comment section below or on my twitter @jchex



Working with sceptics to new practises



There comes a time when you must introduce new practises or processes to your team.

Don’t expect it to be all smooth sailing, especially for well-established teams. They will question it. Unfortunately, it’s very easy to convince yourself that by virtue of your title you can push the practice and have it adopted whole heartedly

What you want to think of is the distinction between compliance and commitment.

Here are some of my suggestions for working with your sceptics.

Let them see the benefits

It’s bad enough you are introducing a new system for them to use it better work!

In leadership, it’s easy to assume what you know is correct and others are wrong. This dangerous assumption means you push practices that have no other value besides inflating your own ego.

If the practice is beneficial, then let the people see it. By adopting the practice, you should be able to show them via anecdotal evidence of its success and how it benefits them.

Provide training

The knowledge that is painfully obvious to you is likely foreign and unintuitive to your team.

Hanlon’s razor captures it beautifully:

Don't assume bad intentions over neglect and misunderstanding.

Training can be very useful in this respect, by running even an hour session with the team showing them how the process is done, you can make a lot of headway in getting them to adopt it.

Celebrate vocal sceptics

There is always that thorn to your flesh. The individual who is very vocal about your changes and how stupid they are.

The natural human reaction to such hostility is to close them out or attack them.

I suggest you instead keep an open mind and assume the individual is questioning the methods not you as an individual.

As such, invite them to all relevant process improvement sessions, let them air their views. Genuinely take them into consideration and address what can be addressed.

Hopefully, they can become your champions, if not, then maybe they can disagree but commit.

Have Backbone; Disagree and Commit. “Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.”

    ~ Jeff Bezos

Challenge them to do their best so that they can prove you wrong

All processes introduce a level of drag into the system, in effect what was getting done, gets done slower. The benefit usually lies in improved quality and less rework.

That’s of course if your process is a good one, there is always the chance you are wrong and unnecessarily burdening your team.

So teach the team the easiest way to shove it in your face is to do their best at this new practice and if no benefit accrues, you will be forced to reconsider.

While obviously a dangerous move, they can choose sabotage, if it works it will provide compelling evidence, enough to move them from compliance to commitment.

Show don’t tell

This is a particularly useful heuristic in many areas of life including the change in the process.

One of the great commandments of science is:

Mistrust arguments from authority

You want your team constantly engaged in a constructive disagreement with you, that’s how you get the most creative ideas out of them. If they become “yes men” your innovation capacity effectively shrinks to just one person, you.

By allowing for disagreement you then have the chance to show your new method will be of benefit to the organization of which you are all part of.

How do you introduce new practices in your own organization? Talk to me in the comment section below or on my twitter @jchex