Managing Short and Long-Term Projects Software Teams Love


January 2023 Release Notes

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

Read More »

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?

The Engineering Manager’s Mindset

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:

  • Change standards
  • Adjust processes
  • Restructure teams
  • Allocate funds for experiments, upgrades, and attending conferences
  • Outsource tasks as needed
  • Hire and fire
  • Train and promote
  • Listen to and share feedback from all team members
  • Listen to and provide feedback for senior management

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?

Short vs. Long-Term Projects

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 ProjectsLong-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.

Short vs. Long-Term Management Tools

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 ToolsUniversal ToolsStrong 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.

Getting Excited About Short-Term Projects

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.

Future Project Launchpad Tips:

  1. Encourage your team to document what they (you, too) learn on the project – skills, coding techniques, tools, etc. Encourage everyone to keep a weekly log.
  2. While the technology is fresh in everyone’s minds, encourage your team to look at getting relevant certifications, LinkedIn Skill Assessments, or similar programs with UpWork, SkillValue, and others.
  3. Capture and share performance metrics as they can be referenced on your resume/CV.
  4. If the project is online; suggest to everyone to add it to their portfolio (link, description, role, achievements).
  5. If they perform well, welcome team members and stakeholders to use you as a reference for their next job.
  6. Give competent team members recommendations on their LinkedIn profiles, feel free to ask them to consider doing the same for you.
  7. As a manager, consider writing letters of recommendation for your team members.
  8. On an ongoing basis, it is a great practice to share suitable opportunities with former team members whom you think would make a great fit.

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.

Getting Gung-Ho! About Long-Term Projects

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?

  • Identify the problem/s
  • Determine probable root causes
  • Come up with ideas
  • Determine the best remedies
  • Take action

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.

Turning Bad Projects into Good Projects for Everyone

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.
Simplifying your software project management challenges goes into more depth on solving the above issues.
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.

Contending with Legacy Systems

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:

  • Change and risk-averse C-levels
  • Budget constraints
  • Investment of effort needed
  • Downtime of critical systems
  • Defunct vendors and the end of support for older systems

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.

Did you like our content?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates.
All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.

Did you like our content?

Spread the word

Subscribe to Our Newsletter

Don't miss our latest updates. All About Software Engineering Best Practices, Productivity Measurement, Performance Analytics, Software Team Management and more.