Codethink is a company which provides software services and consultancy. We work with our clients to help them to deliver their projects effectively and efficiently. We prefer to work on a managed project basis as we feel this usually results in the best possible outcome for our clients and ensures our engineering teams are well-supported.
The pushback against the inclusion of project management in software engineering projects is more common than you'd think, both within companies and across consultancy and service engagements. I have been a project manager at Codethink for nearly 5 years now, and I wanted to share my observations on the topic in this blog post.
"We don't want to pay for project management; we don't need it"
I'm paraphrasing, but this has been a common thread among a number of our clients over the years. As a project manager myself, I have absolutely questioned the value of my role at times, like when I try to keep up as a group of very intelligent engineers discuss some deep, dark, kernel driver issue they're trying to debug (DMA will forever be a mystery to me).
However, there are more ways in which a non-technical project manager can provide value to their team and their client than simply managing budget and delivery targets, and being present in case something goes wrong. Have you ever seen an orchestra trying to play without a conductor? No matter how skilled the musicians are, it simply... doesn't work.
At Codethink, we believe in the value of project management, and consider it to be essential for at least the following reasons:
1. Building and maintaining the best team for the project
For us, the project manager's work starts fairly early on, with the sales lead and the bid submission process. The Project Manager is the driving force to identify the skills and personalities required for a project and ensure that the team will work well together and provide value for the client.
Sometimes things change on a project which means the team assembled is no longer the best team for the job. This could be due to interpersonal relationships between team members, how well a person gets on with the client or the fact that, as tasks change, skills required change. A Project Manager's job here is to identify these situations and act accordingly, showing a level of flexibility commended by our clients.
2. Support and wellbeing
At Codethink, despite dedicated line management as you'd find in larger companies, Project Managers still have a degree of pastoral responsibility toward their engineering teams. People management is present, in some form or another, at all levels of management, and Project managers are key to building an effective team, ensuring that their team remains happy, challenged, engaged, and are unblocked from making progress as quickly as possible. All that implies regular 1:1 time with every team member and regular team-wide check-ins, and that kind of dedicated support takes time.
Project Managers at Codethink, in conjunction with line managers, enable their engineers are as productive as they possibly can be. Sometimes this means allowing for flexibility in certain cases, increased technical support on a project, or just recognising when someone is reaching burnout and needs some time away. These are all things that engineers might not be comfortable asking for, and thanks to our Project Managers being so closely involved with their teams, they can notice and prevent these risks from becoming significant issues.
3. Quack, like a rubber duck
People don't enjoy being seen as silly or feeling unknowledgeable about a topic area. In particular, software engineers seem to suffer from this, and as such, they can be reluctant to ask a question they feel they should know the answer to, or admit when they don't actually understand the task assigned to them. Project Managers can help here. No one expects a non-technical Project Manager to properly understand deep technical issues, and we can play up to that by asking simple questions which then encourages the team to build on the discussion.
Sometimes, being a "rubber duck", even as a non-technical person, can really help an engineer work through a problem. If someone has to describe something in a way that someone like me can understand, they have to think about it differently and answer questions they wouldn't usually have to.
4. Keeping the overall picture in view
It's very easy to become lost in the weeds when you've been debugging a particular problem for weeks, or if your workstream is separate to others' in the team. Engineers having the capability to get into the detail of a problem is important, reducing the need for context-switching. Project Managers are typically better placed to deal with context-switching simply because we don't need that detailed technical view. Therefore, we can keep the team reminded of the overall goals and where we are in terms of reaching them, ensuring that engineers don't stray too far down a rabbit hole.
5. Being a "s**t umbrella"
...to put it bluntly. Projects rarely go to plan. Regardless of how meticulous a Gantt chart you've put together, how much contingency and contingency-contingency you've allowed for, something will go wrong. And when it does, it's the Project Manager's job to:
- Ascertain the impact and plan a solution.
- Communicate with the client about the risk or issue.
- Shield the team from any fallout, be the point of responsibility, and ensure the blame is not put on any individual in the team.
As with any company, and more so with companies working together, there will be politics. There will be things that the engineering team don't need to worry about, there will be times when the client isn't happy, there will be frustrations at management level for various reasons. Our job is to ensure the engineering team only need to focus on getting the job done rather than worry about the logistics of doing so.
This is not about keeping things hidden from our teams - we are a very transparent organisation inside and out, and find that keeping people informed helps maintain trust. This is just about ensuring our teams trust their Project Managers to be handling the logistics and allowing them space to focus.
6. Process, process, process
Anyone who has ever looked at a PRINCE2 qualification will know how many processes and admin there can be. Effective project management will choose the aspects of any methodology which work for their current project, team and client, and use whichever kinds of documentation and processes make sense. For some projects, this could be full-scale RAID logs, change logs, quality register, issue register, lessons log, daily logs, etc. But for others, it could be as simple as a high-level weekly report and an assurance that we are not yet close to the budget cap. Either way, it is important to have someone on the team who understands how to do these things and has the time and space to do them.
"We have our own project management for this"
This is a reasonable point, and I don't doubt that client-side project management helps fulfil what is needed internally. However, in our experience it is always better for a team to have a manager who knows them, who works directly with them, in their own company infrastructure, understanding the issues that they themselves face with their own working environment. If a client wants to have their own Project Manager on the ground too, reporting back up internally then that is great - we can work together, communicate regularly, and perhaps decrease a bit of each others' workload if we do that well. Less work reporting to client management means fewer PM hours charged by Codethink, and less chasing information down from a supplier engineering team means more efficient use of time for the client Project Manager.
I don't mean to suggest that Codethink engineers aren't capable of assuming management roles. Many of them are, and many of them do. However, I am stating that certain skillsets are best utilised in certain ways, and our engineers are better placed spending their time working to solve our clients' software problems than they are trying to couple that with part-time project management.
So there you have it, my take on why dedicated project management is actually important and the key to an engineering team's success and wellbeing. Personally, it has taken me a long time to realise this value, and I often struggle to believe it even now simply because I work with such intelligent people, I think they can't possibly need me! Sometimes, when things are running smoothly, it can be easy to think that I'm not really needed, and it can take effort to remember that, more often than not, it is the project management effort which ensures that smooth running.
Related blog posts:
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- RISC-V User space access Oops
- Tracking Players at the Edge: An Overview
- What is Remote Asset API?
- Running a devroom at FOSDEM: Safety and Open Source
- Meet the codethings: Understanding BuildGrid and BuildBox with Beth White
- Streamlining Terraform configuration with Jsonnet
- Bloodlight: Designing a Heart Rate Sensor with STM32, LEDs and Photodiode
- Making the tech industry more inclusive for women
- Bloodlight Case Design: Lessons Learned
- Safety is a system property, not a software property
- RISC-V: Codethink's first research about the open instruction set
- Meet the Codethings: Safety-critical systems and the benefits of STPA with Shaun Mooney
- FOSDEM 2021: Devroom for Safety and Open Source
- Meet the Codethings: Ben Dooks talks about Linux kernel and RISC-V
- Here we go 2021: 4 open source events for software engineers and project leaders
- Xmas Greetings from Codethink
- Call for Papers: FOSDEM 2021 Dev Room Safety and Open Source Software
- Building the abseil-hello Bazel project for a different architecture using a dynamically generated toolchain
- Advent of Code: programming puzzle challenges
- Improving performance on Interrogizer with the stm32
- Introducing Interrogizer: providing affordable troubleshooting
- Improving software security through input validation
- More time on top: My latest work improving Topplot
- Cycling around the world
- Orchestrating applications by (ab)using Ansible's Network XML Parser
- My experience of the MIT STAMP workshop 2020
- Red Hat announces new Flatpak Runtime for RHEL
- How to keep your staff healthy in lockdown
- Bloodlight: A Medical PPG Testbed
- Bringing Lorry into the 2020s
- How to use Tracecompass to analyse kernel traces from LTTng
- Fixing Rust's test suite on RISC-V
- The challenges behind electric vehicle infrastructure
- Investigating kernel user-space access
- Consuming BuildStream projects in Bazel: the bazelize plugin
- Improving RISC-V Linux support in Rust
- Creating a Build toolkit using the Remote Execution API
- Trusting software in a pandemic
- The Case For Open Source Software In The Medical Industry
- My experiences moving to remote working
- Impact of COVID-19 on the Medical Devices Industry
- COVID-19 (Coronavirus) and Codethink
- Codethink develops Open Source drivers for Microsoft Azure Sphere MediaTek MT3620
- Codethink partners with Wirepas
- Testing Bazel's Remote Execution API
- Passing the age of retirement: our work with Fortran and its compilers
- Sharing technical knowledge at Codethink
- Using the REAPI for Distributed Builds
- An Introduction to Remote Execution and Distributed Builds
- Gluing hardware and software: Board Support Packages (BSPs)
- Engineering's jack of all trades: an intro to FPGAs
- Bust out your pendrives: Debian 10 is out!
- Why you should attend local open source meet-ups
- Acceptance, strife, and progress in the LGBTIQ+ and open source communities
- Codethink helps York Instruments to deliver world-beating medical brain-scanner
- Codethink open sources part of staff onboarding - 'How To Git Going In FOSS'
- Getting into open source
- How to put GitOps to work for your software delivery
- Open Source Safety Requirements Analysis for Autonomous Vehicles based on STPA
- Codethink engineers develop custom debug solution for customer project
- Codethink contributes to CIP Super Long Term Kernel maintenance
- Codethink creates custom USB 3 switch to support customer's CI/CD pipeline requirements
- Codethink unlocks data analysis potential for British Cycling
- MIT Doctor delivers Manchester masterclass on innovative safety methodology
- Balance for Better: Women in Technology Codethink Interviews
- Full archive