Browsing all 5 posts in Business.

Communication issues in small business

1 Comment

A good friend/ex-colleague of mine and I got into a discussion recently about some of the woes that accompany being a tech guru in a small business. The number one issue at hand was communication – trying to interpret the needs of the business (and the managers) and create a solution that made everyone smile.

Unfortunately, developers are terrible at managing the expectations of the boss, and managers are typically not quite as clued in as their technical subordinates with regards to technical limitations. What usually results is a solution which was either a) done within the timeframes required but falls short of expectations, or b) meets expectations to a degree, but took twice as long as intended.

In a larger business this unfortunate phenomenon is mitigated by two things. Firstly, timelines are paradoxically both more expanded/lenient (read: realistic) and also very inflexible… perhaps not so much a paradox, as the longer timelines may be designed specifically to prevent deadlines slipping… allocate more time than you need and all is well. The key however, is that while there’s plenty of time allocated to meet that goal… The Deadline Is Not Arbitrary. It must be met, on time, every time.

Secondly, an all-important position within the company becomes viable (even essential): there could be a dozen different titles for the position, but what it boils down to is that you have someone who is technically savvy and understands limitations, and has enough experience dealing with/participating in management to effectively manage the expectations of the top brass. Essentially this boils down to having a mediator, a translator who can take the requirements of the business, turn it into a specification the tech guys can understand, while at the same time effectively communicating the technical limitations (and the workload of the tech team) to the boss(es) and keeping their expectations within the bounds of realism.

If you’re dealing directly with tech staff, you may be inclined to put on your Leader Hat and rally them to nail a deadline they just can’t manage, whereas dealing with a single person who acts as an authority over your technical assets means you’re more likely to delegate the management of the project to them, instead of doing it yourself. This means managers can do their job more effectively and not worry themselves with the details, and the tech team can work under the leadership of someone who was once in their shoes.

So how do you fill such a position in a small business? From experience it’s pretty difficult… either you get someone who’s happy to occasionally step over from another role (say, marketing manager or business development manager) or you get a tech guy who can both do the hard work and manage the “team”, even if the team is just him/herself and one other.

It’s a no-brainer that having a separation between management and tech is a good thing, unless you’re lucky enough to build a team made up of a mixed bag of ex-tech, management etc. where the manager(s) has/have a keen understanding of the tech side of the business that they’re directing. This is surprisingly rare.

Well, that’s all I’ve got on that subject… I’d love to hear from you if you have any insight as the “ultimate solution” to the problem of communication within a small business still eludes me!

Continue reading...

Providing Web Services – Lessons Learned.

Leave a Comment

Thankfully, these lessons haven’t been learned the hard way – not entirely anyway.

I’m not referring to my own web services – I don’t provide any of these. I’m referring to a particular web service I use to create and lodge invoices electronically.

Granted they are working hard to restore their services so I’ll refrain from outing them, but I’ll share a few things I’ve learned, not just with this latest incident but with web services in general.

1. Keep the customers informed. If you’re planning an outage period, or things aren’t going as expected, send a single email to your customer base explaining the planned/estimated outage times, or if applicable, an explanation of what went wrong and what you’re doing to fix it. While your customers might still be peeved, at least they’re in the loop.

2. Try and avoid using social networking tools to announce outages. Twitter is NOT a suitable means by which to communicate outages, as progressive and “nu-skool” as this approach may seem.

3. For the love of God, tread carefully when dealing with DNS changes. DNS, by nature and with regards to change, is a slow, unweildy beast. If you make a mistake and spot it too late (i.e. overnight) the mistake may have already propagated, and fixing it will take just as long (unless you set your TTLs ridiculously low).

4. If you can’t release a product or revision to the product without a prominent risk of failure, just don’t. The old mantra “real programmers ship” is as vague as it is foolish….. I’d rather wait another week for an upgrade I might not even notice, than go 24 hours without a crucial service because something went “bang”. You can still make ambitious release dates, but just put some real time, effort, and most of all, serious and careful thought, into setting up your development and release infrastructure. If you do things right, announcing an outage for purposes of maintenence/upgrade will be a thing of the past… your customers won’t even notice.

5. Prepping a release at 6pm on a Friday evening is a no-no. Your developers are probably burnt out from a week of frantic preparation, and this sets the stage for errors. I’ve been told on numerous occasions that shipping a particular feature/product on a particular date is “important to the business”. What’s more important is your image, and having exhausted developers cram something out the door in time for the upper echelons to nod their heads in approval, and then having said product blow up in your face because of an error that got missed, makes you look stupid in the eyes of your customers. Again: it is always better to ship late than ship broken. As a customer, I’d rather see a polished, functional product than a broken, rushed one. A poorly executed release reflects badly on you and your product. Take the time to do it properly.

That’s it for today’s rant!

Continue reading...

Find Music Stores - Best Workout - South East London Roofing