My first stunt in management was back in 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. 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. In fact, it rarely revolves around the programming chops anymore. When I made the leap myself, I had to come up a couple of hours earlier and I would spend the time 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 the 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.
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 was a weird balance and definitely different from 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 multiple disciplines on a day-to-day basis which is probably a habit from my earlier days. 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 the major aspects of software team management that make the job difficult. 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.
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 cover 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. Software developers are known to be more sensitive to certain topics than most other non-managerial roles. Pro Tip: Code faster with TextExpander TextExpander makes it easy to save commonly-used code snippets, documentation comments, and more — then insert them anywhere you type with a simple shortcut or inline search.
Click here to learn more. Tied to your overall team goals are individual goals; these are the expectations and goals set for each member of the team. While they should have some bearing on business goals, the main driver should be personal development. All too often, these goals are discussed once per year, during an appraisal meeting and get promptly forgotten.
Having regular s is a great way to avoid this mistake. Some of the concerns that your team has will not be within your power to fix.
When this happens, you need to be good at feeding concerns up the management chain. Communication is vital here. You need to package the concern up in a way that is useful to your manager, and you need to communicate your intent with the person who raised the matter. If someone raised an issue that needs clearance from your boss, you could respond with the following:. Thank you for bringing this to my attention.
I will need to run this by my manager, which I will do today. If you treat some issues very casually, but others in a very formal manner, then your staff cannot know how best to share a problem with you. You should also strive for consistency when performing work. If you say you will do something by a particular time, make sure that happens. Doing so helps build trust between you and your team. Having an open-door policy means that any time one of your team members needs help you make time to speak with them.
Your main job as a manager is to keep your team running smoothly. This means removing blockers and being there for your team. Software development teams are made up of people with a vast range of skillsets. Make sure you know which particular skills your team members have. This makes it easier to allocate work on projects and plan for personal growth. A naive manager might split their technical team into frontend and backend developers, but there is more nuance to these skills than two categories.
Knowing who is excited by accessibility means you are better positioned to bring the correct person into a meeting. A great way to avoid the temptation of micromanaging is to instill a culture of remote work. Setting the example is about managing by doing. If you want your developers writing issues with precise details, make sure you always write first-class tickets.
Many managers expect their team to behave in ways in which they do not personally act. By living the example, you are building trust and establishing the expected culture. When setting tasks or passing on a directive, you should strive to provide as much context as possible. You have a team of smart software developers, by letting them know why they should do something instead of just what they have to do, they can work more effectively.
Managing software teams can be difficult, even for the most disciplined and well-established organizations. Every aspect of the software development process must be carefully considered and balanced, allowing multiple teams to equally and efficiently produce software that customers will truly love.
Managing these teams requires an understanding of the details of the project, along with the broader picture of relationships within and among teams, as well as the business requirements behind each executive decision. Nobody wants a boss or executive lurking around or taking note of their every move.
Thus, one of the most important roles you have while managing software teams is to hire the right people. In spite of what some reports claimed the past few years, the practice is still in full swing at Google, and has become common practice throughout the industry. One of the most fundamental rules of software development is that adding more people to a troublesome, delayed project will not expedite the process but will, counterintuitively, slow progress down, which results in an even greater delay.
Yet, time and again, executives and managers come to the seemingly obvious conclusion that more manpower equates to more output. This rule may be fruitful in certain realms of production, such as adding more hands on the widget factory line, but even in such fantasy scenarios, at some point those extra hands will get in the way of existing hands-in-progress, causing more trouble than benefit.
Similarly, development is an especially complex production, which cannot be brute forced into submission — software development is an elegant ballet where great ideas meet robust implementation. Make every effort to avoid falling behind schedule or allowing your teams to experience major setbacks, but, should such a problem occur, one of the worst things you can do is try to bring on swaths of new people to get things back in shape.
Outside of mass exodus causing a severe shortage of manpower, your focus should be on reshaping the practices and mindsets of those existing team members who are already intimately familiar with the project and its particular intricacies and requirements.
If new blood must be added to an already-bleeding project, make sure it is added through a slow drip, as opposed to a quick injection straight to the heart. Put simply, the point here is to always keep perspective when approaching a seemingly intractable issue. Instead of trying to come at it headlong and tackle it in one go, divide it into smaller and smaller tasks, until the scope of said tasks seems manageable and can be handled by the team.
If this divide and conquer technique is practiced frequently enough, there will never be any major, insurmountable problem. Practice actively listening to team members and other managers, to better understand the ongoing status and progress of each team and project.
Did it come together? Why not? What can be improved? As such, you should practice proactive communication , whether that be checking in with team leads or managers on a regular basis, or simply walking around and informally chatting with developers. This will allow and encourage team members to approach you with problems that might have otherwise gone unsaid. Managing multiple software teams can be challenging even in the best of environments, but nothing makes this task more difficult then when said teams are completely separated from one another, geographically, chronologically, and so forth.
It probably comes as no surprise that studies have shown that teams perform much better when they are working in close proximity to one another. If at all possible, get all teams working in the same building, ideally on the same floor or even in the same workspace.
0コメント