Authored by Diane Kenyon
Leadership in today’s technology field can be challenging. We hire the best and brightest and provide the foundation for them to build great solutions. We provide equipment, tools and education to ensure staff members are confident to perform their jobs and conquer the challenges that come their way.
That said: This set of tools needs to include “best practices” as well.
Many will say “best practices” is another way of also saying passé or anti-innovative — which is not entirely untrue. We, as an industry (the IT / technology / digital business industry), are specifically charged with keeping the company relevant, interesting, and attuned to new functionality. Whether the customer is internal or external, it’s our job keep our eye on the horizon.
When I say we need to incorporate best practices into our toolbox of resources, I’m not talking about creating edicts carved out from old, established or outdated expectations.
There’s the inherent benefit of best practices: they are industry-accepted tips and tricks of the trade. Perhaps more importantly, there is experiential benefit of best practices: they are the collection of what the team already knows. Documenting the predispositions everyone brings to a project can also be — should be — a collaboration tool.
Here’s why and how.
Collaboration is Not an Exercise
One of the great things of working within a centralized location of whole project teams is that collaboration is expected — and not in a contrived way. We don’t have “collaboration meetings” where a select few have the chore of talking about their idea in less than five minutes for the purpose of inspiring the primary architects.
Meeting with client liaisons, project managers, developers, and architects in a single location at regular intervals gives everyone a stake in the progress of the project. We chat in the hallways and come upon concepts and innovations organically because of the group’s familiarity. From my experience, this is rare in the appdev industry, but not totally unlike an internal IT organization.
Under these circumstances, it makes sense for the project team to articulate where they are coming from, to round out expectations and highlight expertise before and during each project. For a team leader, formalizing this in a way that is comfortable and sincere is important to enabling best practices to be a part of team culture.
Step 1. Understand Those Best Practices That Follow You
As technology professionals, each of us has learned and adopted best practices that have served us well in our profession. We are exposed to these in educational settings and in the workplace. We put many into practice without much thought. We collect and keep best practices that serve us well and create a toolbox of them.
Mentally we establish a minimum baseline of these that will always be incorporated into the work we perform. Others will be utilized for specific types of work or when required. New technologies and new methodologies require an on-going assessment and update to the best practices you take with you from project to project.
Understanding what is in your toolbox will be helpful in contextualizing them for your team and provide insight into where your professional style, peccadillos and preferences stem.
Step 2. Get Your Team Thinking About Best Practices That Follow Them
Your team brings the same tools with them as well. They are as diverse as their prior experience and, as a leader, it is your job to know what they are and how they are being utilized — if consistently or not.
The novice on your team is likely closer to their education and theory while your veterans will have project- and client-specific personal victories they can rely on. Both and everyone in-between have learned their lessons and bring that to the table just as you have.
Step 3. Incorporate Best Practices Into Your Standard Documentation
Best practices should be part of the project conversation early and throughout; and be outlined when setting performance and project expectations.
Leaders often fall short in ensuring this discussion occurs and this is the opportunity at hand. At minimum, project documentation will identify an agreement on what the best practices are, which ones to follow, and validation as to when they have been utilized.
In addition, the best places to document this consensus would be on project topics you would document anyway:
- Where the work product is stored and where it is backed-up
- Process for documenting and validating assumptions, risks, decisions, etc.
- Expectations for building in unit testing or automated testing
- The process and outputs for code walkthroughs
- What evaluation tools the code is run through to ensure standards/best practices are met
- How they ensure the code will be secure
Hyperlinks to articles and shared documents are, by very definition, collaborative and are enabled in nearly all project tools. This step is as easy as creating and walking through a special folder or project comment.
Giving Your Team the Tools They Need
Validating your team’s experiences is an act of leadership. In addition, documenting and pointing to best practices within the project plan instills confidence. While this may not be the same as providing the laptop they need or the software they request; best practices are a part of your team’s arsenal and you can use it as such.
It’s intuitive: Get started by simply asking your team to identify best practices and the stories they have that affirmed or instilled it — as a team. Explain that the criteria for the best practice is that it is one that will follow them wherever they go and that applies to the project at hand. Provide an example or two within your stock.
Watch how ensuring best practices are collectively assembled and ultimately followed then creates predictability and comfort. Enjoy how your team operates after they’ve realized their individual and collective comforts. This is camaraderie and cohesion. This is real leadership.