If you have a team of software engineers and want to move them to Mac, you will need to consider a number of things before you do so.
Here’s what’s new in our January 2023 Release Notes:
* Tables Columns Sorting Improved
* Reconcile Commits Count Between KPI Card and the Table
* Efficiency Tab Improvements and Efficiency KPI Cards Align
Both short-term and long-term projects have their own peculiarities when it comes to team management. As a project manager or software engineering manager, if you don’t LOVE your job or feel it has a future – your team will pick up on it. If they don’t pick up your feelings from daily interaction with you, they will in your one-on-one meetings. Are you inspiring them? Do you appreciate the feedback they provide – about the project and how you’re managing it? Are you actually making it easier for them to be the best coders they can be?
Software projects, really all projects, are not created equal. There’ll be some you love. There’ll be some you really, really don’t love, at all – for any of a number of reasons. And that’s okay, except that as a manager, your mindset can have a massive influence on both your own and your team’s performance.
The difference can be weighed by a routine where everyone’s just going through the motions to get the job done. And that may be sufficient. But it begs the question as to how different things could be if everyone was inspired to do their best?
As an engineering manager, you probably aren’t writing code. You may not even be involved in a lot of technical work so much as consulting with developers and specialists to decide on the best course of action. It’s cool if you are, suffice that the management side of your job is more about enabling everyone to do their best work.
You’re not on the front lines per se. You can be, but being in a support role, you have the ability to call in the big guns to reshape the landscape. If need be, you can:
You have the resources to change just about everything. If you find changing your mind difficult, remember one thing:
“The best way to get to where you want to be is by helping others get to where they want to be.”
When your team is inspired to do their best, somehow I’m inclined to think that you’ll have a bright, bright sunshiny day… every day. Why settle for anything less?
Ultimately, every developer has their own personal objectives and one-on-one meetings are the perfect way for engineering managers to find out what they are. There are, however, some pretty big differences between short and long-term project management, especially when it comes to team dynamics.
| Short-Term Projects | Long-Term Projects | |
|---|---|---|
| Duration: | Weeks or months. Fixed-term or scope. Usually have a clear definition of done. | Can span years, sometimes a decade or more. It may have a roadmap, but it can change for many reasons. |
| Type of Job: | Development agency providing outsourcing services; independent freelance teams; contracts. | Often employees or dedicated contractors for software publishers, service providers, and/or tech-first startups. |
| Tech Outlook: | A variety of projects encourages constantly learning new skills and technologies. A wide build. | Focus on a single piece or family of software encourages specialization in specific technologies. A tall build. |
| Movie Quote: | Gump – “Life is like a box of chocolates, you never know what you’re gonna get.” | Groundhog’s Day – “Well, what if there is no tomorrow? There wasn’t one today.” |
While it’s not always clear-cut, the pros and cons of short vs. long-term projects are often mirror opposites of the other. Developers with short-term projects, for example, might wish they had greater certainty over their future. Conversely, developers who have been in the same job for ~18 months may be itching for more freedom and a chance to learn something new.
Agile software engineering managers have many tools available to facilitate team management. There’s not always enough time for a team to mature together with short-term projects. They don’t all fit equally all of the time. But some do! True, some of these aren’t “Agile” per se, but they’re still part of your toolkit.
| Strong Short-Term Tools | Universal Tools | Strong Long-Term Tools |
|---|---|---|
Essentials to starting and keeping your project on track. Resources are often more limited with short-term projects and areas of specialization more clearly defined. Walkthroughs and tips can work in lieu of mentoring. | Critical for optimizing communication, teamwork, alignment, clearing obstacles, and motivation with any project. |
Building on “everything else” – your organization has the time, resources, and a vested interest in keeping your team together longer by offering more of what other projects can’t. |
With long-term projects, engineering managers do well to remember that on average, developers change jobs every ~18 mo. If they’re competent, they are probably hurting themselves financially, if they don’t. However, good companies that encourage continuous skill development, clear advancement opportunities, and time-based bonuses can push their average to 4-5 years.
There’s a large global shortage of developers and most companies are much more open to remote teams than they were pre-Covid. Software developers have lots of options today. Even if the project you’re on doesn’t have a future, you have a future. Every project is a stepping stone, but it can be a launchpad to great projects.
Striving to make every project a success should go without mention. That boils down to delivering high-quality software, on time and within budget. But, the Standish Group’s CHAOS Report, indicates that only a third of projects meet all of these criteria.
A successful project then sets you apart from two-thirds of your competitors. By the time you factor in your project’s specific programming languages, technologies, and industries – you and your team members should have no difficulty getting shortlisted as candidates for projects needing your expertise.
Making an effort to establish a good rapport with team members increases the chances they may recommend you, but also expands your network when it comes to hiring future talent. Employee referrals are considered the best, easiest, fastest, and cheapest way to hire quality people. These tips are useful for all managers as eventually, even long-term projects will eventually be a short-term prospect for everyone.
This may seem to place undue emphasis on future work instead of your current project. The focus is still on delivering a successful software project as a prerequisite for future projects. Just, sometimes it’s the motivation of what you can achieve in the future that drives you to do your best today. It’s like why you might work a little harder this month so you can actually enjoy your vacation next month.
Having a steady job is not always synonymous with having a job that you enjoy or even want to keep despite the pay and benefits. Some high-profile companies have been called out for a lot of really, really bad practices over this summer. It’s easy to love your job and project when everything’s great. What do you do when everything is not great?
Keep a list, prioritize issues according to urgency. Remember, you’re not in it alone – and that’s why one-to-one meetings are so important. They provide you with a feedback loop and a direct mechanism to enlist every team member to help you make the team the best it can be. Merely making this your mission can improve your mindset. Each obstacle cleared provides fuel, momentum, and confidence to clear more. If your team sees that you are serious, they will almost always support your efforts.
Long-term projects are inclined to be much more stable and have mature processes for everything. Performance analytics are central to managing large-scale and long-term projects so you can spot issues and take corrective action early.
That’s really the key. We’ve seen some super high-profile examples of companies that have gone totally off the rails this summer – if not on developer performance, on behavior, and toxic environments. Big problems usually don’t happen overnight, but accumulate over time.
In project management, it always pays to correct problems as soon as you spot them – and that goes equally for your team, individual developers, and other stakeholders (especially senior management). The drama at Blizzard/Activision is a prime example of what happens when toxic, downright wrong behavior is allowed to persist. The longer situations like this persist, the more dangerous it is for anyone to even try to correct them.
| Problem | Root Causes | Possible Remedies |
|---|---|---|
| Inherited a project with poorly defined requirements | The existing team is missing essential skill sets. Problem might be compounded if the budget doesn’t allow hiring or outsourcing needed skills. | Map out what you have and don’t have; work with the project owner to reduce scope, delay implementation, or how they can get creative with funding. |
| A critical stakeholder is not engaged. | Poor feedback loop delays critical decisions and moving onto the next step. | Explain (and quantify if you can) the impact to either get them more engaged or to appoint/delegate an assistant. |
| Task management generally | Team members are slacking in updating tasks in the PMS or there’s excessive rework due to changes in task descriptions. | Work with the Scrum Master to achieve unambiguous task descriptions. Set standards for PMS use. Verify everyone is trained to use the PMS. Moving to a new PMS is likely to only compound the problem. |
| Toxic environment | Arguments, insults, abusive behavior, etc. | It happens. Involve Human Resources. If no HR, identify and talk with the main instigators. Company policies and local laws must be observed to avoid bigger problems. Your #1 task is to document everything so you can substantiate a trend of disruptive behavior. If corrective actions don’t work, firing the disruptive employee/s may be your only workable option. |
| Consistently not meeting Sprint objectives | Many possible root causes, but worse – they’re probably compounded by an upset client or c-level over missed deadlines; the team feeling pressured; future Sprints getting thrown out of whack due to excessive defects/rework. | Hire more devs? Probably not. Overtime? Maybe. The root probably goes back to poorly defined requirements, lack of due diligence in hiring, or team structure. Prioritize efforts and plan for some technical debt. Restructure large teams into smaller teams to reduce process complexity; use story-splitting to facilitate lower task/code complexity for less-experienced developers to help increase test coverage, reduce defects, and improve cycle time. Analytics will help narrow down which factors are contributing the most. |
Having evoked the “Chaos Report” earlier, we must at least mention what may be the greatest project management challenge of all. Legacy systems, especially those rooted in the technologies of the ancient Mesopotamian peoples, can evoke nightmares of Cthulhu. Legacy systems exist for many reasons:
There are a lot of things that could be fixed or perhaps even updated step-by-step to make managing ”legacy” systems easier. And quite often, refactoring and “fixes” aren’t allowed for these same reasons. In To Rewrite or Refactor, we highlighted a CXOTalk interview with David Chou, VP, CIO, and CDO of Children’s Mercy Hospital noting that many organizations spend 80% or more of their IT budget simply maintaining their legacy systems.
When you’re team is constantly dealing with old, shite code and isn’t allowed to fix it, you can bet they’re already looking for a new job. If not, Cthulhu may have already sucked out their soul.
Okay, a little drama never hurts… too much… usually.
The solution? A champion of digital transformation must arise and make an exceptional effort to show the organization that (in all probability) they are losing money by keeping their antiquated system.
This champion could be you. You will need to map a path forward, how to replace the system while keeping the old one operational. You’ll need to show what this will cost and how it can be financed, ideally with realistic ROI projections. It could be a monumental task. It could also be 10x easier than you think – where the majority of your effort turns to investigate how you can leap-frog technologies. This, however, is a topic for future discussion – but it might banish Cthulhu enough to where you can see some light at the end of the tunnel.
