Embrace the silence

When i am silent, i have thunder hidden inside me.

Over the years in my career so far, I’ve found that in some (many) situations, my speaking style in meetings doesn’t always “work” effectively.

Some background: when I was young, I was diagnosed with dyspraxia, and had trouble forming sentences and speaking properly. I had speech therapy until the age of around 8 years old. The word “hammer” was a particular challenge for me, apparently. I don’t know why. I can say hammer really well now. Try me.

As a result of this (or maybe it’s just coincidental), I often pause before speaking, particularly when in a larger group, or in a situation where what I say really matters. It’s partly to formulate the content, the idea, the concept, but also to establish the “how” of it; i.e. how to structure the sentences, what phrasing to use, and how the statement is to be delivered.

Now, this pause is useful for everyone. It allows for a more cogent, relevant and useful discussion.

But, people seem to feel the need to fill this audible space. Whether that’s a result of a discomfort with silence, or a desire to be the one speaking and presenting their ideas instead of me, I don’t know. I suspect both, in different scenarios. I don’t really care though, as it gives me more time to build my response anyway.

I guess I could be concerned that some might interpret a pause as a weakness, as some kind of hesitation because I don’t understand the subject matter, but I choose to ignore that concern, and focus instead on being me, and how I function best.

I wonder if we should all try to pause a little more. Think about what we say, how we say it, and how we deliver it. Imagine if meetings were 30% less talk, but with 50% better quality contributions as a result.

Embrace the silence. Embrace your own, and allow others to use theirs.

The OSI model for the cloud

While I was putting together a talk for an introduction to AWS, I was considering how to structure it and thought about the “layers” of cloud technology. I realised that the more time I spend talking about “cloud” technology and how to best exploit it, manage it, develop with it and build business operations using it, the more some of our traditional terminologies and models don’t apply in the same way.

Take the OSI model, for example:

osi model

(Source: http://www.tech-faq.com/osi-model.html)

 

When we’re managing our own datacentres, servers, SANS, switches and firewalls, we need to understand this. We need to know what we’re doing at each layer, who’s responsible for physical connectivity, who manages layer three routing and control, and who has access to the upper layers. We use the terms “layer 3” to describe IP-based routing or “layer 7” to describe functions interacting at a software level, and crucially, we all know what each other means when we use these terms.

With virtualisation, we began to abstract layers 3 and above (layer 2? Maybe?) into software defined networks, but we were still in control of the underlying layers, just a little less “concerned” about them.

Now, with cloud tech such as AWS and Azure, even this doesn’t apply any longer. We have different layers of control and access, and it’s not always helpful to try to use the OSI model terms.

We pay AWS or Azure, or someone else, to manage the dull stuff – the cables, the internet connections, power, cooling, disks, redundancy, and physical security. Everything we see is abstract, virtual, and exists only as code. However, we still possess layers of control and management. We may create multiple AWS accounts to separate environments from each other, we’ll create different VPCs for different applications, multiple subnets for different functions, and instances, services, storage units and more. Then we might hand off access to these to developers and testers, to deploy and test applications.

The point is that it seems we don’t yet have a common language, similar to the OSI model, for cloud architecture. Below is a first stab at what this might be. It’s almost certainly wrong, and certainly can be improved.

Let’s start with layer 1 – the physical infrastructure. This is entirely in the hands of the cloud provider such as AWS. Much of the time, we don’t even know where this is, let alone have any visibility of what it looks like or how it works. This is analagous to layer 1 of the OSI model too, but more complex. It’s the physical machines, cabling, cooling, power and utilities present in the various datacentres used by the cloud providers.

Layer 2 is the hypervisor. The software that allows the underlying hardware to be utilised – this is the abstraction between the true hardware and the virtualised “hardware” that we see. AWS uses Xen, Azure uses a modified Hyper-V, and others use KVM. Again, we don’t have access to this layer, but a GUI or CLI layered on top. For those of us who started our IT careers managing physical machines, then adopted virtualisation, we’ll be familiar with how layer 2 allowed us to create and modify servers far quicker and easier than ever before.

Layer 3 is where we get our hands dirty. The Software Defined Data Centre(SDDC). From here, we create our cloud accounts and start building stuff. This is accessed via a web GUI, command line tools, APIs or other platforms and integrations. This is essentially a management layer, not a workload layer, in that it allows us to govern our resources, control access, manage costs, security, scale, redundancy and availability. It is here that “infrastructure as code” becomes a reality.

Layer 4. The Native Service (such as S3, Lambda, or RDS) or machine instance (such as EC2) layer. This is where we create actual workloads, store data, process information and make things happen. At this level, we could create an instance inside a VPC, set up the security groups and NACLs, and provide access to a developer or administrator via RDP, SSH, or other protocol. At this layer, humans that require access don’t need Layer 3 (SDDC) access in order to do their job. In many ways, this is the actual IaaS (Infrastructure as a Service) layer.

Layer 5. I’m not convinced this is all that different to layer 4, but it’s useful to distinguish it for the purpose of defining *who* has access. This layer is analogous to layer 7 of the OSI, that is, it’s end-user-facing, such as the front end of a web application, the interactions taking place on a mobile app, or the connectivity to IoT devices. Potentially, this is also analogous to SaaS (Software as a Service), if you consider it from the user’s perspective. Layer 5 applications exist as a function of the full stack underneath it – the physical resources in datacentres, the hypervisor, the management layer, virtual machines and services, and the code that runs on or interacts with the services.

Whether something like an OSI model for cloud becomes adopted or not, we’re beginning to transition into a new realm of terminology, and the old definitions no longer apply.

I hope you found this useful, and I’d love to hear your feedback and improvements on this model. Take a look at ISO/IEC 17788 if you’d like to read more about cloud computing terms and definitions.

Finally, if you’d like me to speak and present at your event or your business, or provide consultation and advice, please get in touch. 

tom@tomgeraghty.co.uk

@tomgeraghty

https://www.linkedin.com/in/geraghtytom/

The Three Ways

The three ways are one of the underlying principles of what some people call DevOps (and what other people call “doing stuff right”). Read on for a description of each approach, which when combined, will help you drive performance improvements, higher quality services, and reduce operational costs.

1. Systems thinking.

Systems thinking involves taking into account the entire flow of a system. This means that when you’re establishing requirements or designing improvements to a structure, process, or function, you don’t focus on a single silo, department, or element. This principle is reflected in the “Toyota way” and in the excellent book “The Goal” by Eliyahu M. Goldratt and Jeff Cox. By utilising systems thinking, you should never pass a defect downstream, or increase the speed of a non-bottleneck function. In order to properly utilise this principle, you need to seek to achieve a profound understanding of the complete system.

It is also necessary to avoid 100% utilisation of any role in a process; in fact it’s important to bring utilisation below 80% in order to keep wait times acceptable. See the graph below.

2. Amplification of feedback loops.

Any (good) process has feedback loops – loops that allow corrections to be made, improvements to be identified and implemented, and those improvements to be measured, checked and re-iterated. For example, in a busy restaurant kitchen, delivering meatballs and pasta, if the guy making the tomato sauce has added too much salt, it’ll be picked up by someone tasting the dish before it gets taken away by the waiter, but by then the dish is ruined. Maybe it should be picked up by the chef making the meatballs, before it’s added to the pasta? Maybe it should be picked up at hand-off between the two chefs? How about checking it before it even leaves the tomato sauce-guy’s station? By shortening the feedback loop, mistakes are found faster, rectified easier, and the impact on the whole system – and the product – is lower.

3. Continuous Improvement.

A culture of continual experimentation, improvement, taking risks and learning from failure will trump a culture of tradition and safety every time. It is only by mastering skills and taking ownership of mistakes that we can take those risks without incurring costly failures.

Repetition and practice is the key to mastery, and by considering every process as an evolutionary stage rather than a defined method, it is possible to continuously improve and adapt to even very dramatic change.

It is important to allocate time to improvement, which could be a function of the 20% “idle” time of resources if you’ve properly managed the utilisation of a role. Without allocating time to actually focus on improvement, inefficiencies and flaws will continue and amplify well beyond the “impact” of reducing utilisation of said resource.

By utilising the three ways as above, by introducing faults into systems to increase resilience, and by fostering a culture that rewards risk taking while owning mistakes, you’ll drive higher quality outcomes, higher performance, lower costs and lower stress!

The IT hardware lifecycle explained

In our service desk, where a device is reported as being slow, broken, malfunctioning, or for any other reason the user wishes to have it replaced, we first determine the age of the device. If the device is outside of the standard hardware lifecycle, it will be replaced, because the maintenance and TCO (Total Cost of Ownership) of devices older than the standard lifecycle is more costly than the replacement costs. If it’s within the life cycle, it will either be repaired, or we’ll evaluate if the user actually needs a more capable machine to carry out their role.

TCO vs age:

hardware total cost of ownership

 

 

 

 

 

 

 

In very general, cumulative terms, the TCO of a device increases over time. When the annual TCO exceeds the cost of a new device, it is overdue to be replaced.

TCO includes:

  • Increased support resource costs.
  • Cost of replacement components.
  • Loss of productivity of the employee using the device.
  • Added complexity from maintaining an older (less uniform) fleet.
  • Security concerns due to older devices.
  • Power usage.
  • Staff morale.

An example of a standard hardware lifecycle is:

  • Laptops – 3 years
  • Desktops – 4 years
  • Monitors – 5 years
  • Servers and network hardware – 5 years
  • Mobile phones – 2 years
  • Printers – 3 years (but using a managed service lease contract)

This is standard across the IT industry, although many science/tech firms may have dramatically shorter lifecycles due to the higher workloads that devices are expected to handle.

The above lifecycle means that we will maintain a life cycle of replacing 33% of our laptops each year, 25% of our desktops, 20% of our monitors, and so on. This is the staggered approach; some firms employ the forklift approach which means replacing (e.g) the entire laptop fleet once every three years. This impacts cash flow harder, and can be more disruptive during the change, but has the advantage of delivering a perfectly uniform fleet of hardware each time. Many contact centre-style businesses employ this approach.

The only time I’ve modified this life cycle is when the company I’ve worked for has gone through cash flow difficulties, and we’ve extended the replacement period with a “promise” to pull it back in-line when cash allows. Of course, the promise is rarely fulfilled…

Q. How do you know that you could improve as a leader?

Q. How do you know that you could improve as a leader?

A. You’re still breathing.

Check out Jenifer Richmond and  find out more about her excellent executive coaching services. I’ve been working with Jenifer for some time now, and she has helped me hugely in identifying my career goals and, through questioning and challenging, helped me to make difficult decisions and changes of direction where necessary. I really can’t recommend her enough.

 

 

10 elements of managing a successful IT team

  • Give time to your team
    • 1-1’s, development reviews, PDR’s, working together on projects, or just time for a coffee and a chat. Whatever you call it, it’s important to regularly spend time with each of the team members. Rarely, if ever, will you find that one of these sessions wasn’t worthwhile. Just don’t rush it.
  • Make sure everyone has a role.
    • Every single member of your team is important, and everyone needs to feel that their efforts are worthwhile, whether it’s setting up new servers, systems, and infrastructure, or manning the telephones and taking calls. Nobody likes to feel like the spare wheel, and it’s unproductive, but it can easily happen.
  • Take them with you.
    • Going to a conference, seminar, networking event or similar? Take one of the team with you, and prioritise the junior members. It’s a great learning experience for them, and a good bonding exercise for the both of you. You don’t need to do this every time, but depending on the size of the team, it should at least be possible to do this once a year per team member.
  • Put the team first.
    • Your team get things done. Without them, you’re nothing. Put them first, and make sure they know you’re fighting their corner. Even if it means you taking the hit for something, or to the detriment of your reputation in the business, ultimately if your team see you working hard for them, they’ll work hard for you. In the long run, this is what matters more.
  • Be a good role model
    • Demonstrate a good work / life balance. This isn’t easy, and particularly in IT, where the servers don’t sleep just because you do, but if you can show that you work when you need to, and relax when you can by making the most of your free time, it’ll set an example that will help prevent burn-out and make for a more productive, enjoyable work environment.
    • Don’t be late. Set standards that the rest of the team can abide by. Get to work on time, be prompt for meetings. Don’t be a “Do as I say, not as I do” boss.
    • Be tidy. If you want your team to keep a tidy workspace, it’s going to be a lot easier if you set a good example.
    • Put in the extra hours when you need to, but make sure you take those holidays that you earn. Don’t make your team feel guilty if they ask for time off.
    • Customer service – put the customer first. In internal IT departments, the customer is the end-user, and the old stereotype of IT helpdesk staff disliking end users still holds true in many cases. Make sure your team know that while half of their job is technical, in some ways the most important half is good old customer service. Set an example by providing excellent service to your customers.
    • Respect your colleagues – set a good example by not complaining about your colleagues in the business. Even if you’ve been terribly disappointed or let down by one of your peers, don’t pass that down to your team. It’s demotivating for them to hear, and can damage relationships between departments and teams. Be open, but not negative.
    • Enjoy your job and be positive! If you don’t enjoy what you do, it’ll be clear to your team, but if you enjoy what you do, that positivity will spread.
  • Ask for feedback
    • Don’t be afraid to ask for feedback from your team. This can be intimidating, especially in person, but it’s absolutely invaluable. Asking “is there anything I could be doing that I’m currently not doing?” or “What could I be doing better?” will provide you with superb information to help you develop and improve as a manager, and help to identify any issues that could be hindering the team’s productivity. If the answer to both of these questions is “nothing”, then well done – however make sure you ask it regularly and phrase it differently each time to tease out any issues.
  • Keep up to date.
    • Ask for regular updates on performance, tasks, challenges, difficulties and successes. Whether you do this via email, phone, in person, or some other way will depend on your particular circumstances. Personally, I like the “15/five” style of weekly report via email, meaning it should take them 15 minutes to write, and you 5 minutes to read, but use whatever works for you.
  • Focus on development.
    • IT careers are all about what you know, and what experience you have. If you let your staff development fall behind, not only will they become less productive, but they’ll be thinking about moving on to somewhere else to continue to learn and develop their skills and knowledge.
    • Engender a culture of learning and knowledge sharing. In our team, we share “discoveries” every Friday via group emails, demonstrating what we’ve learned or discovered that week, from how to create a new maintenance task in SQL Server, what the new features of the iPhone 6 will be, or even facts about dinosaurs, particle accelerators, or IT industry figures…
  • Follow through on what you say.
    • This should go without saying, but you see it all the time. If you say you’ll do something, do it. Or, if it turns out that you can’t, don’t have time, or the situation changes, inform your team and explain why.
  • Be the best that you can be.
    • No pressure, right? Always strive to be as good as you can possibly be. Don’t burn yourself out, but be constantly looking for ways to improve yourself, the team, the environment, your business and your role. Be awesome.

 

Have I missed anything? I’m sure I have, so let me know by commenting.

Work in IT? Here’s how to ask for a pay rise.

Either ask for a review or 1-1 with your manager, or wait until the next scheduled one. I’d prefer one of my team to ask me for a chat about salaries rather than ambush me with a request, but whatever works with your company culture.

In terms of negotiating, use the following:

  • What have you achieved in your role in the business, and what benefit has that returned? Ignore your standard duties – that’s what you’re employed for anyway. If you do something that clearly makes/saves the business £100k pa, a few k raise is an easy decision.
  • What’s the pay grade for your job across your industry? If you’re good, I don’t want to lose you just because I didn’t pay you enough. Equally, be careful of earning over industry average – you’ll be stuck in a job.
  • Be aware of any mistakes or failures you’ve had. It’s no good shouting about the £100k project you managed if you also ran one that lost £150k.
  • Look at the financial status of the business. If the business is doing well and has turned a sizeable profit, highlight it. This not only shows that the business could afford to give you the raise, but that you’re savvy enough to understand the commercial world you operate in. If the business turned a loss, be very wary of asking for a raise.
  • Have a backup plan. Could you ask for an additional training course? A performance-related bonus instead of a flat raise? If times are hard for the business, could you suggest a post-dated raise, or extra holiday in lieu of pay?
  • Be aware that with a raise comes extra responsibility. Don’t make your manager regret their decision to invest extra money in you. If taking that raise means working an extra few hours a week and extra pressure to hit targets, do you still want it?
  • Play the long game. Don’t suddenly start putting in a few extra hours here and there a few days before you ask. Be consistently excellent long-term.
  • Be aware of the rest of your team. It’s potentially worth suggesting not just a raise for yourself, but a blanket raise for the team, or certain members. Do you want to be the one on £10k more than your team-mate?
  • Ultimately, make the decision easy to make for your manager. They’re going to have to justify it in their budget, and potentially go to ask their boss for the money to pay you anyway. They don’t want to regret their decision.
  • Finally. Don’t forget to actually ask for the pay rise.

Get rid of tuition fees. All university education should be free.

All university-level education should be free. Those people crying out for the good old days when fewer people went to university have got completely the wrong end of the stick.
100 years ago, the same could be said for high/secondary school – why do we need our working classes to be able to read and write, do reasonably complex maths, understand any scientific principles at all?
We live in an age where (almost) everything we do, everything we work with, play with, consume and produce are linked inextricably to very complex scientific products and concepts. Some of the people arguing here went to school before DNA was discovered, for heaven’s sake.
School children now learn about the structure and principles of DNA, particle physics, climate modelling, computing science, software development, and other stuff that didn’t exist 30 years ago.
It’s simply not the case that there’s an “ideal” percentage of the population that should have a university education. As society and technology progresses, there is simply more to know and more to understand. This has been the case since the dawn of human civilisation and will continue to be the case until civilisation ceases to be.
As a society, we owe it to ourselves to aim to provide a university (and higher, if possible) education to every person that desires it and is able to do so. The progress and survival of the human race to some degree relies upon us getting this right, not penny-pinching and making people pay for the “privilege” of developing their (and as a result, society’s) skillset and knowledge.
Just as we reap the benefits of all children going to school up to the age of sixteen, the benefits of nearly everyone in society having a higher level education wouldn’t take long to be realised, through the development of life-enhancing and preserving technologies, to more rapidly developing alternative energy sources and mitigating climate change.
There is also such a thing as knowledge for knowledge’s sake. A more educated society is a fairer, more equal, and (hopefully) happier society.
Put simply, higher education benefits all of us, not just the person being educated.

Streaming music services and the future of consuming music

I’m listening to Spotify while I write this. I’ve been a premium subscriber since early 2010, which means I’ve so far paid spotify £390 of which around 70% has gone to the artists. It took me a while to get used to the idea that i didn’t “own” the music I was listing to, but the benefits of being able to listen to anything I wanted to, whenever i wanted, and the chance to discover new music made up for it and I now believe that as long as streaming services exist, I’ll never buy a CD again. I won’t bang on about how great it is, because you’re generally either into streaming or not, and that usually depends on how you listen to your music.

There’s a lot of bad press about streaming services and the supposed bad deal that the content creators (artists) get paid from it.  Atoms for Peace pulled their albums from Spotify and other streaming services, with band members Thom Yorke and Nigel Godrich criticising these companies for business models that they claimed were weighted against emerging artists. I disagree. Anyone that thinks they can create some music and make a living from it using streaming services is living in a dream world. The music business has changed, and for the better in my opinion. Gone are the days when a band could release a CD, sell hundred of thousands or millions of copies and rake in the big bucks (but don’t forget the record labels and other third parties taking their lion’s share). Some people compare streaming to that old business model, and that’s where it looks like the artists are getting a worse deal, but it’s not a fair comparison.

Musician Zoë Keating earned $808 from 201,412 Spotify streams of tracks from two of her older releases in the first half of 2013, according to figures published by the cellist as a Google Doc. Spotify apparently pays 0.4 cents (around 0.3p) per stream to the artist. When artists sell music (such as a CD), they get a one-off cut of the selling price. When that music is being streamed, they get a (much smaller) payment for every play. Musician Sam Duckworth recently explained how 4,685 Spotify plays of his last solo album earned him £19.22, but the question is just as much about how much streams of the album might earn him over the next 10, 20, 30 years.

If you created an album yourself, and you had a choice between two customers – one who would by the CD, giving you a £0.40 cut, and one who would stream it, providing you with £0.004 per stream, which customer would you choose? Part of this actually might depend on how good you think your music is, and how enduring its appeal will be. If it’s good enough, and al the songs on that album are good (all killer, no filler!), then it’s going to get played a lot, making streaming more lucrative over time, but if it’s poor, with only a couple of decent tracks, and maybe not as enduring as it could be (think Beatles vs One Direction), then a CD is going to be more lucrative, because after a year or so that CD is going to be collecting dust at the bottom of the shelf never to be played again.

I can’t easily find a way to show the number of plays per track in my spotify library, apart from my last.fm scrobble stats, which won’t be entirely accurate as they only record what I listen to in online mode, but I’ve pasted the top plays per artist below:

The Gaslight Anthem (621 plays)

Chuck Ragan (520 plays)

Frank Turner (516 plays)

Silversun Pickups (425 plays)

Biffy Clyro (305 plays)

Ben Howard (302 plays)

Sucioperro (241 plays)

Eddie Vedder (225 plays)

Blind Melon (173 plays)

Foo Fighters (166 plays)

Iron & Wine (141 plays)

Saosin (121 plays)

Benjamin Francis Leftwich (119 plays)

Cory Branan (116 plays)

Twin Atlantic (112 plays)

Kassidy (101 plays)

Funeral for a Friend (94 plays)

Molly Durnin (89 plays)

Crucially, of the 18 artists above, at least 4 or 5 are artists that I discovered on spotify. The radio and “discover” tools on it are actually really good (90% of the time), and of those 4-5 discovered artists, I’ve seen two of them live in the past year or so. If we stop trying to think in pure instant revenue terms, streaming services provide a great part of a business model that includes long term small payments to artists and allows consumers to discover new music more easily.

Artists need to build themselves a business that incorporates records, songs, merchandise and/or tickets, and look for simple ways to maximise all those revenues.

Crucially, they also need to start developing premium products and services for core fanbase – fans who have always been willing to buy more than a gig ticket every year and a record every other, but who were often left under-supplied by the old music business. Which is why, for artists, the real revolution caused by the web isn’t the emerging streaming market, but the boom in direct to fan and pre-order sites.

Frank Turner believes we may eventually move towards a model where all music is free, but artists are fairly compensated. Talking about piracy and torrenting, he says:  “I can kind of accept that people download music without paying for it, but when the same people complain about, say, merch prices or ticket prices, I get a little frustrated.” “I make the vast majority of my living from live, and also from merch. Record sales tick over.”

If you look at Frank Turner’s gig archive, you’ll see he’s performed at almost 1500 live shows from 2004 to 2013. Most of the musicians I know do what they do because they love playing music, and particularly so in front of an audience. I personally believe that live music should be the core of any musician’s revenue stream, with physical music sales, streaming, merchandise, advertising, sponsorship, and other sales providing longer term revenue. Frank seems pretty hot on spotify, and has released a live EP exclusive to the service.

I also believe the format of live shows will change too. I love small gigs in dark little venues such as the Rescue Rooms in Nottingham, but as artists become more popular and play larger venues, there is naturally some loss of fan interaction. With the use of mobile technology, social networks, and heavy duty wifi (802.11ac for example), large venues can begin to allow the artists to interact with fans and provide a more immersive experience. Prior to or while the artist is on stage, content can be pushed to the mobile devices of those in the audience, telling them what track is being played for example, with links to download or stream it later, provision of exclusive content such as video and photo, merchandise, future gig listings, and event the ability to interact with other fans in the venue or otherwise.

The future is a healthier relationship between services like Spotify and musicians, where both can find more ways to make money by pointing fans towards tickets, merchandise, box-sets, memberships, crowdfunding campaigns such as songkick’s detour, and turning simple concerts into fuller experiences for fans.

Mountain biking in the Peak District in the snow again!

I love biking in the snow. The landscape and trails change so dramatically in such a short time, and its great to ride snow-covered trails that you’ve already ridden in rain, wind, sun, baking heat, and whatever else we put up with (enjoy).
On this occasion, the drifts were a bit bigger than I’d expected, but it was still a great ride.

20130402-205939.jpg

20130402-210013.jpg

20130402-210053.jpg

20130402-210111.jpg

20130402-210153.jpg

20130402-210213.jpg

20130402-210225.jpg

20130402-210245.jpg

20130402-210303.jpg

20130402-210312.jpg

20130402-210327.jpg