A Manager's Guide on defining engineering processes
Defining engineering processes with 4-key elements' framework
A bad system will beat a good person every time.
- Edwards Deming.
Making people in your engineering teams great is one of your primary responsibilities as an EM. But still somehow when they work as a team, it feels inefficient and always falls short of achieving expected results. On digging deeper, you found that processes that you have in place are letting them down.
Processes are systems that let your team collaborate, build and deliver software efficiently, as after all it is a team sport. Processes should never be considered as applying a brake that slows down how your team operates but rather as a lubricant that lets your team perform better and smoothly.
In recent years, thinking around engineering processes has evolved to support modern application development and all they ask for is speed 💨. Speed in which you produce software, test hypotheses and make decisions - even if it means failing at it. “Fail fast, iterate and pivot” should be the Mantra and your engineering processes should support that. Let it be moving to agile from waterfall methodology, embracing failures and preparedness of your engineering systems using feature flags and iterative releases, blazing fast deployment using CI/CD process, processes for engineers to collaborate better - a lot has changed and will continue to change as you read this post (believe it or not, estimations are still a hot potato 🥔).
Great People need Great Processes to achieve Greater Results. And Voila! you as an EM are responsible for achieving such greatness. In next few editions of our newsletter, let’s see how to make your engineering processes great again.
What is a process?
Every process takes an input and produces an output. How it produces and what it produces defines the nature and purpose of a process.
Whoa, how simple it is - sweet. Let’s define one for the software development context.
Software development is a chain of processes through which a team collaborates, builds and delivers software efficiently. But wait - it doesn’t end there. You need processes to maintain your software as well and make sure it continues to operate as expected - that is in fact equally important to building and delivering it.
Above image is an example of how a chain of processes is employed to build and deliver software. It doesn’t necessarily have to be the same everywhere in every team. A ML team will have a totally different process for them to build software and iterate fast, A software development team in traditional banking organizations are succumbed to regulations and security compliance processes in how they produce software. That’s where you play a crucial role in understanding the dynamics of your engineering team, what you build and how you contribute to your organization.
A process should make life of your engineers easier; not complicated
Any process that you define in your teams is not to make your people’s life complicated and not imposing just for the sake of it. In fact it’s the other way around. To make their life easier by having a simple and streamlined process to work efficiently and produce software predictably. More often than not, your stakeholders may not care about what process you have in your teams and how you produce software but rather care only about “when” and “what” coming out from your team.
4 Key Elements of a process
When I was an individual contributor, I had many processes in my engineering team for the sake of having it. I was clueless and felt it as a burden rather than enabling me and my team to do a better job. An open confession: when our manager wasn’t around, we never followed it as we never understood why a process exists in the first place, what we get out of it and what role we play.
Before you go on to (re)define processes for your engineering teams, get the basics right. What should be the main purpose of every process you are having in your teams? How do you make sure you get the most out of it? Do engineers in your teams understand the role they play?
Worry not, make use of below 4-key elements’ framework to define a process that brings clarity and real sense of purpose in your teams.
Purpose & Goal: Why does a process exist and what are its goals?
Output & Artifacts: What is the outcome of a process? What do you produce as artifacts?
Roles & Guidelines: Who is part of the process? What role do they play? Are guidelines defined for understanding of how to follow the process?
Operation & Consistency: How often is a process to be carried out? Can the team autonomously run a process?
Let’s take the code review process as an example and define using 4-key elements’ framework to put it into practice.
Purpose & Goal
Why does a code review process exist and what are its goals? - To let your engineering team review each other’s work and produce software collaboratively that conforms to the agreed coding standards and practices, to ensure code is doing what it is intended to do and overall health of the code and system isn’t deteriorated greatly. Remember the code is under scrutiny not the person who wrote it.
Not having that clarity on purpose and goal of a code review process leads to various interpersonal issues, distrust among teammates, ultimately leading to bad quality delivered that deteriorates overall team’s performance.
As an EM, it’s your responsibility to make sure every process is well defined and everyone in the team takes part in defining it, agreeing to it and following it. Organizing a workshop would be a great idea to define the purpose and goal of your team’s processes where everyone shares their thoughts right from the start and clarify any misunderstanding they could have on the process.
Output & Artifacts
What is the outcome of a code review process? What do you produce as artifacts?
Code review isn’t a bug bounty program where you hunt for bugs but rather your team gain understanding as an outcome, review changes for continuous improvement and make sure it’s maintainable by producing quality code as an artifact.
Roles & Guidelines
Who is part of the code review process? What role do they play? Are guidelines defined for understanding of how to follow the process?
Defining clear roles in the code review process will make the life of your engineers easier and know what is expected out of them.
Requester: One who requested for code review. A requester can review their code themself before submitting a code to be reviewed by others but changes have to be at least reviewed by someone else to approve and give them a green signal.
Reviewer: One who will review the code changes. One or more people can be a reviewer.
Approver: One who approves the code change. Subject Matter Expert of the code under review shall be the approver.
What role do you play as an EM in your team’s processes? - You can participate in any of your team’s engineering processes that you wish to. Let it be fixing a P0 production issue, reviewing a code change, delivering and monitoring your release etc. But you should never turn into a blocker or a single point of failure. If you take yourself out of any process, it should continue to work and your team should be capable of carrying it out with ease.
Do you have code review guidelines defined in your team? If not, drafting one would totally make sense. It will serve as a reference for new joiners on how to do code review and even can help those who spent years in your team.
Operation & Consistency
How often is a process to be carried out? Can the team autonomously run it?
Timeliness of your code reviews has a direct impact on the lead time of your team’s deliverable. Your team should have the awareness that a code that isn't reviewed for days can affect overall delivery speed. Keep your code review process as decentralized and autonomous as possible and your approval shouldn’t be mandatory but rather a backup.
Do you want to give it a try? - Pick any process that you have in your engineering team and define it (can also be done collaboratively in a workshop with your team) with 4 key elements’ framework. It will be totally worth it. Once you feel confident about it, discuss with your team and you will be fairly surprised by the real need of such discussions.
That’s it for now - In the next edition, I’ll be publishing about how to evolve your engineering processes, how to bring in a change as a leader and how that plays out with your teammates’ motivation and buy-in.
What are your struggles and learnings with software engineering processes in your teams and how did you evolve? - I would love to know your thoughts.