Starting in a new place

גרסה בעברית

I blinked, and two months(to the day) have passed since I joined my new workplace. and now, siting at the airport with not much to do, is a great time to reflect on those two months and try to figure out what I have learned, what I've noticed and what I should be doing.
Since this is the first time that I join a new workplace  with some confidence about knowing my way around and holding some firm beliefs about the way things should be, I tried to be conscious about my ramp-up and notice the goals I set for myself - the long and short term ones. The most important thing I've noticed is that there is a big gap between where we currently are and where we should be. Or, to be more specific - We have a large debt around testing in the system and unit levels, communication channels that need to become more robust, lack of supporting processes and a cultural shift that we need to undergo. Mais à part ça, tout va très bien. Besides,
Besides all of these gaps, I have my own personal gaps to fill in: Having worked on a web based product until now, I never needed to dive into the workings of the OS (right now I focus on catching up on Windows, other operating systems shall follow) and the really convenient assumption of a SaaS solution - I can control the environment in which my product is running - is no longer true, which means that I need to think different variables than those I'm used to. In addition, the business world of a start up is foreign to me and business decisions have an impact I don't fully understand yet, I am not yet familiar with out clients or what is important for them to help me focus my efforts, and I still don't know the development teams I work with enough, certainly not enough to have the stack of credit I'm used to rely on to influence things. Oh, and we write code in Python, a language I don't have a lot of experience in and I'm not familiar with the tools and libraries that enable working with it effectively.
So, those are the starting challenges.
Now there's also the question of where I want to get to,  you know, once I had all the time in the world to set things the way I believe they should be. Unlike the previous place, where I believe it was right to completely remove the tester role and just stay with engineering teams (They are still working on it, to the best of my knowledge. I think that me leaving was a good step in that direction), I believe that in this place, since there are many teams working on different parts of the system, it is still the right thing to have a team that will be responsible for the larger picture. I'm unsure about how to brand this team or what exactly should fall under its responsibilities, but there's enough to do until then. One thing I am sure about is that this team should rely on strong testing capabilities that should exist within each team, so we still have a lot to do until we need to figure this out.
At the moment, though, the current situation is that there is a dedicated testing team that should provide service to three other developer teams (some of which have a dedicated tester, but from what I've gathered, they are being swallowed into doing feature development and are not able to contribute enough to educating the team or even just taking care of the testing gap), so  if I try to sketch a way forward, I imagine a growth and a shrink.

1. Build safety nets and tools that will enable teams some level of confidence in the product they are building. 
2. While doing 1, increase our reputation stack to better influence what is happening. 
3. Set in place the processes required to connect with feature work while it is being defined and executed instead of getting something vague at the end. This will require using some of the reputation tokens we've accumulated. 
4. Create a testing community, or, failing that, a testing team comprised of all people in testing positions - the idea behind this is to boost and align the testing skills of everyone, as well as a unified testing strategy and also to create another communication channel. 
5. Once things are working, roughly, split the team and distribute most of the working force to be embedded in the development teams. With the goal of having them educating the rest of their new team, helping them take responsibility of testing and pushing out relevant information.  
6. Probably at the same time as 5, redefine the smaller team left after most team members have been embedded in the teams. Initially, it will have the responsibility of maintaining the testing community and keeping the communication channels open, as well as help the testers not to get lost in their new teams,  but after this is covered, I'm unsure. For the time being, the concept of having an "Engineering productivity" team sounds quite appealing, but we won't know until we get closer if this is the correct usage of that team. Maybe, since keeping tabs on the bigger picture is part of that team's role, it will be a good idea to have that team as part of the operations group and push towards having a real DevOps culture. I believe we have at least a year or two before we'll have to deal with those specifics.

At the moment, while I'm still learning my environment, my focus is on the first bullet, which also happens to be the easiest one - build tools. Technical problems tend to be almost always easier than influencing people or culture. In the meanwhile, I'm dealing with a simple problem - we have to re-write the existing testing framework without actually saying we're doing that - after at least one time when someone said "We can't work with that, here, let me show you how to do that" we don't have the credit to do the same, so instead we refactor. Heavily. It gives me a chance to be effective quickly, even if only in limited capacity, and start building up from there. 

I need to notice that I'm not being carried away too much into the easy technical task and invest some time in building bridges to the other teams. I have also noticed how much I relied on the scrum daily standups - I feel a lot more comfortable hearing "I'm doing X" and then asking that person a bunch of questions, or suggest my help than I am comfortable interrupting someone and asking "Hey, what are you doing now? Oh, I have zero relevant input? Thanks for your time". People other than me are working on instituting such procedures, so I think I'll wait a bit and try to leverage those efforts. 

That's it, I think. 

Oh, one last thing, not completely related to this post, but I would like to use this opportunity and warn all readers: Python is a scripting language. It is not suitable for anything long-term or bigger than a couple of files. Once you are over that size, you have to fight the language to write maintainable code or do things that should be trivial, and there are too many convention-based practices out there to actually be able to rely on them. If you ever find yourself in a position where you can choose and you don't have some compelling reasons to do otherwise - avoid Python. I can go into details, but this is not the place, so here are some articles that do this for me.