Continuous Delivery and DevOps:A Quickstart Guide
上QQ阅读APP看书,第一时间看更新

It's all happy-clappy management waffle – isn't it?

Some of you of a technical ilk may be reading this chapter wondering who it's targeted at and thinking "Surely, this is all soft skill people management self-help waffle and doesn't really apply to me". In some respects, this is very true; any good manager or leader worth their salt should at least know how to approach this type of activity, but you have to take into account the very real fact—an ineffectual process has a greater impact on those within it than those who are perceived to be running it. Put simply, if as an engineer your effectiveness, moral, and enjoyment of your role is impacted by a process that you feel is broken and needs changing, then you have as much right and responsibility to help change it for the better as anyone else. In my experience, the best engineers are those who can examine, understand, and solve complex problems—be they technical in nature or not. In addition, who better to have on board while trying to find out the problems with a process than those directly involved in it and affected by it?

If you're a software engineer or an operations engineer, or a project manager or a build and release engineer, or a QA engineer or anyone else involved in delivering software, and you're stuck in a process that slows you down and impacts your ability to effectively do your job, then I would strongly encourage you to get involved with investigating and help to highlight the problems (there will be many and some may not be as obvious to you as you first think). Yes is can be daunting and yes if you're employed to analyze requirements or design systems or cut code or look after the infrastructure then you'll be asking yourself why you should get involved in what equates to business analysis. It's simple really; if you don't do anything then someone else might, and it may get worse.

If you're a manager or leader, then I encourage you to lead by example and get involved. More importantly, you should proactively encourage all members of your team(s) to get involved as well—even if it means taking them away from their day jobs for a relatively short period of time. As stated previously, they are the individuals who are living within the process day to day and by implication know the process very intimately—far better than you I would wager. As a leader, some team members may need your help, some may need encouragement, some may need training or coaching, some may need empowerment, and some may need all of these. In the long run, it will be worth it.

Not only should you encourage the troops to be actively involved, you should also use your influence and encourage your peer group to do the same. On the face of it, this may seem easy to achieve but it can be quite a challenge, especially where other managers start putting roadblocks in your way. The sorts of challenges you going to up against will include the following:

  • Convincing them it is a good and worthwhile thing to do
  • Getting them to agree to allow many of their team to stop doing their day jobs for a few hours so that they can participate
  • Getting them to agree to listen and to not drive the agenda
  • Getting them to be open and honest within a wider peer group
  • Ensuring that they allow subordinates to be open and honest without fear of retribution
  • Getting them to trust you

As you can imagine, you may well be involved in many different kinds of delicate conversations with many people, roles, and egos across the business. As I mentioned previously, in relation to convincing the key people to get involved, you should again consider using some simple human psychology to appeal to their better natures. It won't be easy, but the perseverance will be worth it in the long run.

Now that that's cleared up, let's move on to the fun part—exposing the elephant.