For a Software Developer, it can feel unrealistic to think of being the Engineering Manager of, say, dozens of people in the future.
Time passes by. The future turns into the present.
One day you realize that being a manager has the potential to dramatically increase the influence you have. Together with your teams, you can achieve much more compared to working on your own.
I believe the set of principles below will help you to become a leader worth following in a shorter time frame, particularly in the Software Engineering world.
1st principle: Make changes happen
Stay focused andinvest your time into improvements of a bigger scale. Don’t stay at the level of resolving small daily issues, which results in hundreds of items in your Trello to-do list.
Mission
To avoid the trap, form a Mission Statement and transparently articulate what you plan to achieve on a mid to long-term basis. Make people collaborate on it. Having the Mission Statement, you will ditch the majority of out-of-scope items. The other trick is to refer to your company values to evaluate which initiatives are most aligned with them.
Tip: If you manage your priorities right, you’ll end up with up to eight different goals underlying your Mission, spread over months or quarters. Make sure you ship one bigger change every six weeks on average. People will spot and follow your example of making improvements often, as well as being consistent in the direction.
Source: Mindful Ambition
Communicate what is the next Mission iteration to be accomplished and provide progress updates as much as you can. In parallel, ask for feedback (i.e., NPS score) and evaluate whether the direction helps people and the company to grow in the most realistic way.
A senior manager doesn’t feed his satisfaction demands by completing small, insignificant to “seems to be urgent” tasks just to get a false feeling of accomplishment.
2nd principle: Make people the center of the Universe
You are nothing without your people. Deserve to gain their trust.
Get comfortable spending 3/5 of your time talking to developers, your peers, and top managers, both informally or straight to the point.
Learn to delegate. Help others resolve most of the upcoming issues. In case the problem is complex, step-in, use the divide and conquer strategy, or create the Tiger team responsible for wiping the problem away.
Great managers move from doers to facilitators. Ask what obstacles prevent people from resolving the situation. Then remove the impediments and ask them to build the change. Most importantly, make sure you have a follow-up on whether the situation was resolved. Praise or ask to improve. If there’s failure, make everyone learn from it and blame yourself.
3rd principle: Understand the Product
Ensure you do your best to learn the Product end-to-end: Why our solution brings Value to customers and what is the differentiator. Companies have usually several sources of Knowledge. Look for the videos, release notes and wikis in the first please. Secondarily, talk to all the Product managers and domain experts to deepen your knowledge and answer questions.
Having the product knowledge, you will understand why feature X is of higher priority, including customer impact. You can also enter the product discussions, which ultimately increases mutual trust.
4th principle: Step outside
Leading the software development department is not about having all the teams and internal processes work like a charm. Such an approach makes you focused on a local optimum only (typically Jira tickets with low lead time and high throughput) and paves the road for failure. Instead, step outside of your bubble.
Focus on cooperation and outcomes.
In addition, make sure you have valuable relationships with your managerial peers, and Product Managers in particular. In the work environment, people copy behavioral patterns from the top. Managers with great relationships lead departments with great cooperation.
Excellent Engineering Managers are the ones who, only when necessary, create simple contracts between departments to help people handle situations seamlessly (can be input/output queues capacity caps, clear priority definition, an SLA response time in 4 hours during the workday, or features with average lead time). Context-switching is very expensive. Such agreements are an efficient way to prevent firefighting situations and keep people balanced and focused in the long-term.
Bonus: Master the Essence of Management
In the context of Engineering Management, I prefer the definition of Managing the Risk. Risk of increased tech debt, of missed deadlines, of losing a developer, of making a bad decision.
Risk is the variable that we, as software developers, aren’t used to taking into account due to the binary essence of programming. Either the feature works 100% or not. Either the code passes the code review, testing, and gets deployed or not.
Take the risk
Experienced Managers know that 80% success in decision-making and goals completion is a hell of a good achievement(i.e., in hiring, team reorganization, method boost, responsibilities change) . Don’t fall into the trap of creating the ultimate processes and methods for your people that cover 100% of cases. By the time such a solution is almost complete and described in wiki pages nobody will read, it becomes irrelevant and dies.
From that perspective, a good example could be to create the features flow delivery pipeline which handles 80% of requirements seamlessly. The other 20% coverage is costly, of rare occurrence, and can be managed on-demand instead.
Visualize
The other tip is just to visualize the problem in the form of a simple dashboard pointing to the issue, compared to the complex process creation. When the report becomes visible to all, the root cause tends to disappear, as people start naturally paying attention to it.
This article covers the first three principles which will make you stand out from the crowd and succeed in the end. Yet, there is more to talk about, such as decision-making, hiring and firing, alignment with the top management, and the Learn or die principle.
More to come in the next blogpost 🙂