Professionalism

In TechLauncher you are a practising professional

Everything you do in your project must be professional - respecting the client, your team, your peers and yourself.

If you find yourselves doing something that does not appear to be a good use of time, or seems unnecessary, then STOP and REFLECT - do you really need what you are doing, have you missed something, can you use your time better?

The TechLauncher ‘Triple Bottom Line’

In order to do well in project audits, you should also consider a ‘Triple Bottom Line’

  • Do the best you can for your client or business
  • Work on learning as much professionally as you can
  • Demonstrate the quality and value of the work you’ve done, and highlight the future work

These three objectives are interlinked. Focussing on one to the exclusion of the others will lead to sub-optimal outcomes.

  • Learning about teamwork, stakeholder engagement and applicable technology will lead to improved satisfaction of client needs and, ultimately, better outcomes
  • You will need to learn a great deal during the course to satisfy the needs of your client. In doing so, you will be able to present a great story in your project audit, leading to great outcomes
  • Staying humble as a learner - you are presenting your work to domain experts. It is entirely professional to demonstrate you understand the limits of your work.

*In TechLauncher we do not talk about ‘marks’. If you are using language such as ‘marks’, ‘grades’, ‘scores’, or ‘points’, you are missing the point. Instead, focus on how your work will be ‘evaluated’ - the value you are generating for your client through the project outcomes and processes.

Presenting your work

This is a list of tips for presenting your work compiled over many years of TechLauncher project work

Professionalism at Tutorials

The aim of the Review Tutorials is for you and your team to develop and practise the ability to succinctly present work, and to then address comments and questions in a coherent manner. Tutorials are an opportunity to get feedback from your peers, tutors, mentors, and other stakeholders. Finally, they are an opportunity for you to develop your ability to understand and critique the work of others, and to ask well formed questions that improve your understanding.

With this context in mind, it is important for everyone in the room to:

  • Introduce clients and other stakeholders who are present
  • Engage in the process - no mobile phones, laptops, etc.
  • Be respectful of others - particularly the team presenting and their client
  • While robust, frank and open discussion is very much encouraged, it is not acceptable for people to abuse and attack each other. The point of robust interactions is to help improve approaches and outcomes.

Presentation tips

  • Be honest and open - put your cards on the table. There are people around who know the truth
  • Be enthusiastic about your work and proud of what you have achieved
  • Act like a team. No backbiting or contradictions
  • When pitching - everyone to be engaged in the presentation - we can learn a lot by looking at those who are not presenting!
  • Talk about what you have learned from both failure and success - technical and project perspectives
  • Always have something concrete to show or demo
  • Remember that some people will have no idea what you are doing. Set the scene for the context for the system you are developing, what the client’s business is and what they want you to do

Repository tips

  • Reviewers will use your Audit Landing Page to guide their review. Make it easy for them to find the work you want reviewed
  • Make sure you refer to evidence and rationale for decisions made by your team. For example, meeting minutes, slack comms etc. Many teams will maintain a wiki as a kind of ‘engineering logbook’ or ‘decision log’
  • Point reviewers to exactly where they can find your work - don’t expect them to trawl through repositories looking for material to review - make sure you point them to work that addresses the evaluation criteria.
  • Make sure all reviewers have access rights to read your repositories
  • If you have physical artefacts you want reviewed, then make clear to the reviewer how they can inspect them - eg. contact details to arrange an inspection.
  • It is really up to you to decide how you present your work for review. If you don’t allow your reviewer to properly and fairly review your work, then you should not expect a good evaluation

Evaluation tips

You are also reminded of your professional responsibilities. Refer to the Engineers Australia Code of Ethics Section 1.3, and/or the Australian Computer Society Code of Professional Conduct Section 1.2.6.

Updated:  10 Jul 2018/ Responsible Officer:  Head of School/ Page Contact:  TechLauncher Course Webmaster