Creating Transparent Technology Teams
Technology teams are often seen as siloed nerds and trapped in isolation within organizations. This often makes it hard for others within the organization to collaborate and utilize the technology team effectively. Technology leaders also find it easy to get support from othersenior leaders on key corporate decisions like increasing technology budgets or making a big capital technology investment if others are transparently aware of strengths and current challenges of technology teams. A truly transparent technology team is open, and honestly communicates about both the good and the bad, the wins and failures. It may seem daunting for some leaders but once they see the trust, loyalty, ownership, and accountability it generates, they become believers. Technology teams also often comprise of diverse remote teams and transparency helps internally within their teams as well. Below are a few ideas on how to build this transparency.
Adapting Agile Scrum Methodology: Transparency is one of the key pillars of scrum methodology. Involved team members are transparent in their day-to-day dealings with others. They need to trust each other and keep everyone abreast of successes and setbacks in project delivery. Tools like sprints, burn down charts, retrospectives, end of iteration demos etc.,
provide great transparency in understanding health of team and project.
Open collaboration: Often times technology teams structure themselves in such a way that only a few people get to directly collaborate with others in the organization while others are simply asked to just focus on core development. Roles such as systems analyst, technical project / program manager and team leads typically are tasked with creating these collaborative shields. The primary reasoning I have heard is to reduce meetings / distractions for developers. This may be true in the old days of non-iterative waterfall based product development days but in today’s iterative customer requirement/feedback oriented development process, collaboration is a key ingredient to continuous improvement and delivering what customer wants. Asking developers to directly interact/demo their features to internal stakeholders allows them to get direct understanding/feedback while avoiding layers of translation. The concept of agile pods was developed primarily to facilitate this. Agile pods are small custom agile teams, ranging from four to eight members, responsible for a single task, requirement, or part of the backlog. This organizational system is a step toward realizing the maximum potential of agile teams by involving members of different expertise and specialization, giving complete ownership and freedom, and expecting the best quality output
Technology teams also often comprise of diverse remote teams and transparency helps internally within their teams as well
Postmortems: Critical technology failures are often glaringly visible within the organization like a website/mobile app going down or a data breach affecting users. A postmortem clearly articulates the issue and covers the what, how, why, damage caused, lessons learned and how to prevent it from happening again. It provides a way for technology teams to document their side of the story. Communicating this report to others in the organization promotes transparency/accountability and helps them to make a case for more velocity on technical debts.
Uptime / Current status: Uptime is usually measured as percent of time application/systems were stable during a period of time. Current status is basically the current stability of these systems. Most B2B enterprises expose this to their clients but technology teams can become more transparent by doing this across all their applications (internal / external). Creating an open process for others in the organization to selectively subscribe to applicable alerts greatly helps with adopting this openness. Some ways to do these are open slack channels that anyone can join or mailing lists or RSS subscriptions etc.
Release History & Notifications: Most technology teams are now adopting continuous integration and agile releases. This sometimes makes it hard for others in the organization to keep a tab on what was released and when. Creating an open process where others in organization can search what changed on a certain day and ability to subscribe to release notifications helps resolve this issue. Similar approaches discussed in relaying status can be used here.
A Tech spec for every Product Spec: Product specification helps to capture all the expected specifications and requirements for a product that is being conceptualized. This enables both the design team and potential product users to understand more about the product before it's actually built and readied for distribution or end-use. It provides a platform for product team to show case how they are contributing towards company goals. This however is half the story. Every product specification should have a accompanying technical specification that thinks through the complicated issues and covers technology team’s design for a successful implementation/rollout, testing, operational support, security/privacy considerations etc. In short it covers how the design decisions made will contribute to success of the feature. Any estimates and deliverable guidelines should be based on this spec and referenced in all communications. This creates transparency around implementation cycle.
Introducing Technology Teams during interviews / new employee on boarding: During new employee orientation, providing a high-level overview of technology teams/their process and introducing them to key stakeholders sets the right tone for transparency / future engagement. Similarly, during the interview process if a role will be highly collaborating with technology team then including a technology team member in review process with greatly help both sides.
Open access to performance / failure metrics: Data points such as crashes, freezes, latencies etc are great pointers to understand how user experiences the product. Imagine a scenario where a product analyst is trying to analyze why mobile app retention tanked or greatly improved on a certain day or a certain hour. Having combined access to usage analytics and app performance/failure data allows them to derive if any technology improvements or issues affected any metrics / customer journey within the product.
Technology teams should not be a blocker for access to this data.