Category Archives: Teams

Tweet-Pitch Your Job To A Non-Tech Person

I saw LinkedIn post today from Matt Barrie (head of where he calls for the end of the ACS due to its questionable relevancy and the way in which it operates its Skills Assessment program.  You should have a read.

So why am I blogging about it?

One item called out in the post is the sub-heading attached to each specialisation of “Network & Communications”, “Software Engineer”, “Electrical & Electronic Engineering”.  Sure, they’re simplifications and questionably accurate, but for most people of any age they are as detailed as needed to provide a flavour of what each is about.

I think that as technology professionals and as citizens in a very tech-savvy world we assume the detail of what we do for a job can be explained to and comprehended by most of the population around us.  While this may be true to a degree, I bet if you asked most non-tech people you know to explain what you do for a job (without you first giving them a detailed refresher) they may explain it as:

“Writes software for computers”

“Creates websites”

“Looks after networking at company X”

“Helps people access the internet”.

Sure, they’re not detailed and they most likely fail to capture in any way the complexity of your job.  But they are the way those people have understood what you do for a job and most likely reflect how most people would interpret it.

As professionals we should not be insulted by this.

A key role for the ACS is to help drive the next generation of professionals into our businesses whatever their background.  The ACS simplify the descriptions because they must.  You cannot explain a new concept with another in less characters than a Tweet.

Here’s a challenge – come up with a sub-heading that describes those specialisations in terms that the general public can understand, that captures the job’s main purpose and that fits in that space.  Then Tweet it to the ACS.

Tagged , , , ,

Agile Requirements – An Introduction.

I did a session today with the team at work around how Agile Requirements fit into the bigger picture of Agile project delivery.   The presentation is up on SlideShare so if you’re looking to bootstrap a presentation please feel free to use the contents.

Helping Your Teams To Success

I was going to write a big post about this but every time I come to work on it I find I spend more time that I intend to capture what is actually a fairly easy to understand set of principles that I’ve been lucky enough to pickup during my time working on software delivery teams.  So here they are:

Flexibility: a lot of people join teams expecting to play only one role.  While specialists can probably expect this to be the case, the rest of us should really be prepared to play whatever role is required depending on circumstances.  I’ve seen a lot of people who have been unprepared to show role flexibility where the result is that some aspect of the project delivery is negatively impacted.  Software delivery is not all glamour – there’s a lot of grinding leg work needs doing on any project in order for it to succeed.

Commitment: think about how many teams you’ve been on where you’ve had people who have contributed but ultimately their contribution is dwarfed by others on the team.  What commitment boils down to is doing the things you say you will do by the time you said you will do them (or otherwise early and clearly communicating why they won’t be done). 

Respect: pretty much all the best working relationships I’ve had (and continue to have) are based on respect.  If you approach all relationships you have with your team mates on this basis you will find that your team is far more successful than it could ever be otherwise.  Yes, if you are having challenges with other team mates around "101" concepts it can be a bit hard to proffer respect for them, however you should try your hardest to make it work and to find elements that you can respect. 

Communicate: be open and keep everyone across what you’re doing.  Be pro-active about communicating – don’t wait for someone to ask you for information.  The one proviso here is that you determine what is appropriate for others to be told.  I lean more towards over-communication – people will soon let you know if they don’t need to know the level of detail you are giving them.

Reliable: don’t be random.  Try to keep your behaviour the same as often as you can – people should come to expect you to behave in a certain way in a certain situation.  Some of being reliable goes back to commitment: do the things you say you are going to do when you said you will do them.  Delivery of any project is challenging enough without having team members going off-piste and doing ad-hoc work that was never on the cards.  Ultimately if people don’t find you reliable then you will struggle to be trusted and trust is certainly at the core of any great team.

Well I guess I could ramble about this topic ad nauseum and if you’re reading this far then I salute you!

As always, any discussion of teams and teamwork would not be complete without the obligatory Dilbert cartoon! 

Happy teaming, enjoy!

Tagged , , , ,