Why Organisational Culture Comes From the Top

When you are a doer, you want people to let you do your job and to help you improve at it. You need senior people who enable you.

When you are senior or a lead, you want people to let you do your job and to help people around you. At this point, you know how to improve yourself but you need to be allowed the space to grow and move.

When you are a team, group or organisational leader, you want people to let you do your job and to enable those around you to do their jobs. You want to aid in individual and organisational growth.

If one of these points in the hierarchy doesn't want to enable others and instead focuses on themselves with little to no regard towards those around them then organisational culture changes. In my opinion, it changes for the worse.

Too many places I have worked see leaders who see their career journey and their need to climb a corporate or financial ladder as more important than the people around them. When they finally achieve the power required to drive their own careers, they declare it "every man for themselves!" and start kissing up and kicking down. Or worse, they simply neglect their teams.

I asked a recent manager in a past job if he cared about his team at all and the dysfunction that was tearing his team apart. He said to me "I don't have time to care." At that point, I reached out to my network and found myself a new job.

You shouldn't work for a manager or leader or boss who doesn't have time to care about his or her team. Nothing good comes from that.

If you look above you in an organisation and don't see anyone caring about the people who work for them then leave. If you look around you and can find no allies who will fight for your team over themselves then leave. If you don't want to enable the people you work with or aren't allowed to then leave.

I once had a manager who told me to stop enabling people because it was getting in the way of them working. He also thought bums on seats was more important than productivity which ultimately drove his subordinates to avoid his desk to take coffee and toilet breaks so he wouldn't see them. He didn't want anyone to be allowed to grow and achieve in their roles. Instead, he wanted them to clock in and clock out and show him the appropriate amount of fear inspired respect. As you can imagine, his team ended up as toxic and broken as he was.

Organisational growth comes from its leaders. So does organisational rot.

If you can respect the leaders around you then you will like your job and where you work. If you can't get near them, don't know what they represent or purely dislike their ethos then you need to go somewhere else.

Organisations can not be healed from the bottom. They are shaped and scented from the top.

This is Not a Democracy

When I see people who I consider good leaders, be they of any age, gender, height or ethnicity, I see one thing that they do very well. They make decisions quickly. Quickly does not mean recklessly. It just means that they make a decision knowing that if it isn't right then they can correct at a later time.

Too often, I see people who decide for whatever political, career or other reason that they want to be a leader without understanding the fundamental decision maker trait. They go in to every situation and in particular meetings, as if they are chairing a committee that must come to a full consensus before a decision is made.

This is one of the worst things you can do.

Of course, it is right to listen to the group and take input and feedback at all times. That is a given.

The big mistake is to ask permission to move forward at every stage in a journey. This slows things down because of two important factors: 1) You can't always get everyone to agree; and 2) People don't always want to have to make the decision for you.

The latter is important. That is one reason why people like leaders. The responsibility to deal with consequences often falls to them. Others will assist but they don't want to have to be the ones who decided that things be done. This in itself is not a bad way to be. Not everyone wants to be in control of every situation. That is why we sometimes lead and we sometimes follow.

Making every decision by committee can also mean that the "wannabe" leader loses trust because they look indecisive.

If you want to lead then just lead. People will forgive you errors if you can fix them. If you share the same goals and want the same outcomes then there is nothing bad about deciding now and apologising later.

Not every group has to function as a democracy in order to work.

How To Operate

There is a lot more to agile than a bunch of practices that people claim they have been doing for eternity and someone has just put a name to. There is a lot more to agile than doing a Scrum course over a week and getting a certificate. There is a lot more to agile than reading a few blogs, buying a bunch of books and going to a conference.

I don't believe in big A agile. There is no one methodology for software construction. There is no one method for anything in life. There are however a whole lot of practices that when used in combination with others and in the presence of a certain level of awareness of the required patterns and undesired anti-patterns, you can run a successful agile project that results in emergent quality and software that business wants.

The one thing that I am seeing over and over recently is people coming to me and saying that they are doing agile but it isn't working. They have people on the team who have done agile before. They have people on the team who are trained Scrum Masters. They have people on the team who have bought in and want to do agile. All of these good things and yet, they are failing.

I freely use the word failing without it feeling like that is a bad thing. It isn't. Failing is a way of learning and people who can step back and say that they tried something and it didn't work, are the kind of people who learn and improve.

To actually achieve a cohesive agile environment and a team that can find their peak and attain that, you need the glue that is an agile coach or iteration manager. Some people call it the scrum master but that term is so easily obtained these days that I do not think it holds much credibility.

No matter what you call that glue, they are the person who keeps the the team moving and finds the sweet spot that is the practices and level of rigour that will work for that team in the specific environment they are in.

The famous cry of "I've been doing agile forever and they just gave it a name" is so so wrong.

You can not just grab a bunch of practices and call that agile. The famous cry of "I've been doing agile forever and they just gave it a name" is so so wrong. Agile is not just a bunch of practices and terms and things to do. It is the whole process of constant reassessment, learning, rigour, retrospective analysis and self-organisation. It is something that you must experience and learn before you try it yourself and then help others.

I always refer back to the method that surgeons use to train other surgeons to do an operation.

The method is that you "see one, do one, teach one".

See One
Participate in an agile team as a team member. Seniority does not matter. You can be an expert at anything or nothing and that doesn't change the fact that you take part in the team and learn how practices work together and how to see patterns and anti-patterns that let you choose what shapes the team.

Do One
This time, you organise the agile team and help propel it. Remove blockers; Suggest practices and tools for the context and team; Measure the quantifiable parts and communicate them; and be the glue. This can be done with the support and supervision of a person who knows how to teach or coach. They can back you up.

Teach One
Be the teacher and coach others to be members of an agile team. Let them learn about their environment and adapt to a changing environment. Your job is to enable and act as lubricant for others who are learning.



If you understand that this is the process that must happen before people are fully enabled to work in an agile way then you will understand why teams without this but with the best intentions still fail.

It also explains why having an agile expert on the team can be a peaceful process that makes the whole thing feel easy. When they leave, it sometimes feels a little unstable. They shouldn't hold all the information back or be in control. A coach should enable you and let you find your way, with a safety net.

I had a project manager say to me recently "Damana, the reason why what you do looks easy, is because it is". I smiled kindly and sadly watched him eat his words later when he took over and ran the project on to rocks.

The reason an agile coach makes it look easy is because they saw one and then did one and taught one, several times.

Would you like fries with that?

One in ten.

That's how many managers I have worked with who have made me better at my job just by working for them. There were three things about them that made me a better employee...


They are direct

If they wanted something from me then they asked me clearly and explained the reasons why. That could include doing things to gain brownie points with clients; for political reasons inside an organisation; for urgency; or for winning or losing a battle that needed to be won or lost.

Most developers are not political animals. In fact, trying to make us that works the other way. We don't have the same drives as the fox in the work place. Gaining power and status doesn't attract us to the work we do. Developers who like that usually end up as managers or start calling themselves Architects. No, software engineers chose to work in this profession because creating something from nothing is what we enjoy doing. Bringing order to chaos. Finding patterns in a mess of requirements. Deconstructing an unfathomable problem domain and rebuilding it in technology.

Don't get me wrong, we aren't stupid or disconnected from the games played in the workplace. Most of us would rather be but we are aware the these dynamics exist and that no matter how illogical it is, we are affected by them. We often see them as an necessary evil that must be dealt with to get stuff out of our way so that real stuff can be achieved.

With that in mind, when the political manoeuvrings draw us in we would rather you just tell us what you need us to do to make them go away. I have had many a management type ask me what it is ok to tell the team. My answer is almost always the same: tell them the truth.

Manipulation to get us to do what you want is only going to come across as condescending and kinda stupid (on the part of the manager). We are grown ups. Be straight up with why and how and unless it's illegal or completely immoral then you will find that we are on your side and do want to help make things happen.


They remove blockers

What I do well, is build things. In my world it involves talking to a framework on top of an operating system, running on hardware in a controlled little utopia that (in the best case) helps someone do their job better or be serviced at a higher level. People talk of efficiency and cost-benefit and rapid delivery and usability. That's a lot of blah blah blah to me most of the time. I want what I produce to make a positive difference in the world. When I walk off this client site, it should be in a better state than when I arrived. Be that for the workers internally or customers and external agents. Whoever uses the system should be benefiting from the man(a) hours I put in to it.

Those hours are the hours I bill the client that add up to the how much the project costs and how long it takes. I'm a cog in a complex system of other cogs including other software developers, managers, analysts, business people, users, testers, and dozens of others who care about getting the project out the door. What I need from a manager is to not know what all the other cogs are going through, except in summary. I need to work with a person who can hear me when I identify something that is slowing my progress and use whatever means they have to remove that blocker.

The best managers I have every worked with removed those blockers systematically and efficiently. They heard the pain points we were experiencing and took them seriously. They did not pacify with promises of actions but instead did all they could to get us moving again or at least explain what was holding us up. Information will set you free. Keeping information flowing in to a team and out of it, then on to whoever else needs it or can use it to keep us moving forward is the key to being a good manager or leader of a team.

People who pacify the team and cushion the message to the client are only prolonging the moment until the truth bites and the pain bubbles up to the surface. It's just like patting someone with a dislocated shoulder on the head and saying "I know it hurts. I'll get something for that right away" and then walking in to the next room and telling the doctor that all the screaming is just the person in the other room, having a pillow fight with a bunch of teenage girls. It doesn't help anyone do their job.

Solve the problem by removing the blocker and keeping the lines of communication open.


They are part of the team

This is the controversial one. The one that I have argued with many technical leads and managers about. They say that to lead, you can not be part of the group. That leading means living outside the organism that follows you on the leash. It means appearing infallible to those above and those below.

A very respected project manager at a recent company I worked at gave me feedback at the end of a project that summed up to this: You can not lead a team and be part of that team because no one will do what you say. She was on her way to becoming a big manager in that company. Management loved her because she was one of them. Of course, she wasn't one of us. One of the consultants that went out there and did the actual work. Nobody trusted her. We all liked her and said she was very organised and did her job well but we didn't want to follow her anywhere. She knew how to be a good project manager but she was never a leader.

A leader doesn't need the authority of another person to lead a group, they need the authority of the group. I did tell her this and she scoffed at it. Interestingly enough, within a month of getting a good promotion she was out drinking with the troops and doing all she could to become one of them. Why? Because bossing someone around only gets you so far. People have to know you understand them and have their best interests at heart or they won't follow you anywhere.

The big thing a manager needs is to be part of the team. Not necessarily mates who go out boozing it up together but someone who suffers their pain and celebrates their triumphs. Someone who knows what coffees they drink or that they don't drink coffee at all. Of course they have to be organised and structured and good with clients but people always forget how important it is to be good with your team as well.


In the end, most of this can be summarised by one important skill... communication.

Tell your team what you want in a clear and direct way with the real reasons behind the request. Listen to the team about what is causing them to slow down and remove those blockers or talk to someone else who can. Get to know your team and let them get to know you. You have to spend a lot of your time with these people so they might as well know why your least favourite alcohol is tequila or that the client drives you nuts too.

Is "Tech Lead" the new "Architect"?

Five years ago, everybody seemed to want to have the word "architect" in their title. Firstly, they all needed a title and having an A in the acronym was the bomb - EA (Enterprise Architect); IA (Information Architect); and any other term with the "A" word at the end of it.

With this title came a lot of responsibility for whether the project succeeded or failed. Accepting that meant that you couldn't let others fail and take you with them. That's when in some circumstances, the iron fist came out and the right to veto a change became part of the job description. Of course, that made sense when it was your head on the chopping board.

It is commonly argued regularly that the decision making in a group should be centralised in order to make conflict resolution easier to solve. I agree with the idea that there must be away to settle disagreements between members of a team if they come to an impasse. There are many ways to do this but the fastest and most decisive is for one person to have the final word. The other way I have seen work regularly is to have the team decide through majority opinion or vote. When the group decides something for all then that is usually accepted by all.

The group decision method can go wrong if the most popular person and strongest speaker dominates. The one man final decision can also go wrong if... well, if they aren't good enough to make that call.

It is a rare project that I have worked on that is lead by one person with all the technical and high-level knowledge to make all decisions well. I have however often seen teams with a mix of people who can answer all the questions needed and pick the best option. Add to that team an external arbitrator (like a project manager) who can facilitate the decision making process and you have a much more successfully functioning team.

Software engineers are more creative lateral thinkers than they are credited with. Although the other disciplines of engineering are extremely logical, spend some time herding cats and you'll see that devs are more craftswomen (and craftsmen) than they are plodders through an already defined structured process.

With this creativity in mind, software engineers do not want to be mere typists for their architect or technical lead. They need to be allowed to create and use their skills to move the project forward. If you don't allow this, you lose all that is good about working with them. Unfortunately, this is too often the case with the tech leads I have seen since starting my career. Most of us find ways to work with these little dictators and sometimes we simply get fed up and move on to another team, another project or even another job.

Is today's title of "Tech Lead" the new, more acceptable synonym for what is now the dirty word "Architect"?

Yes, it is. Teams build software. Good tech leads and architects will guide their team, support them and remove technical blockers from their path. They won't use the word veto or force their ideas on to their intelligent peers. If they don't see their team as their peers then that's another problem altogether.

Come on tech leads, keep your title but use your powers for good and not evil.