Tag: <span>Graham Technology</span>

I just found this sitting in my drafts folder. The company name has changed (we are now Kana Software) but the premise is the same. Interestingly, the parallels between our thoughts on customer service and the thoughts in tech comms of better integration within a support system (providing information as part of call deflection) are striking. I’m going to try and pull these together in a future post.

I was asked to write an article for Credit Control Journal on behalf of the company I work for, and for the sake of historical archiving (and so I know I have it somewhere), here is that article.

Work

Comments closed

As featured in the Spring 2008 edition of Communicator, the magazine for ISTC members.

I’m the Publications Team Lead at Graham Technology, a mid-sized (and growing) software company based in Scotland and like many people in this field, I have a wide range of duties. As well as the more traditional technical authoring work, I also manage resources, consider strategy and working practices for the team, and generally do my best to represent the user during development meetings. I also find myself spending time considering the information strategy of the company, investigating translation requirements, and keeping up to speed with the Technical Communications industry.

I joined Graham Technology just over a year ago and it’s my first time working in an Agile software environment. The development team use the Extreme Programming (XP) methodology and it’s taken a little getting used to, particularly as all my previous experience comes from more traditional teams, with long timescales, project managers with Gantt sheets and lots of process documentation to be completed.

There are specific challenges to working in an Agile environment and to a fair extent they shape my working day and, whilst everyday is different, they all start with the same thing. Caffeine.

I’m usually one of the first people in the office and, once the coffee machine is going, I take advantage of the peace and quiet to pick through the emails that have accumulated overnight. I monitor a variety of automated emails from different systems, all of which help me build a coherent view of what is happening during a release cycle.

We have a development arm in Jakarta so I take the time to sift through their work to check for any possible impact on the documentation. Anything that catches my eye is noted on an index card and stuck up on a dedicated whiteboard allowing anyone to see what is outstanding at any given time.

Next up is a quick check of the Publications build to make sure it has run successfully during the night. We currently use Webworks to generate Javahelp which is automatically compiled into the product each night; small changes are quickly actioned and committed to the documentation, and are then available in the next software build, keeping us in-line with the principles of Agile development.

The final set of generated emails I check are from our bug tracking system and they list what has been fixed or added in the past day. Again, anything that may impact the documentation is noted on an index card and added to the whiteboard. And, by now, the coffee is usually ready; milk and one sugar, please.

Last but not least, there may be requests for information that have come in from our Deployment staff out on customer sites. Sometimes all they need is a copy of a specific manual, other times it takes a little research to find the information they need. Once that’s done, I spend a little time skimming my RSS feeds for anything else of interest.

It’s now around 9am and the office is filling up. I typically have a few things to chase up from the previous day, and it’s a good time to have a few quick chats with the developers before they get too embroiled in their daily work.

Our Development Group is split into six distinct teams, with three technical authors covering their output from brand new features to bug fixes and product enhancements. Most of the teams have a standup meeting every day to take a quick look through the tasks that need to be completed, and during these I play user advocate, considering UI design and any information requirements that need considered. It’s a very dynamic and collaborative way of working.

Working within an Agile development environment means that things move fast and information flies in from all sorts of sources and directions. Monitoring email, changes to our internal Wiki, and chatting to the developers and testers in the teams are all part of a typical day. Placing yourself in the path of these streams of information is the best way to keep up to speed, and learn what is really happening on a day-to-day basis.

I also try and keep in touch with Marketing and Training to understand their plans and see if there is any cross-over with what we are doing in Publications. I’m striving to make our message more consistent, and improve the way we plan, design, create and distribute our product information, and maintaining direct lines of communication is crucial.

Part of my Team Lead role is to make sure the product documentation is meeting customer expectations. We have two products, a user-friendly out-of-the-box product which our Deployment staff extend using our development kit. Gathering requirements from the Deployment staff is a constant push-pull exercise and, as they are talking directly to the users of our out-of-the-box product they act as proxies who can be interviewed to make sure we are providing the right information, at the right level for the expected user.

The rest of my time is spent writing documentation. This is broken into three main types of work at any one time; small changes to the products which require less than half a day to complete, larger changes to the products which may take between a day and a week to complete, and documenting the brand new features that are being added to the product.

I start with a high-level plan of what is required and then trickle the information into the relevant document throughout the development cycle, handling changes in scope and requirements as they arise. I try and plan to work on small chunks of content, making it much easier to drop something if the requirement is descoped at any point (this is a key reason we are moving to single source our content) and I spend any additional time researching and learning the part of the product I’m working on, playing with the software regularly to make sure I fully understand both how it works and how it would most likely be used.

Like everyone else, I don’t really have a typical day. I do try and stick to plan for the first few hours but interruptions, conversations and changes of priority are all part of the challenge of working in a fast-paced software development company.

Work

Hello all, apologies for my absence last week, couldn’t be helped, c’est la vie and all that.

So a quick catchup. Last week was my induction week for Graham Technology and the only downside is that it made me feel very old. This is only because the majority of the other ‘new starts’ were fresh out of university, thus limiting conversations about, say, the Smash aliens, or even about how you found information on the internet before Google existed. I am old.

Other than that it was an excellent week, very informative and even this old head learned something new. They even managed to hold Graham Technology’s 21st birthday party on Friday night, and there are rumours that I was drinking tequila and dancing like a loon. Rumours. Honest.

And so to Saturday and the arrival of my new PC.

Ha. Fucking. ha.

Walsh Western, you are a shower of incompetent wankfucks.

And that, via a few games of rugby and a very dodgy movie (National Treasure, which apparently thinks it doesn’t need a storyline), brings us to Monday morning. I’m off to listen to Neon Bible in preparation for the Arcade Fire gig tonight. I’ll try and catch up on what YOU have been doing a little later.

Ohhh, almost forget. It seems I may be quoted in the Sunday Times yesterday. It’s not a paper I buy… does anyone still have a copy?

Life

I know it’s still November, I know we’ve yet to pass Christmas and Hogmanay, but January is already looming large, heralding not only the beginning of a new year but a new beginning for me for, on 8th January 2007, I’ll be joining a new company.

I’m hugely excited, a little nervous/scared, but very eager to start and, despite the fact it’s a couple of months away, I’m already looking ahead.

It’s going to be a huge wrench to leave my current employer; I’ve had many opportunities here that I doubt I would have had elsewhere (an advantage of working for a smallish company), I work with some very smart people and have enjoyed some epic nights out, and as the office is situated in the heart of Glasgow the commute and shopping opportunities have me spoiled.

But.

I’ve been here for seven years, through three changes to the company name, a merger with a sister company, a round of redundancies and several changes of boss and team members. All that’s in the past now, but the environment of change is one I thrive on and as things have been stable over the past couple of years I guess that’s been a factor in my growing desire to seek pastures new.

I’ve learned a lot, more so than on any other job (mind you it’s the longest I’ve been in a job so that says something too), but my enthusiasm has been on the wane for the past year or so, I’ve turned down one job and was short-listed for another (losing out to an internal candidate, why do they do that? I know they must but… meh..) and when this job came along I still wasn’t that sure, until I met with them and chatted about the role.

So, it’s bye bye McLaren Software, hello Graham Technology.

And, whilst I will be sticking to my “don’t blog about work” rule, it would be remiss of me not to mention the new office in which I will be working. Nice, huh.

Life

Comments closed