Transitioning into a leadership role. This is quite an interesting challenge. I have to not only learn a new set of skills, but leave behind doing most of the work, guiding others with no authority of my own.
I am a professional software tester, not developer. And even then my test experience comes from one company. I am in the best position to take lead but lack the holistic experience to be viewed as knowing how to effectively manage code.
I'm interested in being challenged and learning.
I have to take a highly customized platform and test each customized implementation at scale. I can't expect that an implementation will stay up-to-date with development of the components which build the custom implementation.
We utilize npm/nuget packaging to manage injecting customization. This requires there be a solution that brings these packages together.
I have brought up the use of forking and maintaining updates through this old concept of version control. I've also mentioned that submoduals facilitates much of the challenges we address with package managers. This leads to accusation of archaic coding practices and there are reasons everyone is moving to package management.
Now I totally think nuget and npm adds complication for what we deliver, so let's ignore that I'm only talking about what to do with the implementation repos.
See architecture is not tied to how the code is built and packaged. That means you can have a highly decoupled code even if it is in the same repo, I'd even argue that can still be achieved in the same file with the right language. The challenge we face which we are looking to solve with packages is managing changes and delivering changes. Sem versions are of course the solution to making changes that don't break anything (remember I'm QA so that means I get to test for that feature).
For me git was made to manage changes, communicating changes, and I think it helps reducing differences when used appropriately. See I posted about the first two in a previous post. By having the full source code in one location allows for deep coupling and uncontrolled change conflicts.
This is where my experience falls short, how do I create a system or process that facilitates good architecture which make managing changes easier. Yes it can be distilled down to old, tried before version control. But my research suggests this is just as new as cpan is to Javascript. See I do know my history too.
These ideas are not me against the devs, I do have support from some within development and progress is being made in this direction.
Top comments (4)
First, congratulations on being trusted to lead a technical team!
From your writing, I get the feeling that there might be reasons to change the status quo, but they may not be clear to us or indeed the team. If you can articulate what needs to change from another perspective, say the customer or your board, that may help guide what matters at the technical level. Perhaps your team needs to deliver changes in parallel? Then modularisation might help. Perhaps it’s speed of delivery? Would more automation get that done faster?
I recommend summarising these drivers and challenges for the team and stakeholders, then you can resolve them together, it’s not all on you :)
"but leave behind doing most of the work" - your first leadership lesson, if your leadership is not you doing more work then you are probably not doing it right. You have stepped up to doing far more complex work, managing ideas and people and getting those people to follow a path for a mission. People are hard to manage, even harder to lead, and most certainly much harder for most tech people to deal with than machines.
I am very busy with meetings and discussions and training. It has left me with little time to manage the work being done or to do it myself. At this time I believe it is doing it right because I'm laying out a path for less overall work to be done. So many challenges and expectations I would rather not solve at the end of the chain.
Testing is the last line of defense, it is also the first and easiest to add new steps or requirements to.
I've been doing much better with my colleagues, it is the management I'm struggling with. And yes people are hard.
I am not trying to harp "It has left me with little time to manage the work being done or to do it myself". You ARE doing the work too, your work has just changed its form. My desire to also "do the work" got a team of mine in trouble bc I was trying to do the work that wasn't management. I got it done and it worked and was all well and good, except that I wasn't doing enough of that 'non work' called management, and the team suffered. That is also why I harp on the idea that management is not 'the work', its hard to adjust the brain. I srtuggle to remember it. I know it personalty bc i generally leave a place due to poor/bad management, not the quality of the technical expertise and execution, yet i still have to keep my brain from falling back to teh "real work" argument
Test Driven Development would probably argue it is the first line of defense not the last :) You know testing so identifying areas where you can direct that to be better is a good start to feel out your own abilities. For the areas you are not as proficient, ask the people you manage (do it even in areas you are proficient too).
"how do I create a system or process that facilitates good architecture which make managing changes easier." - Ask your team. as a manager you can set some objectives I assume, make this one of them. Your job is not to know everything and be better than all the people you manage at the stuff they do, your job is to manage them and the process to meet the business objectives, etc.
On Meetings, always always always ask for an agenda, and what is the desired outcome of a meeting. Even if it is to your boss. If you are going to hold a meeting, make sure you have an agenda and a goal for it. Respect your coworkers time. There are far too many people who have power who hold meetings for the sake of executing their power by using peoples time in a meeting.