If you’re like me, you always learn something new on a project, but it’s usually incidental. Your focus is on writing code, and the learning just kind of… happens.
I’m here to tell you that you’re wasting a great opportunity. Your colleagues have a lot to teach you—and a lot to learn from you. A project team is a perfect environment for learning, but you’ll only get the full value if you’re intentional and thoughtful about it.
My Story – From Passive to Active Learning
Working at a consultancy like Atomic provides an amazing crucible for growth. We work on multidisciplinary teams, where responsibilities and roles are shared and blurry. This pushes everyone out of their comfort zones, making them broaden their views of their roles and develop skills they’ve previously ignored.
Our projects are usually fairly short: four to twelve months in most cases. This cadence offers a rapid cycle of exposure to new businesses, problems, technologies, and constraints. We journey through the knowledge funnel again and again, each time learning new things about our craft.
This is certainly my takeaway after 12 years at Atomic. I graduated from GVSU in 2006 with a degree in CS and math, as a hopeless nerd mainly interested in the technical aspects of software. I was nervous to talk to customers and clueless about design. I started at Atomic as an intern, with plans to return to graduate school at some point, but I realized very quickly that there is an amazing depth in breadth:
- I knew algorithms well but had no experience with building real systems.
- I could put buttons on a screen, but I didn’t have any sense of how those should really connect to the ideas in a user’s head.
- Eventually, I could build a system, but how could I build one with the structural flexibility to easily adapt to changing business needs?
- Once I was able to build a flexible system, could I get better at seeing to the heart of a problem and designing better from the outset?
Over the course of many projects big and small, I’ve learned new perspectives, honed skills, and continued to inch toward mastery of the huge breadth of challenges that make up software development and consulting.
Looking back over my journey so far, I’ve come to view the software project–the smallest unit of our work at Atomic–as more than a code artifact delivered and a customer satisfied. There’s a crucial internal aspect as well: the project as a team experience and a personal learning opportunity.
For years, I experienced this passively, struggling through a challenge and ultimately succeeding. But over time, I’ve come to value a more proactive approach to teaching and learning as part of a software team.
Learning Goals You Should Have on Every Project
No matter how much (or little) experience or familiarity with the project’s tech stack we may have, all developers can share these learning goals.
As a learner
- I should aim to understand where I’m at in my career and where I hope to head next. What learning and growth goals can I set for myself on this project, and what challenges can I seek out or volunteer to advance those goals?
- I should seek out critique of my strategies, techniques, and results from my colleagues and look objectively at the things I do and produce as specific options with trade-offs.
- I must continually remind myself to not take critiques of my choices personally. There are always opportunities to improve an existing strategy and alternative strategies with the promise of a better cost/benefit balance. A non-optimal result is not a failure, but a successful experiment that produces new data pointing toward optimality.
- My colleagues are smart, motivated, experienced people with diverse perspectives and backgrounds. I should watch how they tackle the challenges they face and look for new strategies and perspectives that I can adopt.
As a mentor
- I should try to proactively understand where my colleagues are in their careers and what their goals are for this project. As the team faces new challenges, I should aim to include colleagues who could gain the most from the experience.
- The tactics of how a teacher and a learner collaborate matter a lot: Is this a situation where we should work closely on a challenge that is totally unfamiliar to the learner, or new to us both? Or would the learner be better served by the space, responsibility, and challenge of owning a task by himself or herself, while I hold back and provide guidance and critique?
- When giving feedback to teammates, I should first seek to understand their mindsets and rationales. I should encourage as I critique. I should focus on a small number of key lessons, and not pepper them with complaints. My goal is to support them in their career growth as I also seek to provide great service to our customers.
- If I’m in a position to make key technology, architectural, or team workflow choices, I must first do what’s best for the customer. However, given an array of options, I should also make choices that are most likely to give the team experiences that will help them grow so they can be better prepared for their next project with their next customer.
Technical Learning Goals, Based on Level of Experience
In addition to those general goals, there are others that correspond to your level of development experience and familiarity with your project’s technology. I see three different, roughly-defined teaching/learning niches:
- Newbie: Someone learning the ropes in one or more aspects of the project, whether tech stack or Atomic development practices. This may be someone in our Accelerator program; a recently hired, yet experienced, developer still learning our processes and practices at Atomic; or a senior Atomic developer working in an unfamiliar technology, codebase, or domain.
- Crusher: A developer with enough experience in the tech stack and our development practice to lead the development of whole features. Usually someone with at least a few years of professional experience, but not always.
- Tech Lead: A developer working in a consulting and leadership role on the team. Tech Leads work closely with the Delivery Lead and Design Lead to help represent the feasibility aspect as part of our Human-Centered Design (HCD) process. Tech Leads must ensure that implementation choices are as closely aligned with the business and human needs as the design of the user experience.
Every developer acts in these roles at different times and bounces between them across projects. Experienced developers are usually Tech Leads, but often also serve as Crushers on teams as well. They may occasionally find that roles are reversed and they’re the Newbies when working with young developers with deep experience in a new tech stack.
The Newbie
Newbies should aim to approach Crusher levels of productivity as quickly as possible. Their goals include:
- I must first endeavor to become a productive member of the team by ramping into technologies and practices.
- I should proactively identify weaknesses in my knowledge base or past experiences and formulate strategies for growing in those areas—perhaps reading books or documentation, or volunteering for the tasks I feel most underequipped to tackle.
- I will share my goals and self-identified weaknesses with a Crusher and/or Tech Lead I’m collaborating with, and seek their assistance in finding the best approach to tackling these challenges.
- At regular points during the start, middle, and end of a task, I will stop and critique my approach and seek out critique and advice from others.
Note that the Newbie role is often transitory. Someone may start as a Newbie in one or two aspects and finish the project a Crusher.
The Crusher
A Crusher should engage in the same practices as a Newbie to continue their own technical growth while modeling good teaching and learning to others on the team. However, a Crusher should also aim to support the growth of Newbies and learn new skills that will support them as future Tech Lead. Crushers should strive for the following goals:
- I should be a good mentor to Newbies, and also continue to practice critique and growth in my core developer skillset.
- I should identify growth areas for myself as a Crusher by continuing to improve my productivity and technical mastery.
- As I approach a steady state as a Crusher, I should look to learn from my Tech Lead about the role and the challenges. I should offer to help define vague features, identifying an implementation plan and breaking down epic stories. I should seek to discover and understand the relevant high-level business, design, and architectural goals as best as I can.
The Tech Lead
Being a Tech Lead is a complicated role that requires a lot of skills that aren’t exercised heavily in the other roles (unless they sought out opportunities as a Crusher)! It takes a long time to get comfortable in the role, especially as things can vary so much from project to project. Being a good Tech Lead requires being a good system architect, a good mentor, and a good consultant. The Tech Leader’s goals include:
- I should aim to be a good mentor to Newbies and Crushers, and look for tasks providing good learning opportunities for individual team members.
- I should pick technologies that meet the needs of our customer and, as much as possible, provide good learning experiences for the team that are likely to help them on future projects: languages we use frequently, architectural patterns that pop up again and again, and principles that provide a solid foundation for almost any project. I should not take shortcuts that don’t generalize well, unless the budgetary wins are significant.
- I must view our planned architecture and design patterns not just as artifacts, but as messages and perspectives that must be continually reinforced and strengthened within the team and across engagements.
- I should pay close attention to the challenges the team is facing and treat them as signals regarding the efficacy of the project architecture and tooling. Team frictions and pain points are my learning opportunities, indicating areas of improvement.
- Since Tech Leads are often the most experienced developers and consultants on a team, I may need to seek out others in the company who can provide the additional perspective and critique I need to grow.
- As a core voice in our HCD process, I must constantly learn from the customer, the Delivery Lead, and the Design Lead and continue to help the team better understand our mission and priorities.
Getting to Giving
A final aspect I’ve noticed in my career at Atomic is a gradual transition from having a lot to learn about what we do to having a lot to teach. As this has become more clear to me, it’s pushed me to shift my focus more toward being a good mentor and teacher and a little less toward learning about technologies and development practices. Put another way, the thing I’m aiming to learn more about now is being a better mentor to people and a more effective teacher of development and consulting skills.
In hindsight, this is an area I wish I’d been more thoughtful about when I was younger. My focus was on the elegant thing, the satisfying thing, or the thing that seemed the least stress-inducing. A mindset that included more of a view of projects as learning experiences for myself and the team would have better helped me and others I was working with grow more effectively as a team.
Here’s to the next 12 years.