Skills, Work Styles and Approaches: What Works in University vs in a Data Role
From College to the Workplace — do the same skills, work styles and approaches matter?
Late last year, I landed my first job as a Jr. Data Strategist at First Circle, a fintech company that provides financing to SMEs in the Philippines. Eight months into the job, I’ve learned that apart from technical skills, developing certain soft skills is equally important to be effective in a data role.
As a fresh graduate, I want to provide insight on what skills, work styles, and approaches I found important in university but not quite as important in the workplace, and vice versa. Here are some examples:
Let me run you through these in detail below.
Being Compliant vs Being Proactive
Think back to some classes you took in college. Did you ever encounter a professor who said, “Guys, let’s work together to decide what topics we’ll cover throughout the course. We can also vote on whether you’ll have to take tests or not!” That sounds ideal but completely unheard of.
In my experience, professors usually outline the course topics, grading system, and course requirements in the Syllabus. Professors usually have the autonomy to decide how each course will be run and as students, we are simply expected to comply with the said requirements to pass the course.
At First Circle, we can take an active role in defining the blueprint for the company. Before the start of every trimester, our leadership team decides on the objectives we will tackle. After which, relevant teams hold ideation sessions to discuss the specific problems to solve under each objective. Everyone is encouraged to proactively suggest work streams and to determine appropriate success metrics. These success metrics are pretty much our grading system.
Through the ideation session, we are able to collaborate to create the “syllabus” for the trimester. However, ideating alone is not enough. Once the work streams are finalized, we identify the “next steps”, and work with key people from different areas of the business to solve the business problem.
Ownership and accountability are important in the workplace. We must own our work streams and approach them as we see fit, and we are accountable for delivering results to the business.
Working Independently vs Working Collaboratively
The key difference between school and work is going from being a one-man team to a team player.
Recall any individual project or requirement you had to submit in college. Say, you had to do a paper. Were you required to consult with your classmates on how to approach the paper? Some of us probably did this, but voluntarily. Professors may even discourage this since it might lead to students copying off each others’ work! In college, you have the freedom to approach individual submissions the way you would like because it will affect your grade, and yours alone.
In the workplace, particularly in the Data team, the projects we are assigned will likely be used by stakeholders across different departments, and also by other members of the team. For that reason, it is important to work collaboratively to develop the data product, whether it is a dashboard, a framework, or an engineering build. To be effective, we must gain context on the business problem we are trying to solve, and introduce our stakeholders to the data or technology being used. This is how we ensure the product will be usable by the business.
Say we are asked to track Sales Performance. We might immediately create an informative dashboard on Defaults. As a financing company, we surely want to have visibility on Defaults so we can minimize it, right? We might later find out that the Sales team actually is more concerned with Revenue. The Defaults dashboard, excellent as it might be, would likely have to be modified or scrapped altogether.
What should we have done differently? We should have worked with our stakeholder at the onset to make sure the dashboard captured the metric we wanted to have visibility on. The first question we should always ask is “What does the stakeholder care about?”
No matter how good a data product is, if it doesn’t fit a business need, it will not deliver the desired level of value across the organization. In the workplace, it is important to work closely and to communicate effectively with stakeholders to build a sustainable product.
Perfection vs Iteration
Imagine a paper you did in college. Did you submit the Introduction first? Then the Body after a few days? Then perhaps the Conclusion and Recommendations the week after?
Presenting or submitting something that is only partially complete just doesn’t cut it for most school requirements. Doing so might reflect laziness or even incompetence on the student’s part. This might not even be allowed at all by the professor.
In college, we usually just get one chance to submit an output. For that reason, we make sure our requirements are complete prior to finally turning it in.
In the workplace, we are encouraged to take an iterative approach with releases.
Suppose we are tasked to create a Strategic Dashboard that will cover 3 key metrics. It is possible to release a first iteration which might track just 1 out of the 3 metrics. Releasing this first iteration will give stakeholders immediate visibility on one metric (which is a lot better than having visibility on no metric at all!) and will create a feedback loop that we can take into consideration for the following iteration. That doesn’t mean the work is done after the first iteration though! The expectation is that the dashboard will be further refined until it covers all 3 metrics.
Through the process of iteration, we are able to deliver product improvements fast and often.
It is important to emphasize that mediocre output is never accepted. We are still expected to deliver the best end-product possible. However, we have found that providing chops of an output can be beneficial since it takes time to get a product to the “ideal state” (i.e complete features).
Short-term Thinking vs Long-term Thinking
Think about a paper you did for a random class back in college; not for a majors class, but for an elective. Did you ever think about it on a Saturday afternoon, go back to reread it, and further improve it? I know I haven’t.
Maybe some have done this for a few papers, but likely not all of them. When given a requirement back in college, I would familiarize myself with the topic and deliver an output, bearing in mind the given criteria. After hitting the submit button, the mindset would be, “Alright, onto the next one!”.
In the workplace, particularly in the Data team, we want our products to be sustainable. We want to create products that can be further enhanced in the future, even by someone else. This highlights the importance of always delivering quality work; it’s not just about chasing deadlines.
Whenever we are asked to create something, the first thing we ask is, “Has something like this already been done before?” We always try to build on existing work rather than starting from scratch. This loops back to the importance of iteration.
How do we make our products iterable?
- Proper Documentation. Documentation can serve as a guide to help people understand how your code works. There are different ways to approach technical documentation. Some teams might have their own ways of going about it, but some general best practices are listed here.
- Understandable Code. Proper indentation and naming can make your code easier to review. You can also include comments, if you must. These things can make your code more convenient to build on.
Writing proper documentation and understandable code can help future users build on your code without you having to intervene. These practices can keep the iterative approach to builds going efficiently.
In Closing
Our CTO always reminds us that the main product of a Data team is decisions. I have found that the approaches and skills discussed above helped me work with stakeholders to help shape business strategy and decisions.
It was a challenge to build these new habits because I grew accustomed to my working style from university. However, my teammates and my manager patiently helped me realize what worked and what did not in the workplace, and this allowed me to adjust to my Data role.
In my first 8 months in Data, I learned that we must proactively define what business problems we think we should be solving, and take ownership of our work streams as we address these problems. We can take iterative approaches with our data products to ensure we are able to deliver immediate yet continuous value. Also, we should work collaboratively with stakeholders to ensure we are approaching business problems in the best way possible. Like Ray Dalio said in Principles, “1+1=3. Two people who collaborate well will be about three times as effective as each of them operating independently”. And as much as possible, it is ideal to build on existing work, and to ensure that whatever we are working on can be built on in the future.
