“Leverage” is an overused phrase in many business settings, but focus for a moment on the actual meaning. A lever multiplies the force you apply to it, and that multiplier depends on where you place the fulcrum. As you mature as a data practitioner, you’ll learn how to leverage your technical skills. Rather than simply using your tools to complete tasks, you’ll focus on where and how to apply your effort for maximum impact.
This is part 3 of a series on skills that enable data practitioners to develop consistently high impact and success. My goal is to help individual contributors understand how to build skills that drive results, and help data managers provide clear, constructive feedback to help their team members grow. Links to the full series can be found at the bottom of this post.
Knowing how to use tools is good; knowing when to use tools is better
Technical skills are often framed as knowing tools, techniques, frameworks, and approaches to solve the needs of your role. This can seem like an easy place to grow – just learn a new language, a new tool, a new analytical pattern. You can take a class or read a book to progress further.
This type of skill development is important in the early days of your role. It’s critical to know how to use your teams’ tools in order to take on projects successfully. But once you build a baseline understanding of those core tools and existing patterns, how you apply your technical skills makes the difference in your impact.
As you become more senior, your role shifts from knowing how to complete a task to knowing how to create value via your technical skills.
The three skills I’ll cover to identify which tools and solutions will give you the most leverage are:
- Building what your organization needs, not what they request
- Making good architectural decisions, and
- Finding opportunities for scale.
For each, I’ll focus on what the skill looks like when it is less developed versus when it is well-developed. I’ll also offer some concrete suggestions on how to improve these skills. .
Build what your organization needs, not what they request, to have more impact
Data teams get a lot of requests. You can create a feeling of productivity by just responding to requests – but if you’ve ever tried that, you’ve found that you spend an awful lot of time on work that you never see or hear about again. Simply doing what stakeholders ask for is not a recipe for maximum impact. Instead, you’ll need to understand how to separate what the stakeholder actually needs from what they believe they need.
What it looks like with underdeveloped skills
You are highly responsive to stakeholders but feel trapped in iterative loops. The work you do generates more work, but no action. You build tools that are used once but don’t remain useful. You bite off very large, complex projects without testing a simpler solution first. You get pulled into projects too late and often receive detailed requests, which makes you feel like you are just churning through tickets and providing service blindly to your colleagues.
What it looks like with highly developed skills
You invest more time in conversation and low fidelity prototypes to limit iterative request loops. You build tools that are widely adopted and appreciated, though they may look different from the initial request. Stakeholders often bring you problem statements instead of data requests because they trust that you’ll help them find the right solution. You get pulled into conversations early as a valuable thought partner.
How to develop this skill
Each time apply your tools (or choose what tools to use) is an opportunity to focus your work to have more impact with less input. That provides lots of opportunities to practice these skills. A few approaches to learn to build what your organization needs, not what stakeholders ask for include:
- Fundamentally, this skill requires treating your work as a product, not a service. Even if you can’t change how your team overall works, you can learn a lot from prior art about running data teams like product teams, and learning how to apply product-adjacent skills in data.
- Practice slowing down and asking more questions before you start building. Whether you have a structured “intake” process or not, asking questions like those on Caitlin Hudon’s intake form can help structure conversations with stakeholders.
- Think about the user experience, and how your users will interact with your end product. Do you understand what happens after they see the data? Will they make a decision or take a concrete action? If you can’t outline that next step clearly (and see how your work will impact it), stop and go talk to your users.
- Understand the business and the players within it. I’ll talk more about understanding the business in a future post, but building a clear understanding of what your colleagues want to accomplish will help you see how data can help them do so. That understanding will allow you to suggest solutions they may not realize exist.
- Ask yourself, “how can I simplify this?” Is an existing metric a good-enough proxy for what you’re measuring? Before you jump to machine learning, have you looked at some basic summary statistics?
- Ask yourself, “how can I make the feedback loops on this project shorter”? Can you provide a few basic insights that help illuminate the situation before you jump into a robust, deep analysis? Alexis Gresham-Johnson and I wrote about several ways to create shorter feedback loops in a post on linear and circular data projects.
- The most important advice in this post is to ask yourself, “what’s the smallest piece of this I can deliver that still creates value?” Testing how you can break down delivery helps you deliver value more quickly, get feedback faster, and often helps you de-scope projects overall when the early chunks of work provide enough information to act.
Good architectural decisions put your effort in the right place
Architecture is the design of the systems we use. It fundamentally shapes how we can leverage tools and skills to solve a problem. In data roles, architecture decisions can be big picture, encompassing how various data sources come into a data lake or data warehouse. They can also be much smaller, like whether the definition of a new dimension should live in a Looker custom field, a core Looker dimension, or upstream in a mart transformed via dbt. There is no one right answer to either of those decisions. An important part of developing as a practitioner is understanding tradeoffs and options, then making the best decision you can.
What it looks like with underdeveloped skills
You can find a path to a solution, and you are likely to implement the solution so long as it achieves your goal. You may not think deeply about tradeoffs between speed, scalability, performance, and other attributes of the solution before you proceed. You may simply pick the most convenient path at the time, implicitly favoring speed to insight above all else without thinking through the tradeoffs. You may find you either invest lots of time building robust data sources that are rarely used, or immediately refactoring your MVP work to make it more robust.
In the example above about defining a new dimension, there are several ways undeveloped architecture skills might manifest. Perhaps you use a custom field to answer the question – without considering whether others should be able to use your work either within Looker or outside of it. When this new dimension gets used in several reports, you find yourself going back to push your logic further upstream. Or, perhaps you immediately jump to putting everything into a mart for scalability – and find yourself with many columns that are rarely used. Either way, you’ve jumped to building without thinking through the best long term approach.
What it looks like with highly developed skills
You are able to identify multiple ways to achieve your goal, weigh the tradeoffs between them, and recommend a solution. You understand how multiple pieces need to fit together and can think through upstream and downstream impacts.
Sometimes you go through this process independently, but you can also identify when to loop in others. When a project is important enough to warrant a more inclusive process, you can identify who to bring together for feedback and alignment on your recommended solution. You can identify that there are likely upstream or downstream impacts, and are comfortable bringing in other teammates to help.
Even when you have developed an ability to focus on architecture, you may not always choose the architecturally optimal path. You know when “quick and dirty” approaches are enough. You can weigh tradeoffs and identify when to take a less ideal approach in order to more quickly reach an outcome for the business, even if that entails thoughtfully accruing some tech debt or loosening your analytical rigor to enable speed.
How to develop this skill
A few approaches to growing your architectural skills include:
- Ashley Sherwood wrote a great Substack post (based on her Coalesce talk) on the component skills of design. Start there!
- Sketch out your approach to solve problems before you build, and challenge yourself to come up with 2 alternatives. Outline at least a couple pros and cons for each before you pick a path.
- I’ll tackle communication skills in a separate post – but clearly articulating options and recommendations in a design doc allows you to practice both your design and your writing skills!
- Ask people who have made recent tooling or design decisions why they took the path they did. Understand what factors they weighed and why they landed where they did.
- If your team has formal or informal established best practices, seek to understand why those practices are important. How do the infrastructure and tools your team have chosen fit together and how are they best used? For bonus points, try to think of situations where you might deviate from the best practices and why. For example, while there may be a general bias for moving all transformations upstream, when might you consciously move logic closer to the end user?
- Ask for feedback on the less visible parts of your work. Sometimes we don’t realize that we’re making a suboptimal decision, because there is no automatic feedback mechanism. Make sure you’re showing your assumptions to teammates or your manager to double check them.
- Read technical blog posts about large architectural decisions. The good ones will discuss the different options considered, the tradeoffs, and why they went with the solution they did.
Opportunities for scale – work slow to move fast later
Many smart people in the data field define the success of at least parts of the data team as speed. In a fast-moving environment, it can certainly be valuable to execute quickly. However, as you grow as a data practitioner, you’ll begin to identify when it’s time to slow down, take a step back, and focus on solving a problem that will ultimately accelerate your team’s progress.
What it looks like with underdeveloped skills
You almost exclusively work on projects in reaction to requests or assignments. You dive in and get through the project as quickly as possible. You may find yourself working on similar problems repeatedly, or consistently dealing with annoying repetitive work. You focus on the volume of your output to measure your own success.
What it looks like with highly developed skills
You think about how your work makes other people’s work go faster or makes them more productive. In addition to work that comes to you from others, you proactively identify ways to free up your and your team’s time. You see themes in the requests your team receives, and identify how you might step back and invest in solutions that alleviate an entire class of problems. That may include building reusable tools, training others, or introducing new ways of working to your teams.
You work with your manager, team or stakeholders to evaluate investing in that high-leverage work, and make time for it even when new projects continue to arise. You are able to put aside the urgent work in favor of this important work.
Over time, your workload shifts as you invest in these scale opportunities. You spend your time on new projects rather than repetitive ones. You focus on the impact and leverage of your work to measure your own success.
How to develop this skill
A few approaches to learn to slow down to move faster later include:
- Try hosting a retrospective with your team with the intention of making it a regular occurrance. As you think about what hasn’t gone well in your role and hear what hasn’t gone well in others’ – what patterns do you see?
- Try hosting a pre-mortem, focused on company growth. After your company (hypothetically) grows 3 times as large, what will your team’s failure points be? How might you build for that scale today (without over-investing in infrastructure you don’t actually need yet)?
- When new work comes to you, pause and do a bit of research on similar recent work your team has done. Think about whether a tool, a data mart, or an automation could make similar future work easier or unnecessary.
- Talk to colleagues with different skill sets to get new perspectives on what’s possible, and even what other tools are available at your company. Software engineering teams, dev ops teams, and data colleagues with different focus areas can help you see leverage opportunities from a new angle.
- Could you invest in training sessions or materials to help your stakeholders more effectively learn how to help themselves? See the prior post in this series for more ideas on how to improve your skills at teaching others.
- Work with your manager to build in some re-investment time in your schedule. Start with a small project and demonstrate your ability to impact your team’s ability to scale without derailing other work.
- Think about whether the scale investment is worthwhile. XKCD’s Is It Worth the Time is a classic framework for considering whether automation makes sense, though there are reasons to automate work that aren’t purely about investing time to save time later. Will it decrease errors? Will it improve someone’s work experience dramatically?
From tasks to impact – finding leverage in your tools
As you mature as a data practitioner, you will spend less time using technical skills solely to complete a task. Instead, your focus will shift to leveraging technical and business understanding together to solve the right problem in the right way. This critical shift requires being thoughtful about what problem you really need to solve, how to remove complexity, how to identify tradeoffs and choose a path forward, and when to slow down to plan for scale. Each decisions is an opportunity to identify leverage points for you and your team.
But learning how to apply your technical skills to create long term value for your organization is a career-long journey. How has this played out in your roles? I’d love to hear more about your experience in LO’s Slack community.
Full Series:
- Post 1: Solidify your Soft Skills
- Post 2: Learning: The Meta-Skill for Accelerating Impact
- Post 3: Applying technical skills (you are here)
