Welcome to WordPress. This is your first post. Edit or delete it, then start writing! Changed.
There is a lot of great articles and evidence to support the principles of agile development. It is capable of being more responsive to customer requirements and has the ability to develop better product faster. There is also evidence that agile marketing techniques can deliver better results than traditional marketing, especially when they embrace and respond to Inbound marketing techniques. However the picture is not complete. Should the whole organisation not behave in an agile fashion to maximize potential? I call this principle ‘Holistic Agile’ (HA).
Smaller companies, where everyone wears many hats, are inherently holistic. It is one of the main reasons they move faster than their larger competitors. Indeed, this is one of the major reasons they win business. Larger companies tend to have more process in place and greater resources but the smaller companies are more responsive to customer requirements, it’s because they are agile. The larger businesses try and become more responsive by putting agile in part of their business development.
However, can they be truly responsive unless the whole organisation embraces this rhythm?
At both ends of the spectrum these businesses are generally far from optimal. I believe it is because there are still disconnects in the organisations and they would benefit from a move towards a more Holistic Agile approach.
Agile methodologies allow an organisation to test and flex product ideas and generally get them to market quicker. However, the business development cycle is still more like the diagram below.
It is generally quite linear and the folks on the chain tend to wait for input from the previous before commencing or completing the task. This also promotes the ideas of silo based budgets and management lines of demarcation.
The model that I think is required should look more like this:
In this model all functional department work in parallel on the product being produced. To make this work is not simply a ‘product managers’ job to tie together the pieces of the organisation but a full organisational commitment to the process. This means you need to overhaul your complete strategy and they way you report and measure your business.
One agile technique that works very well is the idea of a slice. A slice builds a team containing front end, business layer and integration and builds a complete ‘end to end’ slice of technical functionality. This means that the executive team and the customers can engage early in process and can explore realistic scenarios. This allows for quicker flexing and direction changing if necessary. Why do we not do this across the whole business?
To make this work, the management team must put in place a structure, which accepts ‘this is the way we do things around here’. This culture would not only be exciting for the people working in the business but I think would give enormous business advantage.
The question is, how many companies are capable of doing this. The larger companies tend to be layered in the calcium of quarterly reporting and investor packs. The smaller companies too busy surviving to build in the philosophy.
My top three tips for organisations that want to try this are:
- Building a product business is everybody’s job. Do not hand off the responsibility to anyone individual, not even the CEO (who should be involved). Instead create an enthusiasm about they way in which your company attacks this task.
- Create bite size slices of business functionality. A business slice will have a measurable outcome; It will have a technical feature which has an associated marketing story. It will have a target for leads generated and prospect meetings held. In short it will have an associated ‘mini-business’ plan.
- Regular Show and Tell. Nothing paints a picture better than a demo. Make sure the CEO goes to these, it will motivate the team. A great way to tie the business strands together, make sure all parties are represented, although keep the numbers low. Do it later in the day and maybe have a Pizza afterwards.
It is very common for startup businesses to pivot (i.e. change their proposition) as their business grows. It is less common for businesses to bake in the chance of a pivot when they start.
What does youTube, Flickr and Twitter have in common?
You may know that youTube started life as a dating platform. Twitter started of life as a podcast subscription service. Flickr was originally a role playing game. All of them discovered that their original business model was not working and they ‘pivoted’ based on early feedback they had obtained. It is common for startups to flex and change their proposition in micro changes as they learn more from customer’s about the problem they need solved.
This is why an agile development approach is often better than waterfall when the problem is not fully understood. At the early stages you are not just developing software, you are testing the market. This is really the whole genus of a startup. You have a great idea and you keep evolving it alongside sales and marketing to try and find the real solution that your customers react positively too.
However, what is not so common is to communicate the likelihood of this happening with development resources from the start. There is a real danger that founder arrogance (which is absolutely necessary to get the process going at all) is so strong that the development team make architecture and design decisions that reduce overall flexibility.
I believe a pivot orientated approach should be taken. This is when the development team absolutely expect the solution will change. This means that there is time given to ‘what if’ thinking during the design stages. It also means the business owners need to keep close to the development team and keep them in the loop.
So, a good development team should architect for flexibility but it is important that the business owners keep the team close and everyone goes forward on a basis that change is good, may be essential for success and should be expected.
An obsession with the creation and maintenance of a product roadmap is one of the best ways to stop focusing on your customer. It is a meaningless exercise that adds little or no value to a product organisation.
It’s the purpose not the Destination
Years ago, when I was in my late teens, my friend and I embarked on a journey around Europe. We were hungry to learn about all the funky countries on our doorstep and had little of no knowledge of any of them. Our passion and mission was to have fun exploring.
We used a ticket called ‘Inter-rail’, which for £100, gave us unlimited travel by train all around Europe for 1 month. So off we went. Once we had arrived at a destination and had enjoyed it, we then decided where to go next. Where we went next depended upon what kind of weather we wanted, how cultured we felt, how tired we were (you could sleep on an overnight journey and not need to pay for a hotel) and what time the next train was. Depending upon those parameters we would write the destination into our ticket and board the train. The result, a deeply enjoyable journey that rewarded us with experiences for a lifetime.
We reacted on a day-by-day basis and kept true to our original mission to explore, learn and have fun. If we had planned every step day by day beforehand we would not have enjoyed or learned a fraction of what we did. We would have been anxious to keep on mission especially if unexpected delays happened (i.e. train was late). Even getting ourselves to railway stations at the right time would have obsessed us, it would have changed our dynamic. In short we would quickly have lost sight of why we were travelling at all.
I think this is analogous of what a lot of businesses do when they religiously build a product roadmap and try to stick to it (or at least pretend to).
What’s wrong with a Roadmap anyway
The problem with a product roadmap is usually due to the time it takes to develop features and the time it takes to sell them. I think most reasonable sized businesses would look to make maybe two major releases per year. However, the sales cycles will expect to close many more deals each year.
I do not think it is uncommon for development teams to be able to have a feature list, which could take over three years to develop. The result is that some features seem to be ‘always’ in the plan but never materialize into real product. This creates a cynicism throughout the business and as a result we get silos by default. What then happens is that the product manager (or whoever has this mantle) will manipulate the roadmap with justifications about why things are going to move out. They will waste valuable time producing artifacts that no one really reads and have no actual value to the business.
In any case, it is impossible for a development or marketing team to look into the void of time and space and really accurately determine what features are the one the business will need most. The further out the release goes then the quality of the business value tends to diminish. So why do we have them and is there a better way?
The traditional reasons for having roadmaps is to allow the sales and marketing teams to build sales artifacts and customer to plan upgrades. However, in reality the only assets that are really important to the sales and marketing teams are the ones that generate leads and sales. There will be a pile of others which no one really, really cares about (honest!). If the customer does contract a specific feature (or bug fix) that they must have then it is a contracted delivery and you will have to deliver it in any case. That I think is the point. The only features that need to be developed are the one that customers need in the short term, really, really need.
I know a lot of you are throwing your hand up in the air in horror. ‘A detailed roadmap is essential for any business to achieve its strategic goals’ you are saying. Now, I’m really a great believer of having a good strategy with detailed delivery objectives. However, I think what is more important than that is to keep an eye on your purpose.
Your strategic goals can and will change, but your purpose for being should not. You need to sit down and plan what you want to do, but remain flexible in execution. In world war 2, General Dwight Eisenhower was famous for saying “Plans are nothing; planning is everything”. I think everyone will agree that his purpose in WW2 was very clear but he gave himself flexibility in execution.
Also, if you consider how many clever people have created great strategies but have failed to deliver them, you should get the point. The point is that most strategic goals are static and don’t pay enough attention to the customer or the competitor.
Now I hear you say, ‘but our idea is so great it will change things’. It’s been my observation that very few companies have done this, with the notable exceptions of an Apple, Starbucks etc. These companies generally have huge resources, your company probably does not. But you can innovate like crazy and produce cool stuff that customers need. Dump the old product roadmap and re-engage with your customer.
So, why not change your organisation to one that is known to be responsive to customer requirements and your whole business is aligned to delivering these functions. There is not a roadblock from the development team saying it’s not on the roadmap therefore we can’t develop it. There is not an overly long set of fictitious marketing messages that are never actually produced. There is not a roadblock to sales in prioritising functions that will make the difference in winning a valuable piece of business.
I know that a lot of organisations will flex in any case to try and win new business (they have too). What I am suggesting here is that we move away from the traditional roadmap approach and admit and embrace that there is a better way.
There can still be a dusty old list of features that parade as a roadmap. However, it should be though of more of a menu of possible features rather than the ten commandments of your product business. The whole business moves into a more aligned mode whereby the focus returns squarely to the customer. This is done by regular communication and agreement across the functions of the business about what is coming next and why.
If the business works in this mode then it will spend less time producing overly complex gantt charts and blaming each other. It will also be a much more dynamic and fun place to work. So, what is needed is for the executive to lead the way and remind the organisation of what its purpose. No matter what your organisation does, it will have a customer, remember to put the customer first.
Having a good software architecture is really important if you want to make money. This article tries to simplify the technology into a very short, non technical article that will help non technical business leaders understand what ‘software architecture’ means’ and why it is important to the bottom line.
I was asked by a business recently what the term software architecture really meant. The company had heard a lot about it but did not understand what it was. So I gave them an ‘architecture for dummies’ kind of response and they said they thought it helped them. So, here is the anecdotal , trying not to be technical, response to the question: ‘what is software architecture ?‘
Firstly, software architecture is as important to software solutions as traditional architecture is for buildings. If you don’t architect a building correctly it will look horrible, be hard to build and may very well end up falling down. Software architecture is the same. I thought I’d explain it by walking through one classic software architecture: a layered architecture.
Programs are generally created by writing functions, i.e. “Get Customer”, “Calculate Interest” etc. The idea behind a layered architecture is you separate these functions into layers and mandate that each layer is responsible for one (and only one) major part of the overall program.
The diagram to the side is a classic layered architecture, this one has 5 main sections:
- User interface layer only presents information to user and accepts input (generally, these are web browser or mobile app based interfaces).
- Application, is the main program, i.e. “Run mortgage process”.
- Business objects are high level supporting functions, i.e. “Get customer mortgage history”. These may get re-used in multiple points in an application layer.
- Logical Data is supporting functions i.e. “Get customer addresses”, this will operate correctly no matter where data is physically stored.
- Physical is the low level stuff i.e. “Get customer address from an Oracle database”, things like SQL are normally in this layer.
The communications between the layers is usually carried out behind well defined application programming interfaces (API’s). An API is actually quite simple, is simply defines what inputs a function needs to do it’s job and what the outputs are. For example, ‘Get Customer’ may require the customer ID number and will return their address and balance on account. This means I can change code behind the API without risking the creation of unforeseen errors to all the other parts of the program that use the API.
A layered architecture mandates that you can only call into the layer below. So the UI layer could not make direct oracle calls to the physical layer but would have to go through the application layers.
“So what”, I hear you cry! Well, let’s say you were using an Oracle database but then decided it was too expensive and you wanted to move to MySQL. Well, the only layer you would have to reprogram would be the physical layer. This will reduce risk and cost. If you had not done this your developers would have to modify many layers which would increase cost and increase the chances of introducing a bug.
More importantly, as the API’s themselves may not change, you can radically change the internals of a function (sometimes called refactoring) with little risk of breaking other parts of the program stack. So you might, for example, completely change the rules for calculating a mortgage but the UI, which calls ‘Calculate mortgage’ API, might not need to change at all. This allows companies to develop more agile and maintainable code faster. It also means that new software engineers know where to look for the code that they want to change.
So, is this what most software developers do ?
The Bad News
In my experience, there have been lots of times where developers did not think enough about the architecture of their solution. They were so keen to get on with the programming that they omitted this stage. I think this is because they may have been taught to program and not engineer or sheer time pressure makes them hack up a quick solution.
In addition, the business idea behind the software is often run by non technical entrepreneur’s who just assume that best practice is being observed. Generally, if the development is not being overseen by an experienced architect, it’s not being done.
This creates real problems for the business as it is normal for the software to be changed multiple times as the business pivots. The result is a code base of ‘Spagetti code’ which is hard to maintain, is buggy and slow to respond to the market. Therefore, as a business owner, ensure you have someone architecting the solution before the programmers start hacking away.
I also reckon that it is one of the key areas you should investigate if you intend to acquire a business with custom built software. Find out how the solution was architected and who knows how to develop and debug it.
Maintenance costs and unhappy existing customers, may be the pig in a poke that you could well do without.
I was speaking to a friend the other day and they asked what is the best programming language. Of course the answer to that is, ‘it depends’, however if you are going to choose a language you should choose one that is popular. If you don’t do that, you mat find it difficult to find people who can program in that language. This is likely to make your whole venture more expensive and risky.
If you want to know the current trends, then the Tiobe Index is a good place to start :https://www.tiobe.com/tiobe-index/
As of September 2019 the most popular languages are:
In some respects, software businesses are like cars. They need periodic maintenance and checkups or they will break down !
Over the last 40 years I have worked hard to make many software businesses successful. From startup to enterprise level. Over this time I have refined a number of techniques that allow me to dig into the most common areas where a software business will begin to lose money.
There are 8 main areas that I investigate and I have now updated my diagnostic tool that I can use to give a report back to business owners on what areas of their software process might need some attention. If required, I can continue to work with the business after the MOT to drive the necessary change into the business.
The above diagram is a representative output from the process. It is not an automatic process and requires me to meet and work with your team but it is an attempt to give a metric on which business owners can respond. I think it a great tool to use if :
- You are a startup and don’t really understand the software life cycle and could do with a friend to rely on.
- You are an established business but know that you could improve your business and would like external help to galvanise your team.
- You are about to acquire a business and would like an insight into the underlying software processes and general state of health of the business.
If you would like to know more about this or book me in, please contact firstname.lastname@example.org or call +44 7808 056269.
Here are my top three great engineers’ excuses and what to do about them.
- This new technology is cool – we should use it
Your development guys will sometimes get bored with what they are doing. They will chat to their pals, watch a TV programme or discover a new technology or trend on the Internet. Before you know it, they may convince themselves that the business will fail unless in embraces this cool new technology.
Now, they may even be right, the technology may be cool and give you great advantage. I would certainly entertain a culture that allows these discussions to germinate, however you do need to get the guys to convince you as a team that this is the right thing. So, get your engineer to present to you why this will ultimately benefit the customer and to highlight any pitfalls they envisage. Also, if it’s a new development language or technique, ask how many others are using this. If it is a few, then it might be expensive to find developers to maintain the solution later.
Be prepared to reward them if the idea is good, but let them know that the responsibility to ensure this does not damage the business lies with them.
- The last guy who wrote this got it all wrong
Now, they may say something like ‘we need to re-factor this code’ or ‘I would not have done it this way’. To dis-arm this statement you need to have more than one person involved in the decision. Your product manager and team leader need to agree that this code needs to be re-factored (if the effort level is high). It needs to be balanced with the other activities the team is engaged with, therefore you need to keep your team up to date with what you are trying to achieve. Sometimes, if it’s not broken you should not try and fix it!
- I think I can improve this by adding these neat features
Engineers are perfectionists. They will keep engineering until the cows come home. Don’t let them! Unless there is a clear differentiating function for the customer you should not build it. Period! I have seen many occasions where an engineering approach has developed useless functionality that is not only not used but complicates the system on behalf of the customer.
Again, to keep control over your team remember to update them regularly about what the company is trying to achieve and how well it is doing in it’s objectives. Encourage a less is more attitude and ask your team to balance customer benefits against build cost as a matter of course.
The importance of you website cannot be underestimated. This little article pokes a bit of fun at the practices of many companies.
Whilst the subterfuge might be necessary, it really pissed Dave off. He had changed trains twice and had made sure he left his mobile phone at home. Not having his mobile with him was enough to make him shiver. But here he was at last. He looked across the café and there was Terrance, eyebrows raised and a smug smile on his face. Dave walked over.
‘What have you got for me today? ‘ said Dave. He sat down and flicked open his laptop.
Terrance smiled and began ‘Today, my friend, I’m going to tell you about the Internet and in particular how the Spikes use it to control global commerce.’
Dave looked up, nodded then created a new document. ‘OK, lets go.’
Terrance began, ‘Have you ever wondered why so many companies go bust.’
‘Did you know that 50% of all businesses fail in the first two years ? Now, technically the reason why most fail is of course because they run out of money. But the Spikes certainly help these failures along and one of the main ways they help them fail is via their websites.’
‘How so?’ said Dave.
Terrance grinned, thought for a moment then began. ‘You know there are only three purposes of a website. Ecommerce, to enhance a companies’ credentials and to generate leads. Lets not worry about the first one; the Spikes already control Amazon et al. However to make the smaller guys fail they encourage really bad habits that cause the smaller companies websites to become ineffective.’
‘Have you ever heard the expression “form over function”?’ Dave nodded.
‘Have you also noticed how most websites look the same these days? Typically they look better and better every year. They are normally responsive design, simple background images, funky fonts, great pictures and easy to use. In fact they are gorgeous.’
‘So why is that a problem?’ said Dave.
‘Well it’s not a problem in itself, but the design is typically controlled by a certain part of the business. For most smaller businesses, the creative team are normally external and are motivated and driven by design. The designers will probably drive a mini cooper, design on an IMac, love Casablanca etc. In short they love good design probably more than they love the function of the site. ‘
‘Now, this is not in itself an issue, but it is a work of genius that the Spikes promote. They never discourage good design, but they make sure there is a gap between the designers motivation and the business needs. In short the messages that should be used to try and generate more leads are often lost in this gap. Even more than this they leave the impression in the mind of the CEO that the website is OK because the web team are all over it. The reality is that what the CEO knows as the businesses core strengths are often not represented on the website. ‘
‘How many websites have you visited and don’t understand what the business does. This happens all the time and results in a huge loss of lead potential for the business. Companies try hard to get people to visit their site. But, hey presto, when they do they visit they do not recognize that the company can actually help them.’
‘Sorry, I don’t understand, what do you mean? ‘ said Dave.
‘Well. Surely the purpose of most businesses is to help their customers. It must be. But, if you look at most websites they tend to speak more about the owner of the web sites rather than problems of their customers and prospects. They are self-obsessed. They will talk about all the great products they have, their companies’ offices, the brilliance of their staff and so on. It is the wrong focus. But hey, they do it in a really pretty web site!’
‘The prospect is forced to search around to see if this company can actually help them. Now this might work if the prospect was already known and directed to the website by one of the companies’ staff. But even so it would be better for the prospect if they saw their problem on the website along with how with company actually solves the problem.’
‘It’s even worse for product companies. Now most of them know that they should be selling benefit over feature. But do you know what, they do the exact opposite. There will be a list of products that the company sells along with funky names and icon’s. Products that the company is very proud of, but the visitor to the site has no idea of what benefit it would bring them.’
‘Often this is even on the home page !‘ He whispered.
‘In addition the copy is normally given by a technical resource and is copied verbatim onto the website. So the poor prospect is faced with a barrage of words like: framework, cloud, federated, big data etc. etc. They have no idea what it means for them, they are lost and typically seek the solace of a trusted brand. So, yet again the Spikes keep control and another company is on the train heading to oblivion!’ Terrance paused.
‘So there you have it. By promoting really bad messages really great products and services never see the light of day.’
Dave typed a bit then stopped. Looking directly at Terrance he asked ‘How do the Spikes control this behaviour, surely this is in the hands of the management of the company.’
‘Great question! They do it in many ways. Firstly, they create a number of operational issues for the business, like shortages of cash, performance problems etc. that put the team into firefighting mode. They then engineer changes to market conditions that affect the value of the company’s proposition. The management team reacts. But in doing so they lose sight of their strategy and forget to focus on the customer, as they are too busy surviving. The net result is that shabby web sites are allowed to flourish which permeates the problems of cash etc. It’s brilliant really.’
Dave sat back. It was true. If businesses kept a focus on their customers’ problems and offered great solutions they could change the game. But alas, unless they kept reminding themselves of this and reacting with their strategy, the situation would not change.
He sunk back into his chair and though.
If you buy the wrong thing or do the wrong thing you are wasting money.Most organizations are far from efficient and most do not even know where money is being lost.
The Ideal Machine
This article is not about the money you are wasting on travel or even the fact that you don’t switch the lights out when you leave the room. I’m sure there are loads of places your wasting money on things like that, this article is about the real money you lose when your internal processes are not optimised. I also think, that the reason why more than 96% of all software firms have fewer than 10 employees, is partially due to them not optimising or even implementing processes.
So if you are running a small company and dream of running a bigger one, read on !
My experience is that companies are generally far from optimal. In short, they waste money and squander opportunity. Many are not even aware they are doing it. So I thought I’d give my quick heads up on where I think companies have the best opportunity to reverse this loss into a profit. In the spirit of all good storytellers, I’m going to attempt to fit my observations into a metaphor for your delight and delectation.
I remember a lecture once about the ‘Ideal Machine’. For those of you who don’t remember, an Ideal Machine is a hypothetical mechanical system where energy and power are not dissipated through friction, wear or other deficiencies. I started to think, if a business were an ‘ideal machine’, where would I look to see where energy (money) was being lost. So, I took the analogy one stage further and asked myself how is energy lost in a machine. The main losses are to light, sound and heat. So I’ve decided to use these three losses as an example way of introducing loss in a software business.
I‘m going to use light as a great metaphor for vision. If your team does not understand the vision, strategy or direction of the company then they will not be optimal in their endeavors. For example: The company does not have a strategy to differentiate it from its competitors, therefore they never do. The marketing team produces the wrong set of messages, as they do not understand the strategy and objectives of the company. The wrong thing gets built; sometimes, even though people know it’s the wrong, they figure it’s not their responsibility. The development team feels dis-engaged with the business as they only have visibility of development tasks therefore great ideas are never captured.
I think this is a great metaphor for the loss of energy that happens when a company does not internally communicate well enough. Members of the team feel dis-engaged, as they are ‘mushroom managed’ and don’t feel included in the companies’ vision. The development team builds features that are not relevant to the target market. The executive makes incorrect strategy decisions as their view of the market is flawed, even though the sales and marketing team could have told them otherwise. Sales team fails to win a deal because it does not understand that a current benefit exists or cannot get effective input from marketing and development on a sensitive bid.
Departmental targets reduce trust between departments and encourage personal protection over company benefit. The net results are that folks don’t mention things that they know to be wrong.
Internal friction or politics generate useless noise that reduces the benefits a company can produce. Good examples of this are: Department work in Silos’ with little concern for their colleague success. A lack of trust builds up and teams tend to work in isolation. Hidden features in the product are not converted to benefit statements because the marketing team did not know they existed or where planned. The wrong features are development because of an overwhelming and uncontrolled demand from the sales team. No one cares about what is being built and staff attrition rises. The business is not somewhere people want to be. It’s just not any fun.
OK, I’m going to stop the metaphor now. The point I’m trying to make is that an effective and efficient company is one where all the parts join up properly. It is an inclusive environment, which understands that the people on the top of an organization need to be connected to the people at the bottom. Even more it understands that one of the most expensive and effective parts of any business is the people who work there. However, little attempt is made to connect the business and as a result opportunities (and key staff) are lost.
What can be done
The most important part of any business is to identify a product or service that adds value to their customers and differentiates it from its competitors. However it is really common that strategy does not include either of these parties in their definition. Incidentally, by strategy I am not talking about vision or mission statements but more about what the underlying strategy of the businesses is.
A good strategy will put blue water between you and your competitors and delight your customers. But if you don’t have one or have not communicated it to your team your chances of successful execution will be limited. So, number one thing is, determine what your strategy is. However, bear in mind that your strategy may be wrong. So test it often. If it is not working, change it. The quickest way to determine if it is wrong is to include your team and collect information from them.
The next thing is to set up an appropriate structure to ensure that necessary information is collected and distributed to your business. Be inclusive. Your team will respond well and are likely to stick around longer if they feel they are part of the journey of the company. Make your machine more efficient by tightening the connections of the various parts of your company. A loose machine will lose money!
How do I lube my joints
For me, the key objective is to get the whole team working in the same direction. They will feel better If they feel included in the direction of the business and will be more effective if they know what direction the business is heading. So a few things, some more obvious than others :
- Your working environment: Physical walls create emotional barriers. If it is possible to have an open plan-working environment, then have one. People are tribal, if you put people in a room they will become the tribe of the room ! This makes it harder to get people to communicate effectively. Have break out area’s (with free tea, coffee and maybe a wee biscuit) and meeting rooms but try not to have offices.
- Build a governance structure: Now I know all the young companies hate meetings and any kind of structure. The reason why you are so successful is that you just get on with it. I’m a big fan of this. I also know that the bigger companies tend to have too many ineffective meetings, it’s used as an excuse to seem busy. So somewhere along the line you will move from doing nothing to nothing doing. Be honest with yourself and re-evaluate what is working and what is not. But test yourself to see if you have enough structure in place to keep the business informed and aligned to your purpose. It’s a constant struggle but a necessary one. However, of all things please ask yourself if you are being totally re-active or if you have an end goal in mind and are truly trying to reach it. If not, you need urgently to set yourself a new target. If you do reach your target, then also be aware of the ‘now we have arrived syndrome’, that’s the one where you settle back into your own comfort zone and stop testing yourself and growing. Again, in this situation, work out where you are going next and re-communicate.
- Have a strategy: If you have not sat down and worked out your strategy and how you are going to achieve it, do it now. By the way, a mission statement is not a strategy. A strategy will understand how you are going to attract customers and how you will differentiate between competitors. Saying something like “being best in the world” on it’s own is meaningless. Once you have agreed the strategy make sure the objectives to achieve this are known and communicated. Also make sure they are kept front of mind and current, often they will be lost to operational issues. A good way of doing this is with a balanced scorecard (see Kaplan and Norris, Harvard Business Review 1992).
- Revisit your strategy: Guess what, you might have chosen the wrong strategy. If it is not panning out, then change it. You will have a better chance of knowing if is not working by looking into the future as well as the past. Are your original concepts still valid, has the world changed? The best way to know this is to listen to your own people and what they are hearing from the field, don’t cut them out. This means you will need to invest time to work out what communications strategy and governance works for your organisation. No matter what you are doing you need to keep internal comms alive.
- Walk about a bit: If you are in a management position you should walk around your company a bit. Do it regularly so folks are not shocked. Talk to people in an informal way, tell them stuff if you are given the opportunity. Use your emotional intelligence sensors and try to pick up the vibe. How your team feels will have a direct result on how your customers are being treated.
- Try to keep the secrets to a minimum: It’s often the case that managers think people are not in a ‘need to know’ situation. As a result they keep secrets, particularly to do with the performance of the company. I believe this is a mistake. If things are not looking good then your team are the people who need to fix them. Not telling them won’t help. If things are good then it’s probably because of them. Keep them informed, the decisions they make are guided by the data they have.
- Communicate all the time: You need to work out your meetings schedules etc., and you need to have good and optimal meetings but make sure you over communicate.
- Thank you all the time: Great performance is a great chance to give a public thank you to an employee. Not only will this raise the morale of the employee and their team, it gives a great opportunity to re-enforce why what they did was good. This re-enforcement will probably have an affect on the customer and your strategy; so don’t waste the chance to praise where possible. It is also a great way of helping to keep those great guys working in your company.
If you focus on tightening up the gaps between your departments then I think you are well on the way to optimising your performance. I think that the reason behind most inefficiency in a business can be identified as an issue of communication. The issues of communication should be smaller for smaller companies but if you are being successful be aware that these issues lie just around the corner. It is one of the main failings of a company going from ad-hoc to needing to delegate, they assume folks will just get it. They won’t and you will have to work at it. So, my friends, get out there and start talking !
The roadblock’s will be there as you grow, but if you expect them you can remove them very quickly.