Let’s say that you have a growing technology shop, such as for analysis and development, or that you’re establishing a new team. In short order, you’ll become concerned with matters such as ensuring their timely delivery, quality targets, and readiness for a competitive and ever-advancing technology landscape. In other words, you’re going to need some kind of technology leadership. Enter the technical leader!

What is a Technical Leader?

I’m glad that you asked. Technical leaders are charged with the timely delivery of high quality results to the customer. Results can be varied, such as software or training, but invariably they meaningfully produce value and require the investment of skill and time that only a team can provide.

The idea of technical leaders is not new, having been adopted from other engineering industries into the modern technology domain; however, the manner in which a technical leader adds value is often misunderstood. In this post, I am going to explain why you should have a technology leader and what you should expect from him or her to ensure that you get the most out of both the role and the team.

Fundamentally, a technical leader is a facilitator: they balance the customer’s vision with what the team can achieve (within organizational tolerance and contributor ability). That means they will be constantly ensuring everyone’s understanding of how the job needs to be done and which aspects of the job need to be done at all points in the delivery cycle. It’s all about logistics and knowledge sharing.

Let’s start with communication.

It’s imperative for teams of any kind, and especially those doing technical work, to be able to quickly and succinctly impress upon their peers, partners, and customers their challenges and needs. The topics are broad: feature and schedule discussions with the customer; data exchange and component behaviour with partners; and with peers designs, quality benchmarks, capability constraints, location of work, and more. The technical leader must constantly refine everyone’s ability to signal and exchange in a conceptually uniform manner. Easy wins are common programming and spoken languages, but what about design patterns, pseudo code, and functional demonstrations? Even the names and positions of branches and tags within version control systems indicate a state of activity, concern, and acceptance among team members. All of these variables, business and technical, need to be streamlined and standardized by the technical leader so that the team spends more time doing things for the customer as opposed to determining what needs to be done. A good technical leader will use every opportunity, from hack-a-thons to code reviews, to ensure that their team members, customers, and partners can effectively exchange ideas in manners suitable to their environment.

When a team communicates effectively, everyone will be eager to start doing things. It’s great when those things result in a delivery satisfying the customer’s intention, but not all decisions made by individuals will jive with the realities of the business or team. The technical leader needs to be regularly available to the customers, partners, and team to ensure that decisions are accounting for the potential of the situations at hand. In effect, the technical leader needs to be the best connected person on the team, sufficiently aware of the political, resource, talent, schedule, and technology realities of the day. The technical leader will ensure, for example, that the most capable individuals aren’t introducing ideas that cannot be carried by the team’s average skill-to-bandwidth ratio; and that code being prepared by each team member is of sufficient relevance to the critical path.

Obstacle Removal

A key aspect of decision support is obstacle removal, and this effort in various forms will be the core of the technical leader’s daily activity. An astute technical leader will spend significant time evaluating (in advance) the skills, tools, and access carried by the team. Such insight will permit the technical leader to do things such as rotate junior members into appropriately challenging situations to increase their potential; advocate for aligned training plans; and establish systems or permissions relevant to a high quality delivery. When funds fall short or new information arises impacting the path to success, the technical leader needs to provide educated instruction to members so that they can proceed or involve the proper authorities who can make the necessary call. In agile environments, the technical leader has the responsibility of forcing recommits by customers and sponsors if the landscape changes so sufficiently that the team cannot produce any reasonable value. Not least, there will be many instances in which members will want to tackle work that seems, at face value, productive, but in reality does not contribute to the immediate needs of delivery; or would result in unnecessary risk to the project due to an incomplete knowledge or availability by those who would become involved in seeing the solution through to completion.

When it comes to less experienced members, the technical lead assists by researching, demonstrating, and closely guiding how work should proceed. That doesn’t mean that they do the work of the junior engineers, but rather that the lead sets the context for productive progression. For example, the technical leader might prepare a series of unit tests that exercise the API of a new framework so that the team gains a living example of how best to use the functionality. Or, a test framework might be prepared illustrating the lead’s desired outcome for component interactions. In many respects, the technical leader will always be one step ahead of the team by participating in or making use of technology radars, conferences, journals, industry peers, defect lists, and similar to ensure an awareness of options that can result in better deliveries for the customer. The lead will also establish a sufficient learning environment so that the team can make use of new options without the risk of mistakes and delays along the critical path.

Are they the most practiced?

Clearly the technical leader is going to be a team expert, familiar with many tools and tactics for getting the job done. It might surprise you to learn, then, that despite the critical role played the technical leader will probably not be the best programmer or analyst on the team! It’s true, and it’s an important fact for organizations to remember when managing their teams. While the technical leader will be competent, experienced, and wise, the fact of the matter is that they need to split their time between concerns such as feature specifications, user story specifications, engineering metrics, team member environment optimization, business interlock, customer interlock, and more. That means, for any kind of balanced life, the technical leader is going to do less coding, less modelling, and less testing than his or her peers. In other words, they might well be experienced, but they’re going to end up being less practiced.

Don’t panic, especially if you happen to be a technical leader. It’s okay, and in fact it’s an acceptable trade of implementation productivity. In the balance between getting things out the door and into the customers hands versus running the business, the technical leader offers wisdom and refined decision making in the context of external pressures so that the rest of the team becomes more productive. If the technical leader simply coded alongside everyone then the team would be, well, the team + 1 with just a linear increase of productivity instead of factoral leaps. It’s similar to having an engineering manager: they don’t (or at least shouldn’t) code with the team, instead they deal with human resources, budgets, policies, and the translation of business strategy into tactical outcomes. The work needs to be done regardless of whether it is hidden in the team or tackled directly via a supported mechanism.

Balancing Act

But less practiced means less experienced at some point, right? Yes, unfortunately. As Stephen Covey once noted, a sharpening of the saw must occur. This can be achieved either by having the organization invest in training time and resources for the technical leader, or the organization can adopt a rotational model by which different people share the burden. An example rotation strategy is to use a primary-shadow-worker approach by which for a period of time an individual acts as the technical leader and has the part-time assistance of a team peer. The part-time peer, known as a shadow, helps the technical leader such as by doing research or grooming the backlog, and in so doing remains aware of the overarching concerns for the team. At the end of the period, the technical leader transitions into a traditional engineering role within the team, the shadow becomes the new technical leader, and one of the team engineers steps up to be the next shadow. The length of period depends on many things, but for agile teams the feature commit cycle can be a good alignment. The result will be a balanced, self-enabling technology team capable of succeeding in many challenging situations.

In all, technical leaders are vital to healthy and productive teams–but to be the most effective these individuals need to exercise their engineering prowess by focusing less on implementation and more on communication, logistics, and knowledge sharing. Organizations need to recognize that the value of these activities are critical to successful outcomes, and by promoting strong technical leaders they gain the benefit of strong delivery teams.

3 Different Types of Analytics Project Teams and
3 Questions for How to Get to Innovation Faster

Guest Post by Rosemary Hossenlopp

Running an analytics project is not like any other project. There are only a handful of organizations who are running data projects that link data-driven initiatives to corporate innovation goals. This shows that knowledge on how to run a Big Data project isn’t widely understood by most companies. Analytics projects also fail more than other projects so there are risks which most organizations ignore in their haste to get into the data-driven project space. Who says so?

Few Organizations Have a an Analytics Project Process or Plan

According to PwC, a consulting firm powerhouse, only 4% of companies have an effective data strategy. So doing the nonquant-intensive math, this means that 96% of global organizations neither have a process, nor a plan that allows them to use their data assets for competitive growth or internal improvements. To See this Sad Math Summary, click here.

Most Analytics or Big Data Projects Fail

According to Gartner, most projects fail as projects are treated just like any other project. To see this Second Sad Summary, click here.

Analytics Teams Must Understand The Next Big Step to Take

Before this post starts to sound like the opening night of the United States Republican Convention which was touting and trumpeting (pun intended) doom and gloom, there is a path and framework for teams to quickly see how to strategically move their teams to faster launches by understanding Which Type of Analytics Project They Are On. Who can analyze their organization to understand their Big Data Project Type? The likely role suspects would be Project managers, Product Owners, Engineering leaders, Project Management Office (PMO) leaders. Yet first, why should Analytics Project Teams assess their Project Environment?

Benefits For an Analytics Team to Understand Their Current Project Type

Leadership has high expectations for Analytics and Big Data teams to produce results. So teams focus on getting to the next sprint demo rather than stepping back and seeing if there are hidden organizational issues that will trip them up on their way to launch success. In the old engineering days, we called this an undetected defect. Now we need to apply the same focus on finding and removing technical bugs to looking for process and planning steps, that if skipped, will tank your project.

What are the benefits of assessing your Big Data Project Environment?

  1. Increase time to value – avoiding missteps in process & planning will prevent politics and push back at project launch.
  2. Increase team motivation – technical execution is terrific yet ultimate lack of user adoption is terrible.
  3. Increase your motivation – who wants the three cousins of churn, change and chaos on your daily agenda demanding attention?

3 Types of Data Science, Big Data & Predictive Analytics Projects

We are not looking at the Red, Yellow, Green traditional dials for project health but an assessment of where each team is at on its journey to Innovation and Growth Mastery. There may be 3 stages your Analytics team is at:

Technology Tinkering

Definition: Build-out of data science talent, skills and infrastructure for pursuing market opportunities.This is a critical step as organizations try to solve an organization process issue, a market problem or look for intellectual capital insight in their data. There are thousands of technical and talent development user stories in these teams backlog. Many teams can get stalled in this work-intensive stage and not even prioritize monitizable customer use cases.

Market Experimenters

Definition: Coordinated Data Science, data information and Business Process Efforts. These are highly focused, and disciplined efforts within a functional group or business unit. As an example, marketing operations teams are driven to understand their customer base to increase reach and revenue. Marketing product owners have so many experiments to run in their own back yard that they often donít unlock bigger use cases. Why? It is so hard to work with outside teams like finance, compensation, and support to access their data or impact their processes.

Growth Hacking

Definition: Visionary exploration of data driven hyper-growth strategies. Many organizations have visible and articulate spokesman/women for innovation ideas. Demoís may be limited to proof of concepts and not ready to scale. So organizations are in the hype cycle and may not be able to scale to production ready systems. Visionaries may not have the patience to understand the work, time and money needed to build out the infrastructure and data governance.

Next Big Step Plan for Analytics and Big Data teams

There are hundreds of urgent actions for each project type. Yet consistently there is just one question for each project type that can break teams out into a path towards innovation and growth.

Technology Tinkering Teams

  • Big Next Step: Customer Value Creation
  • Key Action Needed: Product Owner working with all stakeholders to gain agreement on problem to be solved & key metrics.

Market Experimenters

  • Big Next Step: Cross-functional Discipline
  • Key Action Needed: Product Owner and Leadership gaining alignment with enterprise stakeholders on end- to-end user stories, which solved, would produce innovation results.

Growth Hacking

  • Big Next Step: Metrics towards scalable & Monitizable Growth
  • Key Action Needed: Gaining agreement on all governance, funding and feature prioritization process.

Question: What Big Next Step would you add or questions do you have? Ask Connie and I in our FREE September Webinar