If you look up the dictionary definition of leadership, you’ll see a lot of very straightforward references to decision-making power, influence, etc. This is what people are referring to when they say things like “the leadership of the company.” It’s the group of people with power/influence to make decisions. However, when saying things like “that team lacks leadership” or “that company has great leadership,” is that what we mean? When an interviewer asks if you have “leadership skills,” what are they really asking?
Having conversations around software development and career advancement you’ll hear a lot about these leadership skills. These are incredibly valuable to helping projects go smoothly and end in success. Everyone has been on a team where nobody is leading, or, worse yet, the wrong person is leadin. The resulting mess of daily work seems to result in an endless list of messes as if by magic. Constant technical issues, inefficient processes, and lack of direction are all common signs of bad or missing leadership.
The question is: what is good leadership? How do you identify it? How do you practice it?
Roles at Atomic
Atomic Object is a consultancy that focuses on small empowered teams staffed with people with the skill sets to deliver a great product to a client. We don’t have managers in the typical sense. We have office managers that manage the business for a given office location, and they’re generally responsible for securing deals with clients and staffing teams for success. Thus they do also have hiring and firing power as someone does need to have that, but developers don’t “report” to them. We do have a few different roles, however, which help our managing partners to staff effectively. There are developers of course, along with designers to handle UI/UX for projects that need it. We also have delivery leads and tech leads, however, and these are a bit more complicated.
Tech Leads and Delivery Leads
On the surface, tech leads are like a lead developer, responsible for the general direction of technology on the project. Likewise, delivery leads are responsible for the project timeline/budget, and the general client relationship. When you start to dig into the specifics of those roles, however, things start to get a lot messier.
A set of things must be done on a client engagement for it to be successful. Those things vary by client and project, sometimes massively. Some clients will have a product owner for us to work with and some won’t. Some clients will have their own developer teams we have to integrate with, or maybe strict budget tracking requirements.
The bottom line is that each project ends up with a set of required responsibilities for a project to go smoothly, and someone is going to do them or it will suffer. This means the tech lead and delivery lead (and often the designer if one is on the project) are really more of a leadership team. Management isn’t so much granting us authority as giving us responsibility. We work as a team to make sure all those things get done. This allows us to be flexible based on individual project needs and on individual people’s strengths and weaknesses. If any of us notices an issue, we bring it to the team and hash out a way to fix it. This often results in slightly altered responsibilities for the project moving forward as we’ve discovered an improvement.
What This Means
Now I’ve spoken a lot about specifics about how Atomic works and used very general terms without mentioning many specific responsibilities. If you’re feeling like you’ve been hoodwinked into reading way too much text and you’re about to close this wishy-washy clickbait article…hold up! You’ve already noticed an important point without realizing it!
The truth is leadership is NOT about doing all these specific things, winning a promotion, or just having decision-making authority. Leadership in the context of a team is about noticing what needs doing and making sure it gets done. Yes, it’s really that simple. It’s so simple it’s the poster child for things that are “easier said than done.” Teams with good leadership are obvious to notice because the important things get done. Risk gets mitigated, processes get streamlined, and team members know where they’re at and where they’re going.
This is why the atomic model is so effective. It’s built around the idea that if you hire effectively, empowered teams are capable of leadership all on their own. The first step of effective leadership is being able to identify what needs doing. While some things are pretty consistent like risk management, team communication, or architecture, lots of other things will vary by project as mentioned earlier. Even those staples can look different depending on the type of project. This means you really need buy-in from your whole team. Everyone needs to agree to be observant about what’s happening and what’s lacking and speak up if they notice it.
This frames the earlier roles in a new perspective. Tech lead is not really a lead develope, but rather the developer that spends the most time working on this loop of making sure things are going smoothly. This means they often write LESS code than other developers. This can be in favor of doing more pull requests or working on stories in the backlog to make sure they’re fleshed out. Or, it could mean researching technology to make sure the team makes a good choice of a framework.
All these odds and ends need to get done, and the tech lead is set up to do them effectively. They’re involved in all the client meetings to get context on the problem the software should solve. They have enough experience to know the common risks and pitfalls of using some frameworks. Even something as simple as lowering the code writing expectation makes space for things like mentorship or story writing.
Note this doesn’t mean your tech lead has to be a super-senior developer. They don’t even have to be the most experienced developer on your team. A lot of people talk about how they don’t think they’re a very good leader because they only have three years, or five years, or 10 years of experience. When I talk to their team though, I hear nothing but praise for how well they managed the technical side of the project, and all the important things got done!
What does it matter if you don’t know something and have to spend time researching it? Or maybe you’re not experienced enough to know the pitfalls of something, so you ask a coworker. In the end, if you ensured that the problem was addressed you lead effectively, no matter how you did it.
Making Space for Leadership
Since we’ve defined leadership very simply, that makes practicing very simple as well… in theory. You just have to pay attention to everything going on around you and try to improve it. Look for processes that are inefficient, think of some risks that aren’t being mitigated, or find lapses in communication and fill people in. If you start doing that, you will likely start noticing your focus naturally shift from the work that’s in front of you to the larger picture more often. Eventually, this might become second nature and you can get a lot of job satisfaction from doing it well!
If you’re currently in a management or leadership position, consider making room for more team members to do this. Give them more context into problems, make space for feedback on processes, or bring them in on discussions about risk. When given the opportunity, you might be surprised at who excels at it (not to mention projects could end up smoother!). If your team is unempowered from having any visibility into what’s happening, or you shoot down any attempts to speak up or make changes, you might find that your best leaders get frustrated and stop trying. Even worse, they might just up and quit! Your project will suffer greatly for it, so try to make space for leadership!