I’m back at it again after a night of watching one of my sons play hockey and playing some Smash Up with the family. I finished the first chapter of the GDQuest tutorials called “To Space and Beyond”.
Next, I watched Adam C Younis’ video on “How to Start Learning Game Engines and Development” just to get some perspective from someone that I think does a great job of documenting making a game. Adam has a YouTube channel and a Twitch stream. Watching that video, I learned about Processing.org – which I didn’t realize I had interacted with by using p5.js.
Adam C Younis – Super straightforward video today about getting started in game development
One thing to note is that Adam uses Aseprite to edit his sprites with layers, which is great to know because finding a program that another dev is using to make a production game involving many changes is great to know. Here is a link to his playlist on Pixel Art
8:30 AM
Oh man – I’m procrastinating. Got sidetracked on the whole Adam C Younis thing and reached out to my one teenager who is into art but not programming to share the channel. I’m still trying to figure out a way to help them see the path to having a successful career isn’t based in finding something that “pays a lot” but rather a blend of both what you are passionate about and something you can make a living at. And to note, I do have an art degree but I never had someone to mentor me in getting into the game-making arena. I’m actually hoping my artistic teen will be able to help me do some of the art for some of the ideas I have – that would be a fun collaboration. Time to get back to learning!!!
11:30 AM
Gotta call it quits for the day – but I made it pretty far along, working on showing a scoreboard that leveraged adding nodes dynamically. This all feels so familiar to all of the other work I’ve done over the years in application development, so I’m really happy to have some familiar concepts to lean on during this adventure.
I bought a course on how to make Godot games from GDQuest.com yesterday. It was 50% off, so I figured it was finally the time to pull the trigger and do what I’ve always wanted to do since I was 5 (over 40 years ago): Build a game.
8 AM
So, I’ve downloaded the course, I’ve got Godot running on my rig, and I have my coffee. The GDQuest course files have been backed up so I can share them with my kids.
2 PM
By the afternoon, I had managed to get through learning the syntax of GDScript (which feels like a mix of Python and JavaScript). I figured I would walk through everything that you need to learn, since there are always nuggets out there to learn.
I did a quick tutorial of assembling some final pieces of the game so I got a sense of where we are headed on this journey. It felt more like a level builder and less like actually writing code for a game.
GDQuest then had me start from a single sprite (a ship) and throw some basic actions on it. To be honest, what I got done in a single day with a tiny bit of code is way more than I ever got done in 3-days of messing around with code in previous years. I’m feeling incentivized to continue the journey.
All information within leans heavily upon my 15+ years of working at SaaS organizations. Your experience in a non-SaaS org may differ.
“What am I supposed to do now?”
When I first became a Software Engineering Manager, I struggled with this question for months. I remember many times finishing up my workday wondering if I had earned my paycheck. I felt lost when I moved from being an individual contributor who wrote code to a manager whose daily activities seemed to involve anything but that activity. I had wrapped up so much of my identity in the ritual of writing, compiling, and debugging that it took quite a while to finally say to myself, “No one is expecting me to open up an IDE at work, not even myself.”
One thing I want to be clear about – you may not need to write code at work, but writing code on the side and staying in touch with new technologies and practices is an excellent idea.
If you don’t write code, how should you be spending your days? If I had to pick one word, I would say it should be “engaging.” Your value is no longer in building an application but rather ensuring its successful delivery. Success means making sure that your teams are building the right product, the right way. Those are two very loaded phrases.
The Right Product, The Right Way
You may imagine that the product manager would be in charge of defining “the right product.” I would agree, but with a caveat that they clarify the vision and desired end-user experience. As a leader, you should recognize that other requirements inherently exist within your organization that will have a strong influence on the development of the product. Any product has several stakeholders – the customer/end-user, support teams, infrastructure, accounting, sales/marketing, product management, and engineering. While each stakeholder has different concerns, the primary considerations should align on having a delightful customer experience.
Your Responsibility to the Customer
As an engineering manager, you are directly responsible for your teams delivering the reliability and performance of the application, which works as intended and designed. The integrity of data and uptime of the application falls within your purview, either directly or indirectly. Defects and poor performance typically land at your feet. Your organization will expect you to address these issues and formulate a strategy to ensure that the problems do not happen again by addressing any technical or process shortcomings.
Your Responsibility to the Support Teams
First, let’s be clear that support teams dealing with application issues exist solely to address product and engineering shortcomings, including poor documentation, poor user experience, and poor onboarding. As an engineer working on a product (managers included), one of your responsibilities includes ensuring that as few calls as possible funnel over to the support teams. Reducing support outreach from customers can be achieved in several ways, such as:
working through edge and corner cases during story grooming
collaboration with the proper groups to create product articles/videos
working sessions with designers when you feel that the current implementation may introduce too much customer uncertainty in proper usage
creation of adequate monitoring and alerting so that engineering can proactively inform support/customers of an ongoing issue
Your Responsibility to Infrastructure
If you develop software to run locally on a device, you may want to shift some of the points made on this topic. Your application will come with some overhead that includes CPU and memory consumption and possibly the opening of communication sockets which will come with bandwidth utilization (ingress or egress). In all cases, this utilization is not free and comes with at least energy costs (battery utilization for mobile devices). As an engineering manager, the efficiency of running your application should be a concern. When it comes to data centers, if you seek to serve a large customer base, the efficient scalability of your application will have real-world costs. Please work with your teams and product managers to understand the requirements and impact of delivering certain key features and how they are architected. Eventual consistency versus strong consistency, high availability versus fault tolerance – each of these decisions impacts the design, development timelines, and infrastructure needs. Driving the communication of these needs and ensuring organizational alignment to these needs is the responsibility of the engineering manager.
Your Responsibility to Accounting
This item tends to escape consideration by new and aspiring development managers. However, it is important to recognize a few things you will be responsible for in a product development organization. First, there is a concept of Capitalized Expenditures and Operating Expenditures (also known as CapEx and OpEx). Take some time to read up on the subject, work with your accounting department to understand their rules, and reflect on any impact those rules may have in scoping out projects and features. Next, it is vital to recognize that the responsible spending of company resources falls within your purview. Beyond simply spending on staff, you need to consider your teams’ costs via licensing and any infrastructure utilization. You will need to balance the financial costs with opportunity costs by understanding the interplay of multiple factors, including speed to market, personnel constraints, and potential revenue.
Your Responsibility to Sales/Marketing
If you are working on building software with more than one single function, you should consider how that software is packaged, sold, and marketed. If your organization wants to have different editions (lite/standard/pro), what does that mean to how your engineers build the product? If Sales is trying to demo the product, have you made it in such a way that this is easily possible? When marketing wants to promote a feature, are you involving them in conversations about deadlines? Are you aware of upcoming marketing events that may require you to cut scope and yet retain enough to make it worth the showing off?
Your Responsibility to Product Management
It would be best if you took the time to recognize the unique alliance that exists between product and engineering leadership. As an engineering manager, you should explicitly ask what metrics need to be measured to drive meaningful decisions based on quantitative data. You exist to help ground a Product Manager’s vision in timelines, the capabilities of the current engineering staff, and the product’s technical capabilities. You will work with the product organization to align their vision to the technical organization’s roadmap. Vetting your product manager’s roadmap and seeing ways that your teams could implement a solution grounded in practical cost models and realistic timelines will help your product counterpart decide if they want to pursue a new feature. While some may believe that a product organization should be solely in charge of a backlog – if your teams are building solutions with tech debt and defects, remember that those items were never part of the original design (most of the time). Therefore, it is your obligation to build and maintain a product that continues to function reliably, which does not take increasingly longer to add new features.
Your Responsibility to Engineering
I will start by saying that security and quality are a part of engineering. You are obligated to representing those organizations to your teams if they are not already part of them. As an engineering manager, you are responsible in an acute way to guarantee that cross-team collaboration and communication is happening between your teams and other teams (this should always be true, but doubly so in your department). You have a responsibility to ensure that your teams are adhering to your department’s standards, such as writing automated tests, logging meaningful messages, following the agreed-upon SDLC processes, and writing clear and concise documentation for future engineers.
Final Thoughts
As the engineering manager, you act as the final backstop to ensuring that your team has a proper connection to the rest of the organization. It is not incorrect to think that this is also the job of the product manager. However, you are the final backstop whose responsibility is to ensure high-quality delivery of the product, which adheres to your organization’s standards, considering the cross-departmental needs within your organization and the inflection points of those departments on your team and the product.
A little over 5-years ago, I wrote a post titled “ 20 Things I Learned as a New Manager “, in which I laid out what I had learned in my first year as a software engineering manager. Some parts still ring true to me, while other parts feel naïve. I tried to remember the person I was back then, the challenges I was facing. In so many ways, it feels like a different person wrote that article and experienced management totally differently than I do today.
With that said, here are 20 things I have learned in the 5-years since penning that original article.
Make data-driven decisions. You hear this all the time, but do yourself a favor and avoid any decision-making in the absence of data. Your intuition is a romantic idea that can help set a hypothesis, but you need to verify that “hunch” of yours using unbiased data sets.
Deliver customer value. People will always talk about delivering x feature or y capability — try to focus on understanding the customer value delivered by x or y. It decouples you from the feature or capability and instead lets you and your teams focus on the bigger picture.
Build relationships. Get to know people across your company. Just because you work in engineering doesn’t mean you work in a closed-loop system. Every person at your organization exists to fulfill a business need. Every person. Recognize that your job often involves needing help from Legal, Marketing, Accounting, Analytics, Sales, Customer Support, etc. Try to understand how your department can help them.
Collaboratively set objectives with clear milestones. Setting objectives can be hard, and it can be even harder if you don’t have clear demarcations of progress. Collaborate with your teams to set a vision and a clear set of tactics that will help your teams achieve the end goal. Make sure you get buy-in from the people doing the work.
Set a bar for excellence. Don’t be a maniac and set such a high bar of excellence that only you (or not even you) can achieve. Establish a reasonable but challenging standard that team members can maintain for an extended period. Recognize that not everyone will hit your standard on day 1 or day 100. You may need to put in the work to help people achieve it. Then adjust the bar upwards.
Be compassionately candid. Don’t beat around the bush, but also, don’t be a jerk. When someone turns in sub-par work, be clear in telling them in what ways the work fell short and have them go back and work on it again. When you encounter behaviors that conflict with your organization’s core values, pull that person aside and explain why that behavior is in conflict, then offer alternative approaches which align more with the core values of your organization. Book: “Radical Candor”
Admit you don’t understand. If your team takes on a legacy project, you probably don’t know everything about it. When someone throws out a term or concept you don’t understand, please raise your hand and ask them to clarify. You might be the only person in the room who isn’t clear on the concept, but then again, maybe other people were nodding their heads while also lacking clarity. Either way, you’ve just opened up the door for a culture where asking questions is always okay.
Your calendar is your to-do list. A lot of managers tell me they never have time for their personal work. When I ask why that is, I’m often told, “People throw meetings into all the open spots on my calendar.” Well, schedule your work. If you need to reply to an e-mail and know it will take 15-minutes, find a slot and book some time to do it. Eventually, your calendar will fill up in places, but even if someone books a meeting over your work-time you can either a) notify them you already had a meeting or b) move that work time to another open slot. Remember, a to-do list is just a backlog — putting it on your calendar turns it into an actionable event.
Build autonomous teams. I would love to tell you I know everything that happens on my teams. But I don’t. I know their mission; I know what they are currently trying to accomplish, what help they need, and who the stakeholders are. I have a rough sense of any ongoing defects they face, and I’m typically up-to-date on all Slack channels. But I’m not in every meeting; I’m not working through deep design discussions. I’m verifying decisions the team has come up with, being notified that there may be a meeting that I would want to attend, and the team understands the standards by which we should operate. Book: “Turn the Ship Around”
Take notes during stand-ups. If you have many direct reports (over 10 or 12) or run 3 or more teams, try taking notes during stand-ups, which is especially easy if you work from home. Create a weekly standup document and write what each individual says. Group the document by Person and Day of the Week. This way, you can see what “Pat” did on Monday and Tuesday to detect any churn. Also, have a column for open floor questions and action items for yourself. This form of documentation will help you draw a connection to each person’s work throughout the week and let you ask more insightful questions as time passes.
Inform teams on how the business is doing. Out of anything I can do for my teams, helping connect them to how the overall business is doing seems like the one request I always get (when I’m not doing it). People want to know how the business is doing — and you probably hear about it all the time that you feel like it’s obvious. Take some time, maybe once a month or once every two weeks, to let people know how the business is doing.
Connect the dots from company goals to individual work. Help each person understand how their work is contributing to the overall company goals and how they play into the bigger picture. People want to know that their work matters — and it does, that’s why you hired them! Make sure that your teams understand where their work fits into meeting quarterly and annual goals. Help them see why their current project is important.
Summarize conversations and include action items. If you have a conversation with someone and you want to ensure they complete the work, document a summary of the conversation, including any action items along with any expected due dates—schedule follow-up meetings. The act of putting a conversation in writing and sending it to all included parties creates an artifact that allows people to either respond to if they are in disagreement or be silently in agreement with. There will be times when individuals will only come to recognize that they’ve agreed to work once presented with it in writing.
Help individuals grow as professionals. Your job is to grow and retain talent to deliver customer/stakeholder value through software development. Helping individual contributors understand how to navigate their careers and how to grow is on you. Being a software engineer is more than writing code — it’s about collaborating with other team members and across teams. It’s clear communication and follow-through. It’s handling a production outage, running post-mortem meetings, creating presentations to sell an idea, and documenting procedures for future team members. It is gathering requirements and being a driver for objectives. It’s holding others accountable and being open to being held accountable. Your job is to make responsible, collaborative engineers that others enjoy working with.
Practice a healthy work-life balance. By taking at least a few days of vacation every quarter, you set a good example for those around you regarding balancing work and relaxation. Let people see you’re human. Also, if you are sick, stay home — I think that goes without saying after 2020, but seriously, be the example of what to do to avoid getting your entire team sick. And while I know everyone has a different health situation, try to establish healthy work habits, like working a normal set of hours. And while occasionally reaching out on Slack or email after hours is okay, try to establish healthy boundaries outside of work hours, which will allow your teams to feel like they can unplug.
Speak up. After years in leadership, it still shocks me how quiet other leaders can be. Ask a room full of engineering managers a question, and it is shocking how few of them speak up. I’m not asking you to be the first one to voice an opinion, but if you notice there’s a lack of input, either chime in or try to get the ball rolling on the topic. We all know how awkward it can be to stand up in front of a room full of people and face a wall of silence after asking a question — be kind by getting the ball rolling.
Know what is happening on your teams. This sounds so obvious, and yet it can sometimes be elusive. You have 1-on-1’s, meetings, interviews, and a small fire to put out. It isn’t surprising that we can lose track of exactly what is happening on our teams and the exact status of a project from time-to-time. If you are consistently experiencing hectic weeks, be sure to invest in developing team leads that you can rely on to help you stay on top of projects. And always make sure you can attend stand-ups.
Be an accountability partner. Most of the time, if you are working with good teams, people want to do the right thing. It just so happens that there are often so many things to get done. So leverage quarterly objectives to help keep them focused on the most important work. Then check in on those objectives at least every month. People don’t mind being held accountable, but it helps if you can partner with your team members and regularly remind them of their objectives. Consider adding reviewing objectives as part of sprint reviews — ideally, your team members’ objectives are widely known and aligned to their work in the sprints.
Every manager is different. This took me a while to realize. It seems obvious now, but when I started as a manager, I assumed that there were just a few different ways to manage. Then I came to realize that every leader is different. Some are amazing project managers, others are great people managers, while others are great technical managers. I have experienced directors who have deep insights into how people can improve — and VPs that can motivate their entire departments with amazing goals and consistently hitting their OKRs. All you can do is be you. You got this position because someone saw something in you. Don’t doubt that you belong in the position.
Your team is made of the engineering managers that work with you. I used to think that my team was myself and everyone I managed. While I am part of those teams, my Team 1 is the group of engineering managers I work with. If you are fortunate to be in an organization of several engineering managers, those folks are your team. They are the ones to bounce ideas off of, the ones to grab lunch with when things go a little sideways at the office. Your problems and concerns are shared amongst that group. Only they can understand the exact pressures that your position holds at your company. Work hard to create meaningful relationships with those folks and try to meet with them regularly — even consider holding stand-ups with them several days a week.
When I switched career paths by becoming a software development manager/leader, I didn’t understand completely the journey I was about to embark on. Management had never been on my radar as something I wanted to do. Luckily, the people I worked with were very patient. With that said, 20 things I have come to recognize during my time in management, in no certain order:
The best intentions will almost always go awry. Own up to your mistakes immediately and move on. Always take ownership of everything you do, right or wrong.
Trying to make something happen is nowhere close to as good as creating the right conditions to allow something to happen
Finding good people is hard, keeping great people is even harder
Give the whole picture or don’t give any at all — partial information leads to anxiety or misunderstanding
Keep the big picture in mind and only change what needs to be changed
It is almost always better to wait and plan than to act/react quickly to tricky situations and have to adjust on the fly.
It is almost always better to let your teams work it out themselves than to get involved directly.
Hire for culture over talent, hire for raw talent over experience. Given two technically equivalent potential hires, hire the one with better soft skills.
Sincerely saying “Thank you” and “Good job” is sometimes more important than any bonus.
Challenge people to perform above what they think they are capable of doing — sometimes it is better to throw the hardest tasks at the people who have the least amount of experience in that task.
People change. Constantly. A bad employee can become a great employee, a great employee can become a complicated employee. 99% of the time, people have good intentions but bad execution.
Have patience, all things change with time and some applied effort.
Authority is best displayed through influence, not direct intervention.
Don’t be afraid to intervene when it is needed.
Never take credit when you can give it to your employees. Use “we” when talking about successes. Use “I” when talking about failures.
Stand up for your employees, not because they are weak, but because they are too important to be pulled into any politics of your office. Be their advocate at all times, but don’t defend indefensible actions — take ownership of your employee’s missteps and address them.
Talk less, listen more. Act on your promises and don’t promise anything that you aren’t sure of — offer to try when you aren’t sure.
Be involved and smile. No one likes an out-of-touch moody boss.
Try to stay in shape and eat healthily; there’s no time for being sick.
Don’t manage, lead.
No one is going to thank you for doing a good job — it’s the equivalent of saying, “Thanks for not screwing everything up” or “Thanks for doing your job.” But when you look out over your teams and your department, if you have done things right, things will begin to hum like a well-oiled machine. If you are doing things wrong, you will spend your days putting out fires.
Be honorable in your actions and do the right thing. Your focus should be on the careers of your employees, not your own career. Doing right by your employees and getting things done will naturally advance your own career. Remember, there is only so high you can climb, with each step becoming more precarious than the previous step. Get solid footing before trying to climb another rung. It is easier to climb when people are helping to push or pull you up.
Remember that family and friends are more important than any job. That’s true for you and the same holds for your employees. Make sure that you unplug on your days off or at least as much as possible. You will undoubtedly change jobs, but if you are not careful, you may inadvertently change your relationship and friends. Give them focus, spend time with them.
Be part of something bigger than yourself, a community if possible. Volunteer when you can. Compassion is not a limited resource, but rather the opposite — your ability for compassion grows the more you use it. Being a more compassionate person will make you have more empathy for those you manage. Remember, that compassion is not loving and it can be extended to those you dislike or distrust.
Finally, spend time with yourself. Find something you love outside of work and family. Learn to unwind — meditate. If you are a person of faith, develop a relationship with your deity/deities. If you are a secular person, deepen your relationship with nature and the indiscernible place you hold in the universe. Appreciate that all things pass and that your time is limited. Determine how you will want to be remembered by your friends and family which is never based on money or power.
The Weekend Project 