How do we know that a team of engineers are performing well? How can we tell that one company is producing better code than another? Is it the size of the engineering group, or perks the engineering team has, the amount of code or the speed of their application? Is it the budget the engineering team has to work to support the end product. Is it the amount of support the engineers have in terms of project managers and dedicated QA personnel? Is it the amount of work from home days? Many different techniques are used and companies employ many different techniques help keep their engineers motivated and support quality code. Its more than just the tangible assets that help engineers be their best. There different approaches taken and each one has its good and bad. Some are more bad than others but it takes the right perspective to understand what the goal of management is. In my 8 years of engineering experience I have seen a lot of poor engineering decisions and I've come to realize that there is always an underlying reason for why code is produced in a messy or clean manner.
There is the "no owner" style of management.No one takes responsibility for what is actually a correct way to do things. Many features are requested with little detail and vague designs. The engineer is responsible for checking and making sure things are correct. There is little separation from the developer any feature requester. The developer is left to their own devices. The only thing the project manager wants to know is when things are done. Usually a feature is requested and put in the developers queue and the priority will be set. Then its up to the developer to talk to the right people and get the resources necessary to complete the project. The PM (project/product manager) will point the developer to the right people when necessary but doesn't do any of the resources gathering for the developer (assets, emails, UI details, links). This method has no standards which makes it difficult to know what went wrong if a feature is late or something is implemented wrong. Usually its the developers fault. All responsibility is on the developer making this method stress free for the PM and feature requester. If you are the type of developer that likes to have input on designs and likes to discuss product decisions this method opens up the possibility more than others that silo the engineer to just tech responsibilities. This management style has more human interaction because the lack of standards around feature requesting and ownership.
In the "hyper strict" management style every part of the development cycle laid out and tied to deployment. There are standards in process as well as in documentation of bugs and features. There is a queue system that dictates the assembly line style development. This style costs a lot because you have personnel for every part of the process (QA, dev ops, pm , developer, sysadmin) and usually you have software dedicated to organizing everyone in queue. This approach can be boring for the developer as it silos them to a specific part of the product but overall its good for the product. A robust process makes the development transparent and supports quality by making sure everyone has what they need and only have to focus on what they are best at. Rarely is there an opportunity to try anything interesting for the engineers as their time as already been scheduled for other tasks by the process. This environment is good for people that only like to do their part of the job and do not want to be involved with the creative side of the product.
The "Basic Agile" style employs a small team, frequent stand-ups, and a basic deploy scheduling. Project manager keeps everyone organized while engineers relay questions and concerns to the PM. Deployments are scheduled into the process similar to the time for a feature being scheduled. This approach requires a skilled PM. The PM here is a liaison between the engineers and the feature requester in the company. The PM will usually drive the engineers schedule while also doing some of the QA. The engineers can focus on code and have a single point of reference for all their questions. This allows for happy medium between structure and freedom, keeping the engineers focused on engineering problems but allowing for PM to bring different personnel together when something needs further discussion. The challenge with this approach is getting a good PM. A good PM knows how to keep any unnecessary distractions away from the engineers (everyone wants to have direct communication with the developers to get their feature in) while making sure the developers are focused on priorities. A good PM knows how to crack a whip for both the engineers and the rest of the company and this is why its difficult to find a good PM because its as much about attitude as it is about organizing. It also helps for the PM to have some technical knowledge. Usually the last person to be hired is a PM because managers have a tough time spending money on a person that does not add new features to the product and (if they do their job well) will ultimately separate the management from the engineers. For a super small team its better to just get another developer (like 3 people) but as soon as you get multiple projects going in the company I would suggest looking into hiring a PM. As your company grows there are more moving parts and the PM is the juggler for the engineering team.
All styles have their ups and downs, recognizing who has responsibility is in each style is key. Its also important to know what you are looking for in your job and what kind of experience you want to have at work. Some people like a lot of structure and some people are good at communication and self organization. The approaches above might not describe one of your desired approaches to software development but you should take the time to think about it and be able to communicate it to employers. Hopefully you find the right place or convince your managers to make your job a better place for you. Coding is hard enough there is no reason to make it more difficult by approaching the task in an uncomfortable way.
No comments:
New comments are not allowed.