Hey. You. Come over here, friend, I want to chat with you.

You look like someone who wants your company to be less profitable. Success keeps hounding at you even though you’re trying damn hard to fail. With every fibre of your being, you wish this place would go bankrupt and shut down: with a chain on the front doors and boards nailed over the windows.

Well… don’t give up hope. I have a solution that should wipe all chance of success off the roadmap! And I’m willing to share it with you today… for free.

Failed Strategies

I’m sure you’re thinking, “I’ve tried it all. Wreck the customer journey. Become apathetic and expensive, let the competitors eat up our market share.”

The problem is, that takes too long to achieve… because your strategy isn’t addressing the root of the problem. And that’s where you have to go to really muck it up – to the roots!

Identifying the problem

The core of the issue is those stinkin’ developers you hired. They keep producing… and they’re not just slinging any old crap into production, they’re turning out work that delights your customers. Heck, even YOU are impressed with it, despite the fact that you don’t want success – you can’t help but give them some respect. Every time you implement some price hike or add a new “customer service” process that makes it harder to get support, the dev team comes along and releases some new incredible feature. If we want to well and truly wreck our company’s balance sheet, we can’t have them being so effective.

Can’t we just fire them all?

Unfortunately, no. HR will get wind of that and then Legal and then it’s just nasty. The kind of thing that’ll make you late for dinner. And even if we succeeded in firing them all, they’ll just hire more! So we’ll have to be a little more indirect – we can’t let on that our goal is to sink the ship. Since we can’t just get rid of the developers, we have to make them wish we’d fired them… but what would cause that kind of reaction in really smart, dedicated folks?

The Next Best Thing

The problem with developers is that they’re smart AND dedicated. If they were ONLY smart, and not dedicated… they probably wouldn’t stick around in an environment where they could see how hard we were trying to fail. If they were ONLY dedicated, and not smart… they’d be much more controllable, and that would actually help us. What we need to do is take one of these traits off the table. We can’t make them less smart, so we’ll need to make them less dedicated. How could we do that?

Attack their Motivation

Developers are often intrinsically motivated. They love the dopamine hit that comes from solving a hard problem in code. They love the challenge of getting these little rectangles of light to show the lights in the pattern they want.

If we want to destroy the developer, we have to deny them that!

…but HOW?

Add Obstacles that lead to dead ends.

They love a challenge… but it’s because they feel so good when they solve the puzzle. If we’re going to destroy their motivation, we have to make sure that the puzzles they solve don’t have those same kinds of payoffs anymore! Here are a few ideas:

Make it hard to obtain developer tooling… both ‘new’ AND ‘old’

This one’s a great place to start – if it’s hard to get to the “old” approved tools, new hires will be slow to on-board. This will frustrate them more than anything – they know they’re well-paid for their work and they don’t like feeling useless or idle. If it’s hard to try out “new” tools, they’ll chafe at the fact that technology outside the company is changing rapidly, but they can’t use it themselves. There are several ways to make tools harder to obtain:

• Make the “approval process” long and cumbersome, and slow down the fulfillment process so that opening a ticket for an installation means they have to wait a few days, even if the software install is ‘pre-approved’. Adding wait time is the most frustrating thing you can do.
• Install Corporate Spy-ware tools whose policies lock down their workstations beyond usefulness. “Won’t someone think of the Security?” is a wonderful battle-cry, because they can’t say they don’t care about it!

These two tactics will crush the soul of a developer in just a few weeks. The most ‘gung-ho-change-the-world’ coding genius will become a mere shell of themselves, curled up in the fetal position underneath their desk, before a month is out. Guaranteed.

Documentation is a Problem.

Even with the previously-mentioned changes, a few really scrappy developers will resist. They’ll start making documentation to share with each other… “here’s how to bypass all the organizational crap that makes it hard to onboard”… and they’ll start giving this to new hires, in hopes that having the workarounds documented will help the newbies’ souls not be sucked out of them before they have a chance to make things better.

We may not be able to find and delete all of their documentation, but we can surely make it hard to access!

• Add policies to the “official docs” tool that bottleneck all document changes with one single team. Use the excuse of “needing things reviewed before they’re published” or something like that. You can’t just add indefinite wait time here or it will backfire on you, but a little increase is possible without them getting wise to your intent.
• Shut down “unofficial” documentation sources as quickly as you can… developers are likely to store them anywhere they can find a quiet corner. Make them hide it – because then it’s hidden. The easier it is to find, the more useful it will be.
• When someone makes an official request to research a new “official docs” tool, GET POLITICAL. You can bog them down in proceedings for DECADES if you play your cards right!

Write Processes for ALL THE THINGS.

This is a two-pronged approach; on one hand, you show up under the guise of “researching how things are done today”, ostensibly so a product evaluation team can gather requirements for the next developer tooling project. This is you raising their hopes. Then in reality, this is your chance to harden your process manual and make “how we do it today” permanent… dashing their hopes against the rocks! Make sure your processes require SPECIFIC outputs that are only available from the current toolset and would be impossible to modify other products to deliver. Insist that process changes be reviewed by a Board that meets infrequently (quarterly is a good sweet spot; long enough to make process changes cumbersome while not tipping your hand that you never plan to actually change anything). Then, all you have to do is find one pedantic person who can derail the proposal each quarter with some minutiae, or by asking a question that was answered 6 months ago but everyone’s forgotten!

All-in-one SaaS Platforms are your friend.

You will eventually be worn down in this battle – developers are tenacious like that. So when you can’t hold them off any longer, offer to research a GIANT ALL-IN-ONE SOLUTION and try to reimplement the whole universe at once.

Bonus points if you can get to two finalists here, and insist on a long and costly Pilot implementation! You can siphon a lot more cash by running extensive tests that are based on your process documentation… which is almost certainly not up-to-date, and therefore isn’t representative of what you’ll actually do with it.

This will come with an easy first obstacle – the price will be exorbitant. You can milk that for a few years… “We can’t spend $15 Million on replacing everything now! Sunken Costs Fallacy!”

Shortly after that, you can begrudgingly agree to the huge price tag, with the caveat that ONE TOOL is being purchased so IT MUST DO EVERYTHING. This ensures that the implementation project will go over budget and fail to deliver.

Slow the software release cycle down.

This is a tough one to pull off rapidly, it usually takes some time. In the alleged words of Winston Churchill,

How can you do this?

• Wait for an outage, then knee-jerk your response. Insist that the problem can never, ever, ever happen again. Initiate an Inquisition. Add complexity or wait times to the delivery process in the name of safety and security. You can do it “in the name of the Customer” and if you’re really convincing, you might even convince the developers that your goals are noble long enough to gain a foothold without them fighting back!
• Add Approvals EVERYWHERE. Do you need to move some code? Create a Change Advisory Board made up of people who have never written code before. Insist that they approve/deny all requests to push changes to Production. Have an urgent hotfix? Require a VP or higher to sign off on “going outside of process”. Convince people that ‘urgent’ changes are somehow of a completely different class than ‘standard’ changes.
• WARNING: Under NO CIRCUMSTANCES should you allow the developers to have input into how these developer tools are configured! Again, focus on getting people into decision-making positions for software delivery who have never written code. Or at least, haven’t written code since Minecraft was first released! (If you don’t know what that is… ask your kids. They can tell you.)

Wrapping up

It’s hard to get a company full of intelligent, dedicated folks to fail, but I believe in you. I hate being profitable and successful too, and I wake up every morning just like you, hoping I can cash out my golden parachute and leave a disaster in my wake.

I hope these tips help you to understand the importance of the Developer to your efforts, and give you some practical ideas for how you can prevent them from thwarting your attempts to fail!

Postscript… Blink, are you okay? What did I just read?

Look, I get it. You don’t wake up and try to bankrupt your company. I’m using the hyperbole intentionally: to highlight that if you’re struggling to improve things in your shop, you’ve likely overlooked the opinions of the biggest potential force-multipliers on your team. A developer who’s empowered and enabled can make entire other departments more efficient. It follows, then, that Developer Experience (defined by Microsoft as “how easy or difficult it is for a developer to perform essential tasks needed to implement a change”) needs to occupy a very high-priority space on your to-do list.

I really liked the phrasing in this Psychology Today article:

Cater to the emotional needs of the people who actually do the work.

Focusing on your developers, making sure they’re empowered and not impeded… this is what will make the changes that you want possible. Start there.

The post The Adventures of Blink #29: How to Unalive Your Company appeared first on ProdSens.live.

“I’m good at writing code. Just this month I shipped 11 PRs! I even updated most of my tickets on time. Didn’t take that many leaves either! And I worked so many more hours than Sam, too! Why didn’t I get promoted but they did?”

— Some unfortunate person who didn’t get the promo this time.

Does that sound relatable by any chance?

I’ve seen this before.

A LOT.

Sometimes the reason is office politics.

Sometimes it’s simply expectations not being communicated well. That can suck.

Sometimes it’s a mismatch between how you stood up to the defined expectations, and where the bar actually was.

You may not be able to control or change what your office environment is like. But you’re certainly in control to ensure there’s nothing on your end that prevents you from rising up the career ladder.

Cool! Could you speed-run me through what I need to do?

The first thing is to know what your responsibilities are as a software developer. I don’t mean your responsibilities in your current org, I mean it as a holistic and individual dev.

Table of contents

I see there’s 5 broad areas that a dev should aim to cover.
Click on the links to jump to that section.

1. Technical (code quality, lang. proficiency, testing, perf.)
2. Productivity (reliability & efficiency)
3. Collaboration (communications & reviews)
4. Ownership (responsibility & initiative)
5. Impact (system/product improvements & innovation)

“With that, we’re halfway to making a D&D character sheet. Roll Nat 20! ”

I’m going to only cover things that ARE in YOUR CONTROL.

I’m specifically mentioning this because one thing I’ve seen many orgs get wrong is, various areas of evaluation end up including things that you may not have control over.

Such as, you may not have control over how impactful your work was to the company. In most cases, you’ll only get to work on the things you’ve been directly asked to do.

Alright! Let’s go! I’m ready to get promoted!

The 5 areas I mentioned above aren’t specific to SDE1’s. It’s something every dev needs to be on top of. But the bar and expectations from each of those areas change.

Let’s talk about what the baseline expectation is from each area, and what you need to do to get to the next level.

Hold your horses. This is going to be long.
But remember, there’s only 5 sections below…

1. Technical Skills []

At SDE1, no one expects you to make a major splash, change the world, save billions!
They expect you to do your job in a way that needs minimal, or at-best occasional hand-holding, and for your delivered work to not need revisiting or fixes (as far as reasonable).

tl;dr
Write decent code that others can read, and doesn’t break every 2 seconds.

There’s a few ways to do that.

Write dumb code. Not “smart” code.

• You might be the wizard of Leetcode, Hackerrank, or something similar. But unfortunately these sites encourage juniors to pursue performance so hard that it often comes at a cost of readability.
• It’s NOT a bad idea to use a nested loop, if you know both loops run only for small values of i and j.
• It’s NOT a bad idea to NOT use a map/dict instead of an array if that array is guaranteed to only have a few items at max.

Learn about all the tools the language offers you.

• You might be used to using for-loops for everything, but arrow/lambda functions could make your code a lot more readable.
• [JS example] you might be used to storing things in an object {} for O(1) lookup every time, but set.has(thing) is a lot easier to read than !!obj[thing] (or even Boolean(obj[thing])

Understand why tests are valuable, and THEN write tests

• Too often people just write tests because it’s a “best practice”.
• Without understanding the WHY behind it, you may write ineffective or pointless tests.
• The idea is, do whatever you need to, to increase confidence in the stability of your code. You need to use types? Sure. You need to hire a QA person? A bit inefficient, but cool. Maybe you need to write… TESTS? Okay, but… what do I aim for?
• This can be a separate blog on its own. But here’s a quick brief…
  • It doesn’t matter whether you need to write Unit tests, Integration tests, Acceptance tests, whatever you call them. People can get “religious” about it. But none of it matters as long as your test does the one fundamental thing… improves your confidence that your code will not break.
  • Sometimes you may need to refactor your code so it’s more testable, but once you do it a few times you’ll begin thinking about code from a testability point of view.
  • It’s also a great idea to write the tests for your expected implementation before you’ve implemented anything at all! Resulting in a testing suite that completely fails at the start, and as you’ve implemented things it gradually keeps passing! This is basically what Test Driven Development (TDD) is btw.

Care about performance

• No one’s expecting you to run everything at 60 FPS all the time or sub 100ms latency for everything.
• But be mindful of when your code may cause too many requests to the DB, or loads too much data. Don’t let your component render 5 times because you couldn’t figure out how to use useEffect and useState right. Ask for help where you need to, but care enough to not let this stuff reach production.

To get to SDE2:

• Dive deeper into the internals of the languages and frameworks you use. Know how React actually renders things. Understand how a browser handles multiple requests from the browser to a server. Learn how Postgres chooses to optimize a query or doesn’t. Get into how your applications deployment pipeline is configured.
• Ask questions about how the project, components, APIs, etc. were architected the way they were. Learn what these design patterns are called, and what their pros and cons are. Start contributing to architectural discussions and suggest improvements. Who knows? You might have ideas that more experienced people didn’t consider.
• Mentor others on best coding practices. You will often have people junior than you on the team. Review their code. Get your code reviewed by them and share what they should focus on. Like Yoda, your wisdom you should share.

2. Productivity []

As an SDE1, your productivity is measured by your ability to reliably complete tasks on time, manage your workload efficiently, and maintain consistent progress on your projects. You should also be able to handle minor disruptions and dependencies without losing focus or needing constant guidance.

You may often need to rely on tools or apps or scripts to do certain things more effectively. Sometimes you may need to MAKE these tools yourself.

It’s okay if this feels like too much. It won’t always be perfect. Even far more senior devs don’t always nail this down.
You’ll get there. The important part is, if you’re not able to live upto your commitments, then communicate as early as you can.

tl;dr
Aim to get your tasks done well and on time. When you feel that you can’t, let people know asap.

Know when do to what, and when to say NO

• Learn to distinguish between what’s urgent and what’s important. Use tools like Eisenhower Matrix to prioritize effectively.
• Focus on high-impact tasks, but don’t ignore the small ones that keep the wheels turning.
• LEARN TO SAY NO. Oh goodness this is a BIG one. This is so important that this could be a blog on its own. I got stories.
  • You’ll occasionally find yourself being overloaded with work if you’re not good at saying no. People will often find it acceptable if you can simply and clearly explain what you’re occupied with, and instead when you’ll be able to pick up the next thing.
  • If you find yourself pressured into a corner, you NEED to rely on your manager to prioritize things for you. Just ask them what’s most important according to them.
    
    You saw this one coming, didn’t you?

Manage your time, and don’t burn yourself out

• Use techniques like Pomodoro to maintain productivity without burning out. I’ve had many friends that use some kind of a digital or physical Pomodoro timer to manage their workday.
• Track your time on different tasks to understand where you might be spending too much or too little time.
  
  A common pomodoro timer used by my friends back in the day

Automate boring work, by making your own tools if you must

• Automate repetitive tasks to save time. Scripts and tools can handle a lot of the mundane stuff. I’ve created a whole bunch of scripts, Slack commands for internal debugging, etc. that has saved me and the team countless hours already at Middleware.
• Familiarize yourself with IDE shortcuts, plugins, and other tools that can speed up your development process. If a majority of your team uses VSCode for dev, you can even agree on a common IDE config, and share that for that codebase by committing the .vscode directory to the repo!

To get to SDE2:

• Start managing your projects more independently. Create realistic timelines and meet them. An SDE1 might miss timelines every now and then. An SDE2, less so. The higher you go, the more likely it should be that you finish your projects before time even!
• Proactively identify and address bottlenecks in your workflow. Suggest process improvements to the team. Often you may not get the time or support to implement such improvements. A solid SDE2+ move is to just do it yourself in the bits and pieces of time you find between other work, and suddenly one day the team has some key workflow pain-points magically resolved! All because of you.
• Balance multiple projects and tasks without losing track of deadlines, and understand that you don’t always just meet deadlines by working 28 hours a day, you figure out ways to do the same thing more efficiently. As such, show that you can handle increased responsibility with the same level of productivity. Level up your multitasking game like Tony Stark managing his suit tech!

3. Collaboration []

At SDE1, you need to communicate clearly, share your progress, and be a helpful team member. Your ability to collaborate effectively with others is crucial to the team’s success.

There are a lot of people relying on you to deliver things on time. They are your engineering manager, product manager, perhaps other managers they report to, and also your peers who are waiting for your piece of the project to be done.

People may often be understanding of something running a little late, especially if it’s informed as early as possible. But what really causes issues is:

• Not telling you’ll be late till the last minute.
• Not being clear or being VERY inaccurate about your estimates.

I still mess up on some of this. But overall things do get better.

tl;dr
Be a good teammate and communicate well.

Speak early, speak often, but most importantly – listen

• Keep your team updated on your progress. Regular updates in stand-ups and via project management tools like Jira or Trello help everyone stay on the same page. (I know, Jira sucks, but you have to understand that it’s a pretty decent tool for your managers and higher ups to keep track of how things are running.)
• Listen actively during meetings and discussions. Understand what others are saying before you respond.
• Being a good listener will also get you a girlfriend/boyfriend sooner . If you don’t, let’s hope you pass Rule 1 & 2.

Guard your production, review the code

• Participate actively in code reviews. Provide constructive feedback and be open to receiving it. Care deeply about not letting poorly readable, or potentially risky (perf., UX, or security-wise) code from ending up in prod.
• Learn from the feedback you receive and apply it to your future work.

If you need any convincing about why code reviews are critical, and how to do it right, maybe this will help:

The Senior Engineer’s Guide to Code Reviews

Jayant Bhawal for Middleware ・ Jun 3

#codereview
#productivity
#learning
#testing

Keep your team up-to-date with your learnings

• Share what you learn with your team. Whether it’s a new tool, a coding trick, or an interesting article, keeping your team informed helps everyone grow. If you’re on Slack, a #engineering channel is a great place for something like this. So is #memes.
• Write documentation and create guides for complex parts of the codebase or processes. This helps others understand and use your work more effectively. It’s SUPER IMPORTANT to remember that this documentation needs to be searchable. Documentation that can’t be searched for, doesn’t exist. Glean could be a great tool to help with that, but it’s a paid (and expensive) thing.

To get to SDE2:

• Take on a mentoring role. Help junior developers navigate their tasks and challenges. Help them plan, estimate, document, etc. Help them write their first ERDs (Engineering Requirements Document)!
• Lead small projects or initiatives. Show that you can coordinate efforts and bring a team together to achieve common goals.
• Facilitate communication within the team. Help resolve conflicts and ensure that everyone is heard. Every team has introverts, and it’s usually them that have the hardest time communicating, help them as you can. Be the Captain America of your team, uniting and leading by example!

4. Ownership []

Taking ownership means being responsible for your work and its impact. As an SDE1, this means you should ensure your code works as expected, handle your tasks diligently, and follow through on your commitments.

Just as a founder, or CEO must do whatever it takes to ensure the company survives, thrives, and is profitable, you must do whatever you gotta do to ensure that your work meets the timelines set upon in, and is delivered in a way that not just meets, but exceeds the bar.

Understandably, there may be times when the set timelines or expectations are simply unrealistic. That’s where your communication skill needs to shine.

tl;dr
Own your work, and its quality. Finish what you start.

Maybe not like… THAT.

Learn to commit

• If you commit to a task, see it through to completion. If you encounter obstacles, communicate them early.
• Don’t pass the buck. If there’s an issue with your code or task, work to fix it rather than blame others.

Be proactive: See something, do something

• Don’t wait for problems to be assigned to you. If you see something that needs fixing, take the initiative to address it. Of course you’ll need to prioritize appropriately. Not everything that needs fixing requires you to park whatever you’re working on and fix it first either.
• Think ahead. Anticipate potential issues and address them before they become problems. For technical or engineering related work, ERDs (Engineering Requirements Document) can help tremendously with your work planning.
• Your managers may be keeping an eye on your teams productivity from their point of view, but as a proactive dev you can do the same. After all, YOU are the one who truly understands what makes YOU productive. If you can come up with a way your productivity analysis to your managers, show them that your team is actually doing well, or is blocked on things that need their attention, that gets you some serious points.
  DORA metrics is a fairly popular way to measure team productivity among dev teams. If you’re not sure how to start measuring something like this, maybe this blog would help: What are DORA metrics?

Everyday, be better than you were the day before

• Reflect on your work. What went well? What could have been better? Use this reflection to improve continuously. This would be a more personal version of the Sprint Retrospective your manager would (or should) do.
• Seek feedback actively and apply it. Strive to be better with every project you undertake. Sharing feedback is also a lot of work for the one providing the feedback. It might be a good idea to block some time quarterly, monthly, etc. if your org doesn’t have a process defined for this.
• Try and follow the Boy Scouts rule, which basically states that you should leave a codebase better than you found it. Read more here.

To get to SDE2:

• Drive projects from start to finish. Take on tasks that require you to plan, execute, and deliver with minimal supervision. If you prove yourself to be self-capable enough, your manager might let you supervise a couple more devs to execute the project. Now THAT is some Senior Dev stuff.
• Identify and implement improvements in processes, tools, or codebases. It’s been mentioned before too, but here the focus is slightly different. Show that you’re looking out for the bigger picture and contributing to long-term success of the org.
• Advocate for best practices and ensure they are followed. Be the Batman of your projects—reliable, vigilant, and always delivering excellence.

5. Impact []

As an SDE1, your impact might be limited to the tasks and projects assigned to you. However, demonstrating a broader understanding and contributing beyond your immediate responsibilities can set you apart. Impact is not just about what you do, but how your work influences and benefits your team, your project, and the organization as a whole.

tl;dr
Make a difference. Don’t just do, but improve.

Don’t be limited to “your job”

• Learn about the business and the industry you’re working in. Understand how your work fits into the larger goals of the company.
• Identify opportunities for improvement or innovation. Suggest enhancements that could benefit the team or product.
• Pay attention to the end-users of your product. Understanding their needs and pain points can guide you in making more impactful contributions. Don’t just build whatever you’re asked, but also analyze how successful your efforts have been for the users, and the org.

Contribute to the Community

• Participate in internal and external developer communities. Attend meetups, contribute to open-source projects, or write technical blogs.
• Share your knowledge and expertise to help others grow and learn. Organize or speak at tech talks, webinars, or coding bootcamps.
• Engage with other teams within your organization. Offer help and collaborate on cross-functional projects to broaden your impact.

You may not be “asked” to help your community at your job

Be Proactive in Problem-Solving

• Look beyond the immediate requirements of your tasks. Think about how your solutions can benefit other projects or future work.
• Develop a habit of thinking critically about the tools and processes you use. Propose and implement improvements that can save time, reduce errors, or enhance performance.
• Don’t wait for someone to assign you impactful work. Seek out opportunities to contribute meaningfully, even if it means stepping out of your comfort zone.
  Sometimes you may have to rely on third party tools to identify problems in your processes. Tools like Middleware would let you spot issues in your software delivery. Now THAT is a senior dev move.

Innovate and Improve

• Stay updated with the latest trends and technologies in your field. Experiment with new tools and approaches that could benefit your projects.
• Think about scalability and maintainability in your work. Design systems and write code that can grow and evolve with the needs of the business.
• Encourage a culture of innovation within your team. Promote brainstorming sessions and hackathons to generate new ideas and solutions.

To get to SDE2:

• Start thinking strategically. Identify ways to make a significant impact on your team’s goals and the company’s success. Look for patterns in your work and the work of your team, and suggest improvements that could benefit everyone. Most people aren’t too good at this, so if you can pull this off it’ll absolutely set you apart.
• Lead initiatives that drive innovation and improvement. Show that you can think creatively and come up with effective solutions. This might involve proposing new features, optimizing existing systems, or improving development processes.
• Champion new technologies or methodologies that can enhance productivity or quality. Take the lead in integrating these technologies into your projects and mentoring others on their use.

Remember, levelling up from SDE1 to SDE2 and beyond is a journey. Focus on what you can control, seek feedback, and keep improving. Your growth as a developer is a combination of technical skills, productivity, collaboration, ownership, and impact. With dedication and effort, you’ll not only level up but also enjoy the process of becoming a better engineer and a valuable team member. Game on!

P.S.: Senior engineers are good at identifying all kinds of problems that prevent their teams from delivering on time, without compromising on their output quality.

Some of them use tools like Middleware.

The post Going from SDE1 to SDE2, and beyond! 🚀 What it actually takes. appeared first on ProdSens.live.

If you’ve been following my series “How to win with devs”, a sort of “open letter” to engineering management and HR folks who want to learn more about how to better engage with the developer community, you’ve probably noticed that we’ve been covering some really heavy topics, and looking at long-standing practices that don’t serve us anymore… it’s been a little rough, hasn’t it?

Hopefully you find that today’s topic, with which I’m closing out the series, is a bit more lighthearted. Today we’re talking about “Building Excitement” and how you can do this with your dev teams… and why you’d even want to!

Happy engineers are productive engineers

Most people think of “managing people” as a task that requires you as the manager to motivate them to get work done. I believe this is wrong thinking, and I’d like to illustrate it with an anecdote:

When I’ve had a pet project that I was really excited to work on, I’ve been known to abandon everything else in life until I finished it. I skipped showers. I skipped meals. I disappeared from my usual hangouts. While I was working on that project, I reoriented everything in my life around its completion. Even when I eventually took meal breaks, or walked the dog, or whatever… I was still deeply immersed in the project. I was thinking about the code I needed to write next, or how this component was going to interact with that one. I drew pictures of possible next step ideas while I sat in the waiting room at the doctor’s office. I even dreamed about it regularly.

I ask you: does this sound like someone who needs to be motivated by their manager? Quite the opposite! This is someone who’s likely going to hit a wall and burn out. Their manager will need to help them unplug and provide balance.

This is the first rule I want you to learn: If your developers are happy and excited by their work, they’re already predisposed to obsess over it. If you find yourself having to “manage them into productivity”… you have an underlying problem to deal with!

Ask yourself: Why are they disengaged?

In late 2009, Daniel Pink published a book called Drive: The Surprising Truth About What Motivates Us. While this isn’t written specifically about Engineers, its findings definitely apply! He suggests that motivation is tied to three principles for most people:

• Autonomy: We want to be responsible for our work and our choices and we have the opportunity to direct ourselves.

• Mastery: We’re driven to improve ourselves, to learn our craft more deeply and grow our knowledge and skill. We seek opportunities to level up.

• Purpose: We want to connect our efforts to a greater goal, to understand that we’re doing something that matters.

One of the surprising points that came out of Pink’s work was that money didn’t make the list. Well, with a caveat – when you don’t have enough to cover your necessities, money is perhaps the strongest factor in motivation. But once you reach a salary level where you’re not just scraping by anymore, this Autonomy/Mastery/Purpose triangle takes over. (It’s also important to note: that even though money doesn’t have as strong an influence on motivation after the inflection point, it’s not an excuse to get cheap! Everyone can smell a !)

This is counterintuitive, particularly in business where management often assumes that the only lever they have to pull is “pay increases” to incentivize their workforce… they’re shocked that it stops working, because they don’t realize that their folks have shifted into that alternative mindset!

What does it mean to offer autonomy, mastery, and purpose? How would a company give that to its people? If these factors affect developer happiness and motivation, and therefore their productivity, how do I make changes that could influence a developer team?

Autonomy

“Engineers being autonomous” can be a scary thing for managers. I mean, we’re managers. Isn’t it our role to manage?

When a manager develops their relationship with their team to promote mutual trust & understanding, it creates a breeding ground for autonomy. The manager doesn’t feel the need to micromanage because their team does a great job of managing themselves.

On the other hand, when a manager interprets their role as “I tell the team what to do and they do it”, it continually and rapidly erodes the trust between them until the only way anyone gets anything done is that the manager sits over their shoulder like a vulture and watches, continually adjusting direction and micromanaging. For an engineer, this is soul-crushing, y’all.

I’m… not there yet, blink. How can I begin to promote autonomy?

You’re probably talking too much.

I’m not throwing shade… we all tend to talk too much! The wisdom here is to try listening. As the manager, the authority inherent in your position causes your opinion to carry more weight than theirs; therefore when you talk over them or interrupt them, you’re shutting down the creative process. The implication you create is something like “Well, the boss knows what they want done and my opinion is just noise”.

I heard Jeff Bezos say something in an interview once that stuck with me: “Leaders speak last”. The idea behind this is that when the “leader” speaks, everyone else makes the unconscious assumption that a decision has been reached.

It leaves them thinking their input doesn’t matter! By waiting until the end to add your own input to the discussion, you’re offering a chance for everyone else to be heard. This is something you also need to train your senior team members on – because they also may squash their teammates’ input unwittingly.

Your role is to clear obstacles, not design solutions

If you’re managing engineers, you have a tremendous amount of creative problem-solving ability on your team. It might seem obvious, but it’s worth saying: You aren’t there to tell them how to solve the problem! Instead, focus your own personal efforts on finding the organizational hurdles – the dumb processes that prevent them from solving the problem, or the tools they need but don’t have – and removing those barriers so they can focus on their problem. Most engineers hate doing paperwork, it’s often a disruption in their day. Something as simple as “hey, I opened that ticket for you to get access to the database” might keep your engineer “in the zone” for an extra 30 minutes one day, and you can’t begin to fathom the value of that!

Ask the dumb questions

One of the most valuable skills that I’ve learned is how to be willing to ask the “stupid questions” when problem solving in a group. Many people are afraid to ask questions for fear of looking like they’re incompetent, but asking questions is a critical skill in solving problems. So even if you already have some idea what the answer is, ask the question for the benefit of the others on your team!

Mastery

The second motivating factor for people in Pink’s research was the concept of mastery. That is, people are motivated by a desire to level up their skills! There’s a “secret” corollary to this desire: EVERYONE has some skills that can be leveled up!

Mastery’s opposite is boredom. And that’s one thing that most engineers absolutely cannot stand! They’re motivated to learn and grow and improve, and if they’re constrained from doing those things, it’s devastating.

What are some ideas to promote mastery?

• Observe.

I see mastery working hand-in-hand with autonomy – an autonomous engineer is going to find problems they want to solve, projects they want to work on. Your role as their manager is to study them… see if you can identify what kinds of problems they love to work on, and then give them more of those kinds of things.

• Make it safe.

Learning requires failure. If your opportunities to level up are always on high-priority, high-visibility efforts with scary ramifications for failing, you’re doing your team a disservice. Make sure they have plenty of lower-stakes places to work on their skills and improve. You can’t always avoid the high-pressure situation, but try to ensure it isn’t the only path to leveling up.

• Budget for it.

If you don’t already have one… build a professional development budget, and put it to good use. Supporting your team as they learn new skills that they can put to valuable use at work should be a no-brainer, but it’s frightening how many companies either don’t invest at all in this, or do it haphazardly. Do you have a plan for how you’re going to help each person on your team level up a skill this year?

Purpose

This motivator is the most abstract, and it will be very different for each person. Some of it you may not have any control over at all. What the heck is “Purpose”?

Purpose could mean:

• They relate strongly to the mission of the company
• They have a deep passion for a certain type of skill set
• They care about a certain persona of customer

Any “higher meaning” in their work can become a Purpose, but it will be highly subjective. Your role in this motivator is to help them find it.

Helping your team find their Purpose

• Relationship, Relationship, Relationship.

Any assistance you can render here will come directly from how well you know your team. Cultivating a strong personal relationship with each of your engineers will give you the insight into their characters and desires and guide you toward their Purpose.

• Not everything is an assignment.

This one is scary for managers who tend to want to micromanage… but have you considered leaving your team some free time to work on things that they choose?

It seems counterintuitive, but the best way to increase efficiency is actually to build in idle time! If you run the shop at 100% constantly, you create contention when two projects collide (instead of having some slack where they can easily shift to accommodate unexpected turbulence). You also create a culture of burnout (because your team never gets to breathe, you’re always on to the next thing with no chance to regroup).

Good engineers, when given a workload that has a bit of idle time built in (15-20% is mathematically ideal!), will occupy themselves with productive tasks whenever that idle time arrives… they just aren’t assigned tasks, and that makes all the difference. Remember our first motivator? Autonomy! Your engineers will begin to find their purpose when they have a chance to be autonomous.

Wrapping up

There are ultimately two ways for people to be motivated: extrinsically and intrinsically. You can bribe, cajole, nudge… even beat them with a stick… but you’ll never be able to match the output of someone who’s motivated from within themselves. As a manager, you have tremendous influence in this space – and while you’ll be tempted to take the quick path and provide extrinsic motivation, I want to encourage you to stick with your “gardening efforts”… cultivate that motivation from within your teams and watch amazing things happen!

Speaking of “Building Excitement”…

Next week we’re going to delve back into the world of AI! This next Adventure is probably my favorite episode so far, because I get to have a chat with…

Nah. Not spoiling it. Make sure you give me a follow so that you’ll be reminded to tune in next week when we start to play with Large Language Models!

The post The Adventures of Blink #25: Building Excitement appeared first on ProdSens.live.

Managing a product development team with diverse personalities can be both rewarding and challenging. Each team member brings their unique strengths, perspectives, and communication styles to the table, which can lead to rich collaboration and innovative solutions. However, it also requires a skilled manager who can navigate the complexities of interpersonal dynamics and leverage the diversity within the team to drive success.
In this guide, I’ll explore strategies for managing a product development team with different characters effectively.

Embrace Diversity:
The first step in managing a team with diverse personalities is to embrace the diversity within the team. Recognize that each team member brings valuable insights and experiences to the table, regardless of their personality type. Encourage an inclusive culture where all voices are heard and respected, and where differences are celebrated as strengths rather than liabilities.

Understand Personality Types:
Take the time to understand the different personality types within your team. Whether it’s introverts who prefer to work independently, extroverts who thrive in social settings, analytical thinkers who excel at problem-solving, or creative visionaries who think outside the box, each personality type has its unique strengths and preferences. By understanding the various personality types within your team, you can tailor your management approach to accommodate their needs and preferences.

Foster Communication and Collaboration:
Effective communication is essential for bridging the gap between team members with different personalities. Encourage open communication channels where team members feel comfortable expressing their ideas, concerns, and feedback. Foster a collaborative environment where team members can leverage each other’s strengths and work together towards common goals. Use team-building activities, icebreakers, and workshops to strengthen relationships and build trust among team members.

Adapt Your Leadership Style:
As a product development manager, it’s essential to adapt your leadership style to accommodate the diverse personalities within your team. Be flexible in your approach, recognizing that what works for one team member may not work for another. Tailor your communication style, feedback mechanisms, and motivational strategies to align with the preferences and needs of individual team members. By adapting your leadership style, you can create a supportive and empowering environment where all team members can thrive.

Manage Conflict Constructively:
Conflicts are inevitable in any team setting, especially when dealing with diverse personalities. However, conflicts can also be opportunities for growth and learning if managed constructively. Encourage open dialogue and respectful disagreement, and provide a framework for resolving conflicts in a fair and transparent manner. Use techniques such as active listening, empathy, and compromise to find common ground and reach mutually acceptable solutions.

Celebrate Differences:
Finally, celebrate the differences within your team and leverage them as a source of strength and innovation. Encourage cross-functional collaboration and knowledge sharing, where team members can learn from each other’s unique perspectives and experiences. Recognize and reward individual contributions, and foster a culture where diversity is valued and embraced as a key driver of success.

Conclusion:
Managing a product development team with diverse personalities requires patience, empathy, and adaptability. By embracing diversity, understanding personality types, fostering communication and collaboration, adapting your leadership style, managing conflict constructively, and celebrating differences, product development managers can harness the full potential of their teams and drive innovation and success.

The post Harnessing Diversity: Managing a Product Development Team with Diverse Personalities appeared first on ProdSens.live.

Delegation is a vital skill of effective leadership. It involves entrusting tasks and responsibilities to team members based on their skills, capabilities, and expertise, thereby fostering a culture of empowerment and accountability.

Effective delegation not only enhances productivity and efficiency but also promotes professional growth and development within the team. Mastering the art of delegation enables managers to focus on strategic initiatives and decision-making while empowering their team to take ownership and contribute to the overall goals of the organization.

There are lots of things you can do. Here are the ones I believe have the most impact:.

Before delegation

1. Raise team’s capabilities
   According to Blanchard, different people in different situations need different styles of leadership. High competence and a good attitude are the first criteria to consider. Every member needs continuous improvement. Even the ones with high expertise who recently joined your team or the members who formed the team in the first place.

Giving your members training is an effective way to build trust and the foundation so that they can do the work with the least of our direction.

1. Communicate clearly
   There are important things that we need to clearly communicate to your directs

• A SMART goal is a way for us to know when the work is done and how we can measure the progress. This is a critical tool so that they can manage themselves.

• Capability dictionary: a list of what we have to obtain to do the work with best quality. Members who are eager to learn can refer to it to improve their competency.

After delegation
It is very difficult for everything to go the correct way from beginning. Now monitoring comes in handy

1. Provide feedback
   woman in white long sleeve shirt sitting on red couch
   For managers, 1:1 meetings are a familiar tool. We should use it to give instant feedback from various points of view so that members can correctly “turn the steering wheel.”.

2. Reflect on process
   We can learn a lot from observing others working. Write it down and update the processes for future preparation of the next delegation as well as our own way of working.

Last words
Mastering the art of delegation is not just about distributing tasks; it’s about empowering your team, fostering growth, and achieving collective success. By delegating effectively, managers can unlock the full potential of their team members, creating a dynamic and productive work environment where everyone thrives. So, embrace delegation as a strategic tool in your people management arsenal, and watch as your team flourishes and accomplishes more than you ever thought possible.

If you like my post, hit like button or comment if you want to add more ideas
Visit my site for more articles

The post Delegation is the last thing managers should do appeared first on ProdSens.live.

I’ve been captivated by The Lean Startup by Eric Ries. It masterfully adapts lean manufacturing to the tech startup scene, championing agility, rapid iteration, and customer focus. The book isn’t just theory; it’s a practical guide to innovating more effectively and efficiently, valuable for anyone in tech.

Key Insights & Real-World Applications:

1. Build-Measure-Learn Loop: This core loop is about turning ideas into products quickly, then measuring how customers respond and learning whether to pivot or persevere. A vivid example from the book is Ries’ own experience with IMVU, where initial assumptions about customer needs led to rapid iterations before finding a successful product market fit.

2. Validated Learning: This principle involves learning what customers really want, saving time and resources. The book discusses how startups like Dropbox used a simple video to validate customer interest in their product concept before building it, significantly reducing unnecessary development work.

3. Pivot or Persevere: Deciding whether to pivot (change direction) or persevere (continue with the current strategy) is crucial. Ries shares the story of how a pivot in the development strategy, from focusing on complex technology to understanding what was truly valuable to customers, led to the success of Zappos.

4. Innovative Accounting: Setting up metrics that demonstrate clear progress toward the goal. Ries emphasizes the importance of actionable metrics over vanity metrics through examples like Aardvark, a company that pivoted based on learning from customer interactions, which eventually led to its acquisition by Google.

5. Sustainable Growth: Ries explains that sustainable growth comes from products that cause customers to refer others. The example of Votizen, leveraging users’ social networks to drive growth, illustrates how focusing on features that encourage referrals can create a self-sustaining growth loop.

I’m curious to hear about your experiences with Lean Startup principles. Have they shaped your approach to projects or leadership? Let’s share success stories, challenges or limitations in these methodologies.

The post 🚀💼 Lean Startup: Transforming Tech with Lean Principles 💼🚀 appeared first on ProdSens.live.

Meetings are a crucial part of the software engineering process. Whether it’s planning, brainstorming, or troubleshooting, effective meetings can drive projects forward and foster collaboration. However, leading meetings, especially in the fast-paced world of software development, requires a unique set of skills. In this guide, we’ll explore strategies for leading meetings that engage, inspire, and yield results, supplemented with real-life case studies and scenarios.

No one likes lengthy meeting. In this guide, we’ll delve into strategies for leading meetings that engage, inspire, and yield results, while also emphasizing the importance of optimizing time usage and avoiding unnecessary extensions beyond predetermined timeframes. Through real-life case studies and scenarios, we’ll explore how effective meeting leadership can drive project success and foster a culture of productivity in software development teams.

Case Study 1: Sprint Planning Session

Scenario:
Sarah, a software development team lead, is preparing for the sprint planning meeting. The team consists of developers, testers, and a product owner. The goal is to review the backlog, prioritize tasks, and allocate resources for the upcoming sprint.

Approach:
Sarah starts the meeting by setting clear objectives and agenda. She encourages everyone to actively participate and share their insights. Using visual aids like a Kanban board, she facilitates a collaborative discussion to identify tasks and estimate their complexity. Throughout the meeting, Sarah ensures that decisions are documented and actionable items are assigned to team members.

Outcome:
By the end of the meeting, the team has a well-defined plan for the sprint, with clear goals and responsibilities. Sarah’s effective facilitation fosters team alignment and sets the stage for a productive development cycle.

Case Study 2: Code Review Session

Scenario:
John, a senior software engineer, is leading a code review session for a new feature implementation. The team needs to ensure code quality, identify potential bugs, and provide constructive feedback to the developer.

Approach:
John starts the session by explaining the importance of code reviews and setting the guidelines for constructive feedback. He walks through the code changes, highlighting key areas for discussion. As team members share their observations, John facilitates a respectful dialogue, focusing on identifying improvement opportunities rather than assigning blame.

Outcome:
The code review session results in valuable insights and suggestions for enhancing the feature. Through open communication and collaboration, the team strengthens their codebase and fosters a culture of continuous improvement.

Case Study 3: Production Outage Incident Meeting

Scenario:
Emma, a DevOps engineer, is leading a meeting to address a critical production outage incident. The incident has caused service disruption for a significant number of users, and the team needs to identify the root cause and implement immediate fixes to restore service.

Approach:
Emma starts the meeting by acknowledging the severity of the situation and emphasizing the urgency of resolving the issue. She facilitates a structured discussion, starting with a timeline of events leading up to the outage. As team members share their observations and hypotheses, Emma guides the conversation towards identifying potential causes and mitigation strategies.

Outcome:
Despite the high-pressure environment, Emma’s leadership and effective communication help the team remain focused and collaborative. Through thorough analysis and troubleshooting, the team identifies the root cause of the outage and implements measures to prevent similar incidents in the future.

So, Leading meetings for software engineers requires a combination of technical expertise, communication skills, and effective facilitation. By adopting strategies such as setting clear objectives, fostering collaboration, and maintaining a positive atmosphere, engineering leaders can maximize the productivity and impact of their meetings. Through real-life case studies and scenarios, we’ve explored how effective meeting leadership can drive project success and foster a culture of continuous improvement in software development teams.

The post Leading Meetings for Software Engineers: Guidelines appeared first on ProdSens.live.

94% of organizations say that they have a DevEx strategy in place, while only 25% believe that the strategy is mature and delivers value. Despite all the opportunities that DevEx brings, the investments made toward a joyful DevEx are still sluggish.

But this needs to change.

With a 64.4% burnout rate in IT, economic headwinds, and the great resignation continuing, retaining engineering talent is a challenge for CIOs & IT leaders. Hence, it is more important than ever for the top leadership to ramp up the investments into improving the developer productivity, the developer experience (DevEx), joy, and well-being.

You, as an engineering manager, CTO, or CIO, might already know the impact/benefits of investing in developer experience. But the challenge is to get the rest of the C-suite to buy-in the DevEx strategy, especially the CFO, CEO, and the board of directors.

Why so?

• First, the challenge is such initiatives aren’t just cost-intensive, but also demand a cultural shift in engineering processes & how people work. This steep change curve is what scares the C-suite.

• Second, the DevEx advocates don’t talk in the language the C-suite understands, i.e., Financial Numbers, aka Money.

Read this insight to find out how you can overcome the above challenges and get your CFO, CEO, and investors to buy into your DevEx initiatives strategy.

How to Pitch for DevEx Investments to the CXOs?

Speak the linguistic dialect of the C-suite executives. Help them see that the DevEx strategy is for the business’s sustainability & profitability.

Note: If your CTO is not convinced about DevEx initiatives, read our blog on 7 reasons to give to your CTO for investing in developer experience. The current blog is more about winning the trust of the CEO, COO, CMO, investors & other stakeholders who would put the rubber stamp on the DevEx initiatives proposal.

1. Quantify all the Value Propositions

Let’s say, in your proposal, you’re suggesting investing in a log analyzer tool like Splunk. Then try the 2-step strategy to win c-suite trust & get buy-ins.

• Highlight how manual issue identification, root cause analysis & diagnosis can take hours. Especially, for large distributed systems. Increasing MTTD and MTTR and slowing the velocity metrics.

• Explain how manually scanning log files kills developer productivity.

• Prove the utility of a log analyzer tool in minimizing developer interruptions, and maximizing maker time.

• Show the average time that a developer spends trying to identify the issue without a log analyzer, vs. the time spent with a log analyzer.

The same applies to all the tooling-based investments. You have to explain the problem it solves. Then be it IDEs, browser dev tools, AI code generator tools, code quality & review tools, CI/CD platforms, software development & testing frameworks, infrastructure orchestration & monitoring tools, security tools, communication & collaboration tools, or code documentation tools.

But all this is what a CTO would buy into. To have the CEO & CFO on your side, your narrative needs to be further personalized & revenue-rationalized.

Map all the benefits of investing in developer experience to the business’s bottom line. Share with the c-suite the findings of a Forrester report.

2. Communicate The DevEx Impact on Engineering Productivity & Project Success

Investing in devEx initiatives has helped 74% of organizations to unlock higher Developer productivity. DevEx means reducing friction from SDLC workflows. It means investing in Dev tools and inculcating a culture that maximizes the maker time metrics. A developer-first culture helped 81% of organizations improve developer retention.

Better productivity & talent retention strengthen the innovation gears of your organization. DevEx investments improve developer productivity, which translates into better engineering velocity metrics (indirectly, it’s a measure of value delivery rate to the end customers). In fact, 77% of organizations investing in DevEx noticed a significant positive impact on the time to market. This could be because happy developers tend to write quality code with fewer bugs (comparatively), which results in lower technical debt, an increase in code commits, PRs raised, PRs reviewed & PRs merged, high deployment frequency (DF), and low code-churn. As a result, 75% of organizations experienced higher customer attraction & retention rates. Plus, 82% of organizations performed well on customer satisfaction metrics.

3. Translate Ideas Into Revenue Opportunities

Also, the C-suite may just buy in when you tell them how DevEx impacts profitability & revenue. Improving DevEx also means investing in modernizing SDLC workflows with infrastructure orchestration & monitoring tools. This helps DevOps teams proactively respond to security threats in real time. Ultimately, minimizes business losses due to breaches or system downtime/failure. Not to mention, robust security improves business reputation & recognition, customer loyalty, and assists you in competitive market positioning. Thanks to improved innovation muscles, and happy customers, 85% organizations reported a positive impact on revenue growth, and 81% improved profitability as well.

In short, to get buy-in for developer experience initiatives from the top leadership, make your pitch personalized (so that HR, Finance, and other teams support you), and get revenue-focused.

4. Pitch for Incremental/Phased Investment

Strive for gradual progress, recognizing that both large enterprises and smaller businesses often grapple with budget limitations. But you also need to move the needle. So, come up with a strategy for enhancing developer experience that doesn’t feel like a mission impossible. Basically,

• Categorize developer experience into different segments based on outcomes. It could be reducing developer friction, streamlining SDLC, optimizing infrastructure, etc.

• Prepare phased project documentation with budget infusion estimates, timeline, expected tangible outcomes, and impact on the bottom line.

• Factor in the cultural changes as well in your project documentation. For example, if you’re adopting GitOps to streamline infrastructure operations, it would reshape the roles & responsibilities of the operations team, release engineers, configuration managers, and others.

Persist Until DevEx Initiatives Get a Green Flag

For enhancing developer experience, getting the buy-in from the C-suite is undeniably crucial.

However, obtaining approvals or pouring resources into DevEx initiatives doesn’t automatically translate to better business results. There are multiple factors at play.

For instance, siloed departments can hinder innovation. So, inter-team collaboration is going to be a key factor for DevEx’s success. You need to foster a culture of developer autonomy, ownership, and accountability, which again improves the developer experience. But cultural transformation is not simple. A common bummer is resistance to change. Then there is the challenge of re-skilling the workforce to help them adapt to the new technologies and engineering practices.

The best leg forward to overcome these challenges is to improve your overall engineering workflow visibility.

Engineering workflow visibility tools (say ‘Hi’ to Hatica) are the underrated and unsung heroes of your DevEx initiatives. With engineering management platforms, you can help the C-suite to gain data-driven visibility into your engineering processes, practices, and projects. It helps you to clearly visualize, and communicate how the investments impact the bottom line, and most likely, win their support.

Icing on the cake, Hatica is a perfect match for your DevEx initiatives, as it empowers you to place significant focus on the well-being of your developers.

As a takeaway,

• Be shamelessly persistent about getting the buy-in for DevEx initiatives

• Harness the superpowers of Hatica for data-driven DevEx strategy

• Become better at mapping the engineering activities to the business bottom line.

Good luck with your DevEx transformation!

The post How To Get C-suite Buy-in for DevEx Investments appeared first on ProdSens.live.

As a product marketing leader, you’ll know that having a motivated team is critical. But with demanding workloads, evolving priorities, and ambitious targets, motivation can often wane. 

So, how do you keep your team engaged, creative, and committed for the long haul? 

Discover seven proven tactics to motivate your crew, from inspiring OKRs to building a culture of recognition. Follow these tips to lead a driven, cohesive product marketing org that gets results.

1. Set clear, achievable OKRs

Setting clear, achievable goals is fundamental in leading an engaged team. After all, it’s hard to stay motivated if you’re not sure what you’re aiming for. 

This is where the objectives and key results (OKR) framework comes into play. OKRs help you set and communicate clear goals, track progress, and ensure alignment within your team and the broader organization.

Let’s say your objective is to increase market penetration for a certain product. This objective, while ambitious, becomes more tangible when broken down into clear, measurable, and time-bound key results. These could include achieving a specific number of new sign-ups, raising engagement rates by a certain percentage, or getting X number of positive reviews within the next quarter.

Remember, the OKR framework is not just about setting goals; it’s about fostering a culture of accountability and alignment. When everyone understands the objectives, and their role in achieving them, it creates a sense of purpose and drives collective effort. 

By using OKRs, you’re not just dictating what needs to be achieved; you’re empowering your team with clarity and purpose – two key ingredients for motivation.

2. Encourage creativity

No one wants to feel like they’re being told what to do 24/7. Instead, why not Inspire creativity by setting aside time for idea generation within your team throughout the week? Try to make this time as informal as possible – you could even conduct the meeting in your local cafe or bar. 

This session can be as simple as throwing a customer pain point out to the group and having each team member write a possible solution down on a Post-it note. Collect the Post-its, stick them to the wall, and discuss them as a group. This works especially well if you keep the suggestions anonymous, taking the pressure off and encouraging more open, honest discussions. 

Another option is to create a dedicated Slack channel or Kanban board. You can encourage your team members to post one idea per week. Then, gather a few of these to discuss later as a group. 

Ready to take your career to new heights?

Get Advanced Product Marketing Certified.

3. Foster a culture of learning

If you’re reading this article, we probably don’t need to tell you about the power of learning, but here’s some food for thought anyway: When you invest in your team’s professional development, you show that you’re invested in their long-term success. This can be a powerful motivator.

Imagine the impact on your PMMs when they can dive into a cutting-edge course on consumer psychology or attend a messaging masterclass. Better yet – imagine they come back and share what they’ve learned with their colleagues. This not only brings new skills and ideas to the table but also fosters a collaborative environment where knowledge-sharing is the norm. 

To make this dream a reality, allocate a portion of your budget to professional development or set aside a dedicated L&D day every quarter. You can even encourage your team to identify areas where they want to grow and give them the time and resources to pursue those interests.

By creating a learning culture, you’re not just equipping your team with the latest tools and techniques in product marketing; you’re building a motivated, knowledgeable, and cohesive team that’s ready to tackle any challenge.

4. Acknowledge growth and success

To increase motivation within your team, it’s vital to acknowledge growth and success. This is about more than just putting a smile on your team members’ faces (though, of course, that’s important too) – according to one study, companies that build recognition-rich cultures have 31% lower voluntary turnover rates.

One way to start building a culture of recognition is to create a doc listing the positive steps and progress your team members are making – even things as small as an improvement in presenting skills or spotting a juicy tidbit of competitive news. Then you can take a moment to praise this progress in your next one-on-one. 

If you’ve delegated a bigger task, like overhauling positioning and messaging, and someone on your team knocks it out of the park, this should be acknowledged in a bigger way. Why not give them a shout-out in the next all-hands meeting, or include them in the company newsletter?

But you shouldn’t be the only one shouting out accomplishments. Peer-to-peer recognition is every bit as vital as top-down shout-outs – after all, even the most hands-on leader would struggle to witness their team members’ every success. With this in mind, you could create a Slack channel or dedicated newsletter segment for people to thank their colleagues for going above and beyond.

In short, ensure that achievements – big and small – get the recognition they deserve. You’ll be shocked at the surge of motivation from your team. 

5. Delegate the right tasks to the right people at the right time

Though it can be all too tempting to take on every last task, as a senior product marketer, you need to delegate – or risk burning out. In fact, when we surveyed product marketing leaders earlier this year, 61.5% cited delegating effectively as among the most important soft skills to master in their role. 

Crucially, delegating key tasks is a great way to show you trust your team, and teams who feel trusted work harder, perform better, and are more likely to stick around.

But how to decide which tasks to delegate, to whom, and when? That’s a skill you’ll hone throughout your career. There’s a delicate balance to strike: You want to choose a task that’s challenging but achievable. 

Pick one that’s too easy, and even if they pull the task off beautifully, it’s not likely to inspire a sense of progress or pride. Too difficult and you risk totally demoralizing the person responsible – the exact opposite of what you’re trying to achieve for your team.

So, as you consider handing over a key responsibility, ask yourself what makes this person the right person to lead this particular task. Have they shown an interest in this area? Have they demonstrated the relevant skills as they carried out another task? 

And don’t forget – there’s more to delegation than just handing over the reins and bidding your reports “Good luck!”. Be sure to offer support where needed and check in regularly to make sure projects are on track and deadlines remain realistic. 

6. Delegate authority as well as responsibility

While we’re on the subject of delegation, here’s a super important tip that often gets missed: Make sure you delegate not only the job but also the power to get the job done. Give your team members the power to make decisions based on their own expertise and research. 

There will of course be areas that require your sign-off and sign-off from higher up – but you should empower your team members as much as possible to make proactive, independent decisions. 

7. Promote a healthy work-life balance

When launch deadlines loom, it’s easy to overlook the importance of work-life balance. However, as a leader, it’s your responsibility to ensure that your team doesn’t burn out. Encouraging a healthy work-life balance is not just beneficial for your team’s well-being; it’s crucial for maintaining motivation and creativity.

One way to promote this balance is by respecting your team’s time outside of work. That could mean implementing flexible working hours or banning weekend work outright. You could also encourage taking regular breaks during the workday to recharge.

It’s also crucial to lead by example. If you’re sending emails late at night or during weekends, it sets an expectation for your team to do the same. Instead, show them that it’s okay to disconnect and that you value their time off. 

When your team has time to rest and pursue their personal interests, they come back recharged, bringing fresh ideas and renewed energy to their roles.

Lead on!

Implementing even a handful of the tactics here can work wonders. It’s about more than just getting the job done – it’s about fostering an environment where creativity thrives, success is celebrated, and challenges are tackled head-on. 

Follow these tips to lead a team that consistently rises to the occasion with passion and purpose. The results will speak for themselves.

Before you go…

There’s so much more to learn on your quest to become an elite product marketing leader. Luckily, Advanced Product Marketing: Certified has got you covered. 

With expert guidance from product marketing legends like April Dunford and Jennifer Bunting, you’ll blend strategic thinking with in-the-trenches execution to take on more responsibility, ace objectives, and climb the career ladder. 

Sign up today and see what you’re really capable of as a product marketing leader!

The post Motivating your team: 7 strategies for senior PMMs appeared first on ProdSens.live.

Disclaimer. This article is a joke. Only me and God know how to estimate software projects. And I am not sure about God.

The Great Unknown

Let’s imagine you are a Tech Lead, and recently you were asked to estimate a software project. You were given a list of features and asked to estimate how long it would take to implement each feature and the entire project. You were given a couple of days for it…

A couple of days! Really? Estimate the entire project. It cannot be enough. Even for the best of us. Even if you have done it before many times. But how much time do you need? A week? A month? It always will not be precise anyway. So, maybe a couple of days is a good option, at least you will not waste a lot of time on it.

And be sure, your managers will tell you, “Don’t worry, no need to dive deep into details, we just need a rough estimate and nothing more, you will manage to do it, come on buddy”.

And of course, they lie. They will use your estimation to plan the project, to plan the budget, to plan the team, to plan the deadlines, to plan the marketing, to plan the sales, and to plan the future of the company. And they will use it to blame you later when you will not be able to deliver the project on time.

The Burden of Responsibility

The customer needs to know how much it will cost to implement the project. It is a good reason, right? They need to prepare money for their amazing start-up, or maybe find investors, who will pay for it. And the amount of money they will ask depends on you. So, it is a big responsibility, including the fact that only you know how you came up with the numbers.

Usually, customers ask for estimates from several companies, and then they will choose someone. It is not always the cheapest one, there are a lot of factors that influence the decision, but the price is one of the most important factors. And here is the catch:

On your side, if you will give a price that is too high, for the customer, you will usually lose because the project is not on you. If you give a price that is too low, you will usually win the battlefield, but you will lose this war later, when you are working on the project every night.

On the customer side, if you provide them with a budget that is too low, they will not be able to implement the project, and they will lose. If you provide them with a budget that is too high, they will lose, because they will not be able to find investors.

The Illusion of Technique

So, how to estimate the project? There are a lot of techniques and maybe you know some of them. There are countless methods: expert judgment, story points, bottom-up estimate, three-point estimating – you name it. They all promise to unveil the magic number. But guess what? None of them have the Midas touch.

You might meticulously break down the project into user stories, assign story points, and create impressive Gantt charts. You might consult with your team and reach a consensus. You might even throw in some past project data for good measure. Yet, when the deadline day arrives, you’re either ahead of schedule with nothing left to do or drowning in an ocean of bugs and scope changes.

Conclusion

In the wild world of software project estimation, one thing is clear: it’s an art, not a science. It’s a complex dance of uncertainty, expectations, and a dash of wishful thinking. So, next time you’re asked to estimate a software project, remember to take it all with a grain of humor and a pinch of humility. After all, in the ever-evolving realm of software development, the only constant is the unpredictability of estimation..

The post Nobody knows how to estimate software projects appeared first on ProdSens.live.