matthewtpowers Goto Github PK

I got the inspiration for this from a few other CTOs in the startup community. As I began to work with more and more folks over the years I realized that I spend a lot of time explaining who I am, my engineering and product philosophies and generally just what it is like to work with me. This document isn't just for teams I manage but anyone I work with.

These are thoughts and philosophies that I hold true after 20+ years running teams and building "stuff". They are my thoughts and my thoughts alone (and are subject to change). I draw from and love to speak about the wildly different experiences I have had throughout my career and evolve the below from time to time. If you have feedback please let me know.

I graduated from Fairfield University with a BS in Computer Science and then went on to get my Masters at Boston University in Computer Engineering with a concentration in Software Engineering. I have worked in large companies like Raytheon, founded startups, been part of a Series A, B and C. I have been an IC (started my career as an ADA developer, then moving onto Android working on the very first G1 phone). I have managed small teams (starting from scratch) and large(r) teams (40+) and everything in between. At the core of it I love building things, whether its tech, teams, processes, you name it....building something is a passion of mine

I currently reside in Boston, but I have lived in CT, Boston, then NYC (Greenwich Village) then back to Boston etc. When I am not working I love to sit on the beach and read or travel around the world with my travel partner (and loving wife) Molly. I am also an avid Boston sports fan (sorry) and Celtics season ticket holder.

The CTO of an org can have many different roles (and it completely depends on the size and maturity of the organization), but the best ones (IMO) are key contributors to the overall strategy of the business, learning on their tech background to help the business make greeter decisions as a whole. They are able to adapt and setup their engineering teams for success given the constraints around them. The good ones also play key individual contributor roles as well.

• IC Role - I have found well rounded CTO’s can:

  • Make buy vs build decisions (and own your own P&L)
  • Make sound technology decisions in the following areas
    • Architecture
    • Platform Development
    • Delivery Processes
    • Devops/Sysops
  • Manage the delivery of software (through PRs and release engineering)
  • Work closely with other ICs on team projects (such as product management)
  • Be a liaison between different parts of the organization
  • DO THE DIRTY WORK - resources are always limited - never let yourself stop getting your hands dirty

• Leadership and Engineering Management

  • Be able to articulate and effectively communicate engineering items to other key leadership in the org
  • Setup scalable solutions to grow the technical capabilities as the needs of the business change
  • Be efficient and effective and implement high standards when it comes to hiring
  • Be a mentor
  • Be a plow (remove roadblocks)
  • Be a human

When you work at startups and small businesses like I have done recently, you need to be able to balance both roles effectively.

Some of the aspects of my management skills come from reading different materials out there - but most of it has come through managing people for quite some time now (15 years!). I value the following in my employees and my teams (in no particular order)

• Transparency - no team can work effectively if they are not transparent with one another (as well as with me). Transparency builds team cohesiveness and is super important to a successful team. Whether it's working cross functionally or with your own team members I put the utmost importance on constructive and transparent teams. If people can collaborate openly and positively it will lead to less stress, more productivity and higher positivity throughout the org Predictability - teams with good processes (not to be confused with excessive processes) are better for your mental health. Knowing what to expect every day you walk in (or sit down if you are remote) and minimizing surprises go a very long way. I expect to be predictable and reliable and expect the same out of my teammates
• No finger pointing - stuff goes wrong all the time, that is the nature of the work, so we need to feel comfortable celebrating wins but also acknowledging losses in a constructive manner
• Thinking two steps ahead - thinking of the impact of decisions on the rest of the business or codebase is something I value as a leader. Sometimes we have to make decisions knowing that there will be consequences down the line, I am fine with that. But I like to have those laid out and I hate surprises.
• Continuous improvement - I like to put together teams that have like minded individuals on them and I am big on continuous improvement. I like to set goals for myself both personally and professionally and I like to work with people that have goals for themselves and push themselves to be the best version of themselves they can be

Finally, and most importantly, my primary responsibility on any team I manage is to them, not the product, not the code base..but to the people I work with. I have built deep meaningful relationships with the people that I have worked with over the years, I have been to their weddings, I have celebrated their first born and everything in between. Their success and wins mean more to be than any successful business. I pride myself on making myself accessible to my team 24/7.

Some logistics .. Hiring, 1:1s, performance reviews (yay microfeedback) and other stuff

Thanks for reading!