When you become a manager in a team that is making waves, managing differently or trying to improve the business, you’ll need to spend a significant part of your time reminding people why you’re doing what you’re doing.
In some environments, you may have to be “selling” your vision and decisions constantly. You may have to defend your position, or deter naysayers. Of course, you may all be heading swimmingly in the same direction and you don’t need to keep telling people what you’re doing and why.
The following plan is a plan I used when leading an agile transition and new way of managing. Gone were the upfront designs, the Gantt charts and the micromanagement. A new approach was needed. And this agile approach, although delivering tangible results, needed to be communicated with clarity, honesty and passion – for not everyone in the organisation understood why it worked. The same applied to our way of managing which was to focus on improving the system and to career coach our team.
Why do we need a plan?
All business departments should be communicating with each other. There is often a real lack of cooperation and dialogue between the very teams that need to talk to each other.
This results in work not flowing, a misunderstandings about priorities and confusion over who is doing what. As you start to put in place effective management you may also be “managing” in a very different way to others in the business. They may not understand or like what you’re doing, they may want to learn more, they may want to criticise and throw stones.
If agile is to succeed in your business too, it’s also important that people understand the values, principles and culture of your team and why agile works. And don’t forget, culture is nothing more than group habit – it’s what people do every day. So, in order to explain the culture of engineering and agile and anything else you’re doing – you need to be able to communicate what people do and why.
The best way to avoid misunderstanding and confusion and ridicule by others who may not appreciate an effective management style or agile approach is to be pro-active with communicating to that audience.
The goal is not to push your effective management approach or agile on others, but to head off the questions before they start. And with better and more pro-active communication it’s likely work will flow better, better relationships at the boundaries of work will flourish and people will have clarity over what they do and why.
At the heart of both good management and agile is the belief that we can be better – that we need to remove the friction that is stopping us achieving our goals. For agile to succeed you need good management. I call it “Releasing Agility” – but as you try to improve in both management and the way of working, resistance will come from all over. A communication plan can help you as you strive to explain why your way might just work.
As people join the business they will also appreciate the regular and effective communication coming from your management team. Other managers may follow suit too and the whole business lifts it’s collective consciousness – which typically leads to positive results for all.
Who owns the plan?
The plan is usually owned by your boss – the CTO? CIO? Head of Tech? etc.
It is built by all who will contribute to it from the management team and my advice is to create it for your busy boss, who will appreciate having something like this to refer to, and also appreciate not having to be the one to create it (although you could argue it should be them 🙂 )
Examples of communication
The following are all examples of what you could include in a communication plan. Remember the goal is to widen awareness of why Engineering do what they do, why you manage in the way that you do and also how to get work to flow better for the customer. It’s not to push your way of working on others. Awareness, not inflicting help.
The following is just a plan though – you still have to execute it.
For each of the following you need an owner. You need to specify a frequency and keep experimenting with what works. There are things missing from this list. There are things that may not be relevant to you.
Managers should be communicating very frequently indeed. Making it clear what the purpose is, the goals, the sprint themes, the role people play, the problems the team have and anything else that gives people clarity over what they are doing and why. Sometimes, you need to have really hard conversations with other managers to help them see that communicating with each other is valuable.
Don’t shy away from those conversations – the more teams can communicate effectively together, the better the work flows and the more chance the customer has of success.
Customer Case Meeting
Good Engineering/Development Managers know the effect their team’s decisions and work have on others. They know where their work goes and where their work comes from. They also know how their work affects the customer.
The best people to cooperate with when it comes to customer issues is the customer support team. I personally believe that Customer Support is a new form of marketing, and that customer support should sit within the Engineering/Development function.
In my experience, the majority of customer calls/enquiries are related to the product, the documentation, the design or could be easily resolved by code fixes or dev tooling. So why create barriers?
Improve communications with Customer Support by having a regular meeting to discuss customer cases, the causes of them, whether Development may be able to help with tooling & diagnostics and whether process improvements could be tightened up to stop these issues happening in the first place.
Internal Development Blog
Creating an internal Dev blog is a powerful way for your team to share ideas. Programmers, Testers, Agile Coaches and any other roles should all be welcome to post to it.
It’s a place for the team to share ideas, share new techniques and learn about other roles in the department. Raising collective consciousness is a key goal of management so that each person knows how they contribute to the business success, but also how others do too. It builds respect. It allows people to ask tricky questions of others. It allows people to get stuff out of their heads.
There is also no harm in sharing the internal Dev blog with others in the business. I’ve often found that many people were curious about how the product was built but didn’t want to ask.
Public Dev Blog
Many companies have a public facing Technology or Engineering blog where their staff are encouraged to share their thoughts, ideas, implementations and thought leadership with the outside world.
I love these and would recommend management consider encouraging their team to create one and post to it. It can be daunting blogging but it’s also a great way of attracting new talent, giving people a vehicle to share their ideas and marketing how robust your development process is.
Incident Management Communication
Incident management can sometimes be very poorly communicated within the business, for a variety of reasons. If you’re having lots of incidents then the management may not want the entire business knowing about it. Or there may be other political reasons for it such as the reality versus the weekly update report metrics 🙂
I prefer transparency. You cannot fix something that you do not understand and are not willing to accept is an issue. If the platform falls over a lot, or your releases are unstable, or customers are really unhappy you should accept this and communicate it to the business. Everyone in the business is part of the problem, and therefore part of the solution.
Ideas for improvement may come from anywhere in the business. If your performance is public within the business, then you’ll work hard to make it trend in the right way. Just be very careful about what metrics and measures you use for incidents and customer issues. And try not to set targets – targets can often drive the wrong behaviour.
Deming taught us that there are only really three ways of getting better numbers.
- Distorting the system (I see that a lot)
- Distorting the data (I see that a lot)
- Improving the system (I don’t see that very often, but is the best way of getting the right numbers)
If you have a chat tool within your business then a weekly update to the business can be very powerful. It doesn’t have to be much more than a short update about new starters, new releases, new ideas, customer feedback or anything else you think would be useful for the wider business to consume.
Remember to write it for that audience though – don’t use too much technical jargon and keep it interesting.
Internal Group Chat
Most teams already have chat channels open for their teams to use. You may have many of these such as team specific groups, role specific channels or general banter rooms.
I encourage these chat channels but I also advise caution. They can sometimes become a drain on time and effort, are not to everyone’s liking and can, sadly, become a place for people to bitch and moan about others, management and work.
Wiki / Intranet
If you don’t already have a Wiki or Intranet platform then this should be high on your agenda to get one in place. I find them pretty much essential for any Engineering Team. A good Wiki will allow people to store meetings notes, decisions and other references information. But they are also great for storing information about how to work, how to fix problems, how to overcome challenges and much more.
However, there is no substitute to going and seeing the work to learn how it is done and the wiki is only as good as the information in it. If you do create a wiki system then assign owners and make sure they spend time pruning and cleaning the data regularly.
Product Demonstrations / Show and Tell
The way I like to look at agile demonstration is that there is a metaphorical table that you own.
On that table, you are going to put a variety of frequent, easy to digest and easy to consume pieces of communication. The more you have, the harder the work is for you, but the more chance you have of communicating to your target audience. Other people can then come along and choose the piece(s) of communication that resonate.
On this table, you should consider “putting”:
A technology specific “Show and Tell” with the goal of informing other people in the Engineering team what work is going on and who is doing what. It’s a technology meeting for a technology audience. Food and drink helps this meeting go better. It’s a great team building meeting.
A companywide “Show and Tell” where the Product Owners (or proxy) demonstrate new features to the wider business. Anyone can attend, the meeting should be online and the content should be sharp, relevant and easy to consume. You may want to extend this meeting and encourage all departments to showcase what they’ve been up to.
A sprint demonstration within each Dev team open to all in the business. You may have a specific one just for your customer, but I advocate an open meeting for anyone in the business to attend. In this meeting, you demo the new work to the Product Owner and anyone else who turns up. Consider it a regular sprint demonstration but with an open attendance. If no-one turns up – what next? Could you make it more interesting? Does the format work? Ask why those you expected to turn up didn’t show. Improve.
A weekly roundup blog post or email highlighting new priorities, new releases, new insights and customer feedback. This should be for the whole business to consume so needs to be simple, easy to digest and interesting. If it’s not interesting, don’t complain if people don’t read it. It could be a video or webinar. Up to you. Don’t spam via email if you have other channels.
Release notes – a more technical output – probably straight from the build system – but essential for those who need the technical details. Every release should have release notes. If you find your audience like to know what is in each release, but don’t want technical details, then you could use user-stories to explain what has been released, or take the time to create a more digestible release note.
Bug Fixes and Customer Case report – a report for anyone interested in seeing which customer cases and bugs got fixed in the release. I would have thought this was essential for anyone supporting the customer or managing that account.
If people complain that you’re not communicating enough (which they will), or it’s not relevant (which they will), then find out how they like to consume the information and consider adding it to the table. Of course, some people will never be pro-active enough to consume anything, no matter how easy you make it – some feedback to them usually solves that.
What? Your CTO is not sharing his or her insights with the internal team? Or sharing their thoughts externally to the market, customers and potential new hires? Your CTO is not on Social Media? Or writing guest posts? Or speaking at events?
Sure, they are busy. I get that. But the role of a CTO is to inspire, to lead, to help in the recruitment effort, to sell the product or service. They are inspirational, insightful, thoughtful, demanding (in a positive way) and they are a voice piece for the technology side of the business. Right?
As a minimum, a post to the Internal Dev blog once a month builds trust and inspires.
You should be measuring how you are progressing. The measures you choose are up to you, but I like simple measures of effectiveness against purpose. These to me are; cycle time of work through the system, releases to live (and rollbacks), customers using features, revenue returned per capability, user stats from live, velocity and customer case data.
Consider creating an information radiator, report or update around your chosen measures. Put this data in the hands of the very people who can use it to improve. Talk about it, discuss it, experiment with ways to improve it. But make it visible.
And there you have some ideas on what communication topics, channels and ideas you might include in a plan. The plan doesn’t have to be more than a simple document with the above listed.
Don’t forget to include an owner and frequency. Some of these initiatives take a lot of time and effort to get going. Don’t give up too soon either. You may find you get nobody turning up, or the communication is not good. Learn from this and keep improving.
The one thing that does remain constant is that the listener does the communication. If they don’t get your message, or don’t understand what you’ve communicated then it’s your fault (mostly). They share responsibility, but they will also need help with that. The “Table” concept works. Put on it what makes sense, take away that which doesn’t work and experiment.
Good managers communicate well.
I run a fabulous Communication Workshop where we cover many ideas like the ones here. Public dates are on the site as well as pricing for bringing this course to your company.