Technical and design skills are critical to the work we do building software. But it takes much more than technical and design excellence to bring a complex project to fruition and run a successful consultancy. It requires a variety of non-technical leadership skills. In phone interviews with people who want to work at Atomic, we express this as our expectation that makers grow into leadership. That’s a broad statement that bears some thought and exploration.
What does it really mean to “grow into leadership” at a workplace with very little hierarchy?
I’ve spent the past four years working at this, observing my own growth and the growth of those around me. While certainly not an exhaustive list, the points below highlight some of the skills and growth that have been important to me and reflect observations we’ve made collectively about what it means to lead at Atomic.
Project Management
Starting with something relatively straight-forward and concrete, our project management practices are one of the first non-technical areas we introduce new hires to. My first project assignment, working with Dave Crosby on the myGRcitypoints web app, provided ample opportunity for mentorship and learning-by-doing as we tracked our progress and made decisions that kept us on track.
That theme of mentorship has continued through to my current assignment, working as the project lead with Drug Free Sport to build a suite of iPad and web applications to run their data collection processes, where I’ve frequently collaborated with Mike Marsiglia and Shawn Crowley on project management and tracking.
Practically speaking, project management for us means:
- Updating the team’s burn-up chart on a weekly basis
- Keeping the team effective and utilized
- Updating our customer on project progress
- Reflecting project status and team availability to the office’s managing partners
- Generally, being organized and able to respond to questions
Product Management
Product management is a complementary skill to project management. Beyond just keeping the team moving forward, product management’s goal is to optimize the team’s output to provide maximum value as soon as possible. Often, I’ve found the lines between project and product management blur when working through task prioritization.
Further into product management land are the decisions we make on a daily basis that affect the aesthetic and functional aspects of the software we build. I try more and more to keep a holistic picture of a piece of software in my mind to evaluate for consistency and fitness as we build each feature.
Customer Relationship Management
Maintaining good relationships with our customers is everyone’s responsibility, and it’s important. Project teams have support from managing partners when things get tough, but things we do every day affect our relationships. Here are a few things I’ve found that are very helpful:
- Pay attention to communication preferences — email vs. phone vs. in-person
- Communication style matters, too — paragraphs vs. bullet points vs. visuals (or some mix)
- Communicate at the right level for your audience’s understanding of software and computers
- Tie decisions and comments back to things your audience cares about
- Ask for a second pair of eyes on important messages
- Have a bullet-point outline prepared for critical conversations
- Touch base regularly to maintain a read on the pulse of the relationship
Empathize with Clients, Users, and Coworkers
I can’t say enough about empathy. The Merriam-Webster dictionary defines empathy as:
the action of understanding, being aware of, being sensitive to, and vicariously experiencing the feelings, thoughts, and experience of another […] without having the feelings, thoughts, and experience fully communicated in an objectively explicit manner
We do our best work when we understand the needs, expectations, and goals of our customers and users, and the reality is that those things are never fully communicated explicitly. Empathy is the skill that lets us peer beneath the surface of a comment or action to dig up the “why”.
One of the reasons I find certain innovation games beneficial is the opportunity to practice and improve our empathy with customers and the eventual users of our software. For example, Speed Boat gives ample opportunity to observe non-verbal communication, as well as ask explicit “why” questions.
I think it’s important to note that having empathy with someone doesn’t mean you agree with every aspect of their feelings or thoughts. But if you really take the time to understand them, there’s a better chance you’ll be able to assemble win-win scenarios.
Know how to “Zoom Out”
The longer I work in software, the more I see the value of being able to mentally zoom in and out of a problem space.
For a technical example, imagine you’ve sketched out an interface for logging in to your application. You build out a system test that describes the user interaction and then dig in to the implementation. You’re planning to rely on users’ email addresses being unique and using them as part of the authentication credentials. Now would be a good time to quickly zoom out:
- Are email addresses really going to be unique for each user?
- How strict does the uniqueness need to be? What are the consequences for the application and the business if someone shares an email address or uses a slight variation to work around the restriction?
- How often are people going to type these credentials — maybe something shorter would make more sense?
- Or, is the ability to remember credentials more important than concise typing?
Zooming out of a detailed decision to evaluate its broader impact is a skill that takes practice but also pays dividends far outside of technical realms, especially alongside empathy. I like to use these questions as aids for zooming out:
- How else could we accomplish the broader goals this task was meant to?
- How would I describe this decision/direction to a non-technical person?
- What persona(s) would find this decision or implementation disappointing?
- How does this decision or feature affect the overall value my customer gets out of the software?
Know how to Provide Value
When we hire a new employee, there’s a primary value we’re expecting — we exchange a salary and benefits for the new employee’s time writing or designing software. But that’s just a start; we’re hoping for more.
Apply your practice at empathy and zooming out internally. How can you make Atomic a better place to work? How can you contribute to goals one or two levels removed from directly doing excellent projects for our customers? How can your strengths help us become a stronger company overall?
Some examples of non-project value include:
- Blogging and participating in Atomic marketing
- Helping with interviews and hiring
- Mentoring younger, less-experienced coworkers
There are so many more. Develop your sense of self-awareness and find ways to fit your strengths to needs.
Take Initiative
If something needs to be done, why not do it? This is our Own It value mantra in practice. Knowing what to do, and how to do it, are good — being the catalyst for getting it done is even better.
Don’t work at Atomic? These are still great ways to grow.
Even organizations with formal, highly-structured leadership are influenced strongly by people outside of “leadership positions”. Leaders are people who get things done, who influence others to do good, title or not.