Pages

Sunday, 2 April 2017

I think we really do need women in IT...

Back in November 2016, I went to a HumanOps meetup. Unlike the average IT Ops meetup, this one focused on the human aspects of running IT services. Speakers covered topics including the hiring process at Facebook's production engineering teams, the effects of unwritten office rules and the value of talking about your incidents.
I really enjoyed it but I noticed the high proportion of female attendants, perhaps up to 15%. In a gathering about IT, less than 1% is a more typical ratio. So what was different about this event? I asked
one of the female organisers. She wasn't sure why - she asked a colleague who suggested it might be something to do with marketing. A female attendant, who confessed she doesn't really attend IT meetups, said she came because "it just seemed interesting". I think what drew them is the same thing that drew me. I went there to learn more about the non-technical challenges of the business. Providing IT services involves technology, processes and people, but as an industry, we tend to focus on technology most of the time. So even if we succeed in our typical objectives, we still won't be as good as we can be because we're focussing on one side of the problem.

I think that an event like HumanOps shows that if we present the business of IT service management from a different perspective, it will attract a different set of people with an interest in solving those problems. So we need women not just for the sake of equality, but because there are diverse problems in IT so we need a diverse workforce.

As I write this I realise that simply hiring more women would not necessarily make things better. There is the danger of hiring a range of talent, only to shoehorn them into regime where those talents cannot be expressed, turning them into factory workers on a production line. If an organisation really wants to be the best they can be, then they will need a diverse workforce (which must include women), and they will need to re-evaluate how they look at the challenges of managing IT services.

Sunday, 5 March 2017

Better tools do not make better engineers

In these days of DevOps, we have so many tools available to us. From configuration management, to NoSQL databases to containers and orchestration. And under open source, many are available at no cost. While the tools work may solve predominately technical problems, I believe that a significant proportion of the problem in making better systems solutions, are human.

A common issue I've seen is not understanding enough about what problem needs to be solved in the first place. But there seems to be a new tool that Sometimes the problem can inadvertently become "How can we implement technology X in our business?" rather than "How can the implementation of X help this business?".

In my team we've discussed whether we should migrate from Puppet to Ansible. Some people say Puppet is slow, complicated and hard to make reliable. If the criticisms are true, then we have the opportunity to be more productive by migrating. If they are not true, then the migration will cost a lot of time only to end up in a similar place. When faced with a problem that looks like it might be solved by the implementation of a new tool, there a few key questions we should be asking ourselves.

  • Is the problem with the current technology or it's implementation?
    • Consider best practices, whether the design is appropriate for the problem faced, whether extensions to the tech (plugins, libraries, hardware) would solve the problem better.
  • Are the problems solved in a more recent version of the tool?
    • The most common issues with a tool are often known by the organisation behind it, sometimes a fix is in a more recent version or it may be on the development roadmap.
  • How would the cost of migration be offset by the benefits of the new technology?
    • Costs include the training of staff, the development of new workflows (if required) and the time it takes to develop replacement solutions
  • Is the new tool weak in places where the old tool is strong?
    • While the benefits of the successor are touted well, the things it does not do as well may be harder to find. Often such problems are not evident until the migration has started.
The weighting given the questions will change depending on your resources such as time, money, skills, and attitude but I believe they are still valid in most cases. They are not reasons not to change, but appropriate consideration will make it easier to plan for any change and ensure the benefits are realised.

There are issues with every technology but I don't think shifting every time something shiny comes along will make us better engineers. It is often in overcoming challenges that we improve our skill in engineering. Our creativity and understanding of technology are both developed when we persevere with problems. Even if we ultimately fail to solve them the way we like, we still gain by understanding more about what is required for the solution. This way, when we do need to take a technological step forward, we can be confident we're heading in the right direction.

Friday, 13 June 2014

A template for the team weekly roundup

While working in a previous position, I noticed that although the team discussed a lot, the right things were always coming up. That team supported live television services so it was important that engineers were up to date on outstanding problems, workarounds and changes. I found that even when engineers sit next to each others, there was no guarantee that they would exchange the right information that each of them needed. So I initiated a round up meeting that would occur on a Friday to solve this issue.

The focus on the weekly round up was not to review everything that happened in the week, but to determine where problems were and communicate activity to the team. Action points were captured out of the meeting and assigned later. Minutes were sent out that day. Always write some kind minutes for review meetings otherwise decisions and knowledge are lost. The meeting is limited to 30 minutes. 





Weekly Roundup Template


  • Changes: Any failed changes or changes that took longer than one hour to complete? (In that environment, most well written changes could be performed in less than an hour. Any longer and there was probably something wrong).
  • Incidents: Any repeated incidents?
  • Projects
    • What's been done this week
    • What's the next step
  • The Good - What went well
  • The Bad - What should we be doing better
  • Any Other Business - anything else people want to discuss


How this helped:
  • The team had greater awareness important activity.
  • Engineers had the opportunity to review problems as a team - engineers have differing levels of expertise and experience. Putting problems to the team enabled all strengths to be applied.
  • Better identification of problems - There are numerous occasions where engineer adopted a practice of successfully working around a problem, however it still cost a significant amount of time to do this. Specifically discussing repeated incidents helped bring underlying problems to light.
  • Improvement for team morale - It's frustrating to be firefighting much of the week only to know that next week will be the same. Being able to raise problems and track progress of solutions helped to improve morale.

Not everybody was a fan of the meeting. But I found that in those cases it reflected the engineer's approach to teamwork, rather than the meeting itself. It was especially useful to newer engineers as they learned much about things that were going on that wouldn't normally be discussed with them due to their experience. Overall, it turned out to be a very useful 30 minutes out of the week.