Providing clarity and structure around expectations empowers your team members to decide what skills and competencies to focus on improving. However, writing the career ladder is only the beginning of using it well - to get the most value, you have to effectively communicate it to your team and use it as a jumping off point for specific, growth-oriented development conversations. This is part 3 of a series on career ladders - you may want to read part 1, why a career ladder is so important, and part 2, how to create a career ladder before proceeding.

After last week, I hope you’re on board that a career ladder is important, so let’s jump right into creating one that works for your team. This post will walk you through the two key parts of a good career ladder - guiding principles and specific competencies - and will point you toward some examples of ladders others’ have created for inspiration. This is part 2 of a series on career ladders - you may want to read part 1, why a career ladder is so important, before proceeding and follow it up with part 3, how to use a career ladder once you’ve got it.

Happy New Year! In the blank slate of January, many of us are thinking about what’s next. Maybe you need a road map for the projects your team will tackle this year, or maybe you need a road map for yourself. What should you focus on this year to get yourself to the next level? How do you help your team do the same? A career ladder is one effective tool to help answer those questions - and on top of that, a good ladder can help mitigate bias and eliminate glue work.

If you’re lucky, you know what it will take to get your next promotion. Maybe you need to work on communicating your analyses at the C-level instead of primarily to functional managers. Maybe you need to finish a complex project like a predictive churn model. But there is lot of work in every analytics role that just has to be done, even if it doesn’t seem to help you get from where you are to where you want to be.

While efforts to build a data dictionary are often undertaken out of a zeal for documentation that we would normally applaud, in practice data dictionaries and data catalogs end up being a large maintenance burden for little actual value, and tend to very quickly become out of date. Instead of investing in building out traditional data dictionaries, we recommend a few different approaches for achieving the same goals in ways that are less burdensome to maintain and better serve the original objectives as well.

Key Performance Indicators (KPIs) are management tools for monitoring and improving business processes. KPIs are helpful in understanding if you’re hitting your business objectives, improving over time, and helping to forecast future growth. They are also a symbol for folks in the organization to rally around and anchor against, providing clarity and aligning cross departmental objectives.

A Culture of Partnership During my time leading an analytics and data science team, I spent a lot of time thinking about how an ideal analytics team should operate – how the team should work together, how the team should prioritize their work, and how the team can most effectively partner with the broader organization to generate business value. I believe that for an analytics team to be effective, the team must develop a strong culture of partnership in order to actually drive business value.

The landscape of the data and analytics world is shifting rapidly. In many companies, the roles and responsibilities of data engineers, analysts, and data scientists are changing. This change has created the need for a new role on the data team which some have taken to calling the “analytics engineer”.

Imagine you hit a roadblock while trying to tackle a complex piece of analysis, using a python function or designing your first data organization. What do you do? Of course you start with an internet search, but what do you do when you’re really stuck? I like to phone a friend. In this post I explore my favorite learning style – learning from others – and the steps to building your own analytics brain trust. I have used this approach to solve many challenges (including building an Analytics team from the ground up) and I believe it can be almost universally applied.

A data warehouse Service Level Agreement (SLA) is an important building block for a data-driven organization. To help get you started, in part one I introduced a data warehouse SLA template - a letter addressed to your stakeholders. In this post I walk through the meat of the SLA template: services provided, expected performance, problem reporting, response time, monitoring processes, issue communication and stakeholder commitment. If you have not already read part one, I highly recommend reading it first!