Breaking the cycle of poor technical leadership

What happens when you have a weak technical leadership? It builds dissent among everyone working on it. But how does this happen?

With a software project, more often than not, the people working in the lower ranks of the project tend to be fairly smart themselves. This means that they have their own ideas about what’s good or bad about the decisions being made. This leads to the members of the team talking to each other about why the future of the project is bleak or why working on the project is hard.

Having a general air of negativity on a project engenders a negative culture and encourages people to spend their days complaining about why things are hard rather than their work done. This leads to shorter timelines and even more poor planning. It’s a vicious cycle.

Breaking this cycle needs the following steps:

  1. Open up the floor to comments. Having a discussion will help people to feed off each other to turn general complaints into specific issues. These comments will be the basis for creating a plan on how to fix it.
  2. Take the time to make a plan. This certainly does not require everyone’s input in making a plan. This is the chance for the technical leaders to shine and demonstrate their knowledge and skill.
  3. Present and review the plan. In presenting the plan, it forces the leaders to have to defend and justify the plan. It also should be a time to review the plan and adjust it as needed. If sufficient criticism is made about the plan, then take a step back and prepare another plan and review session.
  4. Deploy the plan. With everyone’s buy-in, the plan will blossom and foster positive energy.

Doing these things, of course, requires the decision to undertake them. Hopefully the leaders within your company will be able to see the forest for the trees.

The ideal software developer work environment

Software development is an interesting job. I once explained it to someone as a job where you have to create things but without feeling like you have to so you don’t end up cutting corners or adding too many. I think the work environment plays a huge role in how well each developer can walk this tightrope.

I think when most people think about a good work environment, they think about amenities, like employee lunches, a game room, a gym, and so forth. Things which also play a key role are the application of project/task management strategies, coworker interaction and career management. All these things of course thought about from the perspective of the developer.

In my opinion, the ideal work environment only one aspect: an environment conducive to work. This sounds obvious, but it’s how such an environment is created that is tricky.

I think it is created by having the following 5 things:

  1. Trust. People were hired for their ability to contribute to the company’s goals. Blind trust is needed to avoid comparing yourself to your coworkers.
  2. Respect. True mutual respect between employees should eliminate office politics and corporate climbing. No talking up or down, but a collaborative atmosphere.
  3. Freedom. Hiring an employee is equivalent to paying them for their time spent engaged in contributing to the company. Historically this has been defined as being 8 hours of the day, but this should just be considered a standard for calculating salary. With properly managed tasks, this shouldn’t mean 8 continuous hours, but 8 “however-you-want-to-organize-them” hours.
  4. Focus. Employees at work shouldn’t have to worry about mundane things like where to go on coffee breaks or what to eat for lunch. The more the company can do to answer routine problems, the better it will be.
  5. Management. Having a well-defined and well-communicated approach to management let’s everyone know how things work. Developers need insight into their career paths and the ability to define their own future.

When discussing the ideal, it is important to know that while it is impossible to achieve in reality, it can be approximated. Simply put, however, it is the company’s duty to provide an environment where employees feel comfortable coming to and working on what they love.

The best development team

When people talk about a development team, they think about “a team of developers” but I like to think about the team a lot more holistically. To me, the best development team refers to all employees understanding their roles and working hard towards overall company success.

Let’s talk about job titles and responsibilities.

Software developer. This one is easy. You’re involved with feature development or maintenance. Nothing gets done without people to actually write the code. It’s important to have a cohesive team with a good dynamic meaning people are bouncing ideas off one another, feeling loose and motivated to get the work done. A development team hopefully has more than one developer because it’s easy to let bad habits take hold when there’s no one else to help you break them.

Developer team lead. This role serves to take the heat off of the remaining developers. Ideally it is a rotating role amongst the senior developers so as to keep egos at bay. The team lead can sometimes be needed to serve as a technical resource in non-technical meetings. He is also used to evaluate actual growth of each developer as he knows the fine details of how everyone on the team is doing.

Software architect. Usually seen as a software developer role, this role is involved with setting up the project and having a general knowledge of what’s out there and what works best for the given problem at hand. It’s important for the architect to consider how software will scale over time and ensure good coding practices are followed by all members of the team.

Project manager. This is probably the least well understood role of all. The hardest aspect for the project manager to understand is that he is there to ensure one thing mainly: that the project finishes on time and on budget. This is a hefty responsibility because it involves communicating progress. It involves measuring team performance and tracking it across projects. It involves facilitating a process and participating in the prioritisation of tasks. The biggest mistake a project manager can make is to forget their role and think it’s their job to oversee, assign tasks or put pressure on developers. This implies mistrust in the team and creates a negative culture.

Development manager. This role has another name “the developer’s best friend”. He makes sure that developers have everything they need to be happy in their roles. This means that developers can understand their career paths and are happy in the progress they’re making. If someone is doing well, it should be acknowledged and if someone isn’t doing well, they can be encouraged. This is an important role in development since more and more developers are demanding more attention in their individual careers. The development manager also ensures that technologically, the company has the skills it needs to deliver and if not to train existing or hire new staff to be able to get the job done.

Key stakeholders. When someone is personally vested in a software product it is a great thing. It counts, however, where that energy is being applied. A key stakeholder on a project presents invaluable insight and helps in defining requirements and validating that the end product is delivering what is needed. The key stakeholders will do what they do, but if you are a key stakeholder, then there are some things you can do to help the team. This mostly means saying what you want to do, but not how you want to do it. Regular meetings should be happening to keep key stakeholders in the loop.

Product manager. This role advocates on behalf of the product itself. This is best described in terms of how the softwares features compare to the competition and how easily these are communicated to potential customers. The product manager maintains a roadmap of features to keep the product competitive. If the key stakeholders want some new feature but it makes the product more complicated then the product manager can discuss how to better fulfil the requirement. He works with the project manager to understand when new things can be expected so that he can align other aspects of the business to them.

Chief technology officer. The CTO is responsible for the technological complexity of all the projects and software deployments for the entire company. He will need to make sure that the scope of the software products doesn’t devolve to the point where it costs too much to maintain or that costly decisions are being made by other members of the company. For example, if everything is being deployed in one particular technology stack, but someone wants to introduce another then it may not be a good idea because it’ll end up costing time and money, thus affecting the profitability of the corporation.

Chief executive officer. The CEO is also a valuable member of the development team because he serves as an important buoy to keep morale high. If the company is doing well, then the development team is doing well. This role is all about communication and regular status updates to give developers (and probably everyone else too) insight into how their contributions are making the company more profitable.

These roles can be seen best as pieces of a puzzle. Each member contributes something to the overall picture, none being more important than the other. What each member does comes down to their interest and skill and position in creating success within the corporation.

Each member should have trust in every other member. With great people, great things can be accomplished and if a company can put together a strong team then it will be successful.

The spectrum of development job titles

Junior, senior, intermediate… What am I? Does it matter?

It doesn’t really matter, but it does impact how you think about yourself. It also goes hand-in-hand with your role and your salary expectations too. For the company, it’s helpful because having a good team composition on a project is important. Too many experienced people means a higher project cost. Too many junior people and the project may not come out as polished.

What you or your company calls you mostly comes down to how much guidance you will need from other members of your team and the variety of what you’ve been exposed to thus far in your professional career.

Junior programmer. You have limited experience as a professional developer. Your code may be great, but you still make simple errors like misaligned code blocks, bad class names or even have issues with language syntax. A junior programmer needs programming help.

Intermediate programmer. You’ve got programming down, but you have limited experience with the common pitfalls of design. Design patterns are your friend and you probably should review big tasks with someone else on your team before undertaking a larger task. An intermediate developer needs design help.

Senior programmer. You have a fair number of projects under your belt, but haven’t started too many. You’re a leader on the team, helping design and guide features to completion. You make sure that designs are kept consistent and there aren’t too many clever bits of code. You’re looking to a software architect role for guidance when starting a new project or refactoring something across the board.

Software architect. Another word for senior programmer, but you’re the person who draws the lines for other members of the team to fill in. You also make sure that the lines don’t move. You’re also accountable (meaning you have to fix it) when the project scope changes and the architecture can’t handle it. You may not need to stick around for the duration of a project, but if your company has multiple projects, it’s probably good that you check-in from time to time. You need to get buy-in from the CTO when proposing new software solutions.

There is a hierarchy of job titles, but conceptually these are roles to fill and come down to responsibilities and level of experience. The difficult part for people is that because they are organised hierarchically, it goes hand-in-hand with salary expectations and ego. Once someone gets to a certain level, they don’t want to go down, even though it may better represent their role on the team.