Showing all posts tagged work:

Biting My Tongue

So I'm working with a prospect in the fashion and luxury goods area. We've been doing a Proof of Value for the last few weeks, and we're now at the point of presenting the results.

So I built this slide deck as if it were a fashion collaboration, "Moogsoft X $PROSPECT_NAME", "Spring-Summer 2017", and so on. I'm super proud of it - not just the conceit, but also the results we have been able to provide for very little effort - but I'm also kind of bummed that I can never show it to anyone outside the company.

This prospect does not want its name used anywhere, so even if - I mean, when we close the deal, they will only ever appear anywhere as "fashion & luxury goods house".

This is not the first time this has happened to me. At a previous startup, we sold to, umm, let’s call them a certain automotive manufacturer and motorsports team based near Modena. While negotiating the price, the customer asked for "a last effort" in terms of discounting. In exchange, we asked for them to provide us with an official reference. After consulting with their brand marketing people, it turned out that the fee for use of their trademark would have been nearly twice the total value of the software deal… We respectfully declined their kind offer.

After all, the main thing is to do the deal and provide value; even if we can't get the logo on our site, it's still a win.

My only remaining problem (beyond actually getting the deal over the line) is that my wife wants me to be paid for this current opportunity in handbags, while the Moogsoft colleague who helped me out wants her share in eau de toilette…

New Paths to Helicon

I was chatting to a friend last week, and we got onto the topic of where sysadmins come from. "When two sysadmins love each other very much…" - no, that doesn't bear thinking about. BRB, washing out my mind with bleach.

But seriously. There is no certification or degree that makes you a sysadmin. Most people come into the discipline by routes that are circuitous, sideways, if not entirely backwards. The one common factor is that most people scale up to it: they start running a handful of servers, move or grow to a 50-server shop, build out some tools and automation to help them get the job done, then upgrade to 500 servers, and so on.

The question my friend and I had was, what happens when there are no 10 and 50-server shops around? What happens when all the jobs that used to be done with on-premises servers are now done in SaaS or PaaS platforms? My own employer is already like that - we’re over a hundred people, and we are exactly the stereotypical startup that features in big infrastructure vendors' nightmares: a company that owns no physical compute infrastructure, beyond a clutch of stickered-up MacBooks, and runs everything in the cloud.

The 90s and Naughties, when I was cutting my teeth in IT, were a time when there was relative continuity between desktop and enterprise computing, but that is no longer the case. These days you’ve got to be pretty technical as a home user before anything you’re doing will be relevant at enterprise scale, because those in-between cases have mostly gone away. I got my start in IT working at the local Mac shop, but neighbourhood computer stores have gone the way of the dodo. There simply are not many chances to manage physical IT infrastructure any more.

Where Are Today’s On-Ramps?

There is one part of that early experience of mine which remains valid and replicable today. My first task was pure scut-work, transferring physical mail-in warranty cards into the in-house FileMaker Pro "database". After two weeks of this, I demanded (and received) permission to redo the UI, as it was a) making my eyes bleed, and b) frustrating me in my data entry. Once I’d fixed tab order and alignments, I got ambitious and started building out data-queries for auto-suggestions and cross-form validation and all sorts of other weird & wonderful functions to help me with the data entry. Pretty soon, I had just about automated myself out of that job; but in doing so, I had proven my value to the company, and received the traditional reward for a job well done - namely, another job.

That is today’s path into computing. People no longer have to edit autoexec.bat on their home computers just to play games, but on the other hand, they will start to mess around behind the scenes of their gaming forum or chat app, or later on, in Salesforce or ServiceNow or whatever. This is how they will develop an understanding of algorithms, and some of them will go on from there, gradually growing their skills and experience.

A Cloudy Future?

To be clear, this cloud-first world is not yet a reality - even at Moogsoft, only a fairly small percentage of our customer base opts for the SaaS deployment option. More use it for the pilot, though, and interest is picking up, even in unexpected quarters. On the other hand, these are big companies, often with tens or hundreds of thousands of servers. They have sunk costs that mean they lag behind the bleeding edge of the chance.

Even if someone does have 50 servers in an in-house server room today, as the hardware reaches its end-of-life date, more and more organisations are opting not to replace them. I was talking to someone who re-does offices, and a big part of the job is ripping out the in-house "data closet" to make more work space. The migration to the cloud is not complete, and won't be for some time, but it has definitely begun, even for existing companies.

What will save human jobs in this brave new world will be "intersection theory" - people finding their niches where different sub-fields and specialisations meet. Intuitive leaps and non-obvious connections between widely separated fields are what humans are good at. Those intersections will be one of the last bastions of the human jobs, augmented by automation of the more narrowly-focused and predictable parts of the job.

There will be other hold-outs too, notably tasks that are too niche for it to be worth the compute time to train up a neural network. My own story is somewhere in between the two, and would probably remain a viable on-ramp to IT - asssuming, of course, that there are still local firms big enough to need that kind of service.

Constant Change Is The Only Constant

To be clear, this is not me opining from atop an ivory tower. Making those unexpected, non-obvious connections, and doing so in a way that makes sense to humans, is the most precise definition I’d be willing to sign up to of the job I expect to have twenty years from now.

As we all continue to reinvent ourselves and our worlds, let's not forget to bring the next generations in. Thinking that being irreplaceable is an unalloyed win is a fallacy; if you can't be replaced, you also can't be promoted. We had to make it up as we went along, but now it's time to systematise what we learned along the way and get other people in to help us cover more ground.

See you out there.

Replace or Augment?

One of the topics that currently exercise the more forward-looking among us is the potential negative impact of automation on the jobs market and the future of work in general. Comparisons are frequently made with the Industrial Age and its consequent widespread social disruption - including violent reactions, most famously the Luddite and saboteur movements.

Some cynics have pointed out that there was less concern when it was only blue-collar jobs that were being displaced, and that what made the chattering classes sit up and pay attention was the prospect of the disruption coming for their jobs too. I could not possibly comment on this view - but I can comment on what I have seen in years of selling automation software into large companies.

For more than a decade, I have been involved in pitching software that promised to automate manual tasks. My customers have always been large enterprises, usually the Global 2000 or their immediate followers. Companies like this do not buy software on a whim; rather, they build out extensive business cases and validate their assumptions in detail before committing themselves1. There are generally three different ways of building a business case for this kind of software:

  • Support a growth in demand without increasing staff levels (as much);
  • Support static demand with decreasing staff;
  • Quality improvement (along various different axes) and its mirror image, risk avoidance.

The first one is pretty self-evident - if you need to do more than you can manage with the existing team, you need to hire more people, and that costs money. There are some interesting second-order consequences, though. Depending on the specifics of the job to be done, it will take a certain amount of time to identify a new hire and train them up to be productive. Six months is a sensible rule of thumb. If the rate of growth gets fast enough, that lag time starts to be a major issue. You can't just hire yourself out of the hole, even with endless money. The hole may also be getting deeper if other companies in the same industry and/or region are all going through the same transformation at the same time, and all competing for the same talent.

If instead you can adopt tooling that will make your existing people more efficient and let you keep up with demand, then it is worth investing some resources in doing so.

That second business case is the nasty one. In this scenario, the software will pay for itself by automating people's jobs, thus enabling the company to fire people - or in corporate talk, "reduce FTE2 count". The fear of this sort of initiative is what makes rank and file employees often reflexively suspicious of new automation tools - over and above their natural suspicion that a vendor might be pitching snake-oil.

Personally I try not to build business cases around taking away people's jobs, mainly because I like being able to look myself in the mirror in the mornings (it's hard to shave any other way, for one thing). There is also a more pragmatic reason not to build a business case this way, though, and I think it is worth exploring for its wider implications.

Where Are The Results?

The thing is, in my experience business cases for automation built around FTE reduction have never been delivered successfully - if focused on automation of existing tasks. That is an important caveat, but I will come back to that.

Sure, the business case might look very persuasive - "we execute this task roughly a dozen times a day, it takes half an hour each time, and if you add that up, it's the equivalent of a full-time employee (an FTE), so we can fire one person". When you look at the details, though, it's not quite so simple.

The fact is that people rarely work at discrete tasks. Instead, they spend their time on a variety of different tasks, more or less integrated into a whole process. There is a tension between the two extremes: at the one end you have workers on a repetitive assembly line, while at the other you have people jumping around so much they can never get anything done. Most organisational functions are somewhere in between those two poles.

If automation is focused on addressing those discrete tasks, it absolutely will bring benefits, but those benefits will add up to freeing up existing employees to catch up with other tasks that were being neglected. Every IT department I have ever seen has a long tail of to-dos that keep getting pushed down the stack by higher-priority items. Automation is the force multiplier that promises to let IT catch up with its to-do list.

This sort of benefit is highly tactical, and is generally the domain of point solutions that do one thing and do it well. This will enable the first kind of business case, delivering on new requirements faster. It will not deliver the second kind of business case. The FTEs freed up through automation get redeployed, not fired, and while the organisation is receiving benefit from that, it is not what was built into the assumptions of the project, which will cause problems for its sponsors. Simply put, if someone ever checks the return on the investment (an all too rare occurrence in my experience), the expected savings will not be there.

Strategic benefits of automation, on the other hand, are delivered by bundling many of these discrete tactical tasks together into a new whole.

Realising those strategic benefits is not as straightforward as dropping a new tool into an existing process. Actually achieving the projected returns will require wholesale transformation of the process itself. This is not the sort of project that can be completed in a quarter or two (although earlier milestones should already show improvement). It should also not be confused with a technology implementation project. Rather, it is a business transformation project, and must be approached as such.

Where does this leave us?

Go Away Or I Will Replace You With A Very Small Shell Script

In my experience in the field, while tactical benefits of automation are achievable, true strategic improvement through automation can only be delivered by bundling together disparate technical tasks into a new whole. The result is that it is not skilled workers that are replaced, but rather the sorts of undifferentiated discrete tasks that many if not most large enterprises have already outsourced.

This shows who the losers of automation will be: it is the arbitrageurs and rent-seekers, the body-rental shops who provide no added value beyond cheap labour costs. The jobs that are replaced are those of operators, what used to be known as tape jockeys; people who perform repetitive tasks over and over.

The jobs that will survive and even benefit from the wave of automation are those that require interaction with other humans in order to determine how to direct the automation, plus of course the specialists required to operate the automation tools themselves. The greatest value, however, will accrue to those who can successfully navigate the interface between the two worlds. This is why it is so important to own those interfaces.

What might change is the nature of the employment contracts for those new roles. While larger organisations will continue to retain in-house skills, smaller organisations for which such capabilities are not core requirements may prefer to bring them in on a consultative basis. This will mean that many specialists will need to string together sequences of temporary contracts to replace long-duration full-time employment.

This is its own scary scenario, of course. The so-called gig economy has not been a win so far, despite its much-trumpeted potential. Perhaps the missing part to making this model work is some sort of universal basic income to provide a base and a safety net between consulting jobs? As more and more of the economy moves in this direction, at least in part due to the potential of automation, UBI or something similar will be required to bridge the gap between the assumptions of the old economy and the harsh realities of the new one.

So, the robots are not going to take our jobs - but they are going to change them, in some cases into something unrecognisable. The best thing humans can do is to plan to take care of one other.


Images by Annie Spratt, Janko Ferlic, and Jayphen Simpson via Unsplash


  1. Well, in theory. Sometimes you lose a deal because the other vendor's CEO took your prospect's entire management team for a golfing weekend in the corporate jet. But we don't talk about that. 

  2. An FTE is a Full-Time Equivalent: the amount of work expected of one employee, typically over a year, allowing for holidays and so on. Typically that means somewhere between 200 and 220 working days of 8 hours each, so 1600 to 1760 hours in a year. The "FTE cost" of an activity is calculated by multiplying the time required to perform an activity once, multiplying that by the number of times that activity needs to be performed, and dividing by the FTE rate. 

Misunderstanding Tools

The sour taste in my espresso this morning is courtesy of yet another dudebro tech VC, opining about how ties are uncool, maaaaann! and basically nobody should write on LinkedIn.

If you have a tie on in 2015, it probably means you are a salesman in a non-transparent industry and are generally not to be trusted at any cost. When I see a tie on somebody, I get that funny feeling you get right before the dentist. Let’s face it, the people left wearing ties every day are the confidence-men stealing your money. Think insurance, financial services, bad shoes and, of course, car salesmen.

Well now.

I am on record as not only a tie wearer, but also a tie apologist. To quote myself once again:

In fact, suits & ties are actually the ultimate nerd apparel. You have to put some effort into shopping, sure, and they tend to cost a bit more than a random vendor T-shirt and ancient combats, but the advantage is that you can thereafter completely forget about wondering what to wear. You can get dressed in the dark and be sure that the results will be perfectly presentable. If you want you can go to a little bit more effort and inject some personality into the process, but the great thing is that you don’t have to. By wearing a suit & tie, you lead people to pay attention to what you say and do, not to what you are wearing. And isn’t that the whole point?

This mindset of “distrust anyone dressed like a grown-up" is just one more symptom of the Revenge of the Nerds chauvinism that is rife in the tech industry. The nerds complain about being victimised by the jocks, but it’s not the victimisation itself that they object to, it’s just being on the receiving end of it. “They mocked me for dressing differently from them, but now I mock them for dressing differently from me! Haha, I win!"

No, no you don’t win. You just look like an overgrown, entitled man-child. Grown-ups wear ties as a sign of respect to one another. If some sleaze balls wear suits & ties, that is because they are trying to fake that respect - but just because something is faked, does not mean that it’s not aping something real.

If I visit a customer or a prospect, I am a guest, and I dress and act appropriately. I’m not more “genuine" or “passionate" if I show up in jeans, sneakers and a Zuckerberg-approved hoodie. If I’m doing it right, my passion and competence will show regardless of what I wear. Today, wearing a hoodie to work is not transgressive or cool - it’s just imitating a more successful person. And let’s not even pretend that your hoodie doesn’t get judged for materials, cut, brand, etc., as much or more than suits ever were.

Basically, he is wilfully misunderstanding what people use LinkedIn for and why they would want to write there. Yes, it’s an advertising tool - that’s what we are all there for! LinkedIn is buttoned-down, professional me - although I like to think that I still put some personality in there. Twitter is where I let it all hang out, and talk about what I am up to at work right beside books, music, and whatever has got the Internet in a bunch lately.

Amusingly, Dudebro VC's piece ends up being an example of exactly the sort of writing he decries, since it’s a listicle:

1) LinkedIn has become a giant branded entertainment platform for selling us crappy fake expertise.

2) Crappy writing

3) No real authentic sentiment

4) LinkedIn notifications are predatory

The real kicker is at the end, though, where he says that it’s perfectly okay for him to write a listicle, because it’s not on LinkedIn, plus he got paid for it and doesn’t care about how many times it gets viewed.

Firstly, this is insultingly disingenuous. Writing this sort of flamebait, custom-designed to go viral and provoke reactions1 and then making a big show of turning away and not watching the ensuing furore is a cheap trick - but one that is perfectly in line with the rest of the piece.

Secondly, this is pretty transparently elitist. He's attempting to pull up the ladder behind him, mocking anyone who has not achieved his supposed level of clout in the industry. What he is saying with this piece is, if you’re a big shot, you can wear a hoodie to work and be paid for your opinions. If you have to dress professionally and are still having to work hard to get your opinions out there, you’re a loser.

Just in case you thought Martin Schkreli - he of the 5000% drug price increases and one-off Wu-Tang Clan albums - was an outlier: now you know that he is not. There are plenty of utter tools in VC.


I also took special pleasure in cross-posting this piece to LinkedIn Pulse, just to make my point one more time.


Image by Olu Eletu via Unsplash


  1. Such as this one - hi! Congratulations, it worked! 

Happiness in Typesetting

In my usual spirit of always wanting to try an alternative way of doing something - partly in hope that the alternative might be better, partly due to my latent hipster gene trying to express itself - I have always been curious about LaTeX. It's a big commitment, though, and until now I had lacked data to drive my decision.

Somebody (shockingly, they are in Germany) has done a scientific comparison of LaTeX vs Word.

So it turns out that a specialised tool is really good at a specialised task, while a jack-of-all-trades tool does better at general tasks. Big whoop.

The interesting question to me would be a breakdown of how many Word users know how to use even fairly basic features. The style sheet functionality seems to be a mystery even to people who really should know better.

People complain a lot about Word being obtrusive, and there is definitely truth to that complaint: try nesting tables, or trying to pad them, or doing two-column layouts that don't flow, and then come back and tell me about Word - but only once you stop swearing and twitching, please. However, many of the complaints that I hear tend to be more about people not knowing about a feature in Word, or not using it properly.

Part of that problem is of course due the design and usability of Word itself, but it's noticeable that all of the alternatives to Word run into the exact same problem of complexity, as soon as they get past the basics. It's often said that 80% of users use only 20% of the features of software - but Word is the perfect example of the fact that everybody has a different 20% subset that is critical to them.

Anyway, while it looks like LaTeX only really shines for mathematical equations, since LaTeX users appear to be happier, I may yet have to give it a go.

Watch this space…

Cube dwelling

I complain a lot on Twitter about open-plan offices, but they are not the worst working environment. Every time I spend any length of time in a US-style cube farm, I long for an open-plan office. Cubes are the worst of both worlds: enclosed enough that you feel hemmed in and cannot see daylight, but without any meaningful sound isolation.

enhance_team_pr.jpg

Working from the living room table is good, but I really need to sort out the connectivity to my home office so that I can use it properly. A project for my copious free time!

Two Pizza Disruption

So you have an idea, and you kick it about with some people and refine it, until it's time to take it out into the world. Now that insight gets paraphrased and simplified and reduced to sound-bites, and those sound-bites get passed around by people who don't necessarily understand all of the context behind the sound-bite. In fact, I wrote about this process already: SMAC my pitch up.

In what we laughingly call "software engineering", the current favourite delaying tactic to postpone the onset of cargo cults is the two pizza rule. The rule was coined by Jeff Bezos of Amazon:
if a team couldn’t be fed with two pizzas, it was too big.

The problem with the two pizza rule is not that it doesn't work. Small teams can indeed get a lot more done in a hurry than big teams, which inevitably get bogged down into management by committee. The problem is that very quickly you end up with many two-pizza teams, all eating in different rooms and not talking to each other. Sooner or later, some bright spark will suggest that there should be a committee to manage the interaction between the various teams. In accordance with the Iron Law of Bureaucracy, the requirements of communication proliferate until people in the individual two-pizza teams are spending more time on formal communication processes than on the original purpose that they sat down to thrash out over pizza.

Congratulations: your two-pizza team just reinvented the org chart. As tempting as it may be to set sail in your own pocket battleship, it's generally better to figure out a way to achieve your goals within the corporate structure, or without upending it entirely. Revolution sounds fun, but evolution actually gets results.

Home Office Backlash

Teleworking is back in the news!

The very technology that enables telecommuting and working from home could be destroying its value. Although productivity may increase in the short term, working from home may prevent your teams from working effectively.

I've had both office-based and home-office jobs, so I have an idea of the upsides and downsides of each. I last wrote about teleworking more than a year ago, when Yahoo first banned the practice. Here's what I said at the time:

... the office is where I go to have impromptu conversations and face-to-face meetings, but it's not where I am most productive, even with my headphones on. I am much more productive at home, in aeroplanes, or in hotel rooms without distractions.

I think the sort of togetherness that the Forbes piece describes is real. I work in a team that is entirely remote: no two team-members share an office. For the type of work we do, this works well. It's great to meet up, and we take every opportunity to do so, but mostly we're fairly loosely coupled, so we get on fine as is.

There is another dimension to consider here. If companies gather all their employees except for local field support into one central location, they may have all sorts of serendipitous conversations around coffee machines, but there is a significant risk of an echo chamber effect developing. Silicon Valley is all well and good, but what works there will not necessarily work elsewhere in the US, never mind Europe, Asia and so on. If everyone involved in deciding and communicating the strategic direction of the company lives their entire lives in Silicon Valley, surrounded by people doing exactly the same thing, the company will develop a huge blind spot to the realities on the ground.

Not to mention all the employees spending their bonuses on noise-canceling headphones just so they can get some work done in the office again...

Why Shadow IT exists

Let me share with you a short e-mail conversation I had earlier today, which perfectly illustrates why users will do anything rather than deal with their IT department, up to and including running their own servers.

Me: Hey IT, what are the video conferencing standards we can support?
IT: Just use Lync - it's the standard!
Me: No, it's somebody else's meeting, and they asked what video conferencing standards we can support.
IT: I don't know anything about this meeting, and anyway it's up to them to send you an invitation you can accept.
Me: Agreed, and they are asking what I can accept, hence my question about which video conferencing standards we can support.
IT: * silence *

As usual, Dilbert is spot-on: I am obviously dealing with Mordac, the Preventer of Information Services.

Dilbert.com

Skype for Teams

I wrote a howto on using Skype for my team, and then thought that others could probably take advantage of this too, so here it is. Shout if you have any questions, comments or additions!

These days, most companies above a certain size have some sort of official internal IM/chat solution. In most cases, that solution is Microsoft Communicator or its newer cousin, Lync.

The problem is, the blasted thing just doesn’t work very well, at least on a Mac. Lync goes offline spontaneously at least once every half-hour or so, and it crashes several times a day. It crashes predictably when the Mac resumes from sleep, but it also crashes randomly whenever it feels like it. Finally, Lync is only useful within the company.1 If you need to talk to customers, partners, or contractors, you need an alternative solution.

With that in mind, and in a spirit of Bring Your Own Solution, here is a guide to using Skype for team communications.

Using Skype for basic one-to-one communication is simple enough. Add your team-mates to your contact list, and you can IM or voice chat with them at any time. I would recommend adding team members to your Favorites so they are always available. You can do this by clicking the star icon on each contact, or by right-clicking on their name in the contacts list and choosing "Add to favorites".

Where it gets interesting for a team, though, is that you can set up multi-user chat just as easily. When in a voice or video call, press the plus button in a speech balloon below the contact, and select "Add people…" from the pop-up menu.

You can do the same in a text chat by selecting the plus button and adding people to the chat. Note that history is persistent, so it might be better to start a new group conversation rather than dropping new people into an existing chat session.

In a conversation, it is also possible to share your desktop. Simply go to the “Conversations" menu and choose "Share screen…". This will allow you to do real-time group edits or share a presentation with other participants in the call, much like WebEx and its ilk.

Skype is not just useful for calling other Skype users. One of the banes of my existence is conference calls which only have US toll-free numbers. Even if I’m in my home country, calling the US from a mobile gets expensive fast, and it’s much worse if I’m roaming. If I can get on wifi, I use Skype to call the US toll-free number. This is free and does not require Skype credit, although performance will depend on your wifi connection. It’s fine for listening to a call, but if you are a primary speaking participant, I would not recommend this approach.

With that caveat out of the way, all you have to do to dial national (not just US!) toll-free numbers with Skype is to bring up the Dial Pad, either by clicking on the little telephone icon beside the search field, or by going to the “Window" menu and selecting "Dial Pad".

Here you can dial as normal: +1 for the US (or the correct country code for the number you are calling), and then the number. Unfortunately DTMF tones do not work during dialling, so you can’t save conference numbers and PIN codes directly; these have to be dialled each time. Not all conferencing systems seem to receive DTMF tones from Skype even during call setup, so if it’s the first time you are using a particular conference, dial in with time to spare and have a plan B for how you are going to access the call if Skype doesn’t work.

There are mobile Skype clients for all major platforms. They work fairly well, but synchronisation is not guaranteed to be real-time, so if you move from one device to another, you may not be seeing the latest updates in your IM conversations. Also, if you send a message to an offline user, they will not necessarily receive it immediately upon signing on. Anything time-sensitive should go through another medium. At least the delivery receipts in Skype will tell you whether the message reached the intended destination.

I hope this guide has been helpful! Please share any additional tips that you find useful.


  1. It is technically possible for IT departments to “federate" Lync installations between two companies, but that requires lots of work, sign-offs, and back-and-forth to achieve, and anyway only works if both participants are using Lync.