I’ve jumped between the role of a senior developer and a manager multiple times – including leading and managing a software development team role.
My first stunt in management was over a decade ago. We were building a Java-based distributed software for a telecom group operating in multiple countries. I spent a year and a half with the company as a developer before joining the project along with our Chief Technology Officer (CTO), and a couple of other developers.
The CTO and I spent several months working closely together on the initial architecture and some of the intermediate layers. It was fairly new technology so we had an opportunity to dive deep into technology that still lacked some basic libraries and web components. Spending evenings at the office debugging core code and building proof of concept solutions was certainly exciting – and enlightening in many ways.
A couple of new team members joined and I was involved in their onboarding. Just a few weeks later I got myself into a team leading position until a very senior developer with a Ph.D. in mathematics joined the team and got busy rebuilding some of the web services and data caching layers.
And a couple of days later, I was invited to a management meeting with the senior management on the telecom’s side.
Long story short, my coding nights turned into drafting business requirements and coordinating milestones with the technical team. My CTO was a brilliant engineer and a great leadership model, but sucked at project management – so I had to step in and learn fast in order to get the ball rolling.
From Coding To Managing A Software Development Team
Switching from a traditional software engineering role to a team lead or a technical manager isn’t all about coding. In fact, it rarely revolves around the programming chops anymore.
When I made the leap myself, I had to come in a couple of hours earlier and spent them responding to emails and updating the roadmap with the latest client updates. The time spent with my team was mostly spent discussing roadblocks and assessing challenges we had to work on as a team. At the end of the day, I was in charge of reviewing the latest batch of changes and updating different stakeholders with the latest updates.
We’d managed to hit the first couple of milestones and launched a beta of the product. I left the team (which included a few more developers since) and joined another team as a developer.
Nearly 4 months later, I was assigned to another techie who switched to a business analyst role. Suddenly, I got introduced to a couple of prospects and received an internal handbook on preparing flowcharts, feature diagrams, using case scenarios for both products.
I was left high and dry and expected to handle estimates for both projects, coordinate the communication with both customers and sync with the local dev team as well. It wasn’t a full-time project managerial role as a third of my time was still spent on R&D – researching different toolkits and frameworks for a logistics company and a suitable web framework for a petrol corporation interested in an internal ERP.
It was a weird balance and definitely different than a traditional corporate promotion with a long-term onboarding time (or converting to a PM assistant role working with a senior team of project managers). But I managed to hit some wins and work hard in order to complete the required objectives.
This was good training for my transition to full-time freelancing and, later on, founding my own company. I still juggle with multiple disciplines on a day-to-day basis which is probably a habit from my earlier days.
What Makes Managing A Software Team Difficult?
Managing a team is challenging by itself.
But handling a call center or a team with comparable skills and achievements is still different from managing a software development team. The following are some of the software team management aspects that make the job difficult.
A Wide Area of Skills
A technical project would require a team with diverse skills.
A good example would be a high-scale web application that depends on designers, front-end developers, back-end programmers, DevOps folks, system admins, QA engineers and more.
I recorded a video about the disconnect between project managers and software developers.
Handling different skill sets is a unique challenge that requires extensive research and adoption of the work challenges of each role in the project.
Professional managers cannot realistically mater all areas of expertise. However, studying each role is integral to building a strong team that operates successfully together. Lacking the skills to gauge experience and identify areas where a member can chime in will impact the balance within the department.
If you are not a technical manager, working closely with other senior technical members in the organization is mandatory. This could be the technical team lead within your own crew or the VP of engineering/CTO.
Software developers are known to be more sensitive to certain topics than most other non-managerial roles. While not necessarily being a “rule of thumb”, the competitive landscape comes with the occasional strong opinion and a preference to solve a problem in a certain way.
Managing a team of software engineers can introduce additional challenges leading to heated discussions on the technical end.
This isn’t necessarily a bad thing. Managing a sales team isn’t trivial either. Grunt workers often require micromanagement as they primarily take a low-end job “for a living”. Understanding how software engineers think and operate will help you make a smooth transition.
Resource management in software engineering is one of the trickiest aspects of them all.
Agile projects introduce short sprints and delays (or leaves) that may impact the milestones. Waterfall projects occasionally come with unexpected surprises that would eat up extra time.
Team members who switch between a couple of projects may also have a hard time focusing on the project at hand or handling all of the workloads at once. It is a fine balance, especially when you account for energy management, bringing some diversity and creativity to the job profile, and handling motivation effectively.
The competitive market leads to a quick turnover. Software engineers usually stay with a company for about 2 years (the number may be higher for more reputable companies offering better perks).
But turnover is somewhat common and requires a multitude of hacks when it comes to hiring and onboarding, managing a software development team working on other projects, and handling the ever-changing scope of work.
The complexity of the engineering job combined with short retention cycles commands the need for additional documentation and onboarding. Plan your monthly or quarterly schedule and ensure that technical documentation, commit messages, your project management system — everything is kept clean and easy to follow from new team members.
I’ve met project managers with a purely business background that did well at the job – but the majority of the non-technical managers may have a hard time understanding feedback or complaints from their team.
Accepting client requests lightly that may be complex on the technical end may build up the pressure, too. Nagging team members without understanding the underlying layers will also cause some extra tension.
Our head of PM is not an engineer herself. But she’s investing a good chunk of time on reverse-engineering business requirements, understanding the high-level caveats that the tech team meets, identifying ambiguous areas that would otherwise contribute to scope creep.
Unlike other, more straightforward roles, software engineering is about turning business requirements into practical applications.
Most roadmaps and specifications are up for interpretation. Therefore, 10 different engineers may easily build 10 different versions of a product – with varying flexibility, stability, scalability and workflows.
Being unable to manage those upfront will impact the milestones and lead to consecutive iterations of back and forth.
Assembling a software development team often includes roles with different levels of skills and experience.
Due to the dynamic nature of the industry, assigning the right people to the right assignments is quite a challenge. Junior developers may handle repetitive and somewhat easy work.
But this may also require additional layers in-between in order to simplify the process.
Failing to design the right architecture from day 1 results in technical debt that keeps creeping up during the ongoing development of the project.
Variety and Excitement
Software developers often leave companies due to poor management, but some “job hop” for more exciting opportunities. Engineers want to evolve and progress without sticking to the same boring job over and over again.
When I say “boring job” I’m not referring to a single company. Maintaining a variety on the job with interesting projects, career opportunities, collaborating with new team members may be more than enough to keep your engineers sharp and help them develop new skills on the way.
Project managers need to be proactive in monitoring for mood swings or keeping a developer on the same type of activity for too long. Juniors need to progress slowly and seniors need to undertake different types of challenges. It’s an art by itself.
Bringing the right attitude to the team is not easy. A great project manager should juggle between the team’s workload, the senior management’s requirements, and the client’s wishes.
It’s a fine balance that aims to boost the morale in-house while getting the work done.
How Can a Non-Tech Person Effectively Lead?
Collaborating with experienced technical leads is always the best possible way to move forward. Project managers can team up with CTOs or tech leads, what about senior management though?
I always advise non-technical executives to find a technical co-founder, a reliable external consultant, or appoint a person in the team who could take that role accordingly.
The thing is, programming is executed primarily behind the scenes. It’s not something that you can evaluate visually. It is comprised of software architectures and different layers in charge of stability, performance, compatibility, security.
If you are unable to find the right person who can conduct independent code reviews or assess code quality, I would focus on two separate areas:
- Defining actionable requirements and use cases
- Setting measurable and practical KPIs upfront
The first part revolves around creating a process in terms of defining a feature set and the expected behavior.
It’s easy to point your team in the right direction if you are a technical person. Still, you can leverage some proven processes for creating assignments or reporting bugs and usability issues.
Here’s the bug report template that our technical team uses in-house:
Our technical leads and technical project managers are required to fill out all fields before assigning the task to a developer. While you may omit some of the areas, providing as much context as possible is paramount.
- Explain the business case in detail.
- List down your steps to reproduce and outline the expected behavior as well.
- Point to screenshots, note your browser and OS, attach screenshots.
- If you feel like it’s a minor bug, you can suggest an estimated completion time which is up for discussion.
Use Cases and Use Diagrams
When creating new tasks as a non-developer, pick a use case template that would define that context in a systematized manner. There’s a great collection of use case templates available at, for example:
More complex use cases may benefit from use case diagrams as well:
Note how different roles are involved with (and have access to) different features and components of the applications.
Developers who are not familiar with the complete context may misunderstand the initial requirements without a detailed brief discussing the available use cases. This sort of diagram may help them define the feature set in a more optimal manner, designing the right routers and validation layers under the hood.
It’s all about providing as much context, details, and required constraints as possible.
A developer needs to know what should be built and what are the desired limitations of the solution. You want the full feature set covered without exposing features to certain scenarios.
The second part requires setting technical KPIs that don’t require a programming background.
For instance, we have three core pillars of development in DevriX that we focus on in every step of the way:
While these can’t always be measured without a complete code review, there are ways to define some future KPIs and gauge them during the development process.
- The system needs to work without interruptions with 5,000 registered users.
- 50 registered accounts should be browsing the backend simultaneously without crashing the application.
- The code base has to comply with X coding standards.
- I want the platform to handle 500,000 monthly visitors.
- The knowledge base should load for under 5 seconds when we have 80,000 published articles.
- The system should pass Y security test or a review by Z security team.
The good news is that most KPIs can be measured without reaching the peak point at the end of the process.
- There are load/stress testing tools online that you could run independently. They report on load times, maximum concurrent users, or any technical errors with system outages.
- A test with multiple simultaneous users working with the platform is feasible when you invite a group of friends and ask them to help for an hour.
- Various static testing tools and scripts can run your codebase and ensure that the best practices are followed.
- Same goes for security applications (like penetration testing tools) or agencies that charge a flat fee for an external black box review.
It’s not ideal, but it works.
Management = Communication
Management is all about effective communication.
From understanding mood swings to gathering technical caveats, monitoring for tension between team members, or noticing cases of low energy due to external factors.
- Make sure that you define your requirements properly by providing the context your technical team needs.
- Set realistic expectations that could be measured externally.
You should be good to go until you scale a bit and can allocate resources to a technical consultant or partnering up with a technical co-founder.